Component verification method and device, storage medium and program product

Abstract

The invention provides a component verification method and device, a storage medium and a program product, and can be applied to the technical field of computers. The component verification method comprises the steps that a target verification stage and a corresponding target verification item for a to-be-verified component are determined according to the verification priority of the to-be-verified component, and the target verification stage comprises one of the following stages: a hardware initialization stage for starting a hardware management assembly, a boot loading stage and a firmware main program loading stage; in a target verification stage, matching a target verification item and a target device identifier with an identifier mapping relationship set, the identifier mapping relationship set comprising a mapping relationship between a plurality of verification items and a plurality of device identifiers; under the condition of successful matching, reading time sequence operation data of the to-be-verified component in the equipment, and matching the time sequence operation data with a standard component operation base line of the equipment; and under the condition that the matching is passed, determining that the to-be-verified part passes the verification.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and more specifically to a component verification method, device, storage medium, and program product. Background Art

[0002] The problem of component mismatching is a significant factor affecting equipment quality, production processes, and after-sales service. The relevant method usually involves using physical labels to identify mismatched components. However, this method is highly dependent on manual labor, has low recognition efficiency, and low recognition accuracy. Summary of the Invention

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

[0004] According to the first aspect of the present application, a component verification method is provided, including: determining a target verification phase 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 phase including one of the following: a hardware initialization phase initiated by a hardware management component, a boot loading phase, and a firmware main program running phase, wherein the hardware initialization phase is used to perform a full verification of the component, the boot loading phase is used to perform a core identity attribute verification of the component, and the firmware main program running phase is used to verify the basic identity attributes of the component; in the target verification phase, matching the target verification item and the target device identifier with an identifier mapping relationship set, the identifier mapping relationship set including mapping relationships between multiple verification items and multiple device identifiers; if the match 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 match is successful, determining that the verification of the component to be verified is passed, wherein the standard component operation baseline includes the operation baseline of the standard component allowed to be accessed by the device.

[0005] The second aspect of the present application provides an electronic device, comprising: one or more processors; 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 above method.

[0006] The third aspect of the present application further provides a computer-readable storage medium having a computer program or instructions stored thereon, which implements the steps of the above method when the computer program or instructions are executed by a processor.

[0007] The fourth aspect of the present application further provides a computer program product, comprising a computer program or instructions, which implement the steps of the above method when executed by a processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The above contents and other objects, features and advantages of the present application will become more apparent through the following description of the embodiments of the present application with reference to the accompanying drawings, in which:

[0009] Figure 1 A schematic diagram illustrating component identification of a related method.

[0010] Figure 2 The present invention illustrates an application scenario diagram of a component verification method, device, storage medium, and program product according to an embodiment of the present application.

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

[0012] Figure 4 The flowchart of a component verification method according to another embodiment of the present application is schematically shown.

[0013] Figure 5 A structural block diagram of a component verification device according to an embodiment of the present 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 the present application is shown. DETAILED DESCRIPTION

[0015] Hereinafter, embodiments of the present application will 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 the present application. In the detailed description below, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present application. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessarily confusing the concepts of the present application.

[0016] The terms used herein are only for describing specific embodiments and are not intended to limit the present application. The terms "comprise," "include," etc. 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 should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

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

[0019] Component channeling involves the unauthorized cross-regional and cross-channel sales of components without the permission of the brand or authorized dealers. Components from legitimate channels typically undergo rigorous adaptation testing by the manufacturer to ensure compatibility with other components of the device (such as the motherboard, software system, etc.). Channeled components may present the following issues: Channeled components may be refurbished parts that have not undergone compatibility certification from the original manufacturer, potentially leading to hardware conflicts (such as inability to identify, frequent crashes, functional failures, etc.); 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 components and devices. Long-term use of mismatched components may accelerate device wear.

[0020] The related method is usually to identify whether the component is a parallel import component based on the physical label of the component.

[0021] Figure 1 A schematic diagram illustrating component identification of a related method.

