Component verification methods, equipment, storage media, and program products

Abstract

This application provides a component verification method, device, storage medium, and program product, which can be applied to the field of computer technology. The component verification method includes: determining a target verification stage and corresponding target verification items for the component to be verified based on its verification priority; the target verification stage includes one of the following: a hardware initialization stage during hardware management component startup, a boot loading stage, or a firmware main program loading stage; during the target verification stage, matching the target verification items with a target device identifier and an identifier mapping relationship set, the identifier mapping relationship set including mapping relationships between multiple verification items and multiple device identifiers; if the matching is successful, reading the timing operation data of the component to be verified in the device, and matching the timing operation data with the standard component operation baseline of the device; if the matching passes, determining that the component to be verified has passed verification.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically to a component verification method, apparatus, storage medium, and program product. Background Technology

[0002] The problem of unauthorized parts is a significant factor affecting equipment quality, production processes, and after-sales service. The common method for identifying unauthorized parts is to use physical tags. However, this method is highly dependent on manual labor, has low identification efficiency, and low accuracy. Summary of the Invention

[0003] In view of the above problems, this application provides a component verification method, device, storage medium and program product.

[0004] According to a first aspect of this application, a component verification method is provided, comprising: determining a target verification stage and a corresponding target verification item for the component to be verified based on the verification priority of the component to be verified, wherein the target verification stage includes one of the following: a hardware initialization stage during the startup of a hardware management component, a boot loading stage, and a firmware main program running stage, wherein the hardware initialization stage is used to perform a full verification of the component, the boot loading stage is used to perform a core identity attribute verification of the component, and the firmware main program running stage is used to perform a basic identity attribute verification of the component; in the target verification stage, matching the target verification item with a target device identifier and an identifier mapping relationship set, wherein the identifier mapping relationship set includes mapping relationships between multiple verification items and multiple device identifiers; if the matching is successful, reading the timing operation data of the component to be verified in the device, and matching the timing operation data with the standard component operation baseline of the device; if the matching is successful, determining that the component to be verified has passed the verification, wherein the standard component operation baseline includes the operation baseline of standard components that the device allows to access.

[0005] A second aspect of this application provides an electronic device, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0006] A third aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0007] A fourth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0008] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0009] Figure 1 A schematic diagram of the component identification method is shown.

[0010] Figure 2 The diagram illustrates application scenarios of the component verification method, apparatus, storage medium, and program product according to embodiments of this application.

[0011] Figure 3 A flowchart of a component verification method according to an embodiment of this application is shown.

[0012] Figure 4 A flowchart illustrating a component verification method according to another embodiment of this application is shown.

[0013] Figure 5 A structural block diagram of a component verification apparatus according to an embodiment of this application is shown.

[0014] Figure 6 A block diagram of an electronic device suitable for implementing a component verification method according to an embodiment of this application is shown. Detailed Implementation

[0015] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0016] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0017] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0018] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0019] Component counterfeiting refers to the unauthorized sale of components across regions and channels without the permission of the brand owner or authorized distributor. Components from legitimate channels typically undergo rigorous compatibility testing by the manufacturer to ensure compatibility with other components of the device (such as the motherboard and software system). Counterfeit components may present the following problems: they may be refurbished or lack original manufacturer compatibility certification, potentially leading to hardware conflicts (such as recognition failure, frequent crashes, or malfunctions); components from different regions may have varying degrees of compatibility with the device due to differences in production batches and supply chain standards. For example, subtle differences in electrical parameters and interface protocols can affect the compatibility between the component and the device, and long-term use of incompatible components may accelerate device wear and tear.

[0020] The relevant methods are usually based on the physical tags of the parts to identify whether the parts are parallel imports.

[0021] Figure 1 A schematic diagram of the component identification method is shown.

[0022] like Figure 1 As shown, in related methods, physical labels are typically generated for components by the production end. For example, physical label 1 is generated for one component, physical label 2 for another, and physical label 3 for yet another. Physical labels can include physical QR codes, such as those on product packaging. The component's unique serial number can be encoded into the QR code. By scanning the QR code, information such as the component's production batch, production date, and manufacturer can be obtained. Physical labels can be sent to distributors; for example, the QR code may be included in the component packaging during the logistics process and delivered to the distributor. Distributors can scan the physical labels to verify whether a component is a parallel import. For example, scanning physical label 1 verifies if the component corresponding to that label is a parallel import, scanning physical label 2 verifies if the component corresponding to that label is a parallel import, scanning physical label 3 verifies if the component corresponding to that label is a parallel import, and so on. If the verification passes, the component can be sold at the sales end. If the verification fails, the component needs to be manually reviewed by the auditing end, and the audit information needs to be reported. If the component is determined to be a parallel import, it can be marked as abnormal in the database storing component information.

