Methods, devices, electronic equipment, and storage media for identifying target events

Abstract

This application discloses a method, apparatus, electronic device, and storage medium for identifying target events, relating to the field of computer technology. The method for identifying target events includes: a baseboard management controller directly acquiring behavioral timing data of a target device in the current time period; subsequently, extracting behavioral timing features from the behavioral timing data; and then performing intent detection on the behavioral timing features to determine the target intent corresponding to the behavioral timing features. Event identification is then performed based on the target intent to determine the event identification result of the target device. By determining the target intent corresponding to the behavioral timing features through the baseboard management controller, event identification is performed based on the target intent. Since the baseboard management controller is independent of the main operating system and does not share processes with other processes, event identification can be performed quickly to obtain the event identification result, thereby enabling timely response to security threats.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device and storage medium for identifying target events. Background Technology

[0002] With the rapid development of cloud computing and data centers, computer equipment faces increasing threats, including malicious events at the hardware level such as unauthorized firmware loading, resource abuse, and unauthorized access attempts. These threats can not only lead to data breaches and device malfunctions, but also trigger more serious security incidents such as system crashes and large-scale service outages.

[0003] Currently, identifying these malicious events largely relies on operating system capabilities. Specifically, this involves acquiring relevant data from the target device at the operating system level and performing target event identification to determine the presence of malicious activity. However, because the operating system may share limited system resources with other processes, this can lead to poor real-time performance and an inability to respond promptly to security threats.

[0004] Therefore, how to promptly determine whether a malicious event has occurred has become an urgent problem to be solved. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, and storage medium for identifying target events, in order to at least solve the problem in related technologies where event identification is carried out at the operating system level, which may result in poor real-time performance and inability to respond to security threats in a timely manner because the operating system may share limited system resources with other processes.

[0006] This application provides a method for identifying target events, comprising: acquiring behavioral time-series data of a target device in the current time period; wherein the behavioral time-series data is obtained by monitoring the device behavior of the target device and is used to reflect the device behavior state of the target device in the current time period; determining behavioral time-series features of the target device based on the behavioral time-series data; performing intent detection on the behavioral time-series features to determine the target intent corresponding to the behavioral time-series features; and performing event identification on the target device based on the target intent to obtain the event identification result of the target device.

[0007] This application also provides a target event identification device, comprising: an acquisition module for acquiring behavioral time-series data of a target device in the current time period; wherein the behavioral time-series data is obtained by monitoring the device behavior of the target device and is used to reflect the device behavior state of the target device in the current time period; a first determination module for determining behavioral time-series features of the target device based on the behavioral time-series data; a second determination module for performing intent detection on the behavioral time-series features to determine the target intent corresponding to the behavioral time-series features; and a third determination module for performing event identification on the target device based on the target intent to obtain the event identification result of the target device.

[0008] This application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the above-described target event recognition method.

[0009] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the above-described target event recognition method.

[0010] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method for recognizing any of the target events described above.

[0011] This application enables the baseboard management controller to directly acquire the behavioral timing data of a target device within the current time period. Subsequently, behavioral timing features are extracted from the data, and intent detection is performed on these features to determine the target intent corresponding to each feature. Event recognition is then performed based on the target intent to determine the event recognition result for the target device. By determining the target intent corresponding to the behavioral timing features through the baseboard management controller, and then performing event recognition based on that intent, the system can quickly perform event recognition and obtain results, enabling timely responses to security threats, as the baseboard management controller is independent of the main operating system and does not share processes with other processes. Attached Figure Description

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

[0013] Figure 1 A structural block diagram of a computer device for a target event identification method provided in an embodiment of this application;

[0014] Figure 2 One of the flowcharts for a target event identification method provided in an embodiment of this application;

[0015] Figure 3 A second flowchart illustrating a method for identifying a target event provided in an embodiment of this application;

[0016] Figure 4 A flowchart illustrating a method for identifying a target event provided in an embodiment of this application;

[0017] Figure 5 A timing diagram of a target event identification method provided in an embodiment of this application;

[0018] Figure 6 This is a structural block diagram of a target event identification device provided in an embodiment of this application. Detailed Implementation

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

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

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

[0022] The target event identification method embodiments provided in this application can be executed in a computer device or similar computing device. (See reference) Figure 1 As shown, Figure 1 This is a hardware structure block diagram of a computer device for a target event identification method according to an embodiment of this application. For example... Figure 1 As shown, a computer device may include one or more ( Figure 1Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a central processing unit (CPU), a microprocessor (MCU), or a programmable logic device (FPGA), etc.) and a memory 104 for storing data are also shown. The computer device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the computer device described above. For example, the computer device may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0023] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the target event identification method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to computer devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0024] The transmission device 106 is used to receive or transmit data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the computer equipment. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0025] This application provides a method for identifying target events, applied to the BMC (Baseboard Management Controller) on the aforementioned computer device. The method is described in detail below, along with its execution flow. Figure 2 As shown, the method includes the following steps S202-S208:

[0026] S202, Obtain the behavioral time-series data of the target device in the current time period; wherein, the behavioral time-series data is obtained by monitoring the device behavior of the target device and is used to reflect the device behavior status of the target device in the current time period.

[0027] It should be noted that the target device is the hardware component of the computer device, such as PCIe (Peripheral Component Interconnect Express) device. PCIe devices can specifically include network cards, storage devices, etc., and are an important part of the function and performance of the computer device.

[0028] Behavioral timing data refers to data obtained by monitoring the real-time behavioral sequences of a target device (such as a PCIe device) at preset time intervals. Behavioral timing data exists in time series form and reflects the dynamic behavioral characteristics and state changes of the target device within that time period. Behavioral timing data includes, but is not limited to: register operation data, I / O request (Input / Output Request) data, resource usage data, device state change data, and error code records.

[0029] Specifically, BMC can record the monitored information as behavioral time-series data, identified by precise timestamps. This behavioral time-series data includes detailed information such as the specific type of device behavior, parameters, and occurrence time, forming a time-series log of device behavior.

[0030] S204, Determine the behavioral timing characteristics of the target device based on behavioral timing data.

