Server component authentication method, apparatus, baseboard management controller, program product, and medium

Abstract

The application discloses a server component authentication method and device, a baseboard management controller, a program product and a medium, and relates to the technical field of server management. In order to solve the problems of large storage overhead, heavy maintenance and retrieval burden in related technologies, a plurality of root certificate authentication data and a reference hash-based message authentication code are obtained in a secure storage area. A certificate chain of a component to be authenticated is obtained to determine a root certificate, and a current root certificate hash value is calculated. A key prewritten in a one-time programmable memory is used to calculate a current hash-based message authentication code corresponding to each root certificate hash value. When the current hash-based message authentication code is consistent with the reference hash-based message authentication code, if the current root certificate hash value matches any root certificate hash value in each root certificate hash value, it is determined that the certificate source authentication of the component to be authenticated is passed. The storage overhead of authentication data is reduced, and the maintenance and retrieval burden of multiple certificates or certificate chains is reduced.

Description

Technical Field

[0001] This application relates to the field of server management technology, and in particular to a server component authentication method, apparatus, baseboard management controller, program product and medium. Background Technology

[0002] The baseboard management controller (BMC) typically acts as the requester of the Security Protocol and Data Model (SPDM) protocol, authenticating the identities of components such as RAID cards and network interface cards (NICs) within a server. Existing authentication methods generally require the BMC to pre-store certificate authority certificates or complete certificate chains from component manufacturers and verify the certificate chains returned by the components during authentication. However, components in a server may originate from multiple different manufacturers, and component manufacturers are often unwilling to accept certificates issued by server manufacturers. Furthermore, the lack of a unified root certificate management method forces the BMC to store certificates or complete certificate chains from multiple component manufacturers, consuming significant storage space and increasing the burden of certificate maintenance and retrieval. Therefore, how to achieve certificate source authentication for components by the BMC with lower storage overhead, without requiring the BMC to pre-store certificate authority certificates or complete certificate chains from multiple component manufacturers, becomes a technical problem that needs to be solved. Summary of the Invention

[0003] This application provides a server component authentication method, apparatus, baseboard management controller, program product, and medium to at least solve the problems of large storage overhead and heavy maintenance and retrieval burden caused by the pre-storing of multiple component manufacturers' certificate authority certificates or complete certificate chains in the related art.

[0004] This application provides a server component authentication method, applied to a baseboard management controller, including: Obtain multiple root certificate authentication data stored in the secure storage area and a base hash-based message authentication code corresponding to all root certificate hash values ​​in each of the root certificate authentication data, wherein each root certificate authentication data includes a root certificate hash value; Obtain the certificate chain of the component to be certified, and determine the root certificate of the component to be certified based on the certificate chain; Perform a hash calculation on the root certificate of the component to be authenticated to obtain the current root certificate hash value; Using the key pre-written in the one-time programmable memory of the baseboard management controller, the hash values ​​of each root certificate are calculated to obtain the current hash-based message authentication code; if the current hash-based message authentication code is consistent with the baseline hash-based message authentication code, the current root certificate hash value is matched with the root certificate hash value in each root certificate authentication data; if the current root certificate hash value matches any one of the certificate hash values, it is determined that the certificate source authentication of the component to be authenticated has passed.

[0005] This application also provides a server component authentication device, applied to a baseboard management controller, comprising: The first acquisition module is used to acquire multiple root certificate authentication data and a base hash-based message authentication code corresponding to all root certificate hash values ​​in each of the root certificate authentication data, which are pre-stored in the secure storage area. Each root certificate authentication data includes a root certificate hash value. The second acquisition module is used to acquire the certificate chain of the component to be certified and determine the root certificate of the component to be certified based on the certificate chain. The first calculation module is used to perform hash calculation on the root certificate of the component to be authenticated to obtain the current root certificate hash value; The second calculation module is used to calculate the hash value of each root certificate using the key pre-written in the one-time programmable memory of the baseboard management controller, so as to obtain the current hash-based message authentication code. The matching module is used to match the current root certificate hash value with the root certificate hash value in each root certificate authentication data when the current hash-based message authentication code is consistent with the baseline hash-based message authentication code. If the current root certificate hash value matches any one of the certificate hash values, the certificate source authentication of the component to be authenticated is determined to be successful.

[0006] This application also provides a baseboard management controller, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described server component authentication methods when executing the computer program.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described server component authentication methods.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described server component authentication methods.

[0009] As can be seen from the above technical solution, the beneficial effects of this application are as follows: This application provides a server component authentication method applied to a baseboard management controller, comprising: acquiring multiple root certificate authentication data and a base hash-based message authentication code corresponding to all root certificate hash values ​​in each root certificate authentication data, wherein each root certificate authentication data includes a root certificate hash value; acquiring the certificate chain of the component to be authenticated and determining the root certificate of the component to be authenticated based on the certificate chain; performing a hash calculation on the root certificate of the component to be authenticated to obtain the current root certificate hash value; using a key pre-written in the one-time programmable memory of the baseboard management controller to calculate the hash values ​​of each root certificate to obtain the current hash-based message authentication code; if the current hash-based message authentication code is consistent with the base hash-based message authentication code, matching the current root certificate hash value with the root certificate hash values ​​in each root certificate authentication data; if the current root certificate hash value matches any one of the certificate hash values, determining that the certificate source authentication of the component to be authenticated has passed.

[0010] Therefore, the baseboard management controller in this embodiment pre-stores the root certificate hash values ​​in the root certificate authentication data and saves the baseline hash-based message authentication code corresponding to all root certificate hash values. When authenticating a component to be authenticated, the root certificate is determined from the certificate chain returned by the component to be authenticated, and the current root certificate hash value corresponding to the root certificate is calculated. Before matching the root certificate hash values, the current hash-based message authentication code is calculated for all root certificate hash values ​​using a key pre-written in a one-time programmable memory, and compared with the baseline hash-based message authentication code. If the current hash-based message authentication code matches the baseline hash-based message authentication code, the current root certificate hash value is matched with the pre-stored root certificate hash values. Since the data volume of the root certificate hash value is usually smaller than that of the certificate authority certificate or the complete certificate chain, the baseboard management controller does not need to pre-store the certificate authority certificates or complete certificate chains of multiple component manufacturers. After the integrity verification of the certification benchmark data passes, it can determine whether the certificate source certification of the component to be certified has passed based on the matching result of the root certificate hash value. This reduces the risk of the root certificate hash value being modified and participating in the certification, reduces the storage overhead of certification data, and reduces the burden of maintaining and retrieving multiple certificates or certificate chains.

[0011] Furthermore, the present invention also provides a corresponding implementation device, a baseboard management controller, and a computer-readable storage medium for the server component authentication method, further making the method more practical, and the device, baseboard management controller, and computer-readable storage medium have corresponding advantages. Attached Figure Description

[0012] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 An architecture diagram of a component authentication system provided in this application embodiment; Figure 2 A flowchart illustrating a server component authentication method provided in this application embodiment; Figure 3 A flowchart illustrating a method for factory initialization and pre-setting root certificate authentication data, provided in an embodiment of this application; Figure 4 A flowchart illustrating a runtime component authentication method provided in this application embodiment; Figure 5 A flowchart illustrating a method for adding root certificate authentication data, as provided in this application embodiment; Figure 6 This is a structural diagram of a server component authentication device provided in an embodiment of this application. Detailed Implementation

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

[0015] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0016] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0017] It should be noted that as server architectures become increasingly complex and security threats continue to rise, the issue of authentication for internal server components is becoming increasingly prominent. Hardware-level security vulnerabilities such as Meltdown and Spectre demonstrate that security protection needs to extend to hardware components. Security protocols and data models are open standards managed by the Distributed Management Task Force (DMTF) to provide standardized authentication and secure communication for internal server components.

[0018] Currently, component manufacturers and processor manufacturers are promoting the application of SPDM in server platforms. The Baseboard Management Controller (BMC), as the server's management firmware, usually acts as the SPDM requester, responsible for initiating authentication for high-speed serial computer expansion bus (Peripheral Component Interconnect Express, PCIe) components, such as Redundant Array of Independent Disks (RAID) cards and network cards. However, in actual deployments, the SPDM authentication scheme still has the following problems.

[0019] One approach is for server vendors to issue Certificate Authority (CA) certificates to component vendors, and pre-configure these CA certificates in the BMC as the root of trust for authentication. During authentication, the pre-configured CA certificates are used to verify the certificate chain returned by the components. However, SPDM currently lacks a unified CA organization as the root certificate manager, and component vendors are typically unwilling to accept CA certificates issued by server vendors, making this approach difficult to deploy in practice.

[0020] Another approach is for component manufacturers to issue their own certificate chains, with the server storing multiple CA certificates or certificate chains and selecting the corresponding certificate chain for verification during authentication. However, with a large number of component manufacturers, storing multiple certificate chains will occupy a lot of BMC storage space, and certificate management will be more complex.

[0021] Another approach is to pre-install the BMC's identity certificate in the component's certificate slot. The component verifies the BMC certificate to confirm the pairing relationship between the BMC and the component, and prohibits component operation if authentication fails. This approach requires the component to authenticate the BMC, necessitates pre-installing the BMC certificate in the component, and it also poses a security risk if the component firmware is tampered with.