[0023] However, methods for identifying counterfeit parts using physical tags are highly reliant on manual labor. For example, they require manual scanning of physical tags, which is prone to omissions or misjudgments and has low verification efficiency. Furthermore, physical tags are usually exposed on the surface of the parts, making them susceptible to wear and tear, and they are easily counterfeited, potentially leading to the identification of counterfeit parts as legitimate parts, thus resulting in low accuracy. Moreover, the verification process relies on offline processing via remote servers. For instance, methods using physical tags can only be verified offline; the scanning device needs to download a list of valid devices for the day, but this list cannot be updated in real-time in offline environments, making real-time management difficult. Additionally, these methods lack a complete recording mechanism, making it difficult to support subsequent audits.

[0024] In view of this, embodiments of this application provide a component verification method, comprising: determining a target verification stage and a corresponding target verification item for the component to be verified according to the verification priority of the component to be verified, wherein the target verification stage includes one of the following: a hardware initialization stage when the hardware management component is started, a boot loading stage, and a firmware main program running stage, wherein the hardware initialization stage is used to perform a full verification of the component, the boot loading stage is used to perform a core identity attribute verification of the component, and the firmware main program running stage is used to perform a basic identity attribute verification of the component; in the target verification stage, matching the target verification item with the target device identifier and the identifier mapping relationship set, wherein the identifier mapping relationship set includes the mapping relationship between multiple verification items and multiple device identifiers; if the matching is successful, reading the timing operation data of the component to be verified in the device, and matching the timing operation data with the standard component operation baseline of the device; if the matching is successful, determining that the component to be verified has passed the verification, wherein the standard component operation baseline includes the operation baseline of the standard components that the device allows to access.

[0025] Figure 2 The diagram illustrates application scenarios of the component verification method, apparatus, storage medium, and program product according to embodiments of this application. For example... Figure 2 As shown, application scenario 200 according to this embodiment may include device 210, which may include multiple components, such as component A 211, component B 212, component N 213, etc. It should be noted that... Figure 2 The number of components shown is for illustrative purposes only. The number of components can be set according to actual needs and is not limited here.

[0026] The component to be verified may include all or some of the components in device 210. For example, the component to be verified may include component A 211, component B 212, and component N 213. After determining the component to be verified, a component verification method can be executed. For example, the component verification method can be executed by the Baseboard Management Controller (BMC) in device 210. The component verification method includes: determining the target verification stage and corresponding target verification items for the component to be verified according to the verification priority of the component to be verified. The target verification stage includes one of the following: the hardware initialization stage when the hardware management component starts, the boot loading stage, and the firmware main program running stage; in the target verification stage, matching the target verification items and the target device identifier with the identifier mapping relationship set, the identifier mapping relationship set including the mapping relationship between multiple verification items and multiple device identifiers; if the matching is successful, reading the timing operation data of the component to be verified in the device, and matching the timing operation data with the standard component operation baseline of the device; if the matching is successful, determining that the component to be verified has passed the verification, wherein the standard component operation baseline includes the operation baseline of the standard components that the device allows to be accessed.

[0027] The following will be based on Figure 2 The described scene, through Figures 3-4 The component verification method of the embodiments of this application will be described in detail.

[0028] Figure 3 A flowchart of a component verification method according to an embodiment of this application is shown.

[0029] like Figure 3 As shown, the component verification method of this embodiment includes operations S310 to S340.

[0030] When operating S310, the target verification stage and corresponding target verification items for the component to be verified are determined according to the verification priority of the component to be verified. The target verification stage includes one of the following: hardware initialization stage when the hardware management component starts, boot loading stage, firmware main program running stage.

[0031] Optionally, the components to be verified may include predetermined components that need to be verified every time the server starts up or every time a hot-plug event occurs. For example, for components that are essential for startup, such as the Central Processing Unit (CPU) and motherboard chipset, these components will be verified according to a fixed process every time the device is powered on, thereby ensuring the reliability of the startup chain.

[0032] The components to be verified can also include components from newly connected devices. For example, after inserting a new hard drive, expansion card, or other component, it is necessary to verify the component to determine whether it is a counterfeit or substandard component. For instance, verification can be performed when the component is first connected to the device.

[0033] Optionally, a verification priority can be set for different components to be verified. The verification priority can be determined according to the importance of the component to be verified. For example, for core components such as CPU, memory, and motherboard, the highest priority can be set, such as the first priority. For auxiliary components such as expansion interface panels, since they are not directly related to core business, a lower verification priority can be set, such as the third priority.

