Cross-domain multimodal device fingerprint generation method

Abstract

This invention discloses a method for generating cross-domain multimodal device fingerprints, belonging to the field of network device identity recognition technology. The method includes: collecting multi-dimensional feature data of client cross-domain operation to construct a multimodal fingerprint feature dataset; dividing the operation scenario based on a two-level sliding time window, quantifying stability confidence factors, and generating a cross-domain fingerprint stability parameter set; extracting inherent anchoring features of the protocol stack and software behavior identification features layer by layer, and generating a cross-domain fusion feature code through deviation compensation and dimensional-level differentiated dynamic weighted fusion; and generating a cross-domain multimodal device fingerprint based on the cross-domain fusion feature code. This invention achieves stable recognition across browsers, terminals, and networks, solving the problems of easy tampering and cross-domain drift in traditional fingerprints, and significantly improving the tamper resistance and cross-domain stability of identity recognition.

Description

Technical Field

[0001] This invention belongs to the field of network device identity recognition technology, and particularly relates to a method for generating fingerprints for cross-domain multimodal devices. Background Technology

[0002] With web applications and cross-platform services becoming the mainstream application forms, trusted identity recognition in client software has become the core foundation for implementing network security level protection systems and preventing account theft and cross-domain identity fraud. Seamless device fingerprint technology is currently the mainstream solution in the industry.

[0003] Current mainstream traditional front-end application layer device fingerprinting solutions have two major pain points: First, front-end application layer features are easily tampered with and counterfeited, and have weak anti-attack capabilities; second, features are highly dependent on specific operating environments, and fingerprint drift is very likely to occur in cross-browser, cross-domain, and cross-network switching scenarios, making it impossible to achieve stable cross-domain identity association and continuous trusted identification.

[0004] Therefore, there is an urgent need for a device fingerprint generation method that integrates multimodal features from the network layer, protocol stack layer, and front-end runtime layer, and achieves stable cross-domain association through adaptive calibration of runtime scenarios, dynamic weighted fusion, and deviation source tracing, so as to significantly improve the anti-tampering capability and cross-domain continuous identification stability of client identity recognition. Summary of the Invention

[0005] In order to overcome the defects and shortcomings of the existing technology, the present invention provides a method for generating fingerprints of cross-domain multimodal devices.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] In a first aspect, the present invention provides a method for generating fingerprints for cross-domain multimodal devices, comprising the following steps:

[0008] S1. Collect multi-dimensional feature data of client cross-domain operation, and construct a multimodal fingerprint feature dataset containing runtime scenario feature data, software inherent attribute data, and behavioral feature data;

[0009] S2. Through a two-level sliding time window architecture, stability confidence factors for each time window are generated based on the characteristic data of the running scenario. Based on the stability confidence factors, the multimodal fingerprint feature dataset is divided into stable running scenarios and dynamic switching scenarios. Using the stable running scenario as the benchmark anchor and the dynamic switching scenario as the reference, a cross-domain fingerprint stability parameter set including cross-domain association weight coefficients, personalized dynamic fault-tolerant windows, and nonlinear mutation markers is generated.

[0010] S3. Extract the protocol stack inherent anchoring features and software behavior identification features hierarchically from the multimodal fingerprint feature dataset, perform bias compensation based on the cross-domain fingerprint stability parameter set, and perform dimensional-level differentiated dynamic weight allocation on the protocol stack inherent anchoring features and software behavior identification features based on the scene dynamic degree factor calculated by the stability confidence factor to generate cross-domain fusion feature codes.

[0011] S4. Generate cross-domain multimodal device fingerprints based on cross-domain fusion feature codes.

[0012] According to the above technical solution, the steps of collecting multi-dimensional feature data of client cross-domain operation and constructing a multimodal fingerprint feature dataset containing operation scenario feature data, software inherent attribute data, and behavioral feature data include:

[0013] S110. Operational scenario characteristic data is obtained by passively monitoring network communication data packets through server-side traffic probes to extract network switching status and network latency baselines, and by actively collecting operational status identifier codes through the front end, specifically including:

[0014] The system passively monitors network communication data packets between the client and the server using a server-side traffic probe. It extracts the source IP address from the network layer IP header of the communication data packet and generates network switching status by recording the change sequence of the source IP address and the timestamp of each source IP address change. It calculates the network latency baseline from the round-trip timestamp of the network communication data packet and obtains the running status identifier code through a lightweight active collection method at the front end.

[0015] The source IP address change sequence is determined by comparing the source IP address of the current communication data packet with the source IP address of the previous communication data packet to see if they belong to the same network segment or the same network operator. If the source IP address changes and the location of the new IP address is different from that of the previous IP address, it is marked as a change in source IP address and the specific source IP address is recorded. The network latency baseline is calculated by statistically analyzing the one-way transmission time or round-trip time of a preset number of consecutive communication data packets, and the median is taken as the network latency baseline. The running status identifier encoding includes the foreground running status, background suspended status, or standby status of the client process at the time of collection, and records the timestamp corresponding to each status change.

[0016] S120. Software-specific attribute data is obtained by parsing the Transmission Control Protocol (TCP) layer and Internet Protocol (IP) layer parameters through server-side traffic probes, extracting TCP / IP protocol stack-specific parameters, and generating a JA3 client handshake fingerprint by parsing the transport layer security protocol handshake process. Specifically, this includes:

[0017] The server-side traffic probe passively listens to the network communication data packets between the client and the server, parses the parameters of the transmission control protocol layer and the Internet protocol layer from the communication data packets, and extracts the inherent parameters of the TCP / IP protocol stack, including the TCP initial window value, the maximum segment length value, and the time to live value.

[0018] The server-side traffic probe analyzes the transport layer security protocol handshake process, extracting the cipher suite list, extension type list, and supported protocol version from the ClientHello message sent by the client. The above fields are concatenated in order and hashed using the national cryptographic SM3 hash algorithm to generate a JA3 client handshake fingerprint, which is used as a TLS handshake parameter. The inherent parameters of the TCP / IP protocol stack and the JA3 client handshake fingerprint are aggregated into software inherent attribute data.

[0019] S130. Through a lightweight, proactive front-end data collection method, a collection script is dynamically injected into the client runtime environment to collect behavioral feature data containing JS runtime characteristics and Canvas rendering features, specifically including:

[0020] By using a lightweight, proactive front-end data collection method, a collection script is dynamically injected into the client runtime environment. The collection script is loaded and executed in an asynchronous, non-blocking manner to collect JS runtime characteristics and Canvas rendering features, forming behavioral feature data.

[0021] The JS runtime features are obtained by executing preset JavaScript test functions to obtain function call stack depth, prototype chain traversal time, and asynchronous task queue scheduling delay, which are used to reflect the differences in the underlying implementation of the client's JS engine; the Canvas rendering features are obtained by creating an off-screen Canvas to draw preset graphics and extracting the hash value of pixel data, which are used to reflect the differences in hardware and drivers of the client's graphics rendering pipeline; the collection script destroys itself and all intermediate variables immediately after execution to release client runtime resources.

[0022] S140. Perform client-side local anonymization on the behavioral feature data to generate a behavioral feature security digest; perform outlier removal and linear normalization on the runtime scenario feature data, software inherent attribute data, and behavioral feature security digest, and aggregate them into a multimodal fingerprint feature dataset, specifically including:

[0023] First, local compliance processing is performed on the client side. The collected behavioral feature data is initially screened and anonymized in the local operating environment of the client. After the continuous sampled values ​​are discretized according to the preset bin interval, random perturbation noise following the Laplace distribution is superimposed, and then mapped into a fixed-length behavioral feature security digest through the national cryptographic SM3 hash algorithm. Only the behavioral feature security digest encrypted with national cryptographic SM4 is uploaded to the server. The original behavioral sampled values ​​are not uploaded at all.

[0024] Then, the server performs unified standardization processing. The collected runtime scenario feature data, software inherent attribute data, and behavioral feature security summary uploaded by the client are processed by removing outliers in the same runtime status identifier encoding according to the time series. Then, all continuous feature dimensions in the runtime scenario feature data, software inherent attribute data, and behavioral feature security summary are linearly mapped to the [0,1] interval to obtain the corresponding standardized values, which are then aggregated into a multimodal fingerprint feature dataset.

[0025] According to the above technical solution, the steps of generating stability confidence factors for each time window based on the quantization of operational scenario feature data through a two-level sliding time window architecture, dividing the multimodal fingerprint feature dataset into stable operational scenarios and dynamically switching scenarios based on the stability confidence factors, and generating a cross-domain fingerprint stability parameter set including cross-domain association weight coefficients, personalized dynamic fault-tolerant windows, and nonlinear mutation markers, with stable operational scenarios as the benchmark anchor point and dynamically switching scenarios as the reference, include:

[0026] S210. Based on a two-level sliding time window architecture, by weighted fusion of the operational status timing stability, network connection timing stability, network latency timing stability, and IP usage habit stability in the operational scenario feature data, a stability confidence factor for a short time window is obtained. This stability confidence factor is compared with a stability judgment threshold to classify the short time window into a stable operational scenario or a dynamically switching scenario, specifically including:

[0027] Operational status timing stability is quantified by the frequency and duration of switching of operational status identifier codes within a short time window; network connection timing stability is quantified by the frequency of source IP network segment / home location switching and the duration of continuous connections within the same network segment within a short time window; network latency timing stability is quantified by the fluctuation of the network latency baseline sequence within a short time window; IP usage habit stability is quantified by the matching degree between the current source IP and historically frequently used IPs and the dispersion of historical IP usage.