[0022] like Figure 1 As shown, in related methods, the production end typically generates physical labels for components, such as physical label 1 for one component, physical label 2 for another component, and physical label 3 for yet another component. Physical labels can include physicalized QR codes, such as those found on product packaging. The component's unique serial number can be encoded in the QR code, and by scanning the QR code, information such as the component's production batch, production date, and manufacturer can be obtained. The physical labels can be sent to distributors, for example, with the QR code included in the component packaging as part of the logistics process and delivered to the distributor. Distributors can scan the physical labels to verify whether the component is a channeled product, such as by scanning physical label 1 to verify whether the component corresponding to the physical label is a channeled product, scanning physical label 2 to verify whether the component corresponding to the physical label is a channeled product, and scanning physical label 3 to verify whether the component corresponding to the physical label is a channeled product. If verification passes, the component can be sold at the sales end. If verification fails, the audit end will manually audit the component and report the audit information. If the component is determined to be a channeled product, the component can be marked as an exception in the database storing the component information.

[0023] However, the related methods of identifying parallel-selling parts through physical labels are highly dependent on manual labor. For example, physical labels need to be manually scanned, which is prone to omissions or misjudgments, and the verification efficiency is low. In addition, physical labels are usually exposed on the surface of the parts and are susceptible to physical wear. In addition, physical labels are easy to be counterfeited, which may lead to the identification of parallel-selling parts as regular parts. Therefore, the identification accuracy is low. Furthermore, the verification process relies on offline processing by remote servers. For example, the method of identification through physical labels can only be verified offline. For example, the scanning device needs to pre-download the list of valid equipment for the day, but the valid equipment list cannot be updated in real time in an offline environment, making it difficult to manage in real time. In addition, the related methods lack a complete recording mechanism, making it difficult to provide support for subsequent audits.

[0024] In view of this, an embodiment of the present application provides a component verification method, including: determining a target verification phase and a corresponding target verification item for the component to be verified according to the verification priority of the component to be verified, the target verification phase including one of the following: a hardware initialization phase initiated by the hardware management component, a boot loading phase, and a firmware main program running phase, wherein the hardware initialization phase is used to perform a full verification of the component, the boot loading phase is used to perform a core identity attribute verification of the component, and the firmware main program running phase is used to verify the basic identity attribute of the component; in the target verification phase, the target verification item and the target device identifier are matched with an identifier mapping relationship set, and the identifier mapping relationship set includes a mapping relationship between multiple verification items and multiple device identifiers; if the match is successful, the timing operation data of the component to be verified in the device is read, and the timing operation data is matched with the standard component operation baseline of the device; if the match is successful, it is determined that the verification of the component to be verified is passed, wherein the standard component operation baseline includes the operation baseline of the standard component allowed to be accessed by the device.

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

[0026] The components to be verified may include all or part of the components in device 210. For example, the components to be verified may include component A 211, component B 212, and component N 213. After the components to be verified are determined, a component verification method may be executed. For example, the component verification method may be executed by a baseboard management controller (BMC) in device 210. The component verification method includes: determining a target verification phase and corresponding target verification items for the component to be verified based on the verification priority of the component to be verified, where the target verification phase includes one of the following: a hardware initialization phase initiated by a hardware management component, a boot loading phase, or a firmware main program execution phase; in the target verification phase, matching the target verification items and a target device identifier with an identifier mapping relationship set, where the identifier mapping relationship set includes mapping relationships between multiple verification items and multiple device identifiers; if the match 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; and if the match is successful, determining that the component to be verified has passed verification, where the standard component operation baseline includes the operation baseline of the standard components allowed to be connected to the device.

[0027] The following will be based on Figure 2 The scene described by Figure 3~Figure 4 The component verification method of the embodiment of the present application is described in detail.

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

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

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

[0031] Optionally, the components to be verified may include predetermined components that need to be verified each time the server is started or each time a hot plug event occurs. For example, for components necessary for startup, such as the Central Processing Unit (CPU), the motherboard chipset, etc., these components will be verified according to a fixed process each time the device is powered on, thereby ensuring the credibility of the startup chain.