[0034] Optionally, different verification priorities can correspond to different verification stages and verification items. For example, the highest priority component to be verified can be verified in the earliest verification stage, such as the hardware initialization stage, due to its importance, and the verification items can include more content. Conversely, lower priority components can be verified in a later stage, and the verification items for lower priority components can include fewer items compared to the highest priority component. Verification items may include, for example, the component manufacturer's digital signature and the component's unique identifier.

[0035] Optionally, the hardware management component may include a baseboard management controller, which may perform verification of the target verification items of the component to be verified during the baseboard management controller startup phase. The baseboard management controller startup phase may include a hardware initialization phase, a boot loading phase, and a firmware main program execution phase.

[0036] Optionally, the hardware initialization phase is used to perform a full verification of components. For example, the hardware initialization phase is used to perform a full verification of the highest priority components. Because the highest priority components are of high importance and their identities need to be strictly verified, a full verification can be performed on them. A full verification can include verifying all verification items.

[0037] During the hardware initialization phase, all resources can be used to perform full verification of the highest priority components. At this time, the baseboard management controller has not yet started multi-task scheduling, and non-core drivers have not been loaded. The bus and computing power only serve the initialization of the highest priority components, and there is no resource contention.

[0038] Furthermore, by prioritizing the verification of critical components at the earliest stage of the baseboard management controller's startup, risks can be intercepted before other system functions are activated, cutting off the transmission path of security risks at the source.

[0039] Optionally, the bootloader phase is used to perform core identity attribute verification on components. If full verification is performed on all components, and all verifications are performed during the hardware initialization phase, it will consume a lot of resources, and the baseboard management controller may fail to start due to insufficient resources. Therefore, components with slightly lower importance (such as medium-priority components) can be verified during the bootloader phase, thereby using resources in a staggered manner, avoiding resource overload during the hardware initialization phase, and ensuring that the baseboard management controller can complete the startup stably.

[0040] Core identity attribute verification can include verifying items of higher importance within the verification process. Since identity restrictions on components of slightly lower importance do not need to be as strict as those on the highest priority components, only the core identity attributes of medium-priority components can be verified, eliminating the need for full verification. This achieves lightweight and efficient verification, improving verification efficiency and reducing resource consumption while ensuring component security.

[0041] Optionally, the firmware main program runtime phase is used to verify the basic identity attributes of the component. Basic identity attribute verification may include verifying items of lower importance within the verification process.

[0042] Components of lower importance (such as those with the lowest priority) can be verified during the main firmware program execution phase. These components typically do not affect system security or the startup of core functions; therefore, they can be verified at the final stage of the baseboard management controller startup, thus avoiding the consumption of limited resources from preceding stages. Furthermore, performing only basic identity attribute verification avoids unnecessary computational resource consumption.

[0043] During the S320 operation, in the target verification phase, the target verification items and the target device identifier are matched with the identifier mapping relationship set.

[0044] Optionally, the target device identifier may include the device identifier of the device where the component to be verified resides. The device identifier is used to uniquely identify the device, for example, uniquely identifying the device where the component to be verified resides. Different devices may have different manufacturer digital signatures, component unique identifiers, etc., for the standard components allowed to access that device. A set of identifier mapping relationships can be pre-built, including mappings between multiple verification items and multiple device identifiers. For example, the identifier mapping relationship set might include the fact that the component unique identifier corresponding to device identifier XXXXX1 should be 000000X. For example, the identifier mapping relationship set can be stored in a pre-built component database, and a standardized interface can be provided to support remote upgrades of the component database content without requiring a server restart.

[0045] For example, if the verification item includes a unique component identifier, the device identifier of the device containing the component to be verified is XXXXX1, and the unique component identifier of the component to be verified is 000011X, then matching the target verification item with the target device identifier and the identifier mapping relationship set will fail. Since the identifier mapping relationship set includes the requirement that the unique component identifier of a component corresponding to device identifier XXXXX1 should be 000000X, while the unique component identifier of the component to be verified is 000011X and the device identifier of the device containing the component to be verified is XXXXX1, the target verification item and the target device identifier and identifier mapping relationship set will fail to match. In the case of this failure, the verification of the component to be verified fails, indicating that the component to be verified is not a standard component allowed to access the device containing it, which may affect the device's performance or cause hardware incompatibility issues.

[0046] When operating S330, if the matching is successful, read the timing operation data of the component to be verified in the device, and match the timing operation data with the standard component operation baseline of the device.

[0047] In operation S340, if the matching is successful, the component to be verified is determined to have passed verification. The standard component operating baseline includes the operating baselines of standard components that the device is allowed to connect to.

[0048] Optionally, a successful match may include all target verification items being matched successfully, while a match may fail if any target verification item fails to match. When a component fails to be verified, policies such as disabling, alarming, and logging may be implemented on the component that failed to be verified, and the verification result may be reported to the management system so that the component that failed to be verified can be processed in a timely manner.