[0028] The stability quantification results of the above four dimensions are weighted and fused according to the preset weights of each dimension's impact on device fingerprint stability to obtain the stability confidence factor for the current short time window (the weight allocation prioritizes the dominant role of network connectivity and latency fluctuations in fingerprint stability). When the stability confidence factor is greater than or equal to the stability judgment threshold, the short time window is classified as a stable operating scenario; when the stability confidence factor is less than the stability judgment threshold, the short time window is classified as a dynamic switching scenario. At the same time, all short time window data is cached in a long time window analysis queue for subsequent effective stability period determination.

[0029] S220. Extract short-time window data corresponding to stable operating scenarios from the multimodal fingerprint feature dataset. Based on the effective stability period determination result of the long-time window, and using the stability confidence factor of each short-time window as the weight, calculate the expected baseline value of each data item under the protocol stack inherent anchoring feature dimension and the software behavior identification feature dimension, specifically including:

[0030] The protocol stack inherent anchoring feature dimension includes two data items: TCP / IP protocol stack inherent parameters and JA3 client handshake fingerprint; the software behavior identification feature dimension includes two data items: JS runtime characteristics and Canvas rendering characteristics.

[0031] For continuous numerical data items such as inherent parameters of the TCP / IP protocol stack and runtime characteristics of JS, the stability confidence factor of the full effective time window selected within a long time window is used as the weight (the higher the stability confidence factor of the effective window, the greater the contribution weight to the expected benchmark value). The weighted arithmetic mean of all standardized sampled values ​​of the data item within the full effective window is used to obtain the expected benchmark value of the data item, ensuring that the benchmark value fits the data of highly stable scenarios.

[0032] For discrete hash value data items such as JA3 client handshake fingerprints and Canvas rendering features, the effective time window range is the short time window of the stable running scenario within a long time window. The hash value with the highest frequency within the effective time window range is taken as the expected baseline value of the data item. If all hash values ​​within the effective range have the same frequency, the hash value collected in the first stable running scenario is taken as the initial expected baseline value.

[0033] S230. Taking the multimodal fingerprint feature data corresponding to short time windows divided into dynamic switching scenarios as input, by analyzing the deviation relationship between the sampled values ​​of each data item and the expected baseline values ​​of the corresponding data items in stable operation scenarios, a cross-domain correlation weight coefficient reflecting the relative stability of each data item in dynamic switching scenarios is constructed; a personalized dynamic fault-tolerant window is established for each data item, with the expected baseline value of the data item in stable operation scenarios as the window center, and the standard deviation of the sampled values ​​of the data item in stable operation scenarios as the initial window radius. When the client undergoes normal device evolution, the window radius is updated using an exponentially weighted moving average method, and the update weight is positively correlated with the stability confidence factor of the corresponding short time window. The higher the stability confidence factor of the short time window data, the greater its contribution to the window boundary update; and a numerical and temporal dual-dimensional joint discrimination mechanism is constructed to perform nonlinear mutation marking on abnormal feature changes, specifically including:

[0034] Based on the sampled values ​​of each data item in a dynamic switching scenario within a short time window, the deviation sequence between each data item and the corresponding expected benchmark value is calculated. The cross-domain correlation weight coefficient of each data item is calculated based on the degree of dispersion of the deviation sequence. The higher the cross-domain correlation weight coefficient, the smaller the fluctuation of the data item when switching between scenarios and the stronger the cross-domain stability.

[0035] A personalized dynamic fault-tolerant window is established based on historical sampling data from stable operating scenarios over a long period of time. For each data item, the expected baseline value of the data item is used as the center of the window, and three times the standard deviation of the sampled values ​​of the data item under stable operating scenarios is used as the initial window radius. When the client undergoes normal device evolution, the window boundary is updated using an exponentially weighted moving average method. The update weight is positively correlated with the stability confidence factor of the corresponding short time window. The larger the stability confidence factor of the time window data, the higher its contribution to the update of the personalized dynamic fault-tolerant window boundary, thus avoiding interference from dynamic fluctuation data with window accuracy.

[0036] A dual-dimensional joint discrimination mechanism based on numerical and temporal dimensions is constructed. For each data item sampled in a dynamic switching scenario within a short time window, if the sampled value exceeds the range of the personalized dynamic fault tolerance window corresponding to the current data item and the temporal change of the sampled value before and after the dynamic switching scenario does not conform to the continuous gradual change law, the data item is marked as a nonlinear mutation.

[0037] According to the above technical solution, the steps of extracting protocol stack inherent anchoring features and software behavior identifier features hierarchically from the multimodal fingerprint feature dataset, performing bias compensation based on the cross-domain fingerprint stability parameter set, and allocating dimensionally differentiated dynamic weights to the protocol stack inherent anchoring features and software behavior identifier features based on the scene dynamic degree factor calculated by the stability confidence factor to generate cross-domain fusion feature codes include:

[0038] S310. Extract protocol stack inherent anchoring features and software behavior identifier features from the multimodal fingerprint feature dataset, and vectorize and concatenate them in a fixed order to generate protocol stack inherent anchoring feature vectors and software behavior identifier feature vectors, specifically including:

[0039] Extract all data items from the protocol stack inherent anchor feature dimension and all data items from the software behavior identification feature dimension from the multimodal fingerprint feature dataset; according to the preset feature dimension order, vectorize and concatenate the inherent parameters of the TCP / IP protocol stack with the JA3 client handshake fingerprint to generate a fixed-dimensional protocol stack inherent anchor feature vector, which serves as the basic anchor feature for the client's unique identity; vectorize and concatenate the JS runtime characteristics with the Canvas rendering characteristics to generate a fixed-dimensional software behavior identification feature vector, which serves as the core identification feature for the client's individual distinguishability and anti-tampering.

[0040] S320. For each data item under the protocol stack's inherent anchoring feature vector and software behavior identifier feature vector, obtain the real-time sampled value of the data item, calculate the feature deviation between the real-time sampled value and the expected baseline value of the data item, apply a weighted adjustment to the feature deviation using a cross-domain correlation weighting coefficient to obtain the deviation correction amount, add the expected baseline value and the deviation correction amount, and output the calibrated stable value of the data item. Specifically, this includes:

[0041] For each data item in the protocol stack's inherent anchor feature vector and software behavior identifier feature vector, the expected baseline value and cross-domain association weight coefficient of the corresponding data item in the cross-domain fingerprint stability parameter set are called respectively. Using the expected baseline value of the data item as the anchor point, the cross-domain association weight coefficient is used to compensate for the deviation of the current sampled value, eliminating the systematic deviation caused by the switching of operating scenarios and environmental fluctuations, and preserving the individual characteristics of the device.

[0042] S330. Initial weights are set for each data item using cross-domain association weight coefficients. The initial weights of data items under the protocol stack's inherent anchoring feature dimension are positively correlated with the corresponding cross-domain association weight coefficients, while the initial weights of data items under the software behavior identifier feature dimension are positively correlated with individual discriminative power. A scene dynamics factor is calculated based on the stability confidence factor of the current short time window, and continuous gradient updates are performed on the initial weights according to the scene dynamics factor. Combining the nonlinear mutation markers in the cross-domain fingerprint stability parameter set, gradient weight reduction is performed on data items marked as nonlinear mutations to generate dimension-specific weight vectors, specifically including:

[0043] First, based on the cross-domain association weight coefficients in the cross-domain fingerprint stable parameter set, initial weights are set for two data items in the protocol stack inherent anchor feature dimension and two data items in the software behavior identification feature dimension: the initial weight of each data item in the protocol stack inherent anchor feature dimension is positively correlated with the cross-domain association weight coefficient of that data item; the initial weight of each data item in the software behavior identification feature dimension is positively correlated with the individual distinguishability of that data item.

[0044] Based on this, the dynamic factor of the scenario is calculated based on the stability confidence factor of the current time window;

[0045] Continuous gradient updates are performed on the initial weights based on the scenario dynamics factor: the weight adjustment coefficients of each data item under the inherent anchoring feature dimension of the protocol stack are positively correlated with the scenario dynamics factor, and the stronger the scenario fluctuation, the higher the weight; the weight adjustment coefficients of each data item under the software behavior identification feature dimension are positively correlated with the stability confidence factor, and the more stable the scenario, the higher the weight.

[0046] Simultaneously, by combining the personalized dynamic fault tolerance window and nonlinear mutation labeling results in the cross-domain fingerprint stability parameter set, data items that exceed the range of the personalized dynamic fault tolerance window and are marked as nonlinear mutations are subjected to gradient weighting based on the magnitude of the sampled value exceeding the window boundary until they are removed from the feature fusion sequence, thus avoiding the impact of malicious tampering and abnormal fluctuations on fingerprint stability.

[0047] The weight values ​​of each data item that have been allocated are combined into a dimension-specific weight vector that corresponds one-to-one with each data item.

[0048] S340. Based on dimension-level dedicated weight vectors, a weighted fusion is performed on the protocol stack's inherent anchoring feature vector and the software behavior identifier feature vector after deviation compensation to generate a fixed-length cross-domain fusion feature code, specifically including:

[0049] Multiply the TCP / IP protocol stack intrinsic parameter values ​​in the calibrated protocol stack intrinsic anchoring feature vector by the weight coefficient corresponding to the data item in the dimension-level exclusive weight vector; multiply the JA3 client handshake fingerprint values ​​by the weight coefficient corresponding to the data item in the dimension-level exclusive weight vector; combine the two weighted values ​​to form the weighted protocol stack intrinsic anchoring feature vector.