[0032] Components to be verified may also include newly connected components. For example, after inserting a new hard drive, expansion card, or other component, the component needs to be verified to determine whether the newly connected component is a counterfeit component. For example, verification can be performed when the component is first connected to the device.

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

[0034] Optionally, different verification priorities may correspond to different verification stages and verification items. For example, for the component to be verified with the highest priority, verification may be performed at the earliest verification stage, such as during the hardware initialization stage, due to its greater importance, and the verification items may include more content. However, for the component to be verified with a lower priority, verification may be performed at a later stage, and the verification items for the component to be verified with a lower priority may include fewer contents than those for the component to be verified with the highest priority. Verification items may include, for example, the component manufacturer's digital signature, the component's unique identifier, etc.

[0035] Optionally, the hardware management component may include a baseboard management controller, which may perform verification of target verification items of the components 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 running 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 these highest-priority components are more important and require strict identity verification, they can be fully verified. This full verification can include verifying all verification items.

[0037] During the hardware initialization phase, all resources in the hardware initialization phase 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 has not loaded non-core drivers. The bus and computing power only serve the initialization of the highest priority components, and there is no resource competition.

[0038] In addition, by giving priority to completing the verification of more important components at the earliest stage of baseboard management controller startup, risks can be intercepted before other system functions are activated, cutting off the transmission path of safety hazards at the source.

[0039] Optionally, the boot loading phase is used to perform core component identity attribute verification. If full verification is performed on all components, and all verification is performed during the hardware initialization phase, it will consume a large amount of resources and may cause the baseboard management controller to fail to start due to insufficient resources. Therefore, it is possible to verify less important components (such as medium-priority components) during the boot loading phase. This staggers resource usage, avoids resource overload during the hardware initialization phase, and ensures that the baseboard management controller can complete startup stably.

[0040] Core identity attribute verification can include verification of higher-priority items within the verification project. Because the identity restrictions for less important components can be less stringent than for the highest-priority components, only the core identity attributes of medium-priority components are verified, eliminating the need for a full verification. This allows for lightweight and efficient verification, improving verification efficiency and reducing resource consumption while ensuring component safety.

[0041] Optionally, the firmware main program running phase is used to verify the basic identity attributes of the component. The basic identity attribute verification may include verifying items with lower importance among the verification items.

[0042] Less critical components (e.g., the lowest priority components) can be verified during the main firmware execution phase. These components typically do not impact system security or core functionality startup, so they can be verified at the end of the baseboard management controller startup phase, avoiding the use of limited resources in earlier phases. By performing only basic identity attribute verification, unnecessary computing resources can be avoided.

[0043] In operation S320 , in the target verification phase, the target verification item 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 is located. The device identifier is used to uniquely identify the identity of the device, for example, uniquely identify the identity of the device where the component to be verified is located. Different devices may have different manufacturer digital signatures, component unique identifiers, etc. of standard components that are allowed to access the device. An identification mapping relationship set may be pre-built, and the identification mapping relationship set includes mapping relationships between multiple verification items and multiple device identifiers. For example, the identification mapping relationship set includes that the component unique identifier of a component corresponding to the device identifier XXXXX1 should be 000000X. For example, the identification 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 content of the component database, which can take effect without restarting the server.

[0045] For example: when the verification item includes a component unique identifier, the device identifier of the device where the component to be verified is located is XXXXX1, and the component unique identifier of the component to be verified is 000011X, the target verification item and the target device identifier are matched with the identifier mapping relationship set. Since the identifier mapping relationship set includes that the component unique identifier of a component corresponding to the device identifier XXXXX1 should be 000000X, and the component unique identifier of the component to be verified is 000011X, and the device identifier of the device where the component to be verified is located is XXXXX1, the target verification item and the target device identifier fail to match the identifier mapping relationship set. When the target verification item and the target device identifier fail to match the identifier mapping relationship set, the verification of the component to be verified fails, indicating that the component to be verified is not a standard component that is allowed to be connected to the device where the component to be verified is located, which may affect the performance of the device or cause hardware incompatibility issues.

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

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