[0049] If the target verification item and the target device identifier and the identifier mapping relationship set are successfully matched, further verification can be performed. For example, the operating data of the component to be verified in the device can be obtained within a certain period of time to obtain time-series operating data. If the time-series operating data has a high similarity to the operating baseline of the standard component (that is, a successful match), it indicates that the operating status of the component to be verified is consistent with the operating status of the standard component that is allowed to access the device, and the component to be verified is determined to have passed the verification.

[0050] Standard components that the device allows to connect to (such as power supplies, fans, hard drive backplanes, etc.) are consistent in terms of manufacturing processes, component selection, and firmware consistency. Therefore, their operating behavior under different operating conditions (such as power consumption, temperature response, communication latency, etc.) has predictable patterns. However, refurbished components and other abnormal components, due to the use of inferior components, different batch processes, or non-original firmware, often exhibit systematic differences in behavior compared to standard components. Therefore, a baseline for the standard components that the device allows to connect to (i.e., the standard component operating baseline) can be generated through a model. During device operation, the operating data of the component to be verified is collected in real time and compared to the baseline to determine if the component is abnormal. The model used to generate the standard component operating baseline can be determined according to actual needs; for example, it can be a lightweight model, and the trained lightweight model can be deployed to the baseboard management controller's file system. During device operation, the baseboard management controller can periodically collect the behavioral data of the component to be verified and input it into the model for inference. If it is determined that the timing data does not match the standard component operating baseline of the device, an alarm message can be generated, or the function of the component to be verified can be restricted.

[0051] During the model training phase, a large amount of operational data of known standard components under various load, ambient temperature, and voltage conditions can be collected in a production line or laboratory environment. Unsupervised learning algorithms or supervised learning algorithms can be used to train the model according to actual needs, and the distribution boundary of the set of identification mapping relationships can be learned.

[0052] Optionally, if the target verification item and the target device identifier and identifier mapping relationship set fail to match, there is no need to perform subsequent operations such as reading the timing operation data of the component to be verified in the device and matching the timing operation data of the component to be verified in the device with the standard component operation baseline of the device. The component to be verified can be directly determined to have failed verification. Rules can be set in the board management controller to define the measures to be taken when a component that fails verification is detected. The measures include, for example, disabling the device, logging, and triggering an alarm.

[0053] According to embodiments of this application, the target verification stage and corresponding target verification items for the component to be verified are determined based on the verification priority of the component to be verified. Compared with the full verification method that uniformly performs the same verification content on all hardware components and executes the verification process serially, this method can improve verification efficiency. By first matching the target verification items with the target device identifier and the identifier mapping relationship set for preliminary static verification, and then matching the timing operation data of the component to be verified in the device with the standard component operation baseline of the device, further dynamic verification is completed. Through multi-stage verification combining static and dynamic verification, hardware components can be identified and verified in detail, improving verification accuracy and ensuring that the component can only be matched with the specified device type and product model. Moreover, the verification process has low reliance on manual intervention and high verification efficiency. By using the hardware initialization stage to perform full verification of the component, the boot loading stage to perform core identity attribute verification of the component, and the firmware main program running stage to perform basic identity attribute verification of the component, hierarchical verification of components and resource peak shifting can be achieved. While efficiently and accurately completing component verification, the reliability of hardware management component startup and resource utilization can be guaranteed.

[0054] According to an embodiment of this application, the verification priority includes a first priority; the verification stage corresponding to the first priority includes a hardware initialization stage, and the verification items corresponding to the first priority include: the component identifier, component type, and component security credential of the component to be verified.

[0055] Optionally, the first priority can be the highest priority, and can be assigned to components of high importance to be verified, such as core components like the CPU, memory, and motherboard. Verifying the first-priority components during the hardware initialization phase has two advantages: firstly, system resources (such as bus bandwidth and computing power) are relatively idle during hardware initialization, allowing for a concentrated full verification of component identifiers, component types, and component security credentials; secondly, immediate verification during the hardware management component startup phase ensures the trustworthiness of core components, and if verification fails, startup can be terminated directly and a hardware alarm triggered.

[0056] Optionally, a full verification of the component identifier, component type, and component security credentials can be performed on the components to be verified with the highest priority, thereby ensuring the security of the core components.

[0057] By performing full verification of the component identifier, component type, and component security credentials on the highest priority component during the hardware initialization phase, system resources can be utilized efficiently while ensuring the security of core components.

[0058] According to an embodiment of this application, the verification priority also includes a second priority, wherein the second priority is lower than the first priority; the verification stage corresponding to the second priority includes the boot loading stage; the verification items corresponding to the second priority include at least a portion of the component identifier, component type, and component security credentials of the component to be verified.