[0031] It should be noted that behavioral temporal features are extracted from the behavioral temporal data of the target device and represent the characteristics of the target device's behavioral patterns within the current time period. Behavioral temporal features can help understand the target device's workflow, identify abnormal behaviors, and predict the device's state change trends, which is crucial for real-time device monitoring, security threat detection, and fault prediction.

[0032] S206, Perform intent detection on behavioral temporal features to determine the target intent corresponding to the behavioral temporal features.

[0033] Specifically, intent detection is performed based on behavioral temporal characteristics to analyze patterns and trends in the target device's behavior. For example, if a target device frequently attempts to access sensitive areas or makes a large number of I / O requests at abnormal times, this may indicate malicious behavior.

[0034] S208, perform event recognition on the target device based on the target intent, and obtain the event recognition result of the target device.

[0035] In an exemplary embodiment, event recognition of a target device based on a target intent and determination of the event recognition result of the target device include: mapping the target intent to a pre-defined event classification table to determine the event type corresponding to the target device; the event classification table includes: multiple event types and intents matching the multiple event types; performing hierarchical processing on the event types corresponding to the target device to determine the event recognition result of the target device.

[0036] As we can understand, event recognition refers to the process of analyzing and interpreting target intent to identify whether the device behavior of a target device conforms to a predefined event category, and then determining whether the behavior poses a security threat (i.e., whether there is a malicious event). In security protection, event recognition can help users promptly detect and respond to potential device malfunctions, performance problems, or malicious attacks.

[0037] An event classification table is a database or set of rules used to map different behavioral patterns to specific event types. It contains a series of event types and the intents that match those event types. The design of the event classification table is based on an understanding of normal device operation patterns and analysis of known anomalous behaviors and security attacks.

[0038] Tiered processing refers to taking different levels of response measures based on the type of event corresponding to the target device. This approach, based on the severity and urgency of the event, ensures efficient resource utilization and timely event response.

[0039] In some embodiments, when classifying event types, they can be handled separately as low-risk, medium-risk, and high-risk events. Specifically, for low-risk events, such as minor device resource overload or abnormal operation, logs can be logged and monitoring can be performed, but no immediate strong measures will be taken. For medium-risk events, such as potential malware activity or misconfigured devices, certain functions or access permissions of the target device can be restricted, and warnings can be triggered to notify the administrator for manual inspection. For high-risk events, such as clear attack behavior or device firmware tampering, isolation measures can be taken immediately, the target device's connection to the network can be cut off, and an emergency repair process can be initiated.

[0040] In the above embodiments, the event type can be determined based on the target device's target intent, and then the event can be classified and processed according to the event classification table to minimize the impact of potential threats on computer devices, while ensuring that the normally operating target device is not excessively interfered with.

[0041] In steps S202-S208 above, the baseboard management controller directly acquires the behavioral timing data of the target device in the current time period. Then, it extracts behavioral timing features from the behavioral timing data and performs intent detection on these features to determine the target intent corresponding to the behavioral timing features. Based on the target intent, event recognition is performed to determine the event recognition result of the target device. By determining the target intent corresponding to the behavioral timing features through the baseboard management controller, event recognition is performed based on the target intent. Because the baseboard management controller is independent of the main operating system and does not share processes with other processes, event recognition can be performed quickly, obtaining the event recognition result and enabling timely response to security threats.

[0042] In some exemplary embodiments, the behavioral timing data includes: register timing data, bus timing data, and resource timing data; determining the behavioral timing characteristics of the target device based on the behavioral timing data includes: fusing the register timing data, bus timing data, and resource timing data to obtain fused timing data; inputting the fused timing data into a pre-trained feature extraction model, which extracts features from the fused timing data based on a set feature extraction dimension to obtain multiple feature vectors corresponding to the fused timing data; the feature extraction dimension includes at least one of the following: correlation dimension, frequency dimension, and order dimension; and determining the behavioral timing characteristics of the target device based on the multiple feature vectors.

[0043] Behavioral timing data typically includes the following categories: Register timing data: Records read and write operations of registers (such as status registers, control registers, etc.), including timestamps of operations, register addresses, read and write values, etc. Analyzing register timing data reveals the frequency and patterns of changes in the device's internal state. Bus timing data: Reflects detailed information about the target device's communication with other components via a bus (such as the PCIe bus), including data transmission time, packet size, communication frequency, etc. Bus timing data helps in understanding the device's load and communication efficiency. Resource timing data: Records the target device's resource usage, such as CPU utilization, memory usage, power consumption, etc. Resource timing data reveals the resource consumption trends of the device at different points in time, which is very useful for identifying abnormal loads or resource contention.

[0044] Understandingly, time-series data fusion refers to integrating behavioral time-series data from different sources into a comprehensive dataset for more complete analysis of target device behavior. In time-series data fusion, register time-series data, bus time-series data, and resource time-series data can be aligned chronologically and merged into a single data stream containing all relevant behavioral information. The purpose of this is to capture potential correlations between device behaviors, such as the relationship between register read / write operations and resource consumption, or the correlation between bus communication modes and device states.

[0045] Specifically, the fused time-series data is input into a feature extraction model. A feature extraction model is a machine learning model used to extract meaningful feature vectors from the fused time-series data. It can be a neural network-based model, such as LSTM (Long Short-Term Memory), or other types of data analysis models. The main function of the feature extraction model is to transform high-dimensional raw data into low-dimensional feature vectors, which are easier to process and analyze while preserving key information from the data.

[0046] Feature extraction dimensions refer to the key aspects focused on when extracting feature vectors, including: **Correlation Dimension:** Analyzing the correlation between different behaviors, such as the relationship between register operations and resource consumption, or the connection between bus communication modes and device state changes. **Frequency Dimension:** Focusing on the frequency of device behaviors, such as the number of register read / write operations, the frequency of bus communication, and the stability of resource usage. The frequency dimension can reveal patterns in device operations and help identify abnormal operations. **Sequence Dimension:** Analyzing the temporal sequence of device behaviors, such as the order of register read / write operations and the time sequence of bus data transmission. The sequence dimension helps understand the logical flow of device task execution and is key to identifying complex attack intentions.