[0048] Optionally, a successful match may include all target verification items being matched successfully, while a match fails when any target verification item is not matched successfully. When the verification of the component to be verified fails, strategies such as disabling, warning, and logging may be executed on the component that failed the verification, and the verification results may be reported to the management system so that the component that failed the verification can be processed in a timely manner.

[0049] When it is determined that the target verification item and the target device identification and identification mapping relationship set match successfully, further verification can be performed. For example, the operation data of the component to be verified in the device within a certain period of time can be obtained to obtain the timing operation data. When the timing operation data has a high degree of similarity with the standard component operation baseline (that is, the match is successful), it means that the operation status of the component to be verified is consistent with the operation status of the standard component allowed to access the device, and it is determined that the verification of the component to be verified has passed.

[0050] Standard components (such as power supplies, fans, and hard drive backplanes) allowed for device access are consistent in manufacturing processes, component selection, and firmware consistency. Therefore, their operating behavior (such as power consumption, temperature response, and communication latency) under different operating conditions is predictable. However, abnormal components, such as refurbished parts, often exhibit systematic behavioral differences from standard components due to the use of inferior components, different batch processes, or non-original firmware. Therefore, a model can be used to generate an operating baseline for the standard components allowed for device access (also known as a standard component operating baseline). During device operation, operating data from the components to be verified is collected in real time and compared to determine if any anomalies exist in the components to be verified. The model used to generate the standard component operating baseline can be customized. For example, a lightweight model can be deployed to the file system of the baseboard management controller (BMC). During device operation, the BMC can periodically collect behavioral data from the components to be verified and input it into the model for inference. If the time-series operating data is determined to be inconsistent with the device's standard component operating baseline, an alarm can be generated or the functionality of the component to be verified can be restricted.

[0051] During the model training phase, a large amount of operating 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 training models can be used according to actual needs to learn the distribution boundaries of the identification mapping relationship set.

[0052] Optionally, if the target verification item fails to match the target device identifier and the identifier mapping relationship set, 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 baseboard management controller to define the measures to be taken when a component that fails verification is detected, such as disabling the device, recording a log, triggering an alarm, etc.

[0053] According to an embodiment of the present application, according to the verification priority of the component to be verified, the target verification stage and the corresponding target verification item for the component to be verified are determined. Compared with the full verification method in which the same verification content is uniformly executed on all hardware components and the verification process is executed serially, the verification efficiency can be improved; by first matching the target verification item and the target device identifier with the identifier mapping relationship set to perform a 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, the hardware components can be identified and verified in detail, the verification accuracy is improved, and it is ensured that the component can only match the specified device type and product model. The manual dependence of the verification process is low and the verification efficiency is high. Through the hardware initialization stage for performing full verification of the component, the boot loading stage for performing core identity attribute verification of the component, and the firmware main program running stage for performing basic identity attribute verification of the component, hierarchical verification and resource peak shifting of the component can be achieved, while completing the component verification efficiently and accurately, ensuring the reliability and resource utilization of the hardware management component startup.

[0054] According to an embodiment of the present 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: component identification, component type, and component security credentials of the component to be verified.

[0055] Optionally, the first priority can be the highest priority, and the first priority can be assigned to components to be verified that are of higher importance, such as the CPU, memory, motherboard and other core components. Verification of the first-priority components is performed during the hardware initialization phase. On the one hand, during the hardware initialization phase, system resources (such as bus bandwidth and computing power) are relatively idle, and full verification of component identification, component type, and component security credentials can be concentrated. On the other hand, immediate verification during the startup phase of the hardware management component can ensure that the core components are trustworthy. If the verification fails, the startup can be directly terminated and a hardware alarm can be triggered.

[0056] Optionally, a full verification of component identification, component type, and component security credentials may be performed on the first-priority components to be verified, thereby ensuring the security of the core components.

[0057] By performing full verification of component identification, component type, and component security credentials on the highest-priority components to be verified during the hardware initialization phase, system resources can be efficiently utilized and the security of core components can be ensured.