[0050] Multiply the JS runtime characteristic value in the calibrated software behavior identifier feature vector by the weight coefficient corresponding to the data item in the dimension-level dedicated weight vector; multiply the Canvas rendering characteristic value by the weight coefficient corresponding to the data item in the dimension-level dedicated weight vector; combine the two weighted values ​​to form the weighted software behavior identifier feature vector.

[0051] The weighted protocol stack inherent anchor feature vector and the weighted software behavior identifier feature vector are concatenated to form a fused feature vector; L2 norm normalization is performed on the fused feature vector to eliminate the difference in feature dimensions and generate a fixed-length cross-domain fused feature code.

[0052] According to the above technical solution, the step of generating a cross-domain multimodal device fingerprint based on cross-domain fusion feature codes includes:

[0053] S410. Combining the cross-domain fingerprint stability parameter set, perform deviation source analysis on the cross-domain fused signature code to distinguish between normal environmental fluctuations, normal device evolution, and malicious tampering scenarios, specifically including:

[0054] The cross-domain fusion feature code generated within the current short time window is compared with the numerical benchmark fingerprint stored in the client's history. The benchmark fingerprint is a numerical feature vector that has the same structure and dimensions as the cross-domain fusion feature code and is stored in the trusted storage area on the server. It comes from the data updated after the effective stable period of the long window screening. The Euclidean distance between the feature codes is calculated as the deviation metric.

[0055] When the deviation metric does not exceed the weighted comprehensive boundary of the personalized dynamic fault tolerance window of each data item in the cross-domain fingerprint stability parameter set, it is determined to be a normal environmental fluctuation; the weighted comprehensive boundary is obtained by weighting and summing the boundary values ​​of the personalized dynamic fault tolerance window of each data item using the cross-domain correlation weight coefficient of each data item as the weighting coefficient.

[0056] When the deviation metric exceeds the weighted integration boundary of the personalized dynamic fault tolerance window, but the changing trend of each data item in the cross-domain fusion feature code is consistent with the historical continuous gradual change pattern of the data item recorded in the cross-domain fingerprint stability parameter set, it is determined to be a normal device evolution.

[0057] The aforementioned historical continuous gradual change pattern refers to the temporal change pattern of each data item recorded in S230 during the normal equipment evolution process;

[0058] When the deviation metric exceeds the weighted integration boundary of the personalized dynamic fault tolerance window, and the changing trend of one or more data items in the cross-domain fusion feature code is inconsistent with the historical continuous gradual change pattern of the data item recorded in the cross-domain fingerprint stable parameter set, or the data item is marked as a nonlinear mutation in the dynamic switching scenario, it is determined to be a malicious tampering scenario.

[0059] S420. For scenarios determined to be normal environmental fluctuations or normal equipment evolution, generate cross-domain multimodal device fingerprints based on numerical benchmark fingerprints, specifically including:

[0060] For scenarios determined to be normal environmental fluctuations, the numerical baseline fingerprint stored in the client's history is directly used as the current valid baseline fingerprint, without updating the numerical baseline fingerprint;

[0061] For scenarios determined to be normal device evolution, the numerical reference fingerprint is updated smoothly using an exponentially weighted moving average method, and the updated reference fingerprint is used as the current valid reference fingerprint.

[0062] For scenarios deemed to be malicious tampering, a security alert will be triggered and the client's authentication request will be blocked.

[0063] The current valid baseline fingerprint is used to generate a cross-domain multimodal device fingerprint using the national cryptographic SM3 hash algorithm to complete cross-domain identity authentication for the client.

[0064] Secondly, this application provides an electronic device, including a processor and a memory, wherein the memory stores a computer program that can be called by the processor, and the processor executes a cross-domain multimodal device fingerprint generation method by calling the computer program stored in the memory.

[0065] Thirdly, this application provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform a cross-domain multimodal device fingerprint generation method.

[0066] Compared with the prior art, this application has the following advantages and beneficial effects:

[0067] By collecting multidimensional data from cross-domain client operations and quantifying operational scenarios based on stability confidence factors, the root cause decoupling of two different attribute features—the inherent anchoring features of the protocol stack and the software behavior identification features—is achieved. This overcomes the limitations of traditional device fingerprinting schemes, which suffer from severe feature drift and difficulty in balancing stability and discriminability across browsers, terminals, and networks. Through dimensional differentiated dynamic weight fusion analysis, anchoring features and behavioral features are adaptively integrated based on stability confidence factors and scenario dynamic degree factors. This enables intelligent positioning of the current dominant identification basis from composite feature fluctuations and dynamic tracking of feature evolution based on cross-domain fingerprint stability parameter sets. As a result, device identification is upgraded from static comparison to condition-adaptive correlation.

[0068] Ultimately, by integrating cross-domain fingerprint stability parameters with real-time feature calibration results, the causes of feature deviations are accurately distinguished, generating device fingerprints that combine cross-domain stability and individual distinguishability. This significantly improves the accuracy, tamper resistance, and long-term reliability of device identification in complex operating environments, forming a complete intelligent identity recognition closed loop from feature acquisition, stability quantification, scenario division, adaptive fusion to fingerprint authentication. Attached Figure Description

[0069] Figure 1 This is a schematic diagram of the overall process of the cross-domain multimodal device fingerprint generation method provided in the embodiments of this application;

[0070] Figure 2 This is a schematic diagram of the process for generating a cross-domain fingerprint stable parameter set provided in an embodiment of this application;

[0071] Figure 3 This is a schematic diagram of the process for generating cross-domain fusion feature codes provided in an embodiment of this application;

[0072] Figure 4 This is a schematic diagram of the process for generating cross-domain multimodal device fingerprints provided in an embodiment of this application. Detailed Implementation

[0073] The technical solution of this application will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments and specific features in the embodiments are detailed descriptions of the technical solution of this application, rather than limitations thereof. In the absence of conflict, the embodiments and technical features in the embodiments can be combined with each other.

[0074] Please see Figure 1 , Figure 1 This is a schematic diagram of the overall process of the cross-domain multimodal device fingerprint generation method provided in this application embodiment, which specifically includes the following steps:

[0075] S1. Collect multi-dimensional feature data of client cross-domain operation, and construct a multimodal fingerprint feature dataset containing runtime scenario feature data, software inherent attribute data, and behavioral feature data;

[0076] In this embodiment, step S1 includes the following specific contents:

[0077] S110. The operation scenario feature data is extracted by passively listening to network communication data packets through the server-side traffic probe to obtain the network switching status and network latency baseline, and the operation status identifier code is obtained by actively collecting data from the front end.