[0047] Multiple feature vectors are a series of numerical representations extracted by the feature extraction model from fused time-series data. Each feature vector represents a specific aspect of the time-series data. For example, one feature vector might describe the frequency distribution of register operations, while another might reflect the time-series changes in resource consumption. By combining multiple feature vectors, a multidimensional representation of device behavior can be constructed, which is crucial for subsequent behavior analysis, anomaly detection, and intent recognition.

[0048] In some embodiments, after obtaining multiple feature vectors, the temporal characteristics of the target device's behavior are determined based on a comprehensive analysis of these feature vectors. This may involve further processing of the feature vectors, such as statistical analysis, cluster analysis, or fusion through another layer of machine learning models to obtain a more abstract and representative set of features. Temporal behavioral characteristics can reflect the patterns, trends, and anomalies of a target's behavior within a specific time window, and are of significant value for real-time monitoring of device status, predicting future behavior, and identifying potential threats.

[0049] In the above embodiments, behavioral time-series features can be extracted based on fused time-series data, providing data support for real-time monitoring, fault prediction, and security protection of target devices. This helps users understand device status more accurately, respond to abnormal situations in a timely manner, and maintain the stability and security of computer equipment.

[0050] In some exemplary embodiments, the behavioral temporal features include: multiple feature vectors; intent detection is performed on the behavioral temporal features to determine the target intent corresponding to the behavioral temporal features, which can be achieved through methods such as... Figure 3 The steps S302-S308 shown are implemented as follows:

[0051] S302, Match multiple feature vectors with a set target feature vector to determine the similarity between the multiple feature vectors and the target feature vector; wherein, the target feature vector is obtained by vectorizing the event content of the target event;

[0052] S304, determine the weight coefficients corresponding to the multiple similarities;

[0053] S306, based on multiple similarities and the weight coefficients corresponding to the multiple similarities, a weighted result is obtained;

[0054] S308, determine the target intent corresponding to the temporal features of the behavior based on the weighted results.

[0055] The target feature vector is obtained by vectorizing the event content of known behavioral patterns or events. These vectors represent a set of features for a specific intent or event type, such as the behavioral characteristics of a malicious event. When generating target feature vectors, historical data or expert knowledge can be used, and machine learning algorithms can be employed to convert event content into numerical vector form.

[0056] Multiple feature vectors extracted from device behavior time-series data (each vector representing a behavioral characteristic, such as register operation frequency, resource usage trend, etc.) are compared with a predetermined target feature vector to calculate their similarity. Similarity calculation methods can include Euclidean distance, cosine similarity, etc. The smaller the similarity value, or the closer it is to 1, the higher the matching degree between the behavioral time-series feature and the target feature vector; correspondingly, the weight coefficient value is also higher. The weight coefficient can be set based on expert experience, historical data analysis, or the output of a machine learning model.

[0057] Based on the similarity between each feature vector and the target feature vector, and the corresponding weight coefficient, all similarity calculation results are weighted and summed. The weighted result represents the comprehensive matching degree between the temporal features of device behavior and different target intentions. A series of thresholds can be set to determine the target device's behavioral intention based on the magnitude of the weighted result. For example, if the weighted result exceeds a preset malicious attack threshold, the target device is judged to be under malicious attack; if the weighted result is within the suspicious behavior threshold range, it is marked as suspicious behavior, requiring further monitoring or investigation.

[0058] Finally, based on the weighted results and set thresholds, the target intent is classified into different intent levels, such as normal intent, suspicious intent, and malicious attack intent. This classification helps in taking appropriate response measures, such as alerts, access restrictions, or device isolation.

[0059] In the above embodiments, by comparing and matching multiple feature vectors in the behavioral temporal features with predefined target feature vectors to calculate similarity, and then weighting them according to the weight coefficient of each feature vector, a comprehensive weighted result can be obtained to determine the target intent of the device. This process relies on accurate target feature vector generation, reasonable weight coefficient setting, and sensitive threshold decision-making, and is a key step in realizing dynamic security monitoring and intent recognition.

[0060] In some exemplary embodiments, before acquiring the time-series data of the target device's behavior in the current time period, the method for identifying the target event further includes: acquiring the target device's environmental state data and device identifier; determining a private key matching the target device based on the device identifier, and determining the target device's signature based on the environmental state data; encrypting the signature according to the private key to obtain a trusted anchor point for the target device, and performing a hash calculation on the trusted anchor point and a set time parameter to obtain a dynamic trusted anchor point; and performing environmental verification on the target device based on the dynamic trusted anchor point to determine the environmental verification result of the target device.

[0061] It's important to note that environmental status data can include information about the target device and its surrounding environment, such as temperature, humidity, power status, and any physical or logical environmental parameters that may affect the device's operating conditions. This data is crucial for assessing whether the device's operating environment is functioning correctly. Each target device has a unique identifier, such as a BDF identifier (Bus / Device / Function), which uniquely identifies a device within the PCIe bus architecture of a computer. The device identifier is key information for ensuring the trustworthiness of the device's identity.

[0062] Specifically, based on the device identifier, a private key matching the target device is determined. The private key, used in encryption algorithms to encrypt or decrypt data, is held only by the legitimate holder and is central to establishing device trust relationships. Based on environmental state data, a signature related to the current environmental state can be generated. This signature is a digest of the device's current state and can be used for subsequent verification to ensure the device state has not been tampered with. The device signature is encrypted using the determined private key to generate a trusted anchor. The trusted anchor is an encrypted data block containing the signature of the device's current environmental state, and can only be decrypted by an entity holding the correct private key, ensuring data confidentiality and integrity. The generated trusted anchor is combined with a set time parameter (such as a timestamp) for hash calculation. The dynamic trusted anchor is the output of this process; it incorporates time information, ensuring the timeliness and dynamism of the trusted state and preventing potential risks associated with static anchors (e.g., being recorded and replayed).