[0022] Therefore, existing SPDM authentication technology has at least the following shortcomings: traditional certificate chain verification methods have high storage overhead and a heavy burden of certificate maintenance and retrieval; they rely on component manufacturers to provide CA certificates, making deployment difficult when component manufacturers are unwilling to provide certificates, and also creating a strong dependency between server manufacturers and component manufacturers; the stored baseline data lacks integrity protection, and tampering with the baseline data may affect the authentication results; in operation and maintenance scenarios such as component replacement or firmware updates, the updating of baseline data lacks the corresponding security guarantees as the initial establishment process, which can easily introduce security risks.

[0023] Therefore, there is a need to provide an SPDM component authentication solution suitable for server BMC, which can reduce storage overhead and dependence on component manufacturer certificate systems, while protecting the integrity of authentication data, and supporting partition management of factory-pre-configured data and customer-added data, as well as secure updates in operation and maintenance scenarios such as component replacement and firmware updates.

[0024] To address the aforementioned issues, this application provides a server component authentication method. The baseboard management controller acquires pre-stored root certificate authentication data and a base hash-based message authentication code corresponding to all root certificate hash values ​​in the secure storage area. It then determines the root certificate from the certificate chain of the component to be authenticated and calculates the current root certificate hash value. Using a key pre-written in the baseboard management controller's one-time programmable memory, it calculates the current hash-based message authentication code for each root certificate hash value. If the current hash-based message authentication code matches the base hash-based message authentication code, the certificate source authentication result of the component to be authenticated is determined by matching the current root certificate hash value with the pre-stored root certificate hash value.

[0025] For ease of understanding, the system implementation environment used in the embodiments of this application is described below. For example... Figure 1 As shown, the system may include a baseboard management controller, multiple components to be certified, a security protocol and data model component module, a secure storage area, and an external interface module. The baseboard management controller and each component to be certified can transmit security protocol and data model (SPDM) messages via the Management Component Transport Protocol (MCTP). Components to be certified can be SPDM-enabled devices such as RAID cards and network cards connected to the high-speed serial computer expansion bus PCIe. The secure storage area can be located in the dedicated SPDM partition of an embedded multi-media card (eMMC) or in other non-volatile storage media.

[0026] The baseboard management controller, acting as the SPDM requester, is responsible for initiating SPDM authentication requests to the components to be authenticated, obtaining the certificate chain of the components to be authenticated, performing hash calculations on the root certificates, performing root certificate authentication data matching, and recording authentication results and alarm information. The baseboard management controller may also include a one-time programmable (OTP) memory, in which keys can be written during the baseboard management controller's production phase, and these keys cannot be modified after being written. The baseboard management controller can use this key to perform hash-based message authentication code (HMAC) calculations on all stored root certificate hash values ​​to verify the integrity of each root certificate hash value.

[0027] Each component to be authenticated, acting as an SPDM responder, can store one or more certificate chains. When a component to be authenticated receives a certificate chain retrieval request from the baseboard management controller, the component to be authenticated returns the corresponding certificate chain. When a challenge request including a random number is received, the component to be authenticated uses the private key corresponding to the public key of the certificate in the certificate chain to generate a signed response and returns it for the baseboard management controller to perform identity authentication.

[0028] The secure storage area may include a pre-configured area, a client area, and a backup area. The pre-configured area stores root certificate authentication data for each component to be authenticated, collected during the server's manufacturing process. After writing is complete, the pre-configured area can be set to read-only mode. The client area stores newly added root certificate authentication data authorized by the administrator, adapting to operational scenarios where components are replaced or root certificates change. The backup area stores backup data of the root certificate authentication data in the client area, for recovery in case the main file in the client area is damaged or missing. In this embodiment, the pre-configured area, client area, and backup area can be distinguished by different subdirectories, file permissions, or partition access control methods.

[0029] The external interface module provides functions such as enabling or disabling SPDM, querying component security status, updating component security, authorizing the addition of root certificate authentication data, and querying logs and alarms. The external interface module can include a web interface and a Redfish interface, allowing administrators to view the authentication status of components to be authenticated and submit authorization requests when a component is marked as having failed certificate source authentication.

[0030] This application embodiment provides the implementation conditions for the establishment of root certificate authentication data, component authentication, authentication data update and exception handling through the cooperation between the baseboard management controller, the component to be authenticated, the secure storage area and the external interface module.

[0031] The following section describes and introduces the technical solution of a server authentication component method provided in this application, based on the execution flow of the server component authentication method. Please refer to... Figure 2 The flowchart shown is a server component authentication method applied to a baseboard management controller, and the method includes the following steps S110 to S150.

[0032] S110: Obtain multiple root certificate authentication data stored in the secure storage area and the baseline hash-based message authentication code corresponding to all root certificate hash values ​​in each root certificate authentication data, wherein each root certificate authentication data includes a root certificate hash value.

[0033] It should be noted that the baseboard management controller can pre-store multiple root certificate authentication data and corresponding base hash-based message authentication codes for all root certificate hash values ​​in the secure storage area. The base hash-based message authentication codes are calculated using a key pre-written in the baseboard management controller's one-time programmable memory, applying the root certificate hash values ​​from all root certificate authentication data stored in the secure storage area. This secure storage area can be a dedicated partition for the embedded multimedia card allocated by the baseboard management controller, or other non-volatile storage areas. The baseboard management controller can access the secure storage area via its internal bus to read the pre-stored root certificate authentication data and corresponding base hash-based message authentication codes.

[0034] In practical applications, the root certificate hash value in each root certificate authentication data is obtained by hashing the corresponding root certificate and is used to represent that root certificate. Each root certificate hash value can correspond to a different root certificate, so that the baseboard management controller can store the authentication data of multiple confirmed root certificates. In the embodiments of this application, the baseboard management controller obtains the root certificate hash value and the corresponding baseline hash-based message authentication code in each root certificate authentication data, as data for subsequent matching with the current root certificate hash value corresponding to the component to be authenticated.

[0035] It is understood that, in this embodiment of the application, by pre-storing the hash values ​​of each root certificate and the corresponding base hash-based message authentication code, the baseboard management controller does not need to pre-store the complete certificate chain or certificate authority certificate, which can reduce the amount of authentication data stored.

[0036] S120: Obtain the certificate chain of the component to be certified, and determine the root certificate of the component to be certified based on the certificate chain.

[0037] It should be noted that the component to be certified can be a high-speed serial computer expansion bus component in the server that supports security protocols and data model protocols, such as an RAID card or network card. The baseboard management controller, as the requester of the security protocols and data model protocols, can exchange security protocol and data model messages with the component to be certified according to the communication methods described in the system implementation environment above.

[0038] In this embodiment, when the baseboard management controller obtains the certificate chain of the component to be certified, it can send a certificate chain acquisition request to the component to be certified through a security protocol and a data model protocol, and obtain the certificate chain returned by the component to be certified. This certificate chain may include leaf certificates, intermediate certificates, and root certificates. The baseboard management controller can determine the root certificate as the trust anchor point of the certificate chain based on the signing relationship between the certificates in the certificate chain. For example, the baseboard management controller can determine a certificate not issued by other certificates in the certificate chain as the root certificate.

[0039] S130: Perform a hash calculation on the root certificate of the component to be authenticated to obtain the current root certificate hash value.

[0040] It should be noted that, in this embodiment of the application, the baseboard management controller may use the hash algorithm used when generating root certificate authentication data in the secure storage area to perform hash calculation on the root certificate of the component to be authenticated, and obtain the current root certificate hash value. The current root certificate hash value is used to represent the root certificate corresponding to the certificate chain obtained this time.

[0041] In practical applications, using the same hash algorithm ensures that the current root certificate hash value and the root certificate hash value pre-stored in the secure storage area are calculated in the same way, thus enabling subsequent matching.

[0042] S140: Using the key pre-written in the one-time programmable memory of the baseboard management controller, calculate the hash value of each root certificate to obtain the current hash-based message authentication code.

[0043] It should be noted that, in this embodiment of the application, before performing root certificate hash value matching, the baseboard management controller can use the key pre-written in the one-time programmable memory to calculate the hash values ​​of all root certificates participating in authentication in the secure storage area, obtain the current hash-based message authentication code, and compare the current hash-based message authentication code with the benchmark hash-based message authentication code.

[0044] S150: If the current hash-based message authentication code is consistent with the baseline hash-based message authentication code, match the current root certificate hash value with the root certificate hash values ​​in each root certificate authentication data. If the current root certificate hash value matches any one of the certificate hash values, determine that the certificate source authentication of the component to be authenticated has passed.

[0045] It should be noted that when the comparison result between the current hash-based message authentication code and the benchmark hash-based message authentication code is consistent, the baseboard management controller will match the current root certificate hash value with the root certificate hash values ​​included in the root certificate authentication data in the secure storage area. For example, it can match them sequentially according to the storage order of the root certificate authentication data; when the root certificate hash values ​​are arranged in a preset order, a binary search method can also be used for matching.

[0046] It is understandable that when the current root certificate hash value is the same as the root certificate hash value in any of the certificate authentication data, it means that the root certificate corresponding to the current certificate chain is consistent with the root certificate corresponding to the pre-established root certificate authentication data, and the baseboard management controller determines that the certificate source authentication of the component to be authenticated has passed.

[0047] In this embodiment, when the current hash-based message authentication code is consistent with the baseline hash-based message authentication code, the current root certificate hash value is matched with the pre-stored root certificate hash value. The baseboard management controller does not need to store certificate authority certificates or complete certificate chains from multiple component manufacturers to complete the certificate source authentication of the component to be authenticated, thereby reducing the amount of authentication data storage and reducing the risk of the authentication baseline data being modified and participating in the authentication.