[0058] According to an embodiment of the present 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 a boot loading stage; the verification items corresponding to the second priority include: component identification, component type, and at least part of the component security credentials of the component to be verified.

[0059] Optionally, the importance of the components to be verified corresponding to the second priority is lower than that of the components to be verified corresponding to the first priority. For example, the components to be verified corresponding to the second priority may be components to be verified of medium priority. The components to be verified corresponding to the second priority include, for example, hard disks and network cards. Verification of the components to be verified of the second priority may be performed during the boot loading phase, and may be completed during the gap between driver loading, without taking up additional startup time.

[0060] Optionally, the verification items of the component to be verified corresponding to the second priority may be less than the verification items of the component to be verified corresponding to the first priority. The verification items of the component to be verified corresponding to the second priority may, for example, only include part of the component identification, component type, and component security credentials of the component to be verified, for example, only include the component identification and component security credentials.

[0061] Since verifying all verification items will take up more verification time and consume more verification resources, by reducing the verification items of relatively less important components to be verified and performing verification during the boot loading phase, system resources can be saved and verification efficiency can be improved.

[0062] According to an embodiment of the present 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 components to be verified corresponding to the third priority level may be the components to be verified with the lowest priority level. 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 with lower importance, thereby prioritizing verification of more important components to determine component safety. Furthermore, the verification items corresponding to the third priority level may include fewer items than those corresponding to the second priority level. For example, the verification items corresponding to the third priority level may only include component identification.

[0064] By allocating 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 the present application, the component verification method also includes: in response to powering on the device and before the operating system of the device is started, scanning the hardware interface of the device to identify the component to be verified; and collecting the target component identification of the component to be verified through the hardware management component of the device.

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

[0067] The baseboard management controller communicates directly with connected components through the hardware interface, reading their identity information such as SVID, VPD, and firmware signature in real time. Since the collection process of this data is completely automatic within the server, there is no need to obtain it from external devices through the network. In addition, the verification of the target verification items is also performed during the startup phase of the hardware management component. The preliminary verification can be completed before the operating system starts, preventing some abnormal components from exploiting operating system vulnerabilities. Compared with related manual or remote verification methods, it can realize automatic data collection and local verification, avoid delays or tampering risks in data transmission, and realize real-time verification. It can also complete localized real-time verification of components without relying on external servers, which is suitable for network-restricted scenarios such as edge computing.

[0068] Optionally, the collected data may be encrypted and / or digitally signed. The encryption and digital signature methods may be configured based on actual needs and are not limited herein. For example, the collected data may be encrypted and digitally signed to protect data integrity. The signature may be checked during verification to ensure that the data has not been tampered with.

[0069] According to an embodiment of the present 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 match is passed when the similarity meets the target preset numerical condition, wherein the target preset numerical condition corresponds to the target operating time of the component to be verified in the device.

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

[0071] For example: In the early stage of connecting the component to the device (such as the first 3 days after connection), the component to be verified may undergo hardware initialization, firmware adaptation, and environmental adaptation (such as temperature and voltage stabilization), resulting in short-term fluctuations in parameters (such as power consumption). However, this is normal. If a lower threshold is set, normal fluctuations may be easily misjudged as component abnormalities, thereby triggering invalid alarms.

[0072] When the component to be verified reaches a stable period after being connected to the equipment (such as one month after being connected to the equipment), the performance and parameters of the component to be verified enter a stable state after the initial running-in. At this time, fluctuations in the timing operation data are more likely to reflect component abnormalities. Therefore, a lower preset threshold can be set to increase sensitivity to minor abnormalities.

[0073] By calculating the similarity between the timing operation data and the standard component operation baseline, the match is determined to be passed when the similarity meets the target preset numerical conditions, and the target preset numerical conditions are determined based on the target operation time, which can reduce misjudgment and improve verification accuracy.

[0074] According to an embodiment of the present application, the component verification method also includes: in response to triggering a preset update condition, obtaining component update data through the hardware management component of the device; updating the identification 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 an update cycle, updating the device model, and updating the component identification of the standard component.

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