[0063] In some embodiments, the environmental state of a target device can be verified based on a dynamic trusted anchor. When verifying the environmental state of the target device, it can be compared with a preset trusted baseline (e.g., the signature of the target device under normal operating conditions) and the time parameters can be verified to determine that the environmental state of the target device has not been tampered with and matches the expected trusted state. The result of the environmental verification can clearly determine whether the target device is currently in a trusted state. If the environmental state is consistent with the preset baseline and the time parameters of the dynamic trusted anchor are within a valid range, the environment in which the target device is located will be considered trusted, indicating that no malicious event has occurred, and the target device is allowed to continue to operate normally or start up. Conversely, if any mismatch or anomaly is found, the environment in which the target device is located will be marked as untrusted, and corresponding security response measures can be initiated, such as isolating the device, initiating a repair process, or sending an alarm notification.

[0064] In the above embodiments, before acquiring the target device's behavioral time-series data for the current time period, environmental state data and device identifiers are collected, a trusted anchor point is generated by encrypting the device signature using a private key, and a dynamic trusted anchor point is calculated by combining time parameters. This ensures the trustworthiness of the device state and provides a secure foundation for the subsequent collection and analysis of behavioral time-series data.

[0065] In some exemplary embodiments, performing environmental verification on the target device based on the dynamic trusted anchor point and determining the environmental verification result of the target device includes: performing environmental verification on the target device based on the dynamic trusted anchor point to obtain a first verification result, and sending the dynamic trusted anchor point to a verification device connected to the target device and obtaining a second verification result fed back by the verification device; and determining the environmental verification result of the target device based on the first verification result and the second verification result.

[0066] It should be noted that after obtaining the dynamic trusted anchor of the target device, BMC performs a preliminary verification locally. This process typically includes, but is not limited to: verifying the time validity of the dynamic anchor: checking whether the time parameter in the dynamic trusted anchor is within a preset valid window to ensure the timeliness of the information; comparing device signatures: decrypting the signature in the dynamic trusted anchor using the public key matching the target device, and then comparing it with the signature directly obtained from the target device in the current environment to verify the consistency of the device state; comparing environmental state data: comparing the environmental state data in the dynamic trusted anchor with the environmental data currently perceived by BMC to confirm whether there are any signs of anomalies or tampering. Based on the above verifications, BMC generates a preliminary verification result to determine whether the device's environmental state is trustworthy. If all verification items pass, the first verification result will indicate that the device's environmental state is trustworthy; conversely, if any verification item fails, the first verification result will indicate that the device's environmental state is untrustworthy.

[0067] In addition to local verification, BMC also sends the dynamic trusted anchor to a verification device connected to the target device (which can be cloud-based or a dedicated verification device). This step adds an extra layer of security to ensure the reliability of the information. The verification device receiving the dynamic trusted anchor also performs a similar first-step verification process. After completing the verification, the verification device will feed back the second verification result to BMC, which typically includes information on whether the verification passed or failed.

[0068] After receiving the first and second verification results, the BMC performs a comprehensive analysis to determine the final environmental verification result for the target device. This process includes: Consistency check: Comparing the first and second verification results to see if they are consistent. If both verification results indicate that the device's environmental state is trustworthy, the final environmental verification result will be that the target device's environmental state is trustworthy. Arbitration mechanism: If there is a contradiction between the first and second verification results (e.g., one indicates trustworthiness, the other untrustworthiness), the BMC may need to activate an arbitration mechanism to make a final decision based on preset rules or feedback from a more trustworthy verification device. Finally, based on the environmental verification result, the BMC will implement corresponding security policies, such as allowing the device to start normally, restricting certain functions of the device, or completely isolating the device until manual inspection.

[0069] In the above embodiments, by verifying dynamic trusted anchors both locally and remotely, BMC can comprehensively assess whether the current environmental state of the target device is trustworthy. This process increases the depth and breadth of security protection. Even if the local security environment is compromised, the security and integrity of the entire system can be maintained through external verification.

[0070] In some exemplary embodiments, before acquiring the behavioral time-series data of the target device in the current time period, the method further includes: acquiring the firmware image of the target device; detecting the firmware image to obtain a detection result; and, if the detection result indicates that the firmware image has not been modified, loading the firmware image to start the target device.

[0071] As is understandable, a firmware image is a complete copy of all the code and data required to boot the target device. When booting the target device, the BMC first reads the firmware image from the target device's non-volatile memory. After acquiring the firmware image, the BMC performs an integrity check. This is typically done by calculating the hash value of the firmware image and comparing it to a pre-stored hash value. If they match, the firmware image has not been altered. Additionally, the BMC checks the digital signature of the firmware image to verify that it comes from a trusted source, such as the device manufacturer or system management software. Verifying the digital signature helps ensure that the firmware has not been maliciously tampered with or replaced. The check process generates a result detailing the integrity status of the firmware image. If the hash value of the firmware image matches the pre-stored value and the digital signature is valid, the result indicates that the firmware image has not been altered, and the firmware is considered safe to load.

[0072] Once the detection confirms that the firmware image has not been altered, meaning the firmware is in a trusted state, the BMC will initiate the firmware image loading process. The loading process involves copying the firmware code from storage into memory for execution. After the firmware image is successfully loaded, the target device will begin the boot process according to the instructions in the firmware image.

[0073] In the above embodiments, by performing rigorous security checks before loading the firmware image, it is possible to determine whether a malicious event has occurred, thereby effectively preventing infection or attacks by malicious firmware. This process not only improves boot security but also reduces instability and security risks caused by firmware anomalies.

[0074] In some exemplary embodiments, detecting the firmware image and obtaining detection results includes: determining the full hash value of the firmware image and determining the component hash values ​​of N firmware sub-images; wherein N is an integer greater than 1; the firmware sub-images are obtained by splitting the firmware image based on a set file splitting step size; comparing the full hash value with the full hash standard value stored in the secure storage unit of the target device to obtain a first comparison result, and comparing the component hash values ​​with the component hash standard values ​​stored in the secure storage unit of the target device to obtain a second comparison result; and obtaining a detection result based on the first comparison result and the second comparison result.

[0075] Specifically, after acquiring the firmware image, BMC calculates the hash value of the entire firmware image, using strong hash algorithms such as SHA-256 or SHA-512. The full hash value reflects the integrity of the firmware image as a whole. BMC also divides the firmware image into N sub-images based on a set file splitting step size, and calculates the hash value for each sub-image individually. Here, N is an integer greater than 1, and the number of sub-images depends on the size of the firmware image and the required level of granularity for detection. This layered detection mechanism enables more detailed identification of changes or corruption within the firmware.