[0048] Therefore, the baseboard management controller in this embodiment pre-stores the root certificate hash values ​​in the root certificate authentication data and saves the baseline hash-based message authentication code corresponding to all root certificate hash values. When authenticating a component to be authenticated, the root certificate is determined from the certificate chain returned by the component to be authenticated, and the current root certificate hash value corresponding to the root certificate is calculated. Before matching the root certificate hash values, the current hash-based message authentication code is calculated for all root certificate hash values ​​using a key pre-written in a one-time programmable memory, and compared with the baseline hash-based message authentication code. If the current hash-based message authentication code matches the baseline hash-based message authentication code, the current root certificate hash value is matched with the pre-stored root certificate hash values. Since the data volume of the root certificate hash value is usually smaller than that of the certificate authority certificate or the complete certificate chain, the baseboard management controller does not need to pre-store the certificate authority certificates or complete certificate chains of multiple component manufacturers. After the integrity verification of the certification benchmark data passes, it can determine whether the certificate source certification of the component to be certified has passed based on the matching result of the root certificate hash value. This reduces the risk of the root certificate hash value being modified and participating in the certification, reduces the storage overhead of certification data, and reduces the burden of maintaining and retrieving multiple certificates or certificate chains.

[0049] In one implementation, the secure storage area includes a preset area, a client area, and a backup area; wherein, the preset area is used to store the root certificate authentication data corresponding to each component when the server leaves the factory, the client area is used to store the root certificate authentication data added after the component is replaced, and the backup area is used to store backup data of the root certificate authentication data in the client area.

[0050] It should be noted that the preset area, client area, and backup area in this application embodiment can correspond to different subdirectories, different files, or different storage partitions in the secure storage area, and can be distinguished by different file permissions or partition access control methods. Specifically, the root certificate authentication data in the preset area can be written during the server's factory manufacturing process and set to read-only status after writing; the root certificate authentication data in the client area can be written after receiving an authorization addition request; the backup area can store backup data of the client area's main file to provide recovery data when the client area's main file is missing or meets preset recovery conditions.

[0051] For example, the secure storage area can adopt the following directory structure: the root directory is / spdm / , under which there are three subdirectories: preset / , main / and backup / ; the preset / subdirectory stores the preset hash file preset.bin, which is a read-only binary file; the main / subdirectory stores the client hash file main.bin, which is a read-write binary file; and the backup / subdirectory stores the client area backup file cust.bin.backup.

[0052] Therefore, the process in S150 above, which matches the current root certificate hash value with the root certificate hash values ​​in the authentication data of each root certificate, and determines that the certificate source authentication of the component to be authenticated has passed when the current root certificate hash value matches any root certificate hash value, may include: Match the current root certificate hash value with the root certificate authentication data in the preset area; If no root certificate authentication data matching the current root certificate hash value exists in the preset area, the current root certificate hash value will be matched with the root certificate authentication data in the client area. If root certificate authentication data matching the current root certificate hash value exists in the preset area or client area, the certificate source authentication of the component to be authenticated is determined to be successful.

[0053] It is understood that, in the embodiments of this application, when performing certificate source authentication, the baseboard management controller may first match the current root certificate hash value with the root certificate authentication data in the preset area. If there is no matching root certificate authentication data in the preset area, the baseboard management controller will then match the current root certificate hash value with the root certificate authentication data in the client area. If the current root certificate hash value is successfully matched in the preset area or the client area, the baseboard management controller can determine that the certificate source authentication of the component to be authenticated has passed.

[0054] Therefore, this embodiment saves the root certificate authentication data established during the factory stage and the root certificate authentication data added in subsequent authorizations separately, and sets up backup data for the customer area. This not only supports authentication after component replacement, but also facilitates the management and recovery of authentication data from different sources.

[0055] In one implementation, the preset area is further used to store a first base-based hash-based message authentication code corresponding to the root certificate authentication data of each component at the time of manufacture; the client area is further used to store a second base-based hash-based message authentication code corresponding to all newly added root certificate authentication data.

[0056] It should be noted that the first benchmark hash-based message authentication code in this application embodiment is calculated based on the root certificate hash value in all root certificate authentication data stored in the preset area. Correspondingly, the second benchmark hash-based message authentication code is calculated based on the root certificate hash value in all root certificate authentication data stored in the client area.

[0057] Understandably, during the server's manufacturing process, after the root certificate authentication data for each component to be authenticated is written to the preset area, the baseboard management controller uses a key pre-written in a one-time programmable memory to calculate the root certificate hash value of all root certificate authentication data in the preset area, obtaining a first baseline hash-based message authentication code, and saving the first baseline hash-based message authentication code to the preset area. After the customer administrator authorizes the addition of new root certificate authentication data, the baseboard management controller uses this key to calculate the root certificate hash value of all root certificate authentication data in the updated customer area, obtaining a second baseline hash-based message authentication code, and updating the original second baseline hash-based message authentication code in the customer area with the new second baseline hash-based message authentication code.

[0058] In this embodiment of the application, in order to ensure that the same set of root certificate hash values ​​obtain the same calculation result at different authentication times, the baseboard management controller can combine the root certificate hash values ​​in the same area in a preset order and then perform the calculation. The preset order can be the order of root certificate hash values ​​from smallest to largest, or it can be the storage order of root certificate authentication data in the corresponding storage area.

[0059] Therefore, the process in S140 above, which uses the key pre-written in the one-time programmable memory of the baseboard management controller to calculate the hash value of each root certificate to obtain the current hash-based message authentication code, may include: The first current hash-based message authentication code is obtained by calculating the root certificate hash value of all root certificate authentication data in the preset area using the key pre-written in the one-time programmable memory of the baseboard management controller. The root certificate hash value of all root certificate authentication data in the client area is calculated using the key pre-written in the one-time programmable memory of the baseboard management controller to obtain the second current hash-based message authentication code.

[0060] It should be noted that before performing the current root certificate hash value matching, the baseboard management controller uses a key pre-written in the one-time programmable memory to calculate the hash-based message authentication code for all root certificate hash values ​​stored in the preset area and the client area. That is, a first current hash-based message authentication code is calculated based on all root certificate hash values ​​in the preset area, and a second current hash-based message authentication code is calculated based on all root certificate hash values ​​in the client area. The first current hash-based message authentication code and the second current hash-based message authentication code are respectively used to compare with the corresponding baseline hash-based message authentication codes pre-stored in the preset area and the client area to verify the integrity of the root certificate authentication data in the corresponding area.

[0061] In one implementation, the process of matching the current root certificate hash value with the root certificate hash values ​​in each root certificate authentication data, when the current hash-based message authentication code matches the baseline hash-based message authentication code, may include: Compare the first current hash-based message authentication code with the first benchmark hash-based message authentication code; If the first current hash-based message authentication code is consistent with the first benchmark hash-based message authentication code, the second current hash-based message authentication code is compared with the second benchmark hash-based message authentication code. If the second current hash-based message authentication code matches the second baseline hash-based message authentication code, the current root certificate hash value is matched with the root certificate hash values ​​in each root certificate authentication data.

[0062] It should be noted that the baseboard management controller can compare the first current hash-based message authentication code with the first baseline hash-based message authentication code; if the comparison result indicates that the two are consistent, it then compares the second current hash-based message authentication code with the second baseline hash-based message authentication code. In this embodiment, when both comparison results are consistent, it is determined that the root certificate hash value stored in the preset area and the client area has not undergone unauthorized changes, and then the current root certificate hash value is further matched with the root certificate hash values ​​in the preset area and the client area.

[0063] When the first current hash-based message authentication code is inconsistent with the first baseline hash-based message authentication code, or when the second current hash-based message authentication code is inconsistent with the second baseline hash-based message authentication code, the baseboard management controller records the security log and outputs alarm information, and does not perform subsequent current root certificate hash value matching processing.

[0064] Therefore, this embodiment utilizes the key in the one-time programmable memory to calculate the current hash-based message authentication code for all root certificate hash values ​​in the preset area and the client area, and compares it with the corresponding baseline hash-based message authentication code. Even if an attacker modifies one or more root certificate hash values ​​in the secure storage area, it is difficult to construct a valid hash-based message authentication code corresponding to the modified hash value set without knowing the key, thereby reducing the risk of unregistered root certificates passing the matching by tampering with authentication data; and while retaining the partition management method of factory authentication data and customer-added authentication data, it reduces the risk of root certificate hash values ​​in any area being modified and participating in certificate source authentication.

[0065] In one implementation, the key pre-written in the one-time programmable memory is written during the production stage of the baseboard management controller and cannot be modified after being written.

[0066] It should be noted that the one-time programmable memory in this embodiment only allows one write operation, and the saved key remains unchanged after the write is completed.

[0067] In other words, the same baseboard management controller can use a key stored in a one-time programmable memory to calculate hash-based message authentication codes for all root certificate hash values ​​in the preset area and all root certificate hash values ​​in the client area, respectively. The hash-based message authentication codes corresponding to different storage areas can be different, but they are all calculated based on the key stored in the one-time programmable memory of the baseboard management controller.

[0068] Therefore, in this embodiment of the application, the key is written into a one-time programmable memory during the production stage of the baseboard management controller, and the key cannot be modified after it is written. This reduces the risk that the message authentication code calculation result will become invalid after the key is replaced, and maintains the consistency of the basis for the message authentication code calculation.