[0076] When adding a new standard component, you can determine the corresponding verification items such as the component identification, component type, and component security credentials, and add the mapping relationship between the verification items of the newly added standard component and the device identification in the identification mapping relationship set. When deleting a standard component, you can directly delete the mapping relationship between the verification items of the standard component and the device identification in the identification mapping relationship set.

[0077] Optionally, the manufacturer may update the standard parts list regularly. To avoid information lag caused by the long-term non-update of the identification mapping relationship set, thereby reducing the verification accuracy, a fixed update cycle (such as weekly or monthly) can be set according to actual needs. After the expiration, the component update data will be automatically obtained and the standard parts list will be updated.

[0078] Optionally, the manufacturer updates the standard parts list, for example, including updating the model of the equipment, updating the component identification of the standard parts, etc. Therefore, in response to updating the equipment model and updating the component identification of the standard parts, the identification mapping relationship can be updated in a timely manner to ensure that the identification mapping relationship includes the mapping relationship between the latest verification items and the equipment identification.

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

[0080] By updating the identity mapping set based on component update data, the identity mapping set can be kept consistent with actual component specifications, device requirements, and manufacturer standards, ensuring accurate and effective device verification of components and avoiding misjudgments or missed detections due to outdated information. Furthermore, to accommodate diverse hardware vendors and ever-changing device models, the system supports flexible updates of the identity mapping set, adapting to hardware from different manufacturers and ensuring good compatibility and scalability.

[0081] According to an embodiment of the present application, the component identification includes: supplier identification, component feature identification, wherein the component feature identification 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] For example, a vendor identifier uniquely identifies the manufacturer and supplier of a component. This identifier includes, for example, a subsystem vendor identifier. Component feature identifiers are derived from the key information set stored within the hardware component. The underlying driver can read the vendor identifier and component feature identifier of the component to be verified and structure them into a standard format for subsequent verification.

[0083] Component internal keys can include tamper-proof, embedded keys embedded in standard components, such as keys stored in fuses. When verifying component internal keys, the legitimacy of the key 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 the response with the key). Because the key cannot be extracted or copied from the hardware, even if the vendor identification and component feature identifiers are obtained in an unauthorized manner, the erroneous component will fail key verification.

[0084] A Physical Unclonable Function (PUF) is generated by exploiting random physical differences (such as tiny circuit defects and material inhomogeneities) that occur during the production of hardware such as chips. It is difficult to accurately replicate and is bound to the physical entity of the hardware.

[0085] Since supplier identification and component feature identification are easy to obtain and thus be exploited by abnormal components, while physical unclonable functions and component built-in keys are more secure, by combining multiple verification methods, the verification accuracy can be improved compared to the method of verifying only based on a single content.

[0086] According to an embodiment of the present 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 time series data can include the real-time current, voltage, and power of the component under verification, as acquired via a monitoring chip. Temperature response time series data can include the temperature rise / fall rate of the component under verification as its load changes (e.g., the slope of the temperature change from no load to full load). Response delay time series data can include the response time of the component under verification to commands. The frequency of error events reported by the component under verification, such as fan stalls, can be counted to generate corresponding error codes. Error code distribution time series data can include data on the time-varying distribution characteristics of error codes, such as frequency, number, and percentage. Sensor time series data can include the noise level of readings from sensors such as temperature and voltage sensors.

[0088] Through timing operation 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 angles to improve the verification accuracy.

[0089] Figure 4 The flowchart of a component verification method according to another embodiment of the present application is schematically shown.

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

[0091] In operation S410, components are produced, for example, by a supplier.

[0092] In operation S420, the supplier identification and the component characteristic identification are written in. For example, after the component is produced, the supplier or manufacturer may write the supplier identification and the component characteristic identification into the memory chip of the component.

[0093] In operation S430, the component is configured in a server device. For example, the component with the identification information written therein can be installed in a server, such as a server in a data center.