[0059] Optionally, the component to be verified corresponding to the second priority is less important than the component to be verified corresponding to the first priority. For example, the component to be verified corresponding to the second priority can be a medium priority component, such as a hard drive or network card. The verification of the second priority component can be performed during the boot loading stage, which can be completed during the driver loading interval without taking up additional startup time.

[0060] Optionally, the number of verification items for the component to be verified corresponding to the second priority may be less than the number of verification items for the component to be verified corresponding to the first priority. For example, the verification items for the component to be verified corresponding to the second priority may include only a portion of the component identifier, component type, and component security certificate of the component to be verified, such as only the component identifier and component security certificate.

[0061] Verifying all items takes a lot of time and consumes a lot of resources. Therefore, reducing the number of verification items for less important components and performing verification during the boot loading phase can save system resources and improve verification efficiency.

[0062] According to an embodiment of this application, the verification priority also includes a third priority, wherein the third priority is lower than the second priority; the verification stage corresponding to the third priority includes the firmware main program running stage.

[0063] Optionally, the component to be verified corresponding to the third priority can be the lowest priority component. Verification can be performed in the final stage before the operating system boots up, i.e., during the firmware main program execution phase, to verify components of lower importance, thus prioritizing the verification of more important components to determine component security. Furthermore, the verification items corresponding to the third priority can be fewer than those corresponding to the second priority; for example, the verification items corresponding to the third priority can include only the component identifier.

[0064] By assigning different verification stages and verification items to different priorities, system resources can be saved and verification speed can be improved while ensuring component safety.

[0065] According to an embodiment of this application, the component verification method further includes: in response to the device power-on startup, scanning the device's hardware interfaces to identify the component to be verified before the device's operating system starts; and collecting the target component identifier of the component to be verified through the device's hardware management component.

[0066] Hardware management components, such as the baseboard management controller, scan the device's hardware interfaces before the operating system boots up, identifying components to be verified. For example, the baseboard management controller can proactively determine whether a component is connected to the interface and collect the component's identifier for subsequent verification. For instance, for Peripheral Component Interconnect Express (PCIE) devices such as network interface cards, the Sub-system Vendor Identification (SVID) can be obtained by reading its PCIE configuration space; for storage devices such as hard drives, Vital Product Data (VPD) can be read based on the Small Computer System Interface and Serial Advanced Technology Accessories.

[0067] The baseboard management controller communicates directly with the connected components via a hardware interface, reading their SVID, VPD, firmware signature, and other identity information in real time. Since this data collection is entirely automated within the server, it eliminates the need to acquire data from external devices via the network. Furthermore, the verification of target verification items is performed during the hardware management component's startup phase, allowing for preliminary verification before the operating system boots up. This prevents some abnormal components from exploiting operating system vulnerabilities. Compared to manual or remote verification methods, it enables automatic data collection and local verification, avoiding delays or tampering risks during data transmission and achieving real-time verification. Moreover, by performing localized real-time verification of components without relying on external servers, it is suitable for network-constrained scenarios such as edge computing.

[0068] Optionally, the collected data can be encrypted and / or digitally signed. The encryption and digital signing methods can be set according to actual needs and are not limited here. For example, the collected data can be encrypted and digitally signed to protect data integrity. The signature needs to be checked during the verification process to ensure that the data has not been tampered with.

[0069] According to an embodiment of this application, matching the timing operation data with the standard component operation baseline of the device includes: calculating the similarity between the timing operation data and the standard component operation baseline; and determining that the matching is successful if the similarity meets the target preset value condition, wherein the target preset value condition corresponds to the target runtime of the component to be verified in the device.

[0070] Optionally, the similarity meeting the target preset value condition may include the similarity being greater than a preset threshold, and the preset threshold may correspond to the target runtime.

[0071] For example, in the initial stage of connecting the component to the device (such as the first 3 days after connection), the component may undergo hardware initialization, firmware adaptation, and environmental adaptation (such as temperature and voltage stabilization processes), which may cause short-term fluctuations in parameters (such as power consumption). However, this is a normal phenomenon. If a low threshold is set, normal fluctuations may be misjudged as component abnormalities, thus triggering invalid alarms.

[0072] Once the component to be verified reaches a stable period after being connected to the device (e.g., one month after connection), the performance and parameters of the component will stabilize after the initial break-in period. At this time, fluctuations in the timing data are more likely to reflect component abnormalities. Therefore, a lower preset threshold can be set to increase the sensitivity to minor abnormalities.

[0073] By calculating the similarity between the time-series running data and the standard component running baseline, a match is determined if the similarity meets the target preset value condition. Furthermore, by determining the target preset value condition based on the target running time, false judgments can be reduced and verification accuracy can be improved.