[0069] In one embodiment, the method may further include: During the first startup after the server is fully assembled, enumerate all the components in the server that need to be authenticated. Obtain the certificate chain of each component to be certified, and determine the root certificate of each component to be certified based on the certificate chain of each component to be certified; Hash calculation is performed on the root certificate of each component to be certified to obtain the root certificate hash value corresponding to each component to be certified. The first benchmark for calculating the hash value of each root certificate is a message authentication code based on the hash of the key pre-written in the one-time programmable memory of the baseboard management controller. Based on the hash values ​​of each root certificate, obtain the root certificate authentication data for each component to be authenticated; Store the root certificate authentication data of each component to be authenticated and the first benchmark hash-based message authentication code in the preset area.

[0070] It should be noted that after the server is assembled in the factory, all server components are assumed to be in a safe state during production. Figure 3 As shown, during the first startup after the server is assembled, the baseboard management controller can enumerate each component in the server to be certified, such as RAID cards, network cards and other PCIe components that support SPDM.

[0071] The baseboard management controller sequentially sends SPDM commands to each PCIe component to read the certificate chain of each PCIe component and parse out the root certificate of each PCIe component. Then, the baseboard management controller performs hash calculation on each root certificate to obtain the root certificate hash value corresponding to each component to be certified.

[0072] Furthermore, the baseboard management controller uses a key pre-written in the one-time programmable memory (OTP) to calculate the root certificate hash value of all root certificate authentication data in the preset area, obtaining a first baseline hash-based message authentication code. The baseboard management controller obtains the root certificate authentication data for each component to be authenticated based on the root certificate hash value and stores the root certificate authentication data in the preset area. The hash data in this root certificate authentication data may include the root certificate hash value and the hash algorithm used to calculate that hash value.

[0073] As can be seen, during the first startup after the server is assembled, the root certificate authentication data is automatically established based on the actual assembled components to be certified and written into the preset area. This allows the authentication benchmark data established during the manufacturing phase to be used directly for matching during the operation phase, reducing the work of manually entering the authentication benchmark data item by item.

[0074] In one implementation, after storing the root certificate authentication data of each component to be authenticated and the first baseline hash-based message authentication code in the preset area, the method further includes: Set the preset area to read-only mode.

[0075] It should be noted that after storing the root certificate authentication data and the first baseline hash-based message authentication code in the preset area, the baseboard management controller can set the preset area to read-only mode. For example, read-only permissions can be configured for the files or storage partitions corresponding to the preset area, preventing regular write or deletion requests after the factory write is completed. For example, the file permissions of the preset area can be set to read-only (chmod 444), preventing any process from modifying or deleting the root certificate authentication data in that area.

[0076] For example, when the server performs a factory reset operation, the authentication data in the client area can be initialized, while the preset area remains read-only and continues to store the root certificate authentication data written during the factory reset.

[0077] Additionally, it should be noted that after the server is put into use, root certificate authentication data generated by component replacement, component firmware updates, or customer-authorized addition of components can be stored in the customer area and backed up to the backup area; the default area remains in a read-only state.

[0078] It is understood that, in this embodiment of the application, after writing the authentication data of each root certificate and the first base message authentication code based on hash, the preset area is set to read-only state, which can restrict the regular write and delete operations of the factory authentication base data in the preset area and reduce the risk of the factory authentication base data being modified; at the same time, by storing the authentication data added during operation and maintenance in the customer area, the factory authentication base data and the authentication data added during operation and maintenance are isolated from each other.

[0079] In one embodiment, the process of obtaining the certificate chain of the component to be authenticated in S120 above may include: Send a certificate chain information retrieval request to the component to be certified, and obtain the configured certificate slot information returned by the component to be certified; Determine the target certificate slot based on the configured certificate slot information; Send a certificate chain retrieval request carrying the target certificate slot identifier to the component to be certified in order to obtain the certificate chain corresponding to the target certificate slot.

[0080] It should be noted that, as Figure 4 As shown, during the authentication process of the component to be authenticated by the baseboard management controller, the baseboard management controller can send a certificate chain information retrieval request to the component to be authenticated through the management component transmission protocol. For example, the certificate chain information retrieval request can be a GET_DIGESTS digest request. In response to the certificate chain information retrieval request, the component to be authenticated returns the configured certificate slot information; the configured certificate slot information indicates the certificate slot in the component to be authenticated that has a configured certificate chain. The baseboard management controller determines the target certificate slot based on the configured certificate slot information and sends a certificate chain retrieval request carrying the target certificate slot identifier to the component to be authenticated to obtain the certificate chain corresponding to the target certificate slot.

[0081] Furthermore, the baseboard management controller determines the target certificate slot based on the configured certificate slot information. For example, the baseboard management controller can determine the default configured certificate slot as the target certificate slot, or it can determine the pre-specified configured certificate slot as the target certificate slot.

[0082] Understandably, after determining the target certificate slot, the baseboard management controller sends a certificate chain acquisition request carrying the target certificate slot identifier to the component to be certified, such as a certificate acquisition request GET_CERTIFICATE, to obtain the certificate chain corresponding to the target certificate slot. After obtaining the complete certificate chain, the baseboard management controller determines the root certificate based on the signing relationship between the certificates in the certificate chain.

[0083] It should also be noted that in practical applications, when the certificate chain length exceeds the data length that can be transmitted in a single communication, the baseboard management controller can obtain the complete certificate chain through multiple certificate chain acquisition requests.

[0084] Therefore, this embodiment of the application can obtain the certificate chain according to the specified certificate slot by first obtaining the configured certificate slot information, then determining the target certificate slot and obtaining the corresponding certificate chain, which is applicable to the case where the component to be certified is configured with multiple certificate slots.

[0085] In one application scenario, the aforementioned authentication process during the operational phase can be applied to a situation where, after the server product is delivered to the customer, the client starts up the server, and the baseboard management controller authenticates the various components within the server. In this scenario, the baseboard management controller needs to verify whether all components within the server are in a secure state.

[0086] In one implementation, after determining that the certificate source of the component to be certified has been verified, the method may further include: Send a challenge request, including a random number, to the component to be authenticated to verify whether the component to be authenticated holds a private key corresponding to the public key of the leaf certificate in the certificate chain; Receive the signature response returned by the component to be authenticated, and verify the signature in the signature response based on the random number and the public key of the leaf certificate in the certificate chain; If the signature verification is successful, the part to be authenticated is determined to have passed the identity authentication, and the part to be authenticated is marked as having passed the identity authentication.

[0087] It should be noted that, in this embodiment of the application, after the certificate source of the component to be certified is verified, the substrate management controller can send a challenge request (i.e., a CHALLENGE request) including a random number to the component to be certified. The random number is generated by the substrate management controller and is used to distinguish the current challenge request from previous challenge requests.

[0088] Understandably, after receiving the challenge request, the component to be authenticated uses the private key corresponding to the public key of the leaf certificate in the certificate chain to generate a signed response for the data including the random number, and then returns the signed response to the baseboard management controller. Upon receiving the signed response, the baseboard management controller verifies the signature in the signed response based on the random number and the public key of the leaf certificate. If the signature verification is successful, the baseboard management controller can determine that the component to be authenticated holds the private key corresponding to the public key of the leaf certificate, thereby determining that the component to be authenticated has passed authentication and marking the component as successfully authenticated.

[0089] Therefore, this application embodiment can verify whether the component to be authenticated holds the private key corresponding to the public key of the leaf certificate by using a challenge request containing a random number and signature verification, thereby reducing the possibility that an object that only obtains the certificate chain but does not hold the corresponding private key can pass the identity authentication; the random number can reduce the possibility of directly reusing the previous signature response.

[0090] In one implementation, after sending a challenge request including a random number to the component to be authenticated, the method further includes: If the signature verification fails, or if the component to be certified does not return a signature response within a preset time, a challenge request including a random number will be resent to the component to be certified. If the signature verification still fails or the component to be authenticated still does not return a signature response after the signature verification request has been resent a preset number of times, the component to be authenticated will be marked as having failed authentication and the security log will be logged.

[0091] Understandably, if the signature verification fails, or the component to be certified does not return a signature response within a preset time period, the board management controller can resend a challenge request including a random number to the component to be certified. Each time the challenge request is resent, a newly generated random number can be used.

[0092] If, after resending the challenge request a preset number of times, the signature verification still fails or the component to be authenticated still does not return a signature response, the baseboard management controller can determine that the authentication of the component to be authenticated has failed, mark the component to be authenticated as having failed authentication, and record the information in the security log. The security log in this embodiment may include information such as the component identifier, challenge request time, number of retries, and authentication failure status.

[0093] Therefore, the embodiments of this application allow for a limited number of retries when the challenge request fails, which can eliminate accidental communication failures to a certain extent. At the same time, it can accurately identify insecure components when multiple retries still fail, and record the authentication results when it continues to fail, which is convenient for subsequent investigation.

[0094] In one embodiment, the method may further include: If no root certificate authentication data matching the current root certificate hash value exists in either the preset area or the client area, the certificate source authentication of the component to be authenticated is determined to be unsuccessful. Mark the component to be certified as having failed certificate source authentication, and record the corresponding security log and output alarm information for the component to be certified.

[0095] Understandably, when the current root certificate hash value does not match the root certificate authentication data in the preset area, nor does it match the root certificate authentication data in the client area, the baseboard management controller can determine that the certificate source authentication of the component to be authenticated has failed and mark the component to be authenticated as having failed certificate source authentication.