[0076] BMC compares the calculated full hash value with the full hash standard value stored in the target device's secure storage unit. The full hash standard value is typically generated at the time of device manufacturing or after the last security update and serves as a reference to the original state of the firmware image. If the calculated full hash value matches the full hash standard value, the first comparison result is "match"; otherwise, it is "dismatch". Similarly, BMC compares the component hash values ​​of N firmware sub-images one by one with the corresponding component hash standard values ​​in the secure storage unit. If all component hash values ​​match the component hash standard value, the second comparison result is "match"; if even one sub-image's component hash value does not match the component hash standard value, the second comparison result is "dismatch".

[0077] Based on the first and second comparison results, BMC will synthesize the final detection result. If both the first and second comparison results are consistent, the detection result indicates that the firmware image has not been modified and can be safely loaded; if either comparison result is "inconsistent," the detection result indicates that the firmware image may have been modified or corrupted and should not be loaded.

[0078] In the above embodiments, firmware image detection is a multi-layered, multi-step process designed to ensure the integrity and security of the firmware before its execution. By comparing the full hash value and multiple component hash values, it is possible to effectively detect whether the firmware has been maliciously tampered with or subjected to unauthorized modifications. This detection mechanism is a crucial step in the secure boot process of a server, helping to prevent system crashes, data leaks, or other security threats caused by firmware issues.

[0079] In some exemplary embodiments, before detecting the firmware image and obtaining the detection result, the method for identifying the target event further includes: splitting the firmware image of the target device based on a set file splitting step size to obtain multiple consecutive firmware sub-images; for a first firmware sub-image among the multiple firmware sub-images, determining the component hash standard value of the first firmware sub-image based on the image data of the first firmware sub-image; for a second firmware sub-image among the multiple firmware sub-images, determining the component hash standard value of the second firmware sub-image based on the image data of the second firmware sub-image and the component hash standard value of the previous firmware sub-image of the second firmware sub-image; the first firmware sub-image is the first firmware sub-image among the multiple firmware sub-images; the second firmware sub-image is not the first firmware sub-image among the multiple firmware sub-images; storing the component hash standard values ​​of the multiple firmware sub-images in the secure storage unit of the target device; wherein, the full hash standard value is the component hash standard value of the last firmware sub-image among the multiple firmware sub-images.

[0080] Understandably, a reasonable file splitting step size can be determined, which dictates how many components the firmware image will be divided into. The choice of step size must be based on a balance between firmware size, performance requirements, and security considerations. Based on the set file splitting step size, the firmware image is divided into a series of consecutive firmware sub-images. Each firmware sub-image contains a portion of the firmware image's data, and the collection of these sub-images constitutes the complete firmware image.

[0081] For the first firmware sub-image (the first firmware sub-image), the component hash standard value is calculated directly based on its image data. This is typically done by applying a hash function (such as SHA-256, SHA-512, etc.) to generate a unique hash value, which serves as the integrity benchmark for that firmware sub-image. For each subsequent firmware sub-image (the second firmware sub-image and all subsequent firmware sub-images), the component hash standard value of the previous firmware sub-image is considered when calculating the component hash standard value. Specifically, the hash value calculation of the current firmware sub-image uses the component hash standard value of the previous firmware sub-image as one of the inputs, forming a chain structure. This approach improves the sensitivity of tamper detection because any tampering with a single sub-image in the firmware image will affect the component hash values ​​of all subsequent sub-images, causing integrity verification to fail.

[0082] Furthermore, the component hash standard value of each generated firmware sub-image is saved to the secure storage unit of the target device. The secure storage unit is a non-volatile storage area used to store critical security information that is not easily tampered with. The full hash standard value is actually the component hash standard value of the last firmware sub-image in the entire firmware sub-image. This is because the last hash value in the chain structure reflects the complete state of the entire firmware image. This full hash standard value is also saved to the secure storage unit as a benchmark for the integrity of the entire firmware image.

[0083] These stored hash standards play a central role in the security verification during device startup. They provide the expected state of the firmware image, allowing the BMC to compare the hash value of the current firmware image with these standards to detect any unauthorized alterations or corruption. This practice of pre-generating and storing hash standards ensures that even in the event of an attack or malfunction, firmware integrity checks can still be performed against the standards, making it a crucial component of the server's secure boot mechanism.

[0084] In the above embodiments, generating and storing the component hash standard value and the full hash standard value of the firmware sub-image are crucial steps to ensure that the firmware has not been tampered with. This process, through a pre-set file splitting step size and a chained hash algorithm, creates an unforgeable integrity proof for each part of the firmware image, providing a reliable benchmark for integrity checks during subsequent boot.

[0085] The embodiments described above are merely some embodiments of this application, and not all embodiments. To better understand the above methods, the following description, in conjunction with embodiments, illustrates the process, but is not intended to limit the technical solutions of the embodiments of this application. Specifically:

[0086] The Hardware Management Controller (BMC) in a server plays a crucial role in server management and maintenance. As an independent management subsystem on the server, the BMC's main functions include out-of-band management, remote control, fault diagnosis, configuration deployment, firmware upgrades, and secure boot verification. Currently, when identifying target events, such as determining whether a PCIe device has been maliciously attacked, relevant data from the PCIe device is typically obtained at the BIOS or operating system (OS) level. However, identifying target events through the BIOS or OS level has the following drawbacks: 1. High dependency: Requires the operating system to be running normally; if the operating system crashes or is attacked, status information cannot be obtained; 2. Poor real-time performance: Status updates are delayed, making it impossible to respond to security threats promptly; 3. Insufficient security: The operating system level is vulnerable to malware tampering, leading to unreliable status information. As a hardware management controller independent of the main system, the BMC possesses out-of-band management capabilities and can monitor hardware status in real time without relying on the operating system.

[0087] Based on this, embodiments of this application provide a method for identifying target events, executed by a baseboard management controller, which can promptly initiate event identification, effectively improving the timeliness of event identification. (Reference) Figure 4 The following is a flowchart of a target event identification method provided in an embodiment of this application:

[0088] The identification of target events typically includes: building a dynamic trusted foundation (i.e., detecting the physical environment in which the target device exists), pre-boot protection (i.e., detecting the firmware image of the target device), and runtime proactive defense (i.e., detecting the behavioral timing data of the target device) to determine whether a malicious attack exists, and then proceed with status reporting and intelligent repair. (Reference) Figure 5 The diagram shown is a sequence flow chart for each module mentioned above, including building a dynamic trusted foundation, pre-start protection, runtime proactive defense, and deploying status reporting and intelligent repair.

[0089] The construction of a dynamic and reliable foundation includes: multi-dimensional data acquisition: the temperature and humidity sensors and power supply monitoring units integrated in the BMC can collect physical environment data (ENV_DATA), such as temperature, humidity, and power supply; obtain bus environment data (BUS_DATA) through the PCIe link, such as link speed, signal attenuation, and load fluctuations; and obtain hardware characteristic data (HW_DATA) through the device interface, such as wafer defects, chip erase / write cycles, and PCIe interface voltage stability, forming a 128-dimensional data matrix.

[0090] Dynamic Trusted Credential Generation: The security chip uses the national cryptographic algorithm SM9 to convert ENV_DATA, BUS_DATA, and HW_DATA into a unified binary data stream. This binary data stream is then concatenated with the binary data of the device's UID (Unique Identifier) ​​and BDF identifier to form a continuous raw fused data string, avoiding fusion anomalies caused by differences in data format. The security chip calls the SM9 hash function H1, inputting the UID, BDF identifier, and a preset function identifier, to calculate the hash value of the corresponding identity identifier. This hash value is then combined with the master key to derive the target device's unique signature private key. Finally, the preprocessed raw data string is processed using hash function H2 to obtain a fixed-length hash digest, achieving data compression and standardization.

[0091] The security chip randomly selects a random number, calculates an intermediate value using the publicly available parameters of the SM9 algorithm, then performs a modulo operation based on this intermediate value and the data hash digest, and finally encrypts the result using a dedicated signature private key to generate an SM9 signature. This signature result achieves a deep fusion of the original data and the device identifier, containing both the characteristics of the data itself and binding unique device identity information.

[0092] The data and identifier fusion completed by the SM9 algorithm is only the foundation. It still requires steps such as time-series binding and simplification verification to generate dynamic trusted anchors. The specific steps are as follows: Binding dynamic time-series parameters: The fused SM9 signature result itself lacks dynamism. An additional timestamp parameter (such as a time segment accurate to the minute) can be added. The timestamp is then concatenated with the SM9 signature result to ensure that the input data differs every minute (e.g., every three minutes). Secondary hash simplification: The combined data of "signature result + timestamp" is hashed again to generate a fixed-length (e.g., 256 bits) hash value. This step compresses the data volume, facilitating caching and transmission, and further strengthens data uniqueness, avoiding redundant information from affecting anchor usage efficiency. Further, the hash value is validated to see if it conforms to a preset format (such as length and bit verification rules). If it does, it is determined to be a valid dynamic trusted anchor; if not, the random number selection and signature fusion process is repeated until a valid anchor is generated.

[0093] Finally, dual trusted authentication is carried out: BMC uploads the dynamic trusted anchor point to the cloud trusted center. The cloud trusted center performs cross-verification with the device's historical environment adaptation baseline and the manufacturer's hardware feature library to generate a trusted token. Only when both BMC local verification and cloud verification pass can the target device complete the registration initialization.

[0094] For pre-boot protection, the following measures are implemented: Dynamic sliding window hash encryption: The BMC uses dynamic sliding window hash encryption, dividing the firmware image into several data blocks of 16KB each. The security chip calculates the SHA-512 hash value for each data block, with the hash value of the previous block serving as the input parameter for the hash calculation of the next block, forming a hash chain. This chain structure ensures that if any data block is tampered with, all subsequent hash values ​​become invalid, improving the sensitivity of tamper detection. Hash verification: During verification, in addition to comparing the full image hash, the BMC recalculates the full SHA-512 hash value of the firmware image and compares it with the original full image hash pre-installed in the security chip. Simultaneously, it randomly selects three hash values ​​from the hash chain for verification. When both the full image and the three hash values ​​pass verification, the target device is allowed to boot.

[0095] For runtime proactive defense, it includes: multi-dimensional data acquisition: BMC acquires three-dimensional data through the PCIe out-of-band channel, including register operation data (such as register read / write address, frequency, and value changes), bus interaction data (such as I / O request queue length and transmission rate), and resource usage data (such as power consumption, memory usage, and CPU interaction latency). The data acquisition frequency is 100ms / time, which is used for subsequent analysis.

[0096] Model Construction: The model is built using an LSTM + attention mechanism. LSTM processes behavioral sequences consisting of register operations, I / O requests, and resource usage. Its core function is to mine temporal logic such as the order of occurrence, frequency changes, and linkage patterns of behaviors, providing fundamental features for intent recognition. During input data preprocessing, the original multi-dimensional temporal data is converted into a sequence format that can be processed by LSTM. The LSTM layer mines temporal features of the temporal dependencies of the behavioral sequences, using a gating mechanism of forget gate, input gate, and output gate to remember key associations in long-term sequences. The temporal feature vector extracted by LSTM is processed by multiple LSTM layers (e.g., 2 layers, 64 neurons per layer), and finally, the hidden state at the last time step (or average pooling of the hidden states at all time steps) is taken to obtain a fixed-dimensional feature vector (e.g., 128 dimensions). The feature vector contains temporal information such as the order, frequency, and linkage of the behavioral sequences, serving as the input basis for the subsequent attention mechanism. The attention mechanism assigns higher weights to key behaviors strongly correlated with attack intent in the feature vector (such as kernel address access and permission register modification), weakens the influence of ordinary behaviors (such as normal I / O requests and regular address read / write), focuses on core features, and improves the accuracy of attack intent identification.