[0074] According to an embodiment of this application, the component verification method further includes: in response to triggering a preset update condition, obtaining component update data through the hardware management component of the device; updating the identifier mapping relationship set according to the component update data; the preset update condition includes at least one of the following: adding or deleting a standard component, reaching the update cycle, updating the device model, or updating the component identifier of the standard component.

[0075] Optionally, the hardware management component can communicate directly with the connected components through the hardware interface, read their relevant identity information in real time, and obtain component update data. The component update data may include updated verification item data, such as updated component identifier, component type, component security credentials, etc.

[0076] When adding a standard component, the corresponding verification items such as component identifier, component type, and component security certificate can be identified, and the mapping relationship between the verification items of the newly added standard component and the device identifier can be added to the identifier mapping relationship set. When deleting a standard component, the mapping relationship between the verification items of that standard component and the device identifier can be directly deleted from the identifier mapping relationship set.

[0077] Optionally, manufacturers may periodically update the standard parts list. To avoid information lag caused by the long-term lack of updates to the identifier mapping relationship set, which would reduce the accuracy of verification, a fixed update cycle (such as weekly or monthly) can be set according to actual needs. After the expiration, the parts update data will be automatically obtained and the standard parts list will be updated.

[0078] Optionally, manufacturers may update the standard component list, such as updating the device model or updating the component identifier of the standard component. Therefore, in response to updating the device model or updating the component identifier of the standard component, the identifier mapping relationship can be updated in a timely manner to ensure that the identifier mapping relationship includes the latest verification items and the mapping relationship between the device identifier.

[0079] Optionally, component update data can be stored in a blockchain network to ensure that the component update data is immutable and facilitates subsequent auditing and traceability. For example, a record can be generated each time component update data is generated and the record can be uploaded to the blockchain to ensure the immutability of the component update data. The blockchain network uses distributed ledger technology to ensure that the records on all nodes are consistent and immutable.

[0080] By updating the identifier mapping set based on component update data, the set can be kept consistent with actual component specifications, equipment requirements, and manufacturer standards. This ensures accurate and effective component verification by the equipment and avoids misjudgments or omissions due to outdated information. Furthermore, it supports flexible updates to the identifier mapping set for diverse hardware vendors and constantly changing device models, adapting to hardware devices from different manufacturers and demonstrating excellent compatibility and scalability.

[0081] According to an embodiment of this application, the component identifier includes: supplier identifier and component feature identifier, wherein the component feature identifier is used to characterize at least one of the following information of the component: component model, component serial number, component production date; the component security credential includes at least one of the following: component built-in key, physical unclonable function.

[0082] Supplier identifiers, for example, are used to uniquely identify the manufacturer and supplier of a component; supplier identifiers may include subsystem supplier identifiers. Component feature identifiers originate from a set of key information stored in the hardware component. The supplier identifier and component feature identifier of the component to be verified can be read using the underlying driver and structured into a standard format for easy subsequent verification.

[0083] Component-embedded keys can include immutable built-in keys embedded in standard components, such as keys stored in fuses. When verifying a component-embedded key, its legitimacy can be verified through a cryptographic challenge and response mechanism (e.g., generating a random number for each verification and requiring the component to sign its response with the key). Because the key cannot be extracted or copied from the hardware, even if the supplier identifier and component characteristic identifier are abnormally obtained, an illegitimate component will not be able to pass key verification.

[0084] Physically unclonable functions (PUFs) are generated using random physical differences (such as minor circuit defects or material inhomogeneities) that occur during the manufacturing process of hardware such as chips. They are difficult to replicate precisely and are bound to the physical hardware entity.

[0085] Since supplier identifiers and component feature identifiers are easily obtained and thus exploited by malicious components, while physically unclonable functions and component built-in keys offer higher security, combining multiple verification methods can improve verification accuracy compared to methods that rely solely on a single piece of information.

[0086] According to embodiments of this application, the timing operation data includes at least one of the following: power consumption timing data, temperature response timing data, response delay timing data, error code distribution timing data, and sensor timing data.

[0087] Optionally, power consumption timing data may include real-time current, voltage, and power of the component under test obtained through a monitoring chip; temperature response timing data may include the heating / cooling rate of the component under test under load changes (e.g., the temperature change slope from no-load to full-load); response delay timing data may include the response time of the component under test to commands. The frequency of error events reported by the component under test, such as fan stall, can be statistically analyzed to generate corresponding error codes. Error code distribution timing data may include data on the distribution characteristics of error codes, such as frequency, quantity, and proportion, changing over time. Sensor timing data may include the noise level of readings from sensors such as temperature sensors and voltage sensors.