[0096] Furthermore, the baseboard management controller records security logs corresponding to the components to be certified and outputs alarm information. The security logs may include the component identifier, certification time, current root certificate hash value, and certificate source certification failure status. The certification results can be displayed through the aforementioned administrator interface, displaying the component name, certificate source certification status, and alarm information. In practical applications, the certification results can be displayed to the administrator via a web interface and a Redfish interface.

[0097] Therefore, in this embodiment of the application, the component to be certified that does not match the root certificate authentication data is marked as having failed certificate source authentication, which makes it easier for the administrator to discover components that need further verification or authorization, so that the administrator can promptly discover and handle insecure components.

[0098] In one embodiment, the method may further include: If the part to be certified is marked as having failed certificate source authentication, receive a new authorization request for the part to be certified; In response to an authorization request, the component to be authenticated is treated as a new component to be authenticated, and the current root certificate hash value of the new component to be authenticated is obtained; The new root certificate authentication data is obtained based on the current root certificate hash value of the newly added component to be authenticated, and the new root certificate authentication data is stored in the client area; Using the key pre-written in the one-time programmable memory of the baseboard management controller, the root certificate hash value in all root certificate authentication data in the client area is calculated to obtain a new second benchmark hash-based message authentication code; The previous second-benchmark hash-based message authentication code in the client area is updated using a new second-benchmark hash-based message authentication code. Back up the newly added root certificate authentication data and the updated second benchmark hash-based message authentication code to the backup area.

[0099] It should be noted that, as Figure 5 As shown in this embodiment, when a component replacement or firmware update causes a change in the root certificate, resulting in the component to be certified being marked as having failed certificate source authentication, the baseboard management controller can provide an authorization entry through a web interface. After authorization by the administrator, new baseline data can be generated and stored. For example, the administrator can submit a new authorization request for the component to be certified through the administrator operation interface (i.e., the authorization entry). The failure of certificate source authentication can occur after component replacement or after a firmware update causes a change in the root certificate.

[0100] in, Figure 5 The document also illustrates the process of re-acquiring the certificate chain of the newly added component to be authenticated and obtaining the current root certificate hash value after receiving an authorization request. It then performs a challenge signature verification on the newly added component. If the signature verification passes and the remaining storage capacity in the client area meets the storage requirements, it generates new root certificate authentication data and writes this data to the client area and backs it up to the backup area. The specific processing steps for re-acquiring the certificate chain, challenging signature verification, determining client area capacity, and updating the client area and backup area are performed according to the corresponding methods in subsequent embodiments, and will not be repeated here.

[0101] Upon receiving an authorization request, the baseboard management controller can identify the component to be certified as a new component and obtain its current root certificate hash value. Based on this hash value, it retrieves the new root certificate authentication data and stores it in the client area. The baseboard management controller then uses a pre-written key in a one-time programmable memory to calculate the root certificate hash values ​​of all root certificate authentication data in the client area, obtaining a new second-base-based hash message authentication code. This new code updates the previous second-base-based hash message authentication code in the client area. Finally, the newly added root certificate authentication data and the updated second-base-based hash message authentication code are backed up to the backup area.

[0102] It is understood that, in this embodiment of the application, after the authentication of the certificate source of the component to be authenticated fails, the new root certificate authentication data is generated and written in response to the authorization addition request. After the data in the client area is updated, a new second base hash-based message authentication code is generated again based on the hash values ​​of all root certificates in the client area, and the second base hash-based message authentication codes stored in the client area and the backup area are updated respectively, thereby supporting the addition, integrity verification and backup of authentication base data in the scenario of component replacement or root certificate change.

[0103] In one implementation, the process of obtaining the current root certificate hash value of the newly added component to be authenticated may include: Reacquire the certificate chain of the newly added component to be certified, and determine the root certificate of the newly added component to be certified based on the reacquired certificate chain; Perform a hash calculation on the root certificate of the newly added component to be certified to obtain the current root certificate hash value of the newly added component to be certified; It should be noted that in the case of newly authorized scenarios, the baseboard management controller re-acquires the certificate chain of the newly added component to be certified, determines the root certificate of the newly added component to be certified based on the re-acquired certificate chain, and then performs a hash calculation on the root certificate to obtain the current root certificate hash value of the newly added component to be certified.

[0104] Therefore, before storing the newly added root certificate authentication data in the client area as described above, the method may further include: Send a challenge request, including a random number, to the newly added component to be certified; Receive the signature response returned by the newly added component to be certified, and verify the signature in the signature response based on the random number and the public key of the leaf certificate in the re-acquired certificate chain; If the signature verification passes, proceed with the step of storing the newly added root certificate authentication data in the client area.

[0105] Understandably, before storing the newly added root certificate authentication data in the client area, the baseboard management controller sends a challenge request including a random number to the newly added component to be authenticated, and receives a signature response from the component. Then, it further verifies the signature in the signature response based on the random number and the public key of the leaf certificate in the newly acquired certificate chain. If the signature verification passes, the baseboard management controller executes the step of storing the newly added root certificate authentication data in the client area, and calculates a new second-baseline hash-based message authentication code for all root certificate hash values ​​in the updated client area in the manner described above.

[0106] As can be seen, in this embodiment of the application, verifying whether the newly added component to be certified holds the private key corresponding to the leaf certificate public key before adding root certificate authentication data can reduce the possibility of components that cannot prove their private key holding status being added to the client area, and avoid writing the root certificate authentication data of untrusted components into the client area, thereby further improving the security of the client area baseline data.

[0107] In one implementation, the method may further include, before storing the newly added root certificate authentication data in the client area: Determine the remaining storage capacity in the customer area; If the remaining storage capacity is less than the storage capacity required for adding new root certificate authentication data, the new authorization request is rejected and an audit log is logged.

[0108] It should be noted that, in this embodiment, before storing the newly added root certificate authentication data in the client area, the baseboard management controller can first determine the remaining storage capacity of the client area and judge whether the remaining storage capacity is less than the storage capacity required for the newly added root certificate authentication data. If the remaining storage capacity is less than the storage capacity required for the newly added root certificate authentication data, the authorization request is rejected, and an audit log is recorded. The audit log may include the time of the authorization request, the identifier of the component to be authenticated, the storage capacity required for the newly added root certificate authentication data, the remaining storage capacity of the client area, and the reason for rejection. Additionally, the baseboard management controller can also return a storage capacity shortage warning message to the administrator's operation interface at this time.

[0109] In other words, the newly added root certificate authentication data will only be stored in the client area if the remaining storage capacity in the client area is greater than or equal to the storage capacity required for the newly added root certificate authentication data.

[0110] As can be seen, the embodiments of this application check the remaining storage capacity before writing new root certificate authentication data into the client area, and refuse to authorize new requests and record audit logs when the capacity is insufficient. This can reduce the risk that new authentication data cannot be completely written due to insufficient storage capacity, and retain the corresponding operation records.

[0111] In one implementation, the process of storing the newly added root certificate authentication data in the client area may include: Read the root certificate authentication data from the current master file in the client area and store the root certificate authentication data in memory to obtain the root certificate authentication data of the client area in memory; Add the newly added root certificate authentication data to the client area root certificate authentication data in memory, and sort all client area root certificate authentication data in ascending order of root certificate hash value; Write the sorted customer zone root certificate authentication data to a temporary file; After the temporary file is written, use the temporary file to replace the current main file in the client area to obtain the replaced main file; Then, the previous second-baseline hash-based message authentication code in the client area is updated using the new second-baseline hash-based message authentication code, including: Update the previous second benchmark hash-based message authentication code corresponding to the replaced master file in the client area to the new second benchmark hash-based message authentication code.

[0112] Understandably, when the client area has sufficient remaining storage capacity, the baseboard management controller can first copy all the root certificate authentication data currently stored in the client area (i.e., the client area root certificate authentication data) into memory, then add the newly added root certificate authentication data to the client area root certificate authentication data in memory, and sort all the client area root certificate authentication data in memory from smallest to largest according to the root certificate hash value. The sorted client area root certificate authentication data can be written to the temporary file corresponding to the client area main file.

[0113] After the temporary file is written, the baseboard management controller can use the temporary file to replace the current master file in the client area, thereby obtaining the replaced master file. Then, the new second base hash-based message authentication code is used to update the previous second base hash-based message authentication code corresponding to the replaced master file in the client area, that is, to update the previous second base hash-based message authentication code to the new second base hash-based message authentication code.

[0114] In this embodiment, by reading the client zone root certificate authentication data from the current main file, adding the new root certificate authentication data to memory and arranging it, writing it to a temporary file, and replacing the current main file after the temporary file is written, the risk of partial data writing when directly overwriting the current main file can be reduced. Furthermore, by updating the second base hash-based message authentication code corresponding to the replaced main file, the updated client zone root certificate authentication data is consistent with the corresponding base hash-based message authentication code.

[0115] In one implementation, backing up the newly added root certificate authentication data and the updated second baseline hash-based message authentication code to the backup area includes: A temporary backup file is generated based on the replaced master file in the client area, and the temporary backup file is used to replace the backup file in the backup area. The previous second-benchmark hash-based message authentication code corresponding to the backup file in the backup area is updated based on the updated second-benchmark hash-based message authentication code.

[0116] It should be noted that after the main file in the client area is replaced and the second baseline hash-based message authentication code is updated, the baseboard management controller generates a temporary backup file based on the replaced main file. This temporary backup file includes the updated client area root certificate authentication data. After the temporary backup file is written, it replaces the original backup file in the backup area.