[0078] Deploy a traffic probe on the server side (in this embodiment, the default is to use a packet capture module developed based on the libpcap library, which directly captures raw data packets from the network card driver layer through the AF_PACKET protocol family in the Linux environment; the probe is configured to capture only communication data packets related to the target client's IP address and not store the full traffic to reduce system resource overhead) to monitor network communication data packets between the client and the server in real time.

[0079] For each received network communication data packet, the source IP address is parsed from the network layer IP header. The change sequence of the source IP address is determined by comparing the source IP address of the current communication data packet with the source IP address of the previous communication data packet to see if they belong to the same network segment or the same network operator. If the source IP address changes and the location of the new IP address is different from that of the previous IP address, it is marked as a change of source IP address and the timestamp of the change and the specific source IP address are recorded. The network handover status is generated based on the change sequence of source IP address and the corresponding timestamp.

[0080] Meanwhile, for a preset number of continuously received network communication data packets (in this embodiment, the default preset number is 100, which is set based on the fact that the preset number matches the 30-second time window length set in S210. Under typical network communication frequencies, about 100 data packets can be collected within 30 seconds, which is sufficient to eliminate the impact of single instantaneous latency jitter and ensure the real-time calculation of latency baseline), the one-way transmission time of each network communication data packet from sending to receiving is recorded. These one-way transmission times are arranged in ascending order, and the 50th value in the sequence is taken as the median. This median is used as the current network latency baseline. The median value is not sensitive to extreme values ​​and can truly reflect the typical level of network latency, ensuring that dynamic scene determination is only triggered when network latency is continuous and fluctuates overall.

[0081] A lightweight, proactive data collection method is used on the front end. A JavaScript collection script is dynamically injected into the client runtime environment, and this script is loaded and executed asynchronously and non-blockingly. The script calls the browser's Page Visibility API to obtain the current page's visibility state: this embodiment uses the `document.visibilityState` property by default. If the return value is `visible`, it is determined to be in the foreground running state; if the return value is `hidden` and no page lifecycle freeze event is detected, it is determined to be in the background suspended state; if the return value is `hidden` and a `pagehide` or `freeze` event has been triggered, it is determined to be in the standby state. The above determination results are encoded into a running state identifier code, and the timestamp of each change in the running state identifier code is recorded.

[0082] The network switching status, network latency baseline, and operating status identifier extracted above are encoded and aggregated into operating scenario feature data.

[0083] S120. The software's inherent attribute data is parsed by the server-side traffic probe to extract parameters of the transmission control protocol layer and the Internet protocol layer, extract inherent parameters of the TCP / IP protocol stack, and generate a JA3 client handshake fingerprint by parsing the transport layer security protocol handshake process.

[0084] Deploy a traffic probe on the server side to monitor network communication packets between the client and the server in real time. For each received network communication packet, parse the TCP header from the Transmission Control Protocol layer to extract the initial TCP window value. This initial TCP window value is located in the window field of the TCP header, and the 16-bit binary value of this window field is taken as the initial window size.

[0085] Parse the Maximum Segment Length (MSS) from the TCP options field. The MSS is located in option type 2. Take the last two bytes of the MSS option as the maximum segment length value. Parse the IP header from the Internet Protocol layer and extract the Time to Live (TTL) value. The TTL is located in the TTL field of the IP header. Take the 8-bit binary value of this field as the TTL value.

[0086] Simultaneously, the transport layer security protocol handshake process is analyzed using a server-side traffic probe. When a ClientHello message sent by the client is detected, three fields are extracted sequentially from the message: cipher suite list, extension type list, and supported protocol version. These three fields are concatenated into a string in the order of "cipher suite list | extension type list | supported protocol version," and a hash value is calculated using the SM3 hash algorithm (a national cryptographic standard) to obtain a fixed-length hexadecimal hash value, which serves as the JA3 client handshake fingerprint. This embodiment uses a simplified version of the JA3 fingerprint rules, eliminating redundant fields that do not enhance device distinguishability, thus reducing computational overhead while maintaining fingerprint distinguishability.

[0087] The extracted TCP initial window value, maximum segment length value, time to live value, and JA3 client handshake fingerprint are aggregated into software-inherent attribute data.

[0088] S130: Through a lightweight active collection method on the front end, a collection script is dynamically injected into the client runtime environment to collect behavioral feature data that includes JS runtime characteristics and Canvas rendering features.

[0089] The data collection is conducted using a lightweight, proactive front-end approach (similar to the definition in S110, i.e., dynamically injecting the collection script into the client runtime environment, loading and executing it asynchronously and non-blockingly, and immediately destroying the script and intermediate variables after collection). The collection script first collects JS runtime characteristics: executing a set of preset JavaScript test functions, including a recursive deep test function, a prototype chain traversal function, and an asynchronous task scheduling function. The recursive deep test function constructs a recursive call with a depth of 1000 (adjustable according to actual testing needs) and records the call stack depth to obtain the function call stack depth value; the prototype chain traversal function constructs a prototype chain of length 20 (adjustable according to actual testing needs) and traverses the entire chain, recording the time required to complete the traversal to obtain the prototype chain traversal time value; the asynchronous task scheduling function continuously creates 100 Promise tasks (adjustable according to actual testing needs) and records the total delay time of all task completion to obtain the asynchronous task queue scheduling delay time value.

[0090] The script then collects Canvas rendering features: It creates an off-screen Canvas with dimensions of 300 pixels by 150 pixels. On the canvas, it draws a red-filled rectangle, a blue gradient circle, black-shadowed text, and a green Bézier curve in sequence. After drawing, it calls the Canvas element's `toDataURL` method to obtain a Base64 encoded string of the canvas pixel data. This Base64 encoded string is then hashed using the national cryptographic SM3 hash algorithm to obtain a fixed-length hexadecimal hash value, which is used as the Canvas rendering feature. This JavaScript script executes only in user-authorized business scenarios, and the collected content is solely for device identification and does not involve user personal information, complying with the requirements of the "Personal Information Protection Law of the People's Republic of China" and other relevant regulations.

[0091] After data collection is complete, the collection script immediately calls its own destruction function to clear all defined variables, functions, and event listeners, releasing client runtime resources. The collected JS runtime characteristics (including function call stack depth, prototype chain traversal time, and asynchronous task queue scheduling delay) and Canvas rendering features are then aggregated into behavioral feature data.

[0092] S140. Perform client-side local anonymization on the behavioral feature data to generate a behavioral feature security digest; perform outlier removal and linear normalization on the runtime scenario feature data, software inherent attribute data, and behavioral feature security digest, and aggregate them into a multimodal fingerprint feature dataset.

[0093] On the client side, the collected behavioral feature data is anonymized. The continuous sampled values ​​(i.e., the sequence of JS runtime characteristic values ​​and the sequence of Canvas rendering characteristic values ​​recorded continuously over time in the behavioral feature data) are discretized according to preset binning intervals:

[0094] Taking the function call stack depth in the JavaScript runtime as an example, the preset binning intervals are [0,50), [50,100), [100,200), and [200,∞). Each sampled value is assigned to the corresponding interval and the interval number is used to replace the original value. Random perturbation noise following a Laplace distribution is superimposed on the discretized values, where the scale parameter of the Laplace distribution is set to 0.1 times the interval width. The perturbed values ​​are mapped to a fixed-length hash digest using the national cryptographic SM3 hash algorithm to obtain the behavioral feature security digest. Subsequently, the behavioral feature security digest is encrypted using the national cryptographic SM4 algorithm and uploaded to the server, without transmitting the original behavioral sampled values ​​throughout the process.

[0095] The preset binning intervals are divided based on the theoretical numerical range and natural fluctuation patterns of each behavioral feature: the typical fluctuation range when the data item is running normally is used as the basis for fine-grained binning, the normal fluctuation range covered by 95% probability is divided into multiple sub-intervals, and extreme values ​​exceeding the 95% coverage range are uniformly classified into a small number of coarse-grained intervals; while achieving differential privacy protection, the ability to distinguish normal feature fluctuations is preserved to the greatest extent, and abnormal extreme values ​​are avoided from interfering with fingerprint stability.

[0096] On the server side, the collected operational scenario feature data, software inherent attribute data, and behavioral feature security summaries uploaded by the client are uniformly standardized. First, the data are arranged in time series under the same operational status identifier code, and the median and median absolute deviation of each data item within the time window are calculated. Outliers with sampled values ​​exceeding the median ± 3 times the median absolute deviation are removed.

[0097] Then, for each continuous data item in the remaining sampled values, a linear mapping formula is applied. Map the values ​​to the interval [0,1], where and These are the minimum and maximum values ​​of the data item in all historical data of the current client, respectively. When the client collects data for the first time without historical data, it collects the first batch of data (in this embodiment, the first batch is 100 sampling points by default), using the minimum and maximum values ​​in this batch of data as the initial values. and After accumulating sufficient historical data (this embodiment defaults to collecting 1000 sampling points), the system switches to the minimum and maximum values ​​of all client historical data. This processing method ensures that the normalization boundary always fits the actual data distribution of the client, avoiding loss of discriminability caused by theoretical boundaries.

[0098] The behavioral feature security digest is a discrete hash value that does not participate in linear normalization. Its hash digest value is directly retained. The processed runtime scenario feature data, software inherent attribute data, and the data item values ​​of the behavioral feature security digest are aggregated to form a multimodal fingerprint feature dataset.

[0099] S2. Through a two-level sliding time window architecture, stability confidence factors for each time window are generated based on the characteristic data of the running scenario. Based on the stability confidence factors, the multimodal fingerprint feature dataset is divided into stable running scenarios and dynamic switching scenarios. Using the stable running scenario as the benchmark anchor and the dynamic switching scenario as the reference, a cross-domain fingerprint stability parameter set including cross-domain association weight coefficients, personalized dynamic fault tolerance windows, and nonlinear mutation markers is generated.

[0100] In this embodiment, as Figure 2 As shown, step S2 includes the following specific steps:

[0101] S210. Based on a two-level sliding time window architecture, the stability confidence factor of a short time window is obtained by weighted fusion of the timing stability of the running status, the timing stability of the network connection, the timing stability of the network latency, and the stability of IP usage habits in the characteristic data of the running scenario. The stability confidence factor is compared with the stability judgment threshold to divide the short time window into a stable running scenario or a dynamic switching scenario.

[0102] On the server side, based on the multimodal fingerprint feature dataset, a two-level sliding time window is set: a short time window with a length of 30 seconds and a sliding step of 1 second, used for real-time identification of the current operating scenario; and a long time window with a length of 60 minutes, composed of 120 consecutive short time windows, with a sliding step of 1 short time window, used to accumulate long-term stability data to update the expected baseline value. The short time window length is set based on two criteria: firstly, it needs to be long enough to accumulate sufficient sampling points for stability assessment; a 30-second window can collect approximately 100 sampling points (i.e., the number of network data packets received within 30 seconds), meeting the statistical requirement of at least 10 sampling points for calculating the expected baseline value in S220; secondly, it needs to be short enough to capture timely changes in operating state, ensuring scene re-division is completed within 30 seconds to meet dynamic response timeliness. The long time window length is set based on the following criteria: it can fully cover the entire cycle of cross-network switching, foreground / background switching in operating state, and network latency fluctuations, ensuring that the accumulated stability data is statistically significant, avoiding interference from single accidental fluctuations in stability assessment, and preventing excessively long windows from causing baseline updates to lag behind normal device evolution.

[0103] The stability of the running state sequence is based on the running state identifier code and corresponding state change timestamp recorded within the short time window. It statistically analyzes the fluctuations in the frequency and duration of running state transitions. The running state transition frequency is the total number of transitions between the foreground running state, background suspended state, and standby state within the short time window. The fluctuations in the duration of running states are obtained by calculating the standard deviation of the duration of all individual running states within the short time window; a larger standard deviation indicates more severe fluctuations in the running state. In this embodiment, the running state sequence stability score is... The calculation formula is: ; in, This represents the frequency of operation state switching, and its value is a non-negative integer. The standard deviation of the duration of the running state; The 15 seconds in the figure represents the normal fluctuation limit of the duration of a single running state within a short time window of 30 seconds. The basis for setting the switching frequency weight coefficient of 0.2 is that the theoretical maximum value of the running state switching frequency within a short time window of 30 seconds is 2 times. For every increase in the switching frequency, the stability score decreases by 0.2, so that the stability score decreases by a maximum of 0.4 when switching twice, thus preserving the space for basic stability judgment.

[0104] Network connection timing stability is based on the source IP address change sequence and corresponding change timestamps recorded within the short time window. It statistically analyzes the fluctuations in network switching frequency and the duration of continuous connections within the same network segment. The network switching frequency is the total number of times the source IP network segment or location changes within the 30-second short time window. The fluctuation in the duration of continuous connections within the same network segment is obtained by calculating the standard deviation of all single continuous connection durations within the short time window; a larger standard deviation indicates more severe network connection fluctuations. In this embodiment, the network connection timing stability score is... The calculation formula is: ; in Network switching frequency; This represents the standard deviation of the duration of consecutive connections within the same network segment. The 10-second limit is the normal fluctuation limit of the duration of continuous connections within the same network segment within a short time window of 30 seconds. The value range is [0,1]. The higher the score, the more stable the network connection. The basis for setting the handover frequency weight coefficient of 0.3 is: within a short time window of 30 seconds, the theoretical maximum value of the network handover frequency is 1 time (at most one effective cross-network segment handover occurs in a single window). When a handover occurs, the stability score decreases by 0.3, reflecting the significant impact of network handover on stability.

[0105] Network latency timing stability is calculated based on all network latency baseline sample values ​​recorded within this short time window. The standard deviation of the network latency baseline sequence is used as the degree of network latency fluctuation; a smaller standard deviation indicates less latency fluctuation and higher stability. In this embodiment, the network latency timing stability score is... The calculation formula is: ; in The standard deviation of the network latency baseline sequence is 20 milliseconds, which is the upper limit of normal latency fluctuation within a short 30-second time window under stable network conditions. This 20-millisecond value is set based on the following: the normal fluctuation range of the network latency baseline is determined by the congestion control mechanism of the TCP / IP protocol stack. Under stable network conditions, the instantaneous fluctuation of round-trip time within the 30-second window is mainly caused by link queue delay. Based on the principle of three times the absolute deviation of the median, 20 milliseconds covers more than 95% of the latency fluctuation range in typical wired networks and stable Wi-Fi environments.

[0106] IP usage stability is calculated based on the client's historical IP usage data over the past 30 days. The calculation includes the matching degree between the current source IP and historically frequently used IPs, as well as the dispersion of historical IP usage. The current IP matching degree is the proportion of the cumulative occurrence time of the current short-time window source IP address within the past 30 days to the total runtime. The historical IP usage dispersion is the proportion of the number of different IPs used by the client within the past 30 days to the total number of IPs. A higher dispersion indicates more unstable IP usage habits. This embodiment uses the IP usage habit stability score... The calculation formula is: ; in The current IP match score. The historical IP usage dispersion score ranges from [0,1]. The current IP matching score is weighted at 0.7 because whether the current source IP is a frequently used IP has a dominant impact on the stability of IP usage habits, hence it is given a higher weight. The IP usage dispersion score is weighted at 0.3 because the historical IP usage dispersion serves as an auxiliary indicator, reflecting the long-term stability of client IP usage habits, and its weight is slightly lower than that of the current IP matching score. The sum of the two weights is 1, ensuring that the score is normalized to the [0,1] interval.

[0107] The stability quantification results of the above four dimensions are weighted and fused according to their corresponding weights to obtain the stability confidence factor for the current short time window. ; in The stability confidence factor has a value range of [0,1]. In this embodiment, the weight allocation of the four dimensions is based on the following: network connection status and latency fluctuations have the greatest impact on device fingerprint stability, followed by operating status and IP usage habits.

[0108] When stability confidence factor When the stability judgment threshold is greater than or equal to the threshold, the short time window is classified as a stable operating scenario; when the stability confidence factor... When the data is below the stability threshold, it is classified as a dynamic switching scenario. After the scenario classification is completed, a corresponding scenario label and stability confidence factor value are attached to each short-time window of data for real-time feature calibration and dynamic weight allocation. Simultaneously, this short-time window data is cached in the long-window analysis queue. In this embodiment, the default stability threshold is 0.8, set based on the assumption that when the confidence factor is greater than or equal to 0.8, the corresponding stable operation conditions are: no cross-network segment switching within a 30-second window, no more than one operational state switch, network latency standard deviation less than 5 milliseconds, and the current IP is a frequently used IP. This can cover more than 95% of normal stable scenarios.

[0109] Long-term stability assessments are conducted within a long time window. For each new short time window generated, the stability confidence factor distribution of all short time windows within the current long time window is statistically analyzed. If the proportion of short time windows classified as stable operating scenarios within the long time window exceeds a preset threshold of 80%, and the average stability confidence factor of short time windows classified as dynamically switching scenarios is not lower than a preset low-stability threshold of 0.5, then the long time window is determined to be a valid stable period; otherwise, it is determined to be an unstable period.

[0110] The determination rule is based on the following: long-term stable operation of the equipment requires that it be in a stable scenario for the vast majority of the time, while allowing a small amount of low-intensity dynamic fluctuations that do not affect the overall stability assessment. Only when a long-term window is determined to be a valid stable period will the expected baseline values ​​of each data item be updated using short-term window data from all stable operating scenarios within that long-term window; the expected baseline values ​​will not be updated during unstable periods to avoid dynamic fluctuation data interfering with the accuracy of the baseline values.

[0111] S220. Extract short-time window data corresponding to stable operating scenarios from the multimodal fingerprint feature dataset. Based on the effective stability period determination result of the long-time window, calculate the expected baseline value of each data item under the protocol stack inherent anchor feature dimension and software behavior identifier feature dimension, respectively, using the stability confidence factor of each short-time window as the weight.

[0112] When a long-term window is determined to be an effective stable period, sampled values ​​of each data item are extracted from all short-term windows within that long-term window that are classified as stable operating scenarios. These samples are then used to update the expected baseline value for each data item. If the current client has not yet accumulated any historical data for any effective stable period, the temporary baseline value for the data item within the current effective stable period is calculated according to S220 and directly used as the initial expected baseline value for that data item. If there is already a historical expected baseline value for the data item generated and stored after the last effective stable period update, the expected baseline value for the data item is updated smoothly using an exponentially weighted moving average method. In this embodiment, the update coefficient is set to 0.1, i.e., new expected baseline value = 0.1 × temporary baseline value for the current effective stable period + 0.9 × historical expected baseline value for the data item. This update coefficient ensures smooth updates of the baseline value and avoids excessively large single update magnitudes.

[0113] The protocol stack inherent anchoring feature dimension includes two data items: TCP / IP protocol stack inherent parameters and JA3 client handshake fingerprint. The software behavior identification feature dimension includes two data items: JS runtime characteristics and Canvas rendering characteristics.

[0114] For continuous numerical data items such as inherent parameters of the TCP / IP protocol stack and runtime characteristics of JS, the expected baseline value of the data item is obtained by taking the weighted arithmetic mean of all sampled values ​​of the data item within the short time window of each stable operating scenario during the effective stable period, using the stability confidence factor as the weight.

[0115] For discrete hash value data items such as JA3 client handshake fingerprints and Canvas rendering features, within a short time window of stable operation scenarios during the effective stable period, the hash value with the highest frequency of occurrence is taken as the expected baseline value for the data item; if all hash values ​​have the same frequency of occurrence, the hash value collected in the first stable operation scenario is taken as the initial baseline value.

[0116] Through the above-mentioned layered time window design, the short time window ensures the real-time recognition of the operating scenario, while the long time window ensures the long-term stability of the expected benchmark value and avoids short-term fluctuations from interfering with the benchmark value.

[0117] S230. Taking the multimodal fingerprint feature data corresponding to short time windows divided into dynamic switching scenarios as input, the cross-domain correlation weight coefficient reflecting the relative stability of each data item in dynamic switching scenarios is constructed by analyzing the deviation relationship between the sampled value of each data item and the expected benchmark value of the corresponding data item in stable operation scenarios. A personalized dynamic fault-tolerant window is established for each data item, with the expected benchmark value of the data item in stable operation scenarios as the center of the window and the standard deviation of the sampled value of the data item in stable operation scenarios as the initial window radius. When the client undergoes normal device evolution, the window radius is updated using an exponential weighted moving average method, and the update weight is positively correlated with the stability confidence factor of the corresponding short time window. The higher the stability confidence factor of the short time window data, the greater the contribution of the window boundary update. A numerical and temporal dual-dimensional joint discrimination mechanism is constructed to perform nonlinear mutation marking on abnormal feature changes.

[0118] First, construct the cross-domain association weight coefficients between each data item. For the two data items under the protocol stack inherent anchoring feature dimension and the two data items under the software behavior identification feature dimension, a total of four data items, calculate the deviation between the sampled value of each data item in the current short-time window dynamic switching scenario and the expected baseline value of the corresponding data item in the latest stable operation scenario, and obtain the deviation sequence of each data item.

[0119] For data items containing multiple specific parameters (TCP / IP protocol stack inherent parameters include TCP initial window value, maximum segment length value, and time to live value; JS runtime characteristics include function call stack depth, prototype chain traversal time, and asynchronous task queue scheduling delay time), first calculate the difference between the sampled value of each specific parameter at the current sampling time and the expected baseline value of that specific parameter, and then calculate the root mean square (RMSE, i.e., the square root of the average of the sum of squares) of the difference as the deviation of that data item at the current sampling time; for data items with a single parameter (JA3 client handshake fingerprint, Canvas rendering features), directly use the difference of that parameter as the deviation.

[0120] For a single hash value data item (JA3 client handshake fingerprint, Canvas rendering feature), if the current sampled hash value is the same as the expected baseline hash value, the deviation is 0; otherwise, the deviation is 1. The variance of each deviation sequence is calculated, resulting in four variance values, each representing the degree of fluctuation of each data item under dynamically switching scenarios. The reciprocal of each variance value is taken, and to avoid division by zero due to a zero variance, a very small positive number 10⁻ is added to each variance value. 8 As a smoothing term, sum the reciprocals of all variances, and divide each reciprocal of variance by the sum of the total reciprocals to obtain the cross-domain association weight coefficient for each data item. This cross-domain association weight coefficient reflects the relative stability of the data item in a dynamically switching scenario. The smaller the variance of the data item (the larger the coefficient after normalization), the higher its cross-domain stability, and it should be given a higher weight in subsequent feature fusion.

[0121] Secondly, a personalized dynamic fault-tolerant window is established. For each data item, the expected baseline value of the data item under stable operating conditions is used as the center of the window, and the standard deviation of all sampled values ​​of the data item under stable operating conditions is used as the measure of dispersion. The initial window radius is set to 3 times the standard deviation, resulting in the initial lower and upper limits of the window. The lower limit of the window is equal to the expected baseline value minus 3 times the standard deviation, and the upper limit of the window is equal to the expected baseline value plus 3 times the standard deviation.

[0122] When a client undergoes normal device evolution, the personalized dynamic fault tolerance window boundary is updated using an exponentially weighted moving average method. The update weight is positively correlated with the stability confidence factor of the corresponding time window. The larger the stability confidence factor of the time window data, the higher its contribution to the update of the personalized dynamic fault tolerance window boundary, thus avoiding interference from dynamic fluctuation data with window accuracy.

[0123] Specifically, the formula for updating the personalized dynamic fault-tolerant window radius is as follows: ,in The current window radius; The standard deviation of the standardized sampled values ​​for this data item under the new stable operating scenario; To update the weights, =Current short-time window stability confidence factor × 0.9 + 0.05, The final value range is [0.05, 0.95];

[0124] Should The updated weight formula is set based on the following: when the stability confidence factor is 1, α is 0.95, and historical window data contributes the most; when the stability confidence factor is 0, α is 0.05, and new data contributes the most, perfectly conforming to the design logic of "the higher the stability, the greater the weight of historical data". The updated lower window limit... =Expected benchmark value− Updated window limit =Expected benchmark value+ / 2, maintain personalized dynamic fault tolerance symmetrical about the expected baseline value.

[0125] Finally, a joint discrimination mechanism based on both numerical and temporal dimensions is constructed. For the sampled value of each data item in a dynamically switching scenario (if the data item contains multiple specific parameters, the deviation at that sampling moment is first obtained using the aforementioned deviation calculation method and then used as the current sampled value);

[0126] First, numerical dimension discrimination is performed: it is determined whether the sampled value exceeds the personalized dynamic fault tolerance window range corresponding to the current data item. If the sampled value is less than the lower limit of the window or greater than the upper limit of the window, a numerical dimension anomaly flag is triggered. Simultaneously, temporal dimension discrimination is performed: five consecutive sampled points of the data item before and after the dynamic scene switching occurs are extracted to form a temporal sequence, and the linear regression slope of the temporal sequence is calculated. If the absolute value of the slope is lower than the preset gradient threshold, it is determined to conform to the continuous gradient law.

[0127] The preset gradient threshold is set based on the short-term fluctuation range of the data item under stable operating conditions: the absolute value sequence of the linear regression slope of five consecutive sampling points under stable operating conditions is calculated, and the 95th percentile of this absolute value sequence is taken as the preset gradient threshold to cover the slope fluctuation range under normal conditions; if there is insufficient data under stable operating conditions, it is set to 0.1 by default. When the sampled value of a data item exceeds the range of the personalized dynamic fault tolerance window and the temporal change does not conform to the continuous gradient law, the data item is marked as a nonlinear mutation. If the sampled value exceeds the window range but conforms to the continuous gradient law, it is determined to be normal equipment evolution, triggering the aforementioned window boundary update process.

[0128] The cross-domain association weight coefficients between the data items constructed above, the upper and lower limits of the personalized dynamic fault tolerance window for each data item, and the nonlinear mutation labeling results are aggregated into a cross-domain fingerprint stability parameter set, which is used for feature calibration and weight allocation in subsequent steps.

[0129] S3. Extract the protocol stack inherent anchor features and software behavior identifier features hierarchically from the multimodal fingerprint feature dataset, perform bias compensation based on the cross-domain fingerprint stability parameter set, and perform dimensional-level differentiated dynamic weight allocation on the protocol stack inherent anchor features and software behavior identifier features based on the scene dynamic degree factor calculated by the stability confidence factor to generate cross-domain fusion feature codes.

[0130] In this embodiment, as Figure 3 As shown, step S3 includes the following specific steps:

[0131] S310. Extract the protocol stack inherent anchoring features and software behavior identification features from the multimodal fingerprint feature dataset, and vectorize and concatenate them in a fixed order to generate the protocol stack inherent anchoring feature vector and the software behavior identification feature vector.

[0132] On the server side, all data items of the protocol stack inherent anchor feature dimension and all data items of the software behavior identification feature dimension are extracted from the multimodal fingerprint feature dataset.

[0133] Following a preset data item order, the inherent parameters of the TCP / IP protocol stack are vectorized and concatenated with the JA3 client handshake fingerprint to generate a fixed-dimensional protocol stack inherent anchoring feature vector. Specifically, the inherent parameters of the TCP / IP protocol stack (including TCP initial window value, maximum segment length value, and time to live value) are arranged in the order of TCP initial window value, maximum segment length value, and time to live value, and concatenated with the JA3 client handshake fingerprint value to form a four-dimensional vector as the protocol stack inherent anchoring feature vector.

[0134] Following a similarly pre-defined order of data items, JS runtime characteristics and Canvas rendering features are vectorized and concatenated to generate a fixed-dimensional software behavior identifier feature vector. Specifically, JS runtime characteristics (including function call stack depth, prototype chain traversal time, and asynchronous task queue scheduling delay) are arranged in the order of function call stack depth, prototype chain traversal time, and asynchronous task queue scheduling delay, and concatenated with Canvas rendering feature values ​​to form a four-dimensional vector as the software behavior identifier feature vector.

[0135] The generated protocol stack inherent anchor feature vector is used as the basic anchor feature for the uniqueness of the client identity, and the generated software behavior identifier feature vector is used as the core identifier feature for the individual client differentiation and anti-tampering, which is used for benchmark calibration and dynamic weight allocation in subsequent steps.

[0136] S320. For each data item under the inherent anchor feature vector and software behavior identifier feature vector of the protocol stack, obtain the real-time sampled value of the data item, calculate the feature deviation between the real-time sampled value and the expected baseline value of the data item, adjust the feature deviation by weighting it with cross-domain correlation weight coefficient to obtain the deviation correction amount, add the expected baseline value and the deviation correction amount, and output the calibrated stable value of the data item.

[0137] On the server side, benchmark calibration is performed based on the protocol stack inherent anchoring feature vector and software behavior identifier feature vector generated by S310, combined with the cross-domain fingerprint stability parameter set generated by S230. The expected benchmark value and cross-domain association weight coefficient of each data item are extracted from the cross-domain fingerprint stability parameter set. All sampled values ​​are taken from the standardized processing results of the current 30-second short time window, consistent with the data preprocessing process of S140.

[0138] For continuous numerical data items such as TCP / IP protocol stack intrinsic parameters (including TCP initial window value, maximum segment length value, and time to live value) in the protocol stack intrinsic anchoring feature vector and JS runtime characteristics in the software behavior identification feature vector, the current real-time standardized sample value of each parameter is taken. Call the corresponding expected baseline value Cross-domain association weight coefficient Calculate the calibrated value according to the deviation compensation formula: ; in: The cross-domain correlation weight coefficient generated for S230 has a value range of [0,1]. When the cross-domain correlation weight coefficient is closer to 1, it indicates that the cross-domain stability of the data item is higher in the dynamic switching scenario, and the value after deviation compensation is closer to the current sampled value. When the cross-domain correlation weight coefficient is closer to 0, it indicates that the fluctuation of the data item is greater in the dynamic switching scenario, and the value after deviation compensation is closer to the expected benchmark value. This logic is completely consistent with the definition of the cross-domain correlation weight coefficient in S230.

[0139] For discrete hash value data items such as JA3 client handshake fingerprints and Canvas rendering features, since hash values ​​are discrete identifiers and their numerical values ​​themselves do not have continuous computational meaning, a confidence judgment logic based on cross-domain correlation weight coefficients is used for deviation compensation: when the cross-domain correlation weight coefficient of the data item is greater than or equal to 0.8, the current sampled hash value is determined to have cross-domain stability, and the current real-time sampled hash value is directly used as the calibrated value; when the cross-domain correlation weight coefficient is less than 0.8, the current sampled hash value is determined to be greatly affected by scene fluctuations, and the expected baseline hash value is used as the calibrated value. The setting of this 0.8 threshold is consistent with the stability judgment threshold of S210, ensuring the uniformity of the threshold system across the entire solution.

[0140] The calibrated TCP / IP protocol stack inherent parameters and JA3 client handshake fingerprints are combined in a preset order to form a calibrated protocol stack inherent anchoring feature vector. The calibrated JS runtime characteristics and Canvas rendering characteristics are combined in a preset order to form a calibrated software behavior identification feature vector, which serves as the input for subsequent S330 dynamic weight allocation.

[0141] S330. Set initial weights for each data item using cross-domain association weight coefficients. The initial weights of data items under the protocol stack inherent anchoring feature dimension are positively correlated with the cross-domain association weight coefficients of the corresponding data items, while the initial weights of data items under the software behavior identification feature dimension are positively correlated with individual discriminability. Calculate the scene dynamics factor based on the stability confidence factor of the current short time window, and perform continuous gradient updates on the initial weights according to the scene dynamics factor. Combine the nonlinear mutation markers in the cross-domain fingerprint stability parameter set, perform gradient weight reduction on the data items marked as nonlinear mutations, and generate dimension-specific weight vectors.

[0142] First, based on the cross-domain association weight coefficients in the cross-domain fingerprint stable parameter set, initial weights are set for each data item. The initial weights of each data item under the protocol stack's inherent anchoring feature dimension are positively correlated with the cross-domain association weight coefficients of that data item; therefore, these initial weights are taken. ;in Let be the cross-domain association weight coefficient for the i-th data item, with a value range of [0,1], so that data items with higher cross-domain stability have higher initial weights; the initial weights of each data item under the software behavior identifier feature dimension are positively correlated with the individual distinguishability of that data item, and the initial weights are taken as . This results in higher initial weights for data items with greater cross-domain fluctuations and higher individual differentiation.

[0143] Based on this, the current short-time window stability confidence factor generated by S210 Calculate the dynamic factor of the scene The calculation formula is: =1− , The value range is forcibly normalized to the [0,1] interval. When the stability confidence factor... When =1 (completely stable), =0; when When =0 (fully dynamic), =1, the scene dynamics factor directly reflects the degree of fluctuation in the current running scene.

[0144] Continuous gradient updates are performed on the initial weights based on the scene dynamics factor. The weight adjustment coefficients of each data item under the protocol stack's inherent anchoring feature dimension are positively correlated with the scene dynamics factor; the adjusted weights are then used. The stronger the scene fluctuation, the higher the weight of the protocol stack features, fully utilizing the cross-domain stability advantage of protocol stack features; the weight adjustment coefficient of each data item under the software behavior identifier feature dimension is positively correlated with the stability confidence factor, and the adjusted weights are taken. The more stable the scenario, the higher the weight of the software behavior features, thus fully leveraging the individual distinguishability advantage of the software behavior features.

[0145] Simultaneously, combining the personalized dynamic fault-tolerant window generated by S230 from the cross-domain fingerprint stability parameter set with the nonlinear mutation labeling results, gradient weighting is performed on anomalous data items. Only when a data item is marked as a nonlinear mutation within the current time window, a penalty coefficient is calculated based on the magnitude of the sampled value exceeding the window boundary. The calculation formula is: ; in The current sampled value is used, and the window center and window radius are taken from the personalized dynamic fault-tolerant window of this data item; for data items containing multiple specific parameters, This represents the deviation at the current sampling time, calculated using the S230 root mean square method. Final weight. = (1− ),when When the value is ≥0.9, the dimension-specific weight of the data item is reduced to close to 0 and is removed during actual feature fusion to avoid the impact of malicious tampering and abnormal fluctuations on fingerprint stability.

[0146] The weight values ​​of each data item, as assigned above, are combined in order to form a dimension-specific weight vector that corresponds one-to-one with each data item. Used for subsequent feature weighted fusion of S340.

[0147] S340: Based on dimension-level dedicated weight vectors, perform weighted fusion on the protocol stack inherent anchor feature vector and software behavior identifier feature vector after deviation compensation to generate a fixed-length cross-domain fusion feature code.

[0148] On the server side, based on dimension-specific weight vectors A weighted fusion is performed on the calibrated protocol stack intrinsic anchoring feature vector and the software behavior identifier feature vector. Let the calibrated protocol stack intrinsic anchoring feature vector be... ,in It is the combined calibration value of the inherent parameters of the TCP / IP protocol stack (i.e., the root mean square of the calibration values ​​of the three specific parameters). Let the calibration value be the handshake fingerprint of the JA3 client; let the calibrated software behavior identifier feature vector be... ,in This is the combined calibration value for the JS runtime characteristics (the root mean square of the calibration values ​​of the three specific parameters). Calibration values ​​for Canvas rendering features.

[0149] The calibration values ​​of the four data items are multiplied by their corresponding dimension-specific weighting coefficients to obtain the weighted feature values ​​of each data item. (i=1,2,3,4), concatenate the data items in order to form a fused feature vector. .

[0150] For fused feature vectors L2 norm normalization is performed to eliminate dimensional differences between different feature dimensions, scaling the magnitude of the fused feature vector to 1 while maintaining the relative proportions between the feature dimensions. The normalized feature vector is then output as a fixed-length cross-domain fusion feature code for subsequent S410 bias source analysis and S420 device fingerprint generation.

[0151] S4. Generate cross-domain multimodal device fingerprints based on cross-domain fusion feature codes.

[0152] In this embodiment, as Figure 4 As shown, step S4 includes the following specific steps: S410. Combining the cross-domain fingerprint stability parameter set, perform deviation source analysis on the cross-domain fused feature code to distinguish between normal environmental fluctuations, normal device evolution, and malicious tampering scenarios.

[0153] On the server side, cross-domain fusion signatures are generated based on S340. =[ [Compared with the numerical baseline fingerprint stored in the client's history] =[ Perform deviation source analysis. Numerical benchmark fingerprint. Cross-domain fusion signature Having the same dimensional structure and units, they are stored in the trusted storage area on the server side. When the client first accesses the database without a historical benchmark fingerprint, the initial expected benchmark values ​​of each data item generated by S220 are processed according to the fusion rules of S340 and used as the initial numerical benchmark fingerprint.

[0154] First, the Euclidean distance between the cross-domain fused feature code and the baseline fingerprint is calculated as a deviation metric. This reflects the degree of deviation between the currently collected client characteristics and the historical stable benchmark.

[0155] Secondly, the upper and lower limits of the personalized dynamic fault-tolerant window for each data item are extracted from the cross-domain fingerprint stability parameter set. and The parameters for determining the continuous gradual change pattern defined in S230 are also included. The personalized dynamic tolerance window for each data item defines the acceptable deviation range for that data item under normal environmental fluctuations.

[0156] Calculate the weighted comprehensive boundary based on the S330-dimensional dedicated weight vector. This value serves as the threshold for determining the deviation metric.

[0157] When deviation measurement value Less than or equal to the weighted synthesis boundary At this point, the current cross-domain fused signature is determined to be within the range of normal environmental fluctuations. The difference between the current cross-domain fused signature and the baseline fingerprint is within the range of normal environmental fluctuations.

[0158] When deviation measurement value Greater than the weighted synthesis boundary Then, further analysis is performed to determine whether the trend of feature changes conforms to the continuous gradual change rule specified in S230. The definition of the continuous gradual change rule is consistent with that in S230, that is, the absolute value of the temporal change slope of each data item before and after the dynamic switching scenario is lower than the preset gradual change threshold (the setting method of the preset gradual change threshold is described in S230). If the changes of all data items conform to the continuous gradual change rule, the current cross-domain fusion signature is determined to be a normal device evolution, triggering the baseline fingerprint update; otherwise, the current cross-domain fusion signature is determined to be a malicious tampering scenario.

[0159] S420. For cross-domain fusion feature codes that are determined to be normal environmental fluctuations or normal equipment evolution, a hash algorithm is used to generate cross-domain multimodal device fingerprints.

[0160] On the server side, hierarchical processing is performed based on the deviation source analysis results of S410. For cross-domain fusion signatures determined to be from normal environmental fluctuation scenarios, the device fingerprint is directly generated using the current cross-domain fusion signature. For cross-domain fusion signatures determined to be from normal device evolution, the numerical baseline fingerprint is updated using an exponentially weighted moving average method. The updated baseline fingerprint = ×current baseline fingerprint + (1- )× Cross-domain fusion feature code, where As the baseline fingerprint update smoothing coefficient, this embodiment takes =0.9, meaning the historical baseline fingerprint weight is 0.9 and the new feature code weight is 0.1.

[0161] The value of the baseline fingerprint update smoothing coefficient is exactly matched with the expected baseline update coefficient in S220. Historical information should dominate to avoid excessive disturbance to the baseline in a single evolution. The value can also be adaptively adjusted according to the historical evolution speed of the device, with a range of [0.85, 0.95]. The updated baseline fingerprint is used as the current authentication result. For cross-domain fusion signatures determined to be maliciously tampered, a security alarm is triggered and the client's identity authentication request is blocked. For scenarios determined to be normal environmental fluctuations or normal device evolution, the finally determined feature vector is used to generate a cross-domain multimodal device fingerprint using the national cryptographic SM3 hash algorithm to complete the client's cross-domain identity authentication.

[0162] Embodiments of the present invention also provide an electronic device, including a memory, a processor, and a communication bus; the memory and the processor are connected via the communication bus. The memory stores a cross-domain multimodal device fingerprint generation method that can be loaded by the processor and executed as provided in the above embodiments.

[0163] The memory can be used to store instructions, programs, code, code sets, or instruction sets. The memory may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function, and instructions for implementing the cross-domain multimodal device fingerprint generation method provided in the above embodiments. The data storage area may store data involved in the cross-domain multimodal device fingerprint generation method provided in the above embodiments.

[0164] A processor may include one or more processing cores. The processor executes instructions, programs, code sets, or instruction sets stored in memory, and calls data stored in memory to perform various functions and process data as described in this application. The processor may be at least one of a specific application-specific integrated circuit, a digital signal processor, a digital signal processing device, a programmable logic device, a field-programmable gate array, a central processing unit, a controller, a microcontroller, and a microprocessor. It is understood that, for different devices, the electronic devices used to implement the above-described processor functions may also be other types, and the embodiments of this application do not specifically limit the specific implementation.

[0165] A communication bus may include a pathway for transmitting information between the aforementioned components. The communication bus can be a PCI bus or an EISA bus, etc. Communication buses can be categorized into address buses, data buses, control buses, etc.

[0166] This application provides a computer-readable storage medium storing a computer program that can be loaded by a processor and execute the cross-domain multimodal device fingerprint generation method provided in the above embodiments.

[0167] In this embodiment, a computer-readable storage medium can be a tangible device that holds and stores instructions used by an instruction execution device. A computer-readable storage medium can be, but is not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any combination thereof. Specifically, a computer-readable storage medium can be a portable computer disk, a hard disk, a USB flash drive, a random access memory, a read-only memory, an erasable programmable read-only memory, a podium random access memory, a portable compressed disk read-only memory, a digital multifunction disk, a memory stick, a floppy disk, an optical disk, a magnetic disk, a mechanical encoding device, or any combination thereof.

[0168] 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 process, method, article, or apparatus.

[0169] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing application concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions claimed in this application.

Claims

1. A method for generating fingerprints for cross-domain multimodal devices, characterized in that, Includes the following steps: S1. Collect multi-dimensional feature data of client cross-domain operation, and construct a multimodal fingerprint feature dataset containing runtime scenario feature data, software inherent attribute data, and behavioral feature data; S2. Through a two-level sliding time window architecture, stability confidence factors for each time window are generated based on the characteristic data of the running scenario. Based on the stability confidence factors, the multimodal fingerprint feature dataset is divided into stable running scenarios and dynamic switching scenarios. Using the stable running scenario as the benchmark anchor and the dynamic switching scenario as the reference, a cross-domain fingerprint stability parameter set including cross-domain association weight coefficients, personalized dynamic fault-tolerant windows, and nonlinear mutation markers is generated. The process involves a two-level sliding time window architecture, which quantifies and generates stability confidence factors for each time window based on runtime scenario feature data. This includes the following steps: Based on a two-level sliding time window architecture, the stability confidence factor of the short time window is obtained by weighted fusion of the timing stability of the running status, the timing stability of the network connection, the timing stability of the network latency, and the stability of IP usage habits in the running scenario feature data. S3. Extract the protocol stack inherent anchoring features and software behavior identification features hierarchically from the multimodal fingerprint feature dataset, perform bias compensation based on the cross-domain fingerprint stability parameter set, and perform dimensional-level differentiated dynamic weight allocation on the protocol stack inherent anchoring features and software behavior identification features based on the scene dynamic degree factor calculated by the stability confidence factor to generate cross-domain fusion feature codes. Among them, based on the scene dynamic degree factor calculated by the stability confidence factor, the inherent anchoring features of the protocol stack and the software behavior identification features are dynamically weighted at the dimensional level to generate cross-domain fusion feature codes, including the following steps: Initial weights are set for each data item using cross-domain association weight coefficients. The initial weights of data items under the protocol stack inherent anchoring feature dimension are positively correlated with the cross-domain association weight coefficients of the corresponding data items, while the initial weights of data items under the software behavior identification feature dimension are positively correlated with individual discriminability. The scene dynamic degree factor is calculated based on the stability confidence factor of the current short time window, and the initial weights are continuously updated by gradient according to the scene dynamic degree factor. Combined with the nonlinear mutation markers in the cross-domain fingerprint stability parameter set, gradient weight reduction is performed on the data items marked as nonlinear mutations to generate dimension-specific weight vectors. Based on dimension-specific weight vectors, a weighted fusion is performed on the protocol stack inherent anchor feature vector and the software behavior identifier feature vector after deviation compensation to generate a fixed-length cross-domain fusion feature code. S4. Generate cross-domain multimodal device fingerprints based on cross-domain fusion feature codes.

2. The cross-domain multimodal device fingerprint generation method according to claim 1, characterized in that, Collect multi-dimensional feature data of client cross-domain operation, and construct a multimodal fingerprint feature dataset containing runtime scenario feature data, software inherent attribute data, and behavioral feature data, including the following steps: The runtime scenario feature data is extracted by passively listening to network communication data packets through server-side traffic probes to obtain network switching status and network latency baseline, and by actively collecting runtime status identifier codes through the front end. The software's inherent attribute data is parsed by the server-side traffic probe to extract parameters of the transmission control protocol layer and the Internet protocol layer, extract inherent parameters of the TCP / IP protocol stack, and generate a JA3 client handshake fingerprint by parsing the handshake process of the transport layer security protocol. By using a lightweight, proactive front-end data collection method, a collection script is dynamically injected into the client runtime environment to collect behavioral feature data that includes JS runtime characteristics and Canvas rendering features. The behavioral feature data is anonymized locally on the client side to generate a behavioral feature security digest. Outlier removal and linear normalization are performed on the runtime scenario feature data, software inherent attribute data, and behavioral feature security digest, and they are aggregated into a multimodal fingerprint feature dataset.

3. The cross-domain multimodal device fingerprint generation method according to claim 2, characterized in that, Based on the stability confidence factor, the multimodal fingerprint feature dataset is divided into stable operating scenarios and dynamically switching scenarios, including the following steps: By comparing the stability confidence factor with the stability judgment threshold, the short time window is divided into a stable operation scenario or a dynamic switching scenario.

4. The cross-domain multimodal device fingerprint generation method according to claim 3, characterized in that, Based on a two-level sliding time window architecture, the following steps are included: Short time windows slide forward with a fixed duration, and each short time window independently calculates the stability confidence factor and divides the operating scenario; long time windows are composed of consecutive short time windows, and slide forward with the short time windows as the sliding step size. The distribution of stability confidence factors of each short time window within the long time window is statistically analyzed to determine whether the long time window is an effective stable period.

5. The cross-domain multimodal device fingerprint generation method according to claim 4, characterized in that, Using stable operating scenarios as the baseline and dynamically switching scenarios as the reference, a set of stable cross-domain fingerprint parameters is generated, including cross-domain correlation weight coefficients, personalized dynamic fault-tolerant windows, and nonlinear mutation markers. This includes the following steps: Short-time window data corresponding to stable operating scenarios are extracted from the multimodal fingerprint feature dataset. Based on the effective stability period determination results of the long-time window, the expected baseline values ​​of each data item under the protocol stack inherent anchor feature dimension and the software behavior identifier feature dimension are calculated with the stability confidence factor of each short-time window as the weight. Using multimodal fingerprint feature data corresponding to short time windows divided into dynamic switching scenarios as input, this study analyzes the deviation relationship between the sampled values ​​of each data item and the expected baseline values ​​of the corresponding data items in stable operation scenarios. This constructs a cross-domain correlation weight coefficient reflecting the relative stability of each data item in dynamic switching scenarios. A personalized dynamic fault-tolerant window is established for each data item, with the expected baseline value of the data item in stable operation scenarios as the window center and the standard deviation of the sampled values ​​of the data item in stable operation scenarios as the initial window radius. When a normal device evolution occurs on the client side, the window radius is updated using an exponentially weighted moving average method, and the update weight is positively correlated with the stability confidence factor of the corresponding short time window. Short time window data with higher stability confidence factors contribute more to the window boundary update. Furthermore, a dual-dimensional (numerical and temporal) joint discrimination mechanism is constructed to nonlinearly label abnormal feature changes.

6. The cross-domain multimodal device fingerprint generation method according to claim 5, characterized in that, A joint numerical and temporal dimension discrimination mechanism is constructed to perform nonlinear mutation labeling on anomalous feature changes, including the following steps: For each data item in a dynamic switching scenario within a short time window, obtain the sampled value of the data item and the corresponding personalized dynamic fault tolerance window; if the sampled value exceeds the range of the personalized dynamic fault tolerance window, and the temporal change of the data item before and after the dynamic switching scenario does not conform to the historical continuous gradual change pattern under the stable operation scenario, then the data item is marked as a nonlinear mutation.

7. The cross-domain multimodal device fingerprint generation method according to claim 6, characterized in that, The protocol stack's inherent anchoring features and software behavior identifiers are extracted hierarchically from the multimodal fingerprint feature dataset, and bias compensation is performed based on the cross-domain fingerprint stable parameter set, including the following steps: The protocol stack inherent anchoring features and software behavior identification features are extracted from the multimodal fingerprint feature dataset, and vectorized and concatenated in a fixed order to generate the protocol stack inherent anchoring feature vector and the software behavior identification feature vector. For each data item under the inherent anchor feature vector of the protocol stack and the software behavior identifier feature vector, the real-time sampled value of the data item is obtained, the feature deviation between the real-time sampled value and the expected baseline value of the data item is calculated, the feature deviation is adjusted by cross-domain correlation weight coefficient to obtain the deviation correction amount, the expected baseline value and the deviation correction amount are added together, and the calibrated stable value of the data item is output.

8. The cross-domain multimodal device fingerprint generation method according to claim 7, characterized in that, Generating a cross-domain multimodal device fingerprint based on cross-domain fusion feature codes includes the following steps: By combining the cross-domain fingerprint stability parameter set, the deviation sources of cross-domain fused feature codes are analyzed to distinguish between normal environmental fluctuations, normal device evolution and malicious tampering scenarios; For cross-domain fusion feature codes determined to be normal environmental fluctuations or normal equipment evolution, a hash algorithm is used to generate cross-domain multimodal device fingerprints.

Images