[0088] By using timing data such as power consumption timing data, temperature response timing data, response delay timing data, error code distribution timing data, and sensor timing data, the operating status of the component to be verified can be obtained from multiple perspectives, thereby improving the accuracy of verification.

[0089] Figure 4 A flowchart illustrating a component verification method according to another embodiment of this application is shown.

[0090] like Figure 4 As shown, the component verification method of this embodiment includes operations S410 to S470.

[0091] When operating S410, components are produced. For example, the manufacturing and processing of components can be completed by a supplier.

[0092] During operation of S420, supplier identifiers and component feature identifiers are written. For example, after component production is completed, the supplier or manufacturer can write supplier identifiers and component feature identifiers to the component's memory chip.

[0093] In S430 operation, components are configured into server devices. For example, components that write identification information can be installed into servers, such as data center servers.

[0094] In operation S440, it is determined whether the component verification has passed. For example, the target verification item and the target device identifier and identifier mapping relationship set can be matched. If the match is successful, the timing operation data of the component in the device is read and matched with the standard component operation baseline of the device. If the match is successful, the component verification is determined to have passed.

[0095] When operating S450, if the component verification passes, the component operates normally. For example, if the verification passes, it means that the component is a standard component that is allowed to access the server, and the server can support the normal operation of the component.

[0096] When operating S460, if a component fails verification, a log is logged. For example, if a component fails verification, the system can automatically record detailed information about the verification failure event, such as the component serial number, the reason for the failure, and the timestamp, and store this information in the local log system for subsequent investigation and tracing.

[0097] When operating the S470, an alarm may be triggered. For example, after logging, the system can trigger an alarm mechanism to promptly remind maintenance personnel to handle the anomaly and prevent abnormal components from affecting the stability of the server.

[0098] It should be noted that the component verification method of this application is not limited to server management scenarios, but can also be applied to other scenarios according to actual needs. For example, it can be applied to industrial automation and control systems. In industrial automation environments, it is necessary to ensure the authenticity and compatibility of key components such as programmable logic controllers, sensors, and actuators. The component verification method of this application can prevent unauthorized or low-quality hardware components from being connected to the automation system, thereby ensuring the safe operation and efficient output of the production line. For example, it can also be applied to IoT device management scenarios. With the rapid growth in the number of IoT devices, the requirements for the authenticity and security of devices are gradually increasing. The component verification method of this application can identify secure components, prevent abnormal components from accessing the network, and ensure the security of data acquisition and transmission.

[0099] Based on the above component verification method, this application also provides a component verification device. The following will be combined with... Figure 5 The device is described in detail.

[0100] Figure 5 A structural block diagram of a component verification apparatus according to an embodiment of this application is shown.

[0101] like Figure 5 As shown, the component verification device 500 of this embodiment includes a first determining module 510, a first matching module 520, a second matching module 530, and a second determining module 540.

[0102] The first determining module 510 is used to determine the target verification stage and corresponding target verification items for the component to be verified based on the verification priority of the component to be verified. The target verification stage includes one of the following: the hardware initialization stage when the hardware management component starts, the boot loading stage, and the firmware main program running stage. The hardware initialization stage is used to perform a full verification of the component, the boot loading stage is used to perform verification of the core identity attributes of the component, and the firmware main program running stage is used to verify the basic identity attributes of the component. In one embodiment, the first determining module 510 can be used to perform the operation S310 described above, which will not be repeated here.

[0103] The first matching module 520 is used in the target verification stage to match the target verification items and the target device identifier with an identifier mapping relationship set, wherein the identifier mapping relationship set includes mapping relationships between multiple verification items and multiple device identifiers. In one embodiment, the first matching module 520 can be used to perform the operation S320 described above, which will not be repeated here.

[0104] The second matching module 530 is used to read the timing operation data of the component to be verified in the device when the matching is successful, and match the timing operation data with the standard component operation baseline of the device. In one embodiment, the second matching module 530 can be used to perform the operation S330 described above, which will not be repeated here.

[0105] The second determining module 540 is used to determine that the component to be verified has passed verification if the matching is successful, wherein the standard component operating baseline includes the operating baseline of standard components that the device is allowed to access. In one embodiment, the second determining module 540 may be used to perform the operation S340 described above, which will not be repeated here.

[0106] According to embodiments of this application, the component verification device further includes an identification module and a data acquisition module.

[0107] The identification module is used to scan the hardware interfaces of the device and identify the component to be verified in response to the device power-on and before the device's operating system starts; the acquisition module is used to acquire the target component identifier of the component to be verified through the device's hardware management components.

[0108] According to an embodiment of this application, the second matching module includes a calculation submodule and a determination submodule.