[0117] Furthermore, the baseboard management controller uses the updated second-base hash-based message authentication code to update the original second-base hash-based message authentication code corresponding to the backup file, ensuring that the root certificate authentication data stored in the backup area corresponds to the second-base hash-based message authentication code. Thus, the backup area can store the updated authentication data and integrity verification data from the client area for recovery in case of client area master file corruption.

[0118] In one embodiment, the method may further include: If the main file in the client area is missing but the backup file in the backup area exists, the main file in the client area will be restored based on the backup file. If the master file exists in the client area but the backup file in the backup area is missing, generate the backup file in the backup area based on the master file in the client area. When both the main file in the client area and the backup file in the backup area are missing, generate empty client area root certificate authentication data, write the empty client area root certificate authentication data into the main file in the client area and the backup file in the backup area respectively, and record the initialization event. If both the main file in the client area and the backup file in the backup area exist, calculate the file hash values ​​of the main file and the backup file respectively. When the file hash value of the main file is inconsistent with the file hash value of the backup file, a security alarm is recorded. The key in the one-time programmable memory of the baseboard management controller is used to calculate the root certificate hash value of each root certificate authentication data in the main file and the backup file respectively, so as to obtain the current hash-based message authentication code corresponding to the main file and the current hash-based message authentication code corresponding to the backup file. The current hash-based message authentication code corresponding to the main file is verified using the previous second hash-based message authentication code corresponding to the main file. The current hash-based message authentication code corresponding to the backup file is verified using the previous second hash-based message authentication code corresponding to the backup file; If the current hash-based message authentication code of the main file fails to verify, but the current hash-based message authentication code of the backup file passes verification, restore the main file based on the backup file.

[0119] It should be noted that, in the embodiments of this application, the baseboard management controller can check the existence of the main file in the client area and the backup file in the backup area during the server startup phase or before reading the root certificate authentication data in the client area.

[0120] Understandably, when it is determined that the client area master file is missing in the client area but the backup file exists in the backup area, the baseboard management controller can restore the client area master file based on the backup file in the backup area; when the client area master file exists but the backup file is missing, the baseboard management controller can generate the backup file based on the client area master file; when both the client area master file and the backup file are missing, the baseboard management controller can generate empty client area root certificate authentication data and write the empty client area root certificate authentication data to the client area master file and the backup file respectively, while recording the initialization event. The empty client area root certificate authentication data may include a file header and the number of records indicating that root certificate authentication data is not currently saved.

[0121] In addition, when it is confirmed that both the main file and the backup file exist in the customer area, the baseboard management controller calculates the file hash values ​​of the main file and the backup file respectively. If the file hash value of the main file is inconsistent with the file hash value of the backup file, a security alarm is recorded. Then, the key in the one-time programmable memory is used to calculate the root certificate hash value of all root certificate authentication data stored in the main file and the backup file respectively, so as to obtain the current hash-based message authentication code corresponding to the main file and the current hash-based message authentication code corresponding to the backup file.

[0122] The baseboard management controller uses the previous second hash-based message authentication code corresponding to the main file to verify the current hash-based message authentication code corresponding to the main file, and uses the previous second hash-based message authentication code corresponding to the backup file to verify the current hash-based message authentication code corresponding to the backup file. If the current hash-based message authentication code of the main file fails verification but the current hash-based message authentication code of the backup file passes verification, the baseboard management controller can restore the main file based on the backup file. It should be noted that the different file hash values ​​of the main file and the backup file only indicate a difference in the content of the two files; the baseboard management controller determines whether the conditions for restoring the main file based on the backup file are met according to the hash-based message authentication code verification results.

[0123] Therefore, in this embodiment of the application, when the main file or backup file is missing, it can be recovered based on another file; when the two files are inconsistent and the conditions are met that the current hash-based message authentication code verification of the main file fails and the current hash-based message authentication code verification of the backup file passes, the backup file can be used as the basis for recovery, thereby improving the recoverability of customer area data.

[0124] In one embodiment, the method may further include: After the device to be certified completes the firmware update, the certificate chain of the device to be certified is re-acquired, and the root certificate of the device to be certified is determined based on the certificate chain. Perform a hash calculation on the root certificate of the component to be authenticated to obtain the current root certificate hash value; When the current root certificate hash value matches the root certificate hash value in any root certificate authentication data, the certificate source authentication of the component to be authenticated is determined to be successful. If the current root certificate hash does not match the root certificate hash in the root certificate authentication data, the component to be authenticated will be marked as having failed certificate source authentication.

[0125] It should be noted that when the firmware update in this embodiment does not cause a change in the root certificate, the recalculated current root certificate hash value can still match the pre-stored root certificate hash value, without the need to add new root certificate authentication data. When the firmware update causes a change in the root certificate, the baseboard management controller can display the certificate source authentication failure status through the administrator operation interface. The administrator can then submit an authorization addition request based on the actual situation and update the root certificate authentication data and the second base hash-based message authentication code in the client area according to the corresponding method in the above embodiment.

[0126] In one implementation, after a component is replaced, upon server startup, the baseboard management controller detects that the current root certificate hash value corresponding to the component does not match any of the root certificate hash values ​​stored in the preset area. If the component information and corresponding hash data are also stored in the client area, the current root certificate hash value corresponding to that component will also not match the hash data stored in the client area. At this point, the component is in an insecure state. Components in an insecure state can be displayed through a web interface. The hash data may include hash values ​​and hash algorithms. Clients can trigger a component replacement request by clicking the replacement option corresponding to the insecure component in the web interface. Upon receiving the replacement request, the baseboard management controller first verifies whether the files already stored in the client area are complete. If complete, it further checks whether the storage area in the client area is full. If the maximum storage space has been reached, the addition is rejected, and a message indicating that the storage area is full is returned.

[0127] It should be noted that the root certificate authentication data in this embodiment is based on the operational security process under the principle of non-migratable root of trust, including component updates and component replacement scenarios, and provides customer administrators with the function of self-approval and addition. That is, when a component firmware update or component replacement causes the certificate source authentication to fail, the customer administrator can initiate an authorization addition request through the management interface. After the baseboard management controller meets the authorization addition conditions, it will store the new root certificate authentication data in the customer area and back it up to the backup area, while the preset area remains in a read-only state.

[0128] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0129] Embodiments of this application also provide a server component authentication device, which is applied to a baseboard management controller, such as... Figure 6 As shown, the device includes: The first acquisition module 11 is used to acquire multiple root certificate authentication data stored in the secure storage area and the baseline hash-based message authentication code corresponding to all root certificate hash values ​​in each root certificate authentication data, wherein each root certificate authentication data includes a root certificate hash value. The second acquisition module 12 is used to acquire the certificate chain of the component to be certified and determine the root certificate of the component to be certified based on the certificate chain. The first calculation module 13 is used to perform hash calculation on the root certificate of the component to be authenticated to obtain the current root certificate hash value; The second calculation module 14 is used to calculate the hash value of each root certificate using the key pre-written in the one-time programmable memory of the baseboard management controller, and obtain the current hash-based message authentication code. The matching module 15 is used to match the current root certificate hash value with the root certificate hash value in each root certificate authentication data when the current hash-based message authentication code is consistent with the baseline hash-based message authentication code. If the current root certificate hash value matches any certificate hash value, the certificate source authentication of the component to be authenticated is determined to be successful.

[0130] In one implementation, the secure storage area includes a preset area, a client area, and a backup area; wherein, the preset area is used to store the root certificate authentication data corresponding to each component when the server leaves the factory, the client area is used to store the root certificate authentication data added after the component is replaced, and the backup area is used to store backup data of the root certificate authentication data in the client area. Matching module 15 includes: The first matching unit is used to match the current root certificate hash value with the root certificate authentication data in the preset area; The second matching unit is used to match the current root certificate hash value with the root certificate authentication data in the client area when there is no root certificate authentication data in the preset area that matches the current root certificate hash value. The first determining unit is used to determine that the certificate source authentication of the component to be authenticated has passed when root certificate authentication data matching the current root certificate hash value exists in the preset area or the client area.

[0131] In one implementation, the preset area is further used to store the first base-based hash message authentication code corresponding to the root certificate authentication data of each component at the time of manufacture; the client area is further used to store the second base-based hash message authentication code corresponding to all newly added root certificate authentication data. The second calculation module 14 includes: The first computing unit is used to calculate the root certificate hash value of all root certificate authentication data in the preset area using the key pre-written in the one-time programmable memory of the baseboard management controller, so as to obtain the first current hash-based message authentication code. The second calculation unit is used to calculate the root certificate hash value of all root certificate authentication data in the client area using the key pre-written in the one-time programmable memory of the baseboard management controller, so as to obtain the second current hash-based message authentication code.

[0132] In one implementation, the matching module 15 includes: The first comparison unit is used to compare the first current hash-based message authentication code with the first benchmark hash-based message authentication code. The second comparison unit is used to compare the second current hash-based message authentication code with the second benchmark hash-based message authentication code when the first current hash-based message authentication code is consistent with the first benchmark hash-based message authentication code. The third matching unit is used to match the current root certificate hash value with the root certificate hash value in each root certificate authentication data when the second current hash-based message authentication code is consistent with the second baseline hash-based message authentication code.

[0133] In one implementation, the key pre-written in the one-time programmable memory is written during the production stage of the baseboard management controller and cannot be modified after being written.