[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 the identifier mapping relationship set may be matched. If the match is successful, the timing operation data of the component in the device is read and the timing operation data of the component in the device is matched with the standard component operation baseline of the device. If the match is successful, it is determined that the component verification has passed.

[0095] In operation S450, if it is determined that the component has passed the verification, the component is operating normally. For example, if the verification has passed, it means that the component is a standard component that allows access to the server, and the server can support the normal operation of the component.

[0096] In operation S460, if it is determined that the component has failed verification, a log is recorded. For example, if it is determined that the component has failed verification, the system can automatically record detailed information about the verification failure, such as the component serial number, the reason for the verification failure, and a timestamp, and store the detailed information in a local log system for subsequent investigation and tracing.

[0097] In operation S470, an alarm is triggered. For example, after recording the log, the system may trigger an alarm mechanism to promptly remind the operation and maintenance personnel to handle the abnormality to prevent the abnormal component from affecting the stability of the server.

[0098] It should be noted that the component verification method of the embodiment of the present 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. Through the component verification method of the embodiment of the present application, it is possible to 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 the Internet of Things device management scenario. With the rapid growth of the number of Internet of Things devices, the requirements for the authenticity and security of the devices are gradually increasing. Through the component verification method of the embodiment of the present application, it is possible to identify safe components, prevent abnormal components from accessing the network, and ensure the security of data collection and transmission.

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

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

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

[0102] The first determination 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: a hardware initialization stage initiated by the hardware management component, a boot loading stage, and a firmware main program running stage. Among them, 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 verify the basic identity attributes of the component. In one embodiment, the first determination 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 to match the target verification item and the target device identifier with a set of identifier mapping relationships during the target verification phase. The set of identifier mapping relationships includes mapping relationships between multiple verification items and multiple device identifiers. In one embodiment, the first matching module 520 can be used to perform 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 if 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 determination 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 the standard component allowed to be connected to the device. In one embodiment, the second matching module 540 can be used to perform the operation S340 described above, which will not be repeated here.

[0106] According to an embodiment of the present application, the component verification device further includes an identification module and a collection module.

[0107] The identification module is used to scan the hardware interface of the device and identify the components to be verified in response to the device power-on startup and before the device operating system is started; the acquisition module is used to collect the target component identification of the component to be verified through the hardware management component of the device.

[0108] According to an embodiment of the present 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 whether the match is passed when the similarity meets the target preset numerical condition, wherein the target preset numerical condition corresponds to the target operating time of the component to be verified in the equipment.

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

[0111] The acquisition module is used to obtain component update data through the hardware management component of the device in response to triggering a preset update condition; the update module is used to update the identification mapping relationship set according to the component update data.

[0112] According to embodiments of the present application, any multiple modules among the first determination module 510, the first matching module 520, the second matching module 530, and the second determination module 540 may be combined into a single module, or any one of these modules may be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules may be combined with at least part of the functionality of other modules and implemented in a single module. According to embodiments of the present application, at least one of the first determination module 510, the first matching module 520, the second matching module 530, and the second determination module 540 may be at least partially implemented as a hardware circuit, 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 a package, an application-specific integrated circuit (ASIC), or may be implemented in hardware or firmware through any other reasonable means of circuit integration or packaging, or may be implemented in any one of software, hardware, and firmware, or any appropriate combination of these. Alternatively, at least one of the first determination module 510 , the first matching module 520 , the second matching module 530 , and the second determination module 540 may be at least partially implemented as a computer program module, which may perform corresponding functions when executed.

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

[0114] like Figure 6As shown, an electronic device 600 according to an embodiment of the present application includes a processor 601, which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 602 or a program loaded from a storage unit 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 a related chipset and / or a dedicated 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 the present application.

[0115] Various programs and data required for the operation of the electronic device 600 are stored in RAM 603. The processor 601, ROM 602, and RAM 603 are connected to each other via a bus 604. The processor 601 performs various operations of the method flow according to the embodiment of the present application by executing the programs in ROM 602 and / or RAM 603. It should be noted that the program can also be stored in one or more memories other than ROM 602 and RAM 603. The processor 601 can also perform various operations of the method flow according to the embodiment of the present application by executing the programs stored in one or more memories.

[0116] According to an embodiment of the present application, electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to bus 604. Electronic device 600 may also include one or more of the following components connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including devices such as a cathode ray tube (CRT), liquid crystal display (LCD), and speakers; a storage section 608 including a hard disk; and a communication section 609 including a network interface card such as a LAN card or modem. Communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. Removable media 611, such as a magnetic disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed in drive 610 as needed, so that computer programs read from the removable media can be installed into 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 may exist independently and not be incorporated into the device / apparatus / system. The computer-readable storage medium carries one or more programs, and when the one or more programs are executed, the method according to the embodiments of this application is implemented.

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

[0119] The embodiments of the present application also include a computer program product, which includes a computer program containing program code for executing the method shown in the flowchart. When the computer program product is run in a computer system, the program code is used to enable the computer system to implement the method provided in the embodiments of the present application.

[0120] The computer program executes the above functions defined in the system / device of the embodiment of the present application when the computer program is executed by the processor 601. According to the embodiment of the present application, the system, device, module, unit, etc. described above can be implemented by a computer program module.

[0121] In one embodiment, the computer program may be stored on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may be transmitted and distributed in the form of a signal on a network medium, downloaded and installed via the communication portion 609, and / or installed from a removable medium 611. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to wireless, wired, 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 a removable medium 611. When the computer program is executed by the processor 601, the above-mentioned functions defined in the system of the embodiment of the present application are performed. According to the embodiment of the present application, the systems, devices, means, modules, units, etc. described above can be implemented by computer program modules.

[0123] According to an embodiment of the present application, the program code for executing the computer program provided by the embodiment of the present application can be written in any combination of one or more programming languages. Specifically, these computer 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 computing device, partially on the user device, partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect via the Internet).