[0109] The calculation submodule is used to calculate the similarity between the timing operation data and the standard component operation baseline; the determination submodule is used to determine the match is passed when the similarity meets the target preset value condition, wherein the target preset value condition corresponds to the target running time of the component to be verified in the device.

[0110] According to embodiments of this application, the component verification device further includes an acquisition module and an update module.

[0111] The acquisition module is used to acquire component update data through the device's hardware management component in response to the triggering of preset update conditions; the update module is used to update the identifier mapping relationship set according to the component update data.

[0112] According to embodiments of this application, any plurality of modules among the first determining module 510, the first matching module 520, the second matching module 530, and the second determining module 540 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the first determining module 510, the first matching module 520, the second matching module 530, and the second determining module 540 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in any one of the three implementation methods of software, hardware, and firmware, or in a suitable combination of any of these. Alternatively, at least one of the first determining module 510, the first matching module 520, the second matching module 530, and the second determining module 540 may be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0113] Figure 6 A block diagram of an electronic device suitable for implementing a component verification method according to an embodiment of this application is shown.

[0114] like Figure 6As shown, an electronic device 600 according to an embodiment of this application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0115] RAM 603 stores various programs and data required for the operation of electronic device 600. Processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Processor 601 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 602 and / or RAM 603. It should be noted that programs may also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0116] According to embodiments of this application, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output (I / O) interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output (I / O) interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0117] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0118] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 602 and / or RAM 603 and / or one or more memories other than ROM 602 and RAM 603 described above.

[0119] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0120] When the computer program is executed by the processor 601, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0121] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0122] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0123] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0124] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0125] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

[0126] The embodiments of this application have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of this application. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Without departing from the scope of this application, those skilled in the art can make various substitutions and modifications, all of which should fall within the scope of this application.

Claims

1. A component verification method, characterized in that, The method includes: Based on the verification priority of the component to be verified, the target verification stage and corresponding target verification items for the component to be verified are determined. The target verification stage includes one of the following: hardware initialization stage when the hardware management component starts, boot loading stage, firmware main program running stage, wherein the hardware initialization stage is used to perform full verification of the component, the boot loading stage is used to perform core identity attribute verification of the component, and the firmware main program running stage is used to verify basic identity attributes of the component. In the target verification stage, the target verification items and the target device identifier are matched with the identifier mapping relationship set, which includes the mapping relationship between multiple verification items and multiple device identifiers; If the match is successful, read the timing operation data of the component to be verified in the device, and match the timing operation data with the standard component operation baseline of the device; If the matching is successful, the component to be verified is determined to have passed the verification, wherein the standard component operating baseline includes the operating baseline of the standard components that the device is allowed to access.

2. The method according to claim 1, characterized in that, The verification priority includes the first priority; The verification phase corresponding to the first priority includes the hardware initialization phase, and the verification items corresponding to the first priority include: the component identifier, component type, and component security credential of the component to be verified.

3. The method according to claim 2, characterized in that, The verification priority also includes a second priority, wherein the second priority is lower than the first priority; The verification phase corresponding to the second priority includes the boot loading phase; The verification items corresponding to the second priority include at least a portion of the component identifier, component type, and component security credentials of the component to be verified.

4. The method according to claim 3, characterized in that, The verification priority also includes a third priority, wherein the third priority is lower than the second priority; The verification phase corresponding to the third priority includes the firmware main program execution phase.

5. The method according to claim 1, characterized in that, The method further includes: In response to the device power-on startup, before the device's operating system starts, the hardware interfaces of the device are scanned to identify the component to be verified; The target component identifier of the component to be verified is collected by the hardware management component of the device.

6. The method according to claim 1, characterized in that, The step of matching the timing operation data with the standard component operation baseline of the device includes: Calculate the similarity between the timing operation data and the standard component operation baseline; If the similarity meets the target preset value condition, the match is determined to be successful, wherein the target preset value condition corresponds to the target runtime of the component to be verified in the device.

7. The method according to claim 1, characterized in that, The method further includes: In response to triggering a preset update condition, component update data is obtained through the hardware management component of the device; Update the identifier mapping relationship set according to the component update data; The preset update conditions include at least one of the following: adding or deleting standard components, reaching the update cycle, updating the device model, or updating the component identifier of the standard components.

8. The method according to claim 2, characterized in that, The component identifier includes: supplier identifier and component feature identifier, wherein the component feature identifier is used to characterize at least one of the following information of the component: component model, component serial number, and component production date; The component security credentials include at least one of the following: a component-embedded key, or a physically unclonable function.

9. The method according to claim 1, characterized in that, The timing operation data includes at least one of the following: power consumption timing data, temperature response timing data, response delay timing data, error code distribution timing data, and sensor timing data.

10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 9.

Images