[0134] In one embodiment, the device further includes: The enumeration unit is used to enumerate the various components in the server to be authenticated during the first startup after the server has been assembled. The first acquisition unit is used to acquire the certificate chain of each component to be certified, and determine the root certificate of each component to be certified based on the certificate chain of each component to be certified. The third calculation unit is used to perform hash calculations on the root certificates of each component to be certified, and obtain the root certificate hash value corresponding to each component to be certified. The fourth computing unit is used to calculate the first benchmark hash-based message authentication code for each root certificate hash value based on the key pre-written in the one-time programmable memory of the baseboard management controller. The second determining unit is used to obtain the root certificate authentication data of each component to be authenticated based on the hash value of each root certificate. The first storage unit is used to store the root certificate authentication data of each component to be authenticated and the first baseline hash-based message authentication code in the preset area.

[0135] In one embodiment, the device may further include: The settings module is used to set the preset area to read-only mode.

[0136] In one embodiment, the second acquisition module 12 includes: The first sending unit is used to send a certificate chain information acquisition request to the component to be authenticated and to obtain the configured certificate slot information returned by the component to be authenticated. The third determining unit is used to determine the target certificate slot based on the configured certificate slot information; The second sending unit is used to send a certificate chain acquisition request carrying the target certificate slot identifier to the component to be certified, so as to obtain the certificate chain corresponding to the target certificate slot.

[0137] In one embodiment, the device may further include: The third sending unit is used to send a challenge request, including a random number, to the component to be authenticated in order to verify whether the component to be authenticated holds a private key corresponding to the public key of the leaf certificate in the certificate chain. The first receiving unit is used to receive the signature response returned by the component to be authenticated, and to verify the signature in the signature response based on the random number and the public key of the leaf certificate in the certificate chain. The fourth determining unit is used to determine that the component to be authenticated has passed identity authentication if the signature verification is successful, and to mark the component to be authenticated as having passed identity authentication.

[0138] In one embodiment, the device may further include: The fourth sending unit is used to resend a challenge request including a random number to the component to be authenticated if the signature verification fails or the component to be authenticated does not return a signature response within a preset time period. The first recording unit is used to mark the component to be authenticated as having failed authentication and to record the security log when the signature verification still fails or the component to be authenticated still does not return a signature response after resending the challenge request a preset number of times.

[0139] In one embodiment, the device may further include: The fifth determining unit is used to determine that the certificate source authentication of the component to be authenticated fails when there is no root certificate authentication data matching the current root certificate hash value in either the preset area or the client area. The second recording unit is used to mark the component to be certified as having failed certificate source authentication, and to record the security log and output alarm information corresponding to the component to be certified.

[0140] In one embodiment, the device may further include: The second receiving unit is used to receive an authorization new request for the part to be certified when the part to be certified is marked as having failed certificate source authentication. The second acquisition unit is used to respond to the authorization addition request, take the part to be authenticated as the new part to be authenticated, and obtain the current root certificate hash value of the new part to be authenticated; The second storage unit is used to obtain the new root certificate authentication data based on the current root certificate hash value of the newly added component to be authenticated, and to store the new root certificate authentication data in the client area; The fifth calculation unit is used to calculate the root certificate hash value in all root certificate authentication data in the client area using the key pre-written in the one-time programmable memory of the baseboard management controller, so as to obtain a new second benchmark hash-based message authentication code. The first update unit is used to update the previous second benchmark-based hash message authentication code in the client area using the new second benchmark-based hash message authentication code; The backup unit is used to back up the newly added root certificate authentication data and the updated second baseline hash-based message authentication code to the backup area.

[0141] In one embodiment, the second acquisition unit includes: The first acquisition subunit is used to reacquire the certificate chain of the newly added component to be certified, and determine the root certificate of the newly added component to be certified based on the reacquired certificate chain. The first calculation subunit is used to perform hash calculation on the root certificate of the newly added component to be certified, and obtain the current root certificate hash value of the newly added component to be certified; The first sending subunit is used to send a challenge request, including a random number, to the newly added component to be authenticated; The verification subunit is used to receive the signature response returned by the newly added component to be certified, and to verify the signature in the signature response based on the random number and the public key of the leaf certificate in the re-acquired certificate chain. The trigger sub-unit is used to trigger the second storage unit if the signature verification passes.

[0142] In one embodiment, the device may further include: The sixth determining unit is used to determine the remaining storage capacity of the customer area; The third recording unit is used to reject authorization requests and record audit logs when the remaining storage capacity is less than the storage capacity required for adding new root certificate authentication data.

[0143] In one embodiment, the second storage unit includes: The second acquisition subunit is used to read the root certificate authentication data from the current main file of the client area and store the root certificate authentication data in memory to obtain the client area root certificate authentication data in memory. The added sub-unit is used to add the newly added root certificate authentication data to the client area root certificate authentication data in memory, and to sort all client area root certificate authentication data in ascending order of root certificate hash value; The first write sub-unit is used to write the sorted client area root certificate authentication data to a temporary file; The first replacement subunit is used to replace the current main file in the client area with the temporary file after the temporary file is written, so as to obtain the replaced main file; The second update unit is specifically used to update the previous second benchmark hash-based message authentication code corresponding to the replaced master file in the client area to the new second benchmark hash-based message authentication code.

[0144] In one implementation, the backup unit includes: The backup subunit is used to generate a temporary backup file based on the replaced master file in the client area, and to replace the corresponding backup file in the backup area with the temporary backup file. The update subunit is used to update the previous second-benchmark hash-based message authentication code corresponding to the backup file in the backup area based on the updated second-benchmark hash-based message authentication code.

[0145] In one embodiment, the device may further include: The first recovery unit is used to recover the main file in the client area based on the backup file when the main file in the client area is missing but the backup file in the backup area exists. The first generation unit is used to generate a backup file for the backup area based on the main file of the client area when the main file exists in the client area but the backup file in the backup area is missing. The second generation unit is used to generate empty client area root certificate authentication data when both the main file in the client area and the backup file in the backup area are missing, and to write the empty client area root certificate authentication data into the main file in the client area and the backup file in the backup area respectively, and to record the initialization event. The sixth calculation unit is used to calculate the file hash values ​​of the main file and the backup file respectively when both the main file in the client area and the backup file in the backup area exist. The seventh calculation unit is used to record a security alarm when the file hash value of the main file is inconsistent with the file hash value of the backup file, and to use the key in the one-time programmable memory of the baseboard management controller to calculate the root certificate hash value of each root certificate authentication data in the main file and the backup file respectively, so as to obtain the current hash-based message authentication code corresponding to the main file and the current hash-based message authentication code corresponding to the backup file. The first verification unit is used to verify the current hash-based message authentication code corresponding to the main file by using the previous second hash-based message authentication code corresponding to the main file. The second verification unit is used to verify the current hash-based message authentication code corresponding to the backup file using the previous second hash-based message authentication code corresponding to the backup file. The second recovery unit is used to restore the main file based on the backup file if the current hash-based message authentication code of the main file fails to pass verification, while the current hash-based message authentication code of the backup file passes verification.

[0146] It should be noted that the description of the features of the server component authentication device provided in the embodiments of this application can be found in the relevant description of the server component authentication method, and will not be repeated here.

[0147] Embodiments of this application also provide a baseboard management controller, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the server component authentication method embodiments described above.

[0148] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the server component authentication method embodiments described above when running.

[0149] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0150] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the server component authentication method embodiments described above.

[0151] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the server component authentication method embodiments described above.

[0152] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0153] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0154] The foregoing has provided a detailed description of a server component authentication method, apparatus, baseboard management controller, program product, and medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A server component authentication method, characterized in that, Applications to baseboard management controllers include: Obtain multiple root certificate authentication data stored in a secure storage area and a base hash-based message authentication code corresponding to all root certificate hash values ​​in each of the root certificate authentication data, wherein each of the root certificate authentication data includes a root certificate hash value; Obtain the certificate chain of the component to be certified, and determine the root certificate of the component to be certified based on the certificate chain; Perform a hash calculation on the root certificate of the component to be authenticated to obtain the current root certificate hash value; Using a key pre-written in the one-time programmable memory of the baseboard management controller, the hash values ​​of each root certificate are calculated to obtain the current hash-based message authentication code. If the current hash-based message authentication code matches the baseline hash-based message authentication code, the current root certificate hash value is matched with the root certificate hash values ​​in each root certificate authentication data. If the current root certificate hash value matches any one of the certificate hash values, it is determined that the certificate source authentication of the component to be authenticated has passed.

2. The server component authentication method according to claim 1, characterized in that, The secure storage area includes a preset area, a client area, and a backup area; wherein, the preset area is used to store the root certificate authentication data corresponding to each component when the server leaves the factory, the client area is used to store the root certificate authentication data added after the component is replaced, and the backup area is used to store backup data of the root certificate authentication data in the client area. Matching the current root certificate hash value with the root certificate hash values ​​in each of the root certificate authentication data, and determining that the certificate source authentication of the component to be authenticated is successful if the current root certificate hash value matches any root certificate hash value, includes: Match the current root certificate hash value with the root certificate authentication data in the preset area; If no root certificate authentication data matching the current root certificate hash value exists in the preset area, the current root certificate hash value is matched with the root certificate authentication data in the client area. If root certificate authentication data matching the current root certificate hash value exists in the preset area or the client area, the certificate source authentication of the component to be authenticated is determined to be successful.