[0124] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

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

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

Claims

1. A component verification method, characterized in that: The method comprises: Determine, based on the verification priority of the component to be verified, a target verification phase and corresponding target verification items for the component to be verified, wherein the target verification phase includes one of the following: a hardware initialization phase initiated by a hardware management component, a boot loading phase, and a firmware main program running phase, wherein the hardware initialization phase is used to perform a full verification of the component, the boot loading phase is used to perform a core identity attribute verification of the component, and the firmware main program running phase is used to verify the basic identity attributes of the component; In the target verification phase, the target verification item and the target device identifier are matched with an identifier mapping relationship set, wherein the identifier mapping relationship set includes mapping relationships between multiple verification items and multiple device identifiers; If the match 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, it is determined that the component to be verified has passed verification, wherein the standard component operating baseline includes the operating baseline of the standard component that the device is allowed to access.

2. The method according to claim 1, characterized in that The verification priority includes a 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: component identification, component type, and component security credentials 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 part of the component identification, the component type, and the component security certificate 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 level includes the firmware main program running phase.

5. The method according to claim 1, wherein The method further comprises: In response to the device being powered on and starting up, before the operating system of the device is started, scanning the hardware interface of the device to identify the component to be verified; The target component identification of the component to be verified is collected through the hardware management component of the device.

6. The method according to claim 1, characterized in that The matching of the timing operation data with the standard component operation baseline of the device includes: Calculating the similarity between the time series operation data and the standard component operation baseline; If the similarity satisfies a target preset numerical condition, it is determined that the match is successful, wherein the target preset numerical condition corresponds to a target operating time of the component to be verified in the device.

7. The method according to claim 1, characterized in that The method further comprises: In response to triggering a preset update condition, obtaining component update data through the hardware management component of the device; Updating the identification 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 an update cycle, updating a device model, and updating a component identifier of a standard component.

8. The method according to claim 2, characterized in that The component identification includes: a supplier identification and a component feature identification, wherein the component feature identification is used to represent at least one of the following information of the component: component model, component serial number, and component production date; The component security credential includes at least one of the following: a component built-in key and a physical 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; a memory for storing one or more computer programs, It is characterized in 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