[0097] Tiered early warning and intervention: Based on the predicted risk level of the attack intent, tiered processing is implemented. For low-risk (abnormal I / O), log alarms are triggered, abnormal logs are recorded, but device operation is not affected. For medium-risk (suspicious register read / write), access to sensitive memory areas of the system (such as kernel space, other PCIe device addresses) is prohibited, only necessary business permissions are granted, and local log alarms are triggered. For high-risk (clear attack intent sequence), basic diagnostic channels of the device are preserved (such as register reads, log uploads), business data transmission links are cut off, and alarms are triggered simultaneously.

[0098] For status reporting and intelligent repair, this includes: tiered alarms: The device security status logs collected by the BMC (such as startup verification results, runtime anomalies, and repair records) are formatted into a fixed format, such as timestamp + device BDF + event type + detailed parameters. Logs are digested using the SHA-256 algorithm and then uploaded to the server manufacturer, data center, and security agencies to ensure the logs are unmodifiable and traceable. Raw logs are stored locally in the BMC Flash memory, with a maximum retention of 1900 entries. When the number exceeds 1900, the oldest logs are deleted sequentially by time, and the newest logs are added. Quick queries by device ID and event type are also supported. Adaptive Firmware Repair: BMC locally backs up multiple versions of legitimate firmware, including the latest version (the currently running firmware), the previous stable version (the firmware that previously ran successfully), and the basic version (firmware that only supports basic communication and diagnostics). When a firmware fault is detected, BMC collects key fault symptoms (such as register status codes, alarm information, and environmental data) and autonomously selects the appropriate firmware version for repair based on the symptoms. For example, if only a part of the firmware is malfunctioning, the previous stable version is selected first; if the entire firmware is damaged, the basic version is selected. After the repair is completed, it is confirmed through the pre-boot protection phase. If the repair fails, it switches to another firmware version to improve the success rate of the repair.

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

[0100] Embodiments of this application also provide a target event identification device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the modules described in the following embodiments are preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0101] Figure 6This is a structural block diagram of a target event identification device according to an embodiment of this application. The device includes:

[0102] The acquisition module 602 is used to acquire the behavioral time-series data of the target device in the current time period; wherein, the behavioral time-series data is obtained by monitoring the device behavior of the target device and is used to reflect the device behavior status of the target device in the current time period.

[0103] The first determining module 604 is used to determine the behavioral timing characteristics of the target device based on the behavioral timing data.

[0104] The second determining module 606 is used to perform intent detection on the behavioral temporal features in order to determine the target intent corresponding to the behavioral temporal features.

[0105] The third determining module 608 is used to perform event recognition on the target device based on the target intent, and obtain the event recognition result of the target device.

[0106] Through the aforementioned device, the baseboard management controller directly acquires the behavioral timing data of the target device within the current time period. Subsequently, it extracts behavioral timing features from the data and performs intent detection on these features to determine the target intent corresponding to each feature. Based on this intent, event recognition is performed to determine the event recognition result for the target device. By determining the target intent corresponding to the behavioral timing features through the baseboard management controller, and then performing event recognition based on that intent, the system can quickly perform event recognition and obtain results, enabling timely responses to security threats, as the baseboard management controller is independent of the main operating system and does not share processes with other processes.

[0107] In an exemplary embodiment, the behavioral timing data includes: register timing data, bus timing data, and resource timing data; the first determining module 604 is further configured to fuse the register timing data, the bus timing data, and the resource timing data to obtain fused timing data; input the fused timing data into a pre-trained feature extraction model, and have the feature extraction model extract features from the fused timing data based on a set feature extraction dimension to obtain multiple feature vectors corresponding to the fused timing data; the feature extraction dimension includes at least one of the following: correlation dimension, frequency dimension, and order dimension; and determine the behavioral timing features of the target device based on the multiple feature vectors.

[0108] In an exemplary embodiment, the behavioral temporal feature includes: multiple feature vectors; a third determining module 608 is further configured to match the multiple feature vectors with a set target feature vector respectively, and determine the similarity between the multiple feature vectors and the target feature vector respectively; wherein, the target feature vector is obtained by vectorizing the event content of the target event; determine the weight coefficients corresponding to the multiple similarities respectively; perform weighting based on the multiple similarities and the weight coefficients corresponding to the multiple similarities to obtain a weighted result; and determine the target intent corresponding to the behavioral temporal feature based on the weighted result.

[0109] In an exemplary embodiment, the third determining module 608 is further configured to map the target intent to a pre-set event classification table to determine the event type corresponding to the target device; the event classification table includes: multiple event types and intents matching the multiple event types; the event types corresponding to the target device are classified and processed to determine the event recognition result of the target device.

[0110] In an exemplary embodiment, the device further includes an environment verification module; the environment verification module is configured to acquire environmental status data and device identifier of the target device; determine a private key matching the target device based on the device identifier, and determine a signature of the target device based on the environmental status data; encrypt the signature according to the private key to obtain a trusted anchor point of the target device, and perform a hash calculation on the trusted anchor point and a set time parameter to obtain a dynamic trusted anchor point; perform environment verification on the target device based on the dynamic trusted anchor point, and determine the environment verification result of the target device.

[0111] In an exemplary embodiment, the environment verification module is further configured to perform environment verification on the target device based on the dynamic trusted anchor point to obtain a first verification result, and send the dynamic trusted anchor point to a verification device connected to the target device, and obtain a second verification result fed back by the verification device; and determine the environment verification result of the target device based on the first verification result and the second verification result.

[0112] In one exemplary embodiment, the apparatus further includes a detection module; the detection module is configured to acquire a firmware image of the target device; detect the firmware image to obtain a detection result; and, if the detection result indicates that the firmware image has not been modified, load the firmware image to start the target device.

[0113] In an exemplary embodiment, the detection module is further configured to determine the full hash value of the firmware image and the component hash values ​​of N firmware sub-images; wherein, N is an integer greater than 1; the firmware sub-images are obtained by splitting the firmware image based on a set file splitting step size; the full hash value is compared with the full hash standard value stored in the secure storage unit of the target device to obtain a first comparison result, and the component hash value is compared with the component hash standard value stored in the secure storage unit of the target device to obtain a second comparison result; a detection result is obtained based on the first comparison result and the second comparison result.