3. The server component authentication method according to claim 2, characterized in that, The preset area is also used to store the first base-based hash-based message authentication code corresponding to the root certificate authentication data of each component at the time of manufacture; the client area is also used to store the second base-based hash-based message authentication code corresponding to all newly added root certificate authentication data. The key pre-written in the one-time programmable memory of the baseboard management controller is used to calculate the hash value of each root certificate to obtain the current hash-based message authentication code, including: Using the key pre-written in the one-time programmable memory of the baseboard management controller, the root certificate hash value of all root certificate authentication data in the preset area is calculated to obtain the first current hash-based message authentication code; Using the key pre-written in the one-time programmable memory of the baseboard management controller, the root certificate hash value of all root certificate authentication data in the client area is calculated to obtain the second current hash-based message authentication code.

4. The server component authentication method according to claim 3, characterized in that, When the current hash-based message authentication code matches the baseline hash-based message authentication code, matching the current root certificate hash value with the root certificate hash values ​​in each of the root certificate authentication data includes: Compare the first current hash-based message authentication code with the first benchmark hash-based message authentication code; If the first current hash-based message authentication code is consistent with the first benchmark hash-based message authentication code, the second current hash-based message authentication code is compared with the second benchmark hash-based message authentication code. If the second current hash-based message authentication code is consistent with the second baseline hash-based message authentication code, the current root certificate hash value is matched with the root certificate hash values ​​in each of the root certificate authentication data.

5. The server component authentication method according to claim 3, characterized in that, Also includes: During the first startup after the server is fully assembled, enumerate each component in the server that needs to be authenticated. Obtain the certificate chain of each of the components to be certified, and determine the root certificate of each component to be certified based on the certificate chain of each component to be certified; Hash calculation is performed on the root certificates of each of the components to be authenticated to obtain the root certificate hash value corresponding to each component to be authenticated. A first benchmark hash-based message authentication code is used to calculate the hash value of each of the root certificates based on the key pre-written in the one-time programmable memory of the baseboard management controller. Based on the hash values ​​of each root certificate, the root certificate authentication data of each component to be authenticated is obtained; The root certificate authentication data of each of the components to be authenticated and the hash-based message authentication code of the first benchmark are stored in the preset area.

6. The server component authentication method according to claim 5, characterized in that, After storing the root certificate authentication data of each of the components to be authenticated and the first baseline hash-based message authentication code in the preset area, the method further includes: Set the preset area to read-only mode.

7. The server component authentication method according to claim 1, characterized in that, Obtain the certificate chain of the component to be certified, including: Send a certificate chain information retrieval request to the component to be certified, and obtain the configured certificate slot information returned by the component to be certified; Determine the target certificate slot based on the configured certificate slot information; Send a certificate chain retrieval request carrying the target certificate slot identifier to the component to be certified, so as to obtain the certificate chain corresponding to the target certificate slot.

8. The server component authentication method according to claim 1, characterized in that, After confirming that the certificate source of the component to be certified has been verified, the process also includes: A challenge request, including a random number, is sent to the component to be authenticated to verify whether the component to be authenticated holds a private key corresponding to the public key of the leaf certificate in the certificate chain; Receive the signature response returned by the component to be authenticated, and verify the signature in the signature response based on the random number and the public key of the leaf certificate in the certificate chain; If the signature verification is successful, the component to be authenticated is determined to have passed identity authentication, and the component to be authenticated is marked as having passed identity authentication.

9. The server component authentication method according to claim 8, characterized in that, After sending a challenge request including a random number to the component to be authenticated, the process also includes: If the signature verification fails, or if the component to be authenticated does not return a signature response within a preset time period, a challenge request including a random number will be resent to the component to be authenticated. If the signature verification still fails or the component to be authenticated still does not return a signature response after the challenge request has been resent a preset number of times, the component to be authenticated will be marked as having failed authentication and the security log will be recorded.

10. The server component authentication method according to claim 2, characterized in that, Also includes: If no root certificate authentication data matching the current root certificate hash value exists in either the preset area or the client area, the certificate source authentication of the component to be authenticated is determined to be unsuccessful. The component to be certified is marked as having failed certificate source authentication, and the security log corresponding to the component to be certified and the alarm information are recorded.

11. The server component authentication method according to claim 10, characterized in that, Also includes: If the component to be certified is marked as having failed certificate source authentication, a new authorization request is received for the component to be certified. In response to the authorization addition request, the component to be authenticated is selected as a new component to be authenticated, and the current root certificate hash value of the new component to be authenticated is obtained; The new root certificate authentication data is obtained based on the current root certificate hash value of the newly added component to be authenticated, and the new root certificate authentication data is stored in the client area; Using the key pre-written in the one-time programmable memory of the baseboard management controller, the root certificate hash value in all root certificate authentication data in the client area is calculated to obtain a new second benchmark hash-based message authentication code; The previous second-benchmark hash-based message authentication code in the client area is updated using the new second-benchmark hash-based message authentication code. The newly added root certificate authentication data and the updated second benchmark hash-based message authentication code are backed up to the backup area.

12. The server component authentication method according to claim 11, characterized in that, Obtaining the current root certificate hash value of the newly added component to be authenticated includes: Reacquire the certificate chain of the newly added component to be certified, and determine the root certificate of the newly added component to be certified based on the reacquired certificate chain; Perform a hash calculation on the root certificate of the newly added component to be authenticated to obtain the current root certificate hash value of the newly added component to be authenticated; Before storing the newly added root certificate authentication data in the client area, the method further includes: Send a challenge request, including a random number, to the newly added component to be authenticated; Receive the signature response returned by the newly added component to be authenticated, and verify the signature in the signature response based on the random number and the public key of the leaf certificate in the re-acquired certificate chain; If the signature verification passes, proceed with the step of storing the newly added root certificate authentication data in the client area.

13. The server component authentication method according to claim 11, characterized in that, Before storing the newly added root certificate authentication data in the client area, the method further includes: Determine the remaining storage capacity of the customer area; If the remaining storage capacity is less than the storage capacity required for adding new root certificate authentication data, the request to add the certificate is rejected and an audit log is recorded.

14. The server component authentication method according to claim 13, characterized in that, The newly added root certificate authentication data is stored in the client area, including: Read the root certificate authentication data from the current master file of the client area and store the root certificate authentication data in memory to obtain the client area root certificate authentication data in memory. The newly added root certificate authentication data is added to the client area root certificate authentication data in memory, and all client area root certificate authentication data are arranged in ascending order of root certificate hash value; Write the sorted customer zone root certificate authentication data to a temporary file; After the temporary file is written, use the temporary file to replace the current main file in the client area to obtain the replaced main file; Then, the previous second-baseline hash-based message authentication code of the client area is updated using the new second-baseline hash-based message authentication code, including: Update the previous second benchmark hash-based message authentication code corresponding to the replaced master file in the client area to the new second benchmark hash-based message authentication code.

15. The server component authentication method according to claim 14, characterized in that, The newly added root certificate authentication data and the updated second baseline hash-based message authentication code are backed up to the backup area, including: A temporary backup file is generated based on the replaced master file in the client area, and the temporary backup file is used to replace the corresponding backup file in the backup area. The previous second-benchmark hash-based message authentication code corresponding to the backup file in the backup area is updated based on the updated second-benchmark hash-based message authentication code.

16. The server component authentication method according to claim 13, characterized in that, Also includes: When the main file in the client area is missing but the backup file in the backup area exists, the main file in the client area is restored based on the backup file. When the master file in the client area exists and the backup file in the backup area is missing, the backup file in the backup area is generated based on the master file in the client area. When both the main file in the client area and the backup file in the backup area are missing, empty client area root certificate authentication data is generated, and the empty client area root certificate authentication data is written to the main file in the client area and the backup file in the backup area respectively, and an initialization event is recorded. When both the main file in the client area and the backup file in the backup area exist, calculate the file hash values ​​of the main file and the backup file respectively; When the file hash value of the main file is inconsistent with the file hash value of the backup file, a security alarm is recorded, and the root certificate hash values ​​of each root certificate authentication data in the main file and the backup file are calculated using the key in the one-time programmable memory of the baseboard management controller to obtain the current hash-based message authentication code corresponding to the main file and the current hash-based message authentication code corresponding to the backup file. The current hash-based message authentication code corresponding to the main file is verified using the previous second hash-based message authentication code corresponding to the main file; The current hash-based message authentication code corresponding to the backup file is verified using the previous second hash-based message authentication code corresponding to the backup file; If the current hash-based message authentication code of the main file fails to be verified, but the current hash-based message authentication code of the backup file passes the verification, the main file is restored based on the backup file.

17. A server component authentication device, characterized in that, Applications to baseboard management controllers include: The first acquisition module is used to acquire multiple root certificate authentication data and a base hash-based message authentication code corresponding to all root certificate hash values ​​in each of the root certificate authentication data, wherein each of the root certificate authentication data includes a root certificate hash value. The second acquisition module is used to acquire the certificate chain of the component to be certified, and determine the root certificate of the component to be certified based on the certificate chain; The first calculation module is used to perform hash calculation on the root certificate of the component to be authenticated to obtain the current root certificate hash value; The second calculation module is used to calculate the hash value of each root certificate using the key pre-written in the one-time programmable memory of the baseboard management controller, so as to obtain the current hash-based message authentication code. The matching module is used to match the current root certificate hash value with the root certificate hash values ​​in each of the root certificate authentication data when the current hash-based message authentication code is consistent with the baseline hash-based message authentication code. If the current root certificate hash value matches any one of the certificate hash values, the module determines that the certificate source authentication of the component to be authenticated has passed.

18. A baseboard management controller, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the server component authentication method as described in any one of claims 1 to 17 when executing the computer program.

19. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the server component authentication method as described in any one of claims 1 to 17.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the server component authentication method as described in any one of claims 1 to 17.

Images