[0114] In an exemplary embodiment, the detection module is further configured to split the firmware image of the target device based on a set file splitting step size to obtain a plurality of consecutive firmware sub-images; for a first firmware sub-image among the plurality of firmware sub-images, determine the component hash standard value of the first firmware sub-image based on the image data of the first firmware sub-image; for a second firmware sub-image among the plurality of firmware sub-images, determine the component hash standard value of the second firmware sub-image based on the image data of the second firmware sub-image and the component hash standard value of the previous firmware sub-image of the second firmware sub-image; the first firmware sub-image is the first firmware sub-image among the plurality of firmware sub-images; the second firmware sub-image is not the first firmware sub-image among the plurality of firmware sub-images; and store the component hash standard values ​​of the plurality of firmware sub-images in the secure storage unit of the target device; wherein, the full hash standard value is the component hash standard value of the last firmware sub-image among the plurality of firmware sub-images.

[0115] For a description of the features in the embodiment corresponding to the target event identification device, please refer to the relevant description of the embodiment corresponding to the target event identification method. For a description of the features in the embodiment corresponding to the device startup device, please refer to the relevant description of the embodiment corresponding to the device startup method. They will not be repeated here.

[0116] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described embodiments of the target event identification method.

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

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

[0119] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described target event recognition method embodiments.

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

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

[0122] The above provides a detailed description of a target event identification method provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for identifying target events, executed by a baseboard management controller, characterized in that, include: Acquire behavioral timing data of the target device in the current time period; wherein, the behavioral timing data is obtained by monitoring the device behavior of the target device and is used to reflect the device behavior status of the target device in the current time period; the behavioral timing data includes: register timing data, bus timing data and resource timing data; The behavioral timing characteristics of the target device are determined based on the behavioral timing data. Intent detection is performed on the behavioral temporal features to determine the target intent corresponding to the behavioral temporal features; The target intent is mapped to a pre-defined event classification table to determine the event type corresponding to the target device; the event classification table includes: multiple event types, and intents that match the multiple event types; The event types corresponding to the target device are classified and processed to determine the event identification result of the target device.

2. The method according to claim 1, characterized in that, Determining the behavioral timing characteristics of the target device based on the behavioral timing data includes: The register timing data, the bus timing data, and the resource timing data are fused to obtain fused timing data. The fused time-series data is input into a pre-trained feature extraction model, which extracts features from the fused time-series data based on a set feature extraction dimension to obtain multiple feature vectors corresponding to the fused time-series data; the feature extraction dimension includes at least one of the following: correlation dimension, frequency dimension, and order dimension. The behavioral temporal features of the target device are determined based on the multiple feature vectors.

3. The method according to claim 1, characterized in that, The behavioral temporal features include: multiple feature vectors; intent detection is performed on the behavioral temporal features to determine the target intent corresponding to the behavioral temporal features, including: The plurality of feature vectors are matched with a set target feature vector to determine the similarity between the plurality of feature vectors and the target feature vector; wherein, the target feature vector is obtained by vectorizing the event content of the target event; Determine the weight coefficients corresponding to the multiple similarities; The weighted result is obtained by weighting the multiple similarities and the corresponding weight coefficients. The target intent corresponding to the temporal features of the behavior is determined based on the weighted result.

4. The method according to claim 1, characterized in that, Before acquiring the time-series data of the target device's behavior in the current time period, the method further includes: Obtain the environmental status data and device identifier of the target device; The private key matching the target device is determined based on the device identifier, and the signature of the target device is determined based on the environmental state data; The signature is encrypted using the private key to obtain the target device trusted anchor point, and the trusted anchor point is hashed with the set time parameter to obtain a dynamic trusted anchor point; The target device is subjected to environmental verification based on the dynamic trusted anchor point, and the environmental verification result of the target device is determined.

5. The method according to claim 4, characterized in that, Based on the dynamic trusted anchor point, the target device is subjected to environmental verification to determine the environmental verification result of the target device, including: The target device is subjected to environmental verification based on the dynamic trusted anchor point to obtain a first verification result, and the dynamic trusted anchor point is sent to the verification device connected to the target device to obtain a second verification result fed back by the verification device. Based on the first verification result and the second verification result, the environmental verification result of the target device is determined.

6. The method according to claim 1, characterized in that, Before acquiring the time-series data of the target device's behavior in the current time period, the method further includes: Obtain the firmware image of the target device; The firmware image is inspected to obtain the inspection results; If the detection result indicates that the firmware image has not been modified, the firmware image is loaded to start the target device.

7. The method according to claim 6, characterized in that, The firmware image is inspected to obtain inspection results, including: Determine the full hash value of the firmware image and the component hash values ​​of N firmware sub-images; wherein, N is an integer greater than 1; the firmware sub-images are obtained by splitting the firmware image based on a set file splitting step size; The full hash value is compared with the full hash standard value stored in the secure storage unit of the target device to obtain a first comparison result, and the component hash value is compared with the component hash standard value stored in the secure storage unit of the target device to obtain a second comparison result. The detection result is obtained based on the first comparison result and the second comparison result.

8. The method according to claim 6, characterized in that, Before inspecting the firmware image and obtaining the inspection result, the method further includes: Based on the set file splitting step size, the firmware image of the target device is split to obtain multiple consecutive firmware sub-images. For the first firmware sub-image among the plurality of firmware sub-images, the component hash standard value of the first firmware sub-image is determined based on the image data of the first firmware sub-image; For the second firmware sub-image among the plurality of firmware sub-images, the component hash standard value of the second firmware sub-image is determined based on the image data of the second firmware sub-image and the component hash standard value of the previous firmware sub-image of the second firmware sub-image; the first firmware sub-image is the first firmware sub-image among the plurality of firmware sub-images; the second firmware sub-image is not the first firmware sub-image among the plurality of firmware sub-images. The component hash standard values ​​of the plurality of firmware sub-images are stored in the secure storage unit of the target device; wherein, the full hash standard value is the component hash standard value of the last firmware sub-image among the plurality of firmware sub-images.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the method for identifying the target event as described in any one of claims 1 to 8.

Images