Cross-domain identity authentication method based on x interface

Abstract

The application relates to the technical field of network security and telecommunication management, and particularly discloses a cross-domain identity authentication method based on an X interface, which performs hash operation and fusion signature on device hardware fingerprints and dynamic environment context in a customer domain, generates a dynamic trusted identity load, transmits the dynamic trusted identity load to a provider domain through the X interface to complete signature verification and clustering modeling, establishes a device trust baseline model, and issues a hardware binding token. Before each session, the customer domain collects real-time behavior characteristics and token encryption and encapsulation, and then submits the real-time behavior characteristics and token encryption and encapsulation to the provider domain, the provider domain performs deviation degree evaluation on the real-time behavior characteristics and the baseline model to output a dynamic trust score, generates an adaptive access strategy based on the dynamic trust score, and realizes the transformation from single authentication to continuous trust evaluation. In the deviation degree measurement link, a precision matrix is obtained by jointly extracting a baseline model covariance structure, anisotropic weighting is performed by using Mahalanobis distance instead of Euclidean distance, legal cooperative deviation and abnormal reverse deviation are distinguished, and false positives and false negatives are suppressed.

Description

Technical Field

[0001] This application relates to the fields of network security and telecommunications management technology, and more specifically, to a cross-domain identity authentication method based on the X interface. Background Technology

[0002] As digital transformation deepens across industries, customer networks are increasingly integrating their own IT resources with network services provided by telecom providers. The scale and types of customer front-end devices deployed at the boundary between customer domain and provider domain continue to expand. There is an urgent need for efficient cross-domain management information exchange between the customer domain operating system and the provider domain operating system through the X interface. Identity authentication, as the security cornerstone of cross-domain information exchange, directly determines the security boundary of the entire customer network management system.

[0003] However, existing cross-domain authentication schemes primarily rely on software-level logical identifiers and single-time credential verification mechanisms. These only prove the correctness of the cryptographic dimension and cannot deeply bind identity credentials to physical device hardware entities. Attackers can bypass verification and impersonate others by reverse engineering legitimate credentials and injecting them into cloned devices. Furthermore, existing schemes perform one-time authentication upon session establishment, granting fixed access permissions. They lack dynamic awareness and trust decay assessment capabilities regarding continuous changes in the device's operational state during the session, making it impossible to promptly detect and respond to device hijacking or sudden changes in the operating environment during the session. Moreover, even with the introduction of a continuous deviation detection mechanism based on device behavior characteristics, if the deviation metric only uses isotropic Euclidean distance, it implicitly assumes that each feature dimension is statistically independent and equally weighted. This ignores the inherent statistical coupling relationships between behavioral feature dimensions in the real device operating environment. This leads to false positives caused by multi-dimensional feature co-shifts due to high loads from legitimate business operations being misjudged as anomalies. Simultaneously, attackers' carefully controlled absolute offsets that violate the inherent coupling patterns between features can evade detection due to small distance values, resulting in missed detections.

[0004] Therefore, an optimized cross-domain authentication method based on the X interface is desired. Summary of the Invention

[0005] To address the aforementioned technical problems, this application is proposed. Embodiments of this application provide a cross-domain authentication method based on the X interface, comprising: S1, through the client domain operating system driving the hardware security module, performs irreversible hashing and identity fusion signing on the device hardware fingerprint sequence and dynamic environment context to obtain dynamic trusted identity payload; S2 receives dynamic trusted identity payloads via the X interface from the provider domain operating system, and performs signature verification and unsupervised clustering modeling on the dynamic trusted identity payloads to obtain the device trust baseline model stored in the local authentication database and the hardware binding token issued to the customer domain. S3, before initiating a network session, uses the client domain operating system to perform timestamp-nested encryption and encapsulation of the real-time behavioral feature matrix and the hardware binding token to obtain the session context verification request. S4 receives session context verification requests via the X interface from the provider domain operating system, and performs cross-domain continuous trust assessment and multi-dimensional authentication on the session context verification requests and the device trust baseline model to obtain dynamic trust scores. S5 provides the provider domain operating system to perform interval matching and policy generation on dynamic trust scores and preset multi-level security thresholds to obtain adaptive access policies that are sent to the network-side gateway execution module and verification response messages that are sent back to the customer domain via the X interface.

[0006] Compared with existing technologies, this application proposes a cross-domain identity authentication method based on the X interface. It generates a dynamic, trusted identity payload deeply bound to the physical entity by irreversibly hashing the device hardware fingerprint sequence and dynamic environmental context with the identity fusion signature on the client domain side. This payload is then transmitted to the provider domain via the X interface for signature verification, parsing, and unsupervised clustering modeling. A trust baseline model specific to the device is established, and a hardware-bound token is issued, thus elevating identity authentication from a purely software logical identification level to a hardware physical anti-counterfeiting level. Before each network session is initiated, the client domain collects the device behavior feature matrix in real time and, after timestamp-nested encryption and encapsulation with the hardware-bound token, submits it across domains. The provider domain continuously evaluates the deviation between the real-time features and the trust baseline model to output a dynamic trust score, and generates multi-granularity adaptive access policies accordingly, realizing a shift from single static authentication to continuous trust evaluation throughout the entire session lifecycle. In the deviation measurement stage, the covariance structure in the baseline model is jointly extracted and the accuracy matrix is ​​obtained. The Mahalanobis distance is used instead of the Euclidean distance to calculate the anisotropic weighted deviation, so that the detection boundary can distinguish between legitimate cooperative offsets along the feature coupling direction and abnormal reverse offsets that violate the coupling mode, effectively suppressing false alarms and false negatives. Attached Figure Description

[0007] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0008] Figure 1This is a flowchart illustrating a cross-domain authentication method based on the X interface according to an embodiment of this application; Figure 2 This is a schematic diagram of data flow for a cross-domain authentication method based on the X interface according to an embodiment of this application; Figure 3 This is a flowchart illustrating a cross-domain identity authentication method based on the X interface according to an embodiment of this application, in which the hardware security module driven by the client domain operating system performs irreversible hashing operations and identity fusion signatures on the device hardware fingerprint sequence and dynamic environment context to obtain a dynamic trusted identity payload. Figure 4 This document describes a cross-domain authentication method based on the X interface according to an embodiment of the present application. The method involves providing the provider domain operating system to receive a dynamic trusted identity payload via the X interface, and performing signature verification, parsing, and unsupervised clustering modeling on the dynamic trusted identity payload to obtain a device trust baseline model stored in a local authentication database and a hardware binding token issued to the customer domain. Figure 5 This is a flowchart illustrating a cross-domain authentication method based on the X interface according to an embodiment of this application. The method involves providing a provider domain operating system to receive a session context verification request via the X interface, and performing cross-domain continuous trust assessment and multi-dimensional authentication on the session context verification request and the device trust baseline model to obtain a dynamic trust score. Figure 6 This is a flowchart illustrating a cross-domain authentication method based on the X interface according to an embodiment of this application, which retrieves the device trust baseline model from the authentication database using a hardware-bound token as the primary key, extracts the baseline centroid coordinates, and calculates the deviation distance parameter between the serialized behavioral feature vector and the baseline centroid coordinates. Detailed Implementation

[0009] Hereinafter, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0010] As indicated in this application and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" are not specifically singular and may include plural forms. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0011] While this application makes various references to certain modules of the systems according to embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The modules described are merely illustrative, and different aspects of the systems and methods may use different modules.

[0012] Flowcharts are used in this application to illustrate the operations performed by the system according to embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0013] Existing cross-domain authentication schemes based on the X interface mainly rely on software-level logical identifiers and single-time credential verification, failing to deeply bind identity credentials to physical device hardware entities. Attackers can clone devices to inject legitimate credentials for impersonation, and the lack of continuous dynamic awareness of device operating status after session establishment makes it difficult to promptly detect device hijacking and environmental changes during the session. Even with the introduction of continuous deviation detection based on behavioral features, using only isotropic Euclidean distance metrics will face the dilemma of both false positives and false negatives due to ignoring the inherent statistical coupling between feature dimensions. Therefore, this application proposes a cross-domain authentication method based on the X interface. This method first performs irreversible hashing and identity fusion signature operations on the device hardware fingerprint sequence and dynamic environmental context through a hardware security module in the client domain, generating a dynamic trusted identity payload strongly bound to the physical entity. This payload is then transmitted to the provider domain via the X interface to complete signature verification and unsupervised clustering modeling, establishing a dedicated device trust baseline model and issuing hardware-bound tokens, anchoring the authentication foundation to the unclonable hardware layer. Subsequently, before each session is initiated, the client domain collects a behavioral feature matrix in real time and encapsulates it with a token using a timestamp-nested encryption before submitting it across domains. The provider domain continuously evaluates the deviation between the real-time features and the baseline model to output a dynamic trust score, and generates a multi-granularity adaptive access policy accordingly, achieving continuous trust control throughout the session lifecycle. In the deviation measurement stage, the covariance structure of the baseline model is jointly extracted and the accuracy matrix is ​​calculated. Mahalanobis distance is used instead of Euclidean distance for anisotropic weighted calculation, enabling the detection boundary to distinguish between legitimate cooperative offsets and abnormal offsets that violate coupling patterns, thereby effectively suppressing false positives and false negatives within the same framework.

[0014] Figure 1 This is a flowchart of a cross-domain authentication method based on the X interface according to an embodiment of this application. Figure 2 This is a schematic diagram illustrating the data flow of a cross-domain authentication method based on the X interface according to an embodiment of this application. Figure 1 and Figure 2As shown, an embodiment of this application provides a cross-domain identity authentication method based on the X interface, comprising: S1, driving a hardware security module through a client domain operating system to perform irreversible hashing and identity fusion signing on a device hardware fingerprint sequence and a dynamic environment context to obtain a dynamic trusted identity payload; S2, providing a provider domain operating system to receive the dynamic trusted identity payload via the X interface, and performing signature verification and unsupervised clustering modeling on the dynamic trusted identity payload to obtain a device trust baseline model stored in a local authentication database and a hardware binding token issued to the client domain; S3, before initiating a network session, providing a session context verification request by performing timestamp nested encryption encapsulation on a real-time behavioral feature matrix and a hardware binding token through the client domain operating system; S4, providing a provider domain operating system to receive the session context verification request via the X interface, and performing cross-domain continuous trust evaluation and multi-dimensional authentication on the session context verification request and the device trust baseline model to obtain a dynamic trust score; S5, providing a provider domain operating system to perform interval matching and policy generation on the dynamic trust score and preset multi-level security thresholds to obtain an adaptive access policy issued to the network-side gateway execution module and a verification response message returned to the client domain via the X interface.

[0015] Specifically, in step S1, the hardware security module driven by the client domain operating system performs irreversible hashing and identity fusion signing on the device hardware fingerprint sequence and dynamic environment context to obtain a dynamic trusted identity payload. It should be noted that, given that in cross-domain client network management scenarios based on the X interface, the client's front-end device is deployed at the network boundary between the client domain and the provider domain, if its identity credentials rely solely on software-level logical identifiers, attackers can extract and inject the credentials into cloned devices through reverse engineering. This prevents the provider domain operating system from distinguishing between legitimate physical devices and counterfeit terminals. Furthermore, static identity metadata cannot reflect the actual network access environment the device is currently in, allowing abnormal access after the device is stolen and moved to pass identity verification as well. Therefore, the technical solution of this application first uses the hardware security module driven by the client domain operating system to perform irreversible hashing and identity fusion signing on the device hardware fingerprint sequence, which includes the CPU's unique serial number, the TPM chip's embedded public key, and the network card's physical MAC address, as well as the dynamic environment context, which includes the current access IP address, the base station cell global identifier, and GPS spatial coordinates, to obtain a dynamic trusted identity payload. Through the above processing, the trust foundation of identity authentication can be shifted from the copyable software logic layer to the unclonable hardware physical layer. At the same time, the real-time spatial and network environment information of the device is integrated into the identity credential, so that even if an attacker obtains a copy of the credential, it will fail subsequent verification due to hardware fingerprint mismatch and environmental context offset, thereby effectively blocking device cloning, impersonation and remote access theft.

[0016] Figure 3This document presents a flowchart illustrating a cross-domain identity authentication method based on the X interface, according to an embodiment of this application. The method involves a client domain operating system driving a hardware security module to perform irreversible hashing operations on a device hardware fingerprint sequence and a dynamic environment context, followed by identity fusion signing to obtain a dynamic trusted identity payload. Figure 3 As shown, step S1 includes: S11, reading the device hardware fingerprint sequence and dynamic environment context in parallel through the hardware security module, and performing a concatenation hash operation on the device hardware fingerprint sequence, dynamic environment context, and cryptographic random salt value to obtain hardware and environment hash values; S12, extracting key attribute fields of basic identity metadata based on the cross-domain authentication data standard protocol, and embedding the hardware and environment hash values ​​into the key attribute fields for structured merging to obtain fused identity data; S13, calling the hardware-level private key through the trusted platform module to digitally sign and encrypt the fused identity data to obtain dynamic trusted identity payload.

[0017] In step S11, the device hardware fingerprint sequence and dynamic environment context are read in parallel by the hardware security module, and a concatenation hash operation is performed on the device hardware fingerprint sequence, dynamic environment context, and cryptographic random salt value to obtain the hardware and environment hash values. It should be noted that since the device hardware fingerprint sequence and dynamic environment context belong to two different dimensions of feature data—physical layer and network layer—if they are directly transmitted or stored in plaintext, there is a risk of interception and reverse engineering; furthermore, the original formats and lengths of the two types of data are different, which is not conducive to subsequent unified processing. Based on this, the technical solution of this application first reads the device hardware fingerprint sequence and dynamic environment context in parallel by the hardware security module, and then performs a concatenation hash operation on the device hardware fingerprint sequence, dynamic environment context, and cryptographic random salt value to obtain the hardware and environment hash values. Through the above processing, multi-source heterogeneous physical and environmental features can be compressed into a fixed-length irreversible digest, while the introduction of random salt values ​​defends against rainbow table attacks and replay attacks.

[0018] More specifically, in a specific example of this application, when the customer's front-end device initiates the identity registration process, the hardware security module first reads the device hardware fingerprint sequence and dynamic environment context in parallel through the underlying driver interface. The device hardware fingerprint sequence includes the CPU's unique serial number, the TPM chip's embedded public key, and the network card's physical MAC address. The dynamic environment context includes the current access IP address, the base station cell's global identifier, and GPS spatial coordinates. Subsequently, within the isolated execution environment of the hardware security module, a cryptographically secure random salt value is generated. This random salt value is then concatenated with the read device hardware fingerprint sequence and dynamic environment context according to a predefined fixed byte order to form the original input sequence to be hashed. Based on this, the concatenated original input sequence is fed into the SHA-256 irreversible hash algorithm engine to perform collision-resistant hash calculation, outputting a digest value of fixed length 256 bits. This digest value is the hardware and environment hash value. The above hashing process can be expressed as follows: in, Hardware and environment hash values ​​are fixed-length, unique digest values ​​that represent the physical device entity and the current network access environment. This is an irreversible hash mapping function used to compress an input of arbitrary length into a fixed-length digest. For device hardware fingerprint sequence, For dynamic environment context, The cryptographic random salt value is generated in real time by a random number generator inside the hardware security module. This is a data bit concatenation operator, indicating that multiple data segments are serialized and concatenated in a fixed byte order. Due to the one-way irreversible nature of hash operations, even if an attacker intercepts the hardware and environment hash values ​​in the transmission link, they cannot deduce sensitive information such as the original CPU serial number, TPM public key, or GPS coordinates from them. The independent generation of the random salt value ensures that the hash values ​​generated by the same device at different times are different, thus preventing the intercepted historical hash values ​​from being replayed and reused.

[0019] In step S12, based on the cross-domain authentication data standard protocol, key attribute fields of the basic identity metadata are extracted, and hardware and environment hash values ​​are embedded into the key attribute fields for structured merging to obtain fused identity data. It should be noted that since hardware and environment hash values ​​only carry feature summaries of the physical and network layers, lacking attribute information of business logic dimensions such as device tenant affiliation and factory identification, simply concatenating and transmitting these two types of data will prevent the service domain from parsing and locating fields according to a unified protocol specification after receiving the data. Therefore, the technical solution of this application further extracts key attribute fields of the basic identity metadata based on the cross-domain authentication data standard protocol and embeds hardware and environment hash values ​​into the key attribute fields for structured merging to obtain fused identity data. Through the above processing, physical environment features and business identity attributes can be deeply coupled under a unified protocol framework, enabling the service domain to perform one-time parsing according to standard field offsets.

[0020] More specifically, in a concrete example of this application, firstly, according to the TLV format specification defined by the Cross-Domain Authentication Data Standard Protocol, key attribute fields are extracted from the basic identity metadata. These key attribute fields include the type identifier, length identifier, and value range content corresponding to the customer tenant ID and the device's factory serial number. After extracting the key attribute fields, the hardware and environment hash values ​​generated in the previous step are used as extended verification vectors and embedded into the reserved extended fields of the key attribute fields according to the byte offset positions specified in the protocol. A structured merging operation is then performed on the embedded data, forming a tight field-level binding between the hash digest of the physical environment dimension and the identity attributes of the business logic dimension within the same data structure. After merging, the resulting complete structure is packaged and output as fused identity data. This fused identity data simultaneously carries the device's hardware physical fingerprint, real-time network environment characteristics, and business attribution identifier within a single data object, providing a complete and formatted input for subsequent hardware-level private key signing.

[0021] In step S13, the trusted platform module invokes a hardware-level private key to digitally sign and encrypt the fused identity data to obtain a dynamic trusted identity payload. It should be noted that, because fused identity data faces the risk of man-in-the-middle tampering and forgery injection during cross-domain transmission via the X interface, without cryptographic verification of its source, the provider domain cannot determine whether the received data truly originates from a legitimate physical device. Therefore, the technical solution of this application further invokes a hardware-level private key through a trusted platform module to digitally sign and encrypt the fused identity data to obtain a dynamic trusted identity payload. Through the above processing, the issuance authority of the identity credential can be anchored to a non-derivative hardware private key, preventing any third party without possession of the physical chip from forging a legitimate signature.

[0022] More specifically, in a concrete example of this application, the merged identity data is first transmitted to the hardware-isolated execution environment of the trusted platform module built into the customer's front-end device. Within this isolated environment, an asymmetric encryption private key, embedded in the chip and completely invisible and unexportable to the outside world, is invoked. Subsequently, using this hardware-level private key, a digital signature operation is performed on the merged identity data based on the elliptic curve digital signature algorithm, generating a tamper-proof signature string uniquely corresponding to the merged identity data. After the signature is generated, this tamper-proof signature string is appended as a verification header to the front end of the merged identity data, and both are encrypted and encapsulated together to form a complete data packet with dual attributes of encrypted protection and source authentication. This data packet is the dynamic trusted identity payload. Since the signature operation is completed entirely within the hardware isolation area of ​​the trusted platform module, the private key is never exposed to the operating system's software layer at any stage. Even if the operating system of the customer's front-end device is compromised, attackers cannot extract the private key to forge the signature, thereby ensuring that the dynamic trusted identity payload can be reliably verified for source authenticity and data integrity after cross-domain transmission to the provider domain.

[0023] Specifically, in step S2, the provider domain operating system receives a dynamic trusted identity payload via the X interface, and performs signature verification, parsing, and unsupervised clustering modeling on the dynamic trusted identity payload to obtain a device trust baseline model stored in the local authentication database and a hardware binding token issued to the client domain. It should be noted that, given that the client domain has already generated a dynamic trusted identity payload by fusing the device hardware fingerprint with environmental features and transmitting it across domains to the provider domain via the X interface, the provider domain needs to verify the authenticity of the payload's source and the integrity of the data. Based on this, it needs to establish a mathematical benchmark that can characterize the normal operating state of the device to support the continuous quantitative assessment of the degree of deviation of device behavior in subsequent session requests. Simultaneously, it needs to generate credentials strongly associated with this benchmark and issue them to the client domain as an identity anchor point for subsequent session initiation. Based on this, the technical solution of this application further provides a provider domain operating system that receives a dynamic trusted identity payload via the X interface, and performs signature verification, parsing, and unsupervised clustering modeling on the dynamic trusted identity payload to obtain a device trust baseline model stored in the local authentication database and a hardware binding token issued to the client domain. Through the above processing, a unique multi-dimensional feature space baseline profile can be built for each physically verified customer front-end device within the provider domain. This allows subsequent session requests at any time to quantify the degree of trust by comparing the distance with this baseline. The hardware binding token serves as the unique retrieval key of the baseline model, establishing a persistent trust association channel between the customer domain and the provider domain.

[0024] Figure 4This document describes a cross-domain authentication method based on the X interface, according to an embodiment of this application. The method involves providing the provider domain operating system with a dynamic trusted identity payload via the X interface, performing signature verification and unsupervised clustering modeling on the dynamic trusted identity payload to obtain a device trust baseline model stored in a local authentication database and a hardware binding token issued to the client domain. (See flowchart for details.) Figure 4 As shown, step S2 includes: S21, based on the preset device public key, performing signature verification, decryption, and reverse bit splitting on the dynamic trusted identity payload to obtain hardware and environment hash values ​​and basic identity metadata; S22, projecting the hardware and environment hash values ​​as feature coordinates, and using an unsupervised clustering algorithm combined with clustering labels transformed from basic identity metadata to perform density clustering modeling to obtain the device trust baseline model; S23, based on the unique index identifier of the device trust baseline model, performing a joint hash operation on the unique index identifier and a high-entropy random number to obtain the hardware binding token.

[0025] In step S21, based on the preset device public key, the dynamic trusted identity payload is verified, decrypted, and reversed bitwise to obtain the hardware and environment hash value and basic identity metadata. It should be noted that since the dynamic trusted identity payload may be tampered with or forged during cross-domain transmission, the provider domain must first verify that the payload was indeed signed by the hardware-level private key of a legitimate physical device before using its internal data, and reverse-engineer the fused and encapsulated data into independently processable feature components. Based on this, the technical solution of this application further verifies, decrypts, and reverse-engineers the dynamic trusted identity payload based on the preset device public key to obtain the hardware and environment hash value and basic identity metadata. Through the above processing, cryptographic verification of the payload's authenticity and data integrity can be completed on the provider domain side, and the physical environment characteristics and business identity attributes can be separated into two independent data objects for subsequent processing.

[0026] More specifically, in a specific example of this application, after the provider domain receives the dynamic trusted identity payload via the X interface, it first retrieves a pre-set device public key from the local key management library that is paired with the hardware-level private key of the trusted platform module of the customer's front-end device. Then, using this device public key, it performs an elliptic curve signature verification operation on the digital signature string attached to the dynamic trusted identity payload. The digest value in the signature string is compared bit-by-bit with the hash digest obtained by recalculating the plaintext portion of the payload. If they match, it is determined that the payload has not been tampered with during transmission and indeed originates from the physical device holding the corresponding private key. After successful verification, the encrypted portion of the payload is decrypted to restore the internal converged identity data plaintext. After obtaining the converged identity data plaintext, according to the TLV field offset rules defined by the cross-domain authentication data standard protocol, a reverse bit-by-bit decomposition operation is performed on the plaintext. The hardware and environment hash values ​​embedded in the extended verification field are extracted from the key attribute fields, and the key attribute fields carrying the customer tenant ID and device factory serial number are restored to the basic identity metadata. After the above reverse parsing, the hardware and environment hash value and the basic identity metadata are output as two independent data objects. The former will be used for subsequent high-dimensional feature space mapping and clustering modeling, while the latter will be used as a clustering label to participate in the construction of the device trust baseline model.

[0027] In step S22, the hardware and environment hash values ​​are projected as feature coordinates, and density clustering modeling is performed using an unsupervised clustering algorithm combined with clustering labels transformed from basic identity metadata to obtain a device trust baseline model. It should be noted that since the hardware and environment hash values ​​are fixed-length one-dimensional hash digests, they cannot directly characterize the device's operational status distribution characteristics in a multi-dimensional feature space, and subsequent continuous trust assessment requires a mathematical benchmark with spatial geometric meaning to measure the degree of deviation in real-time behavior. Based on this, the technical solution of this application further projects the hardware and environment hash values ​​as feature coordinates and uses an unsupervised clustering algorithm combined with clustering labels transformed from basic identity metadata to perform density clustering modeling to obtain a device trust baseline model. Through the above processing, a unique health status benchmark profile can be established for each physically verified customer front-end device in a multi-dimensional feature space, providing centroid anchor points and boundary references for deviation distance calculation in subsequent session requests.

[0028] More specifically, in a concrete example of this application, the hardware and environment hash values ​​obtained in the previous step are first subjected to high-dimensional space mapping processing. The 256-bit hash digest is divided into d equal-length sub-segments according to predefined segmentation rules. Each sub-segment is numerically transformed and used as the coordinate component of the corresponding dimension in the d-dimensional feature space. Thus, the one-dimensional hash value is projected into an initial feature coordinate point in the d-dimensional feature space. This coordinate point geometrically represents the spatial location of the device's current physical state and network environment. At the same time, the customer tenant ID and device serial number in the basic identity metadata are encoded and transformed to generate cluster labels used to constrain the clustering calculation boundary, so that the feature coordinates of different devices belonging to the same tenant are confined to their respective independent computational domains during the clustering process. After completing the feature coordinate projection and cluster label generation, both are input into a density-based unsupervised clustering algorithm to perform modeling operations. This algorithm uses the initial feature coordinates as seed points and scans the neighborhood density distribution within the computational domain defined by the cluster labels to calculate the centroid coordinates and security boundary radius of the device-specific cluster features. Finally, the centroid coordinates, safety boundary radius, and cluster labels are structurally encapsulated to output a device trust baseline model. This model mathematically describes the expected position and reasonable fluctuation range of each feature dimension of the customer's front-end device under normal and healthy operating conditions. Subsequent session requests at any time can quantify the degree of deviation of the device behavior by calculating the distance between the real-time feature vector and the centroid coordinates.

[0029] Specifically, the density-based unsupervised clustering algorithm employs the DBSCAN algorithm, with its neighborhood search radius ε preset to 0.5 times the standard deviation of the feature space based on the device type, and the minimum number of neighborhood samples MinPts set to 3. During the cold start phase, when only a single feature coordinate point is generated during the initial device registration, this coordinate point is used as the centroid, and the preset default covariance matrix for the device type is used as the initial covariance structure. As behavioral feature data generated from subsequent interactions with the device accumulates, the clustering model gradually corrects the centroid coordinates and covariance matrix through an incremental update mechanism, making the baseline model more accurate.

[0030] In step S23, a hardware binding token is obtained by performing a joint hash operation on the unique index identifier of the device trust baseline model and a high-entropy random number. It should be noted that since the device trust baseline model is stored in the provider domain's local authentication database, the customer domain needs a lightweight credential to point to this model when initiating subsequent session requests. This credential itself cannot expose the model's internal structure or database storage address to prevent attackers from reverse-engineering the baseline model's retrieval path using the credential. Therefore, the technical solution of this application further performs a joint hash operation on the unique index identifier of the device trust baseline model and a high-entropy random number to obtain a hardware binding token. Through the above processing, a retrieval credential with a unique but irreversible mapping relationship to the baseline model can be generated, establishing a persistent trust association anchor between the customer domain and the provider domain.

[0031] More specifically, in a concrete example of this application, the unique index identifier of the device trust baseline model constructed in the previous step is first extracted from the authentication database. This unique index identifier is a globally unique identifier at the database primary key level, which can accurately locate the device-specific baseline model instance in subsequent searches. Then, a cryptographically secure random number generator from the provider domain is triggered to generate a high-entropy random number. This high-entropy random number is used to inject cryptographic freshness into the token to prevent token collisions between different devices or different registration batches. After obtaining the unique index identifier and the high-entropy random number, the hash message authentication code algorithm is called, and a joint hash operation is performed on the concatenated sequence of the provider domain's secure master key, outputting a fixed-length ciphertext credential, i.e., a hardware-bound token. The above operation process is expressed as follows: in, Bind a token to the hardware. For hash message authentication code functions, To provide a domain security master key, A unique index identifier for the device trust baseline model. High-entropy random numbers, This is the data bit concatenation operator. Due to the one-way irreversible nature of the joint hash operation and the fact that the security master key is held only by the provider domain, even if an attacker intercepts the hardware binding token, they cannot deduce the unique index identifier or the database storage path of the baseline model from it. After generation, the device trust baseline model is written to the provider's local authentication database for retrieval and comparison during subsequent session authentication. At the same time, the hardware binding token is sent to the customer domain via the X interface for storage, serving as the identity anchor credential carried with each subsequent session initiation.

[0032] Specifically, in step S3, before the network session is initiated, the real-time behavioral feature matrix and the hardware binding token are timestamped and encrypted using the client domain operating system to obtain the session context verification request. It should be noted that, since the provider domain needs to obtain the real-time operating status of the client's front-end device at the moment of session initiation for comparison with the trust baseline model in subsequent authentication stages, and the real-time behavioral feature matrix and the hardware binding token are two different types of data objects—dynamically collected data and static credentials, respectively—direct transmission in plaintext would face the risk of link sniffing and replay attacks. Therefore, the technical solution of this application further performs timestamped and encrypted encapsulation of the real-time behavioral feature matrix and the hardware binding token using the client domain operating system before the network session is initiated to obtain the session context verification request. Through the above processing, the device's real-time behavioral characteristics and identity anchor credentials can be fused into a single cross-domain transmission message under cryptographic protection, while timestamping ensures the uniqueness and freshness of each request.

[0033] More specifically, in a concrete example of this application, at the trigger moment when the client's front-end device is about to initiate a new network data session, a real-time behavioral feature matrix containing current memory usage, packet transmission frequency per second, and underlying process status codes is first collected from the underlying probe. Tensor flattening is then performed on this real-time behavioral feature matrix to reduce its dimensionality to a one-dimensional sequence. Subsequently, a maximum-minimum standard interval mapping is performed on each feature value in the one-dimensional sequence, normalizing each component to a standard interval of 0 to 1 to eliminate dimensional differences, and outputting a serialized behavioral feature vector. Simultaneously, the previously obtained hardware binding token is retrieved from the local secure storage area, and the current system timestamp with millisecond precision is obtained by calling the local clock. The current system timestamp is appended to the end of the hardware binding token in a fixed byte sequence format, outputting a time-series binding token.

[0034] Once the serialized behavior feature vector and the timing binding token are ready, they are concatenated into a plaintext session state set by memory-level continuous byte splicing according to the agreed fixed-length message structure. Based on the symmetric session key pre-negotiated with the provider domain, the concatenated set is subjected to AES-256-GCM authentication encryption operation. While encrypting the data, a message authentication code is generated to ensure the confidentiality and integrity of the ciphertext, and the encrypted context payload is output.

[0035] After the encrypted context payload is generated, a plaintext protocol header containing the routing address target, protocol version number, and encryption algorithm identifier type is constructed in memory according to the X interface standard message specification. This plaintext protocol header is used as a prefix and combined with the encrypted context payload in a structured manner. After completing the cross-domain protocol encapsulation, the entire data packet is instantiated into a standard byte stream message that can be transmitted through the network layer. The session context verification request is output and cross-domain transmission is initiated to the provider domain via the X interface.

[0036] Specifically, in step S4, the provider domain operating system receives a session context verification request via the X interface, and performs cross-domain continuous trust assessment and multi-dimensional authentication on the session context verification request and the device trust baseline model to obtain a dynamic trust score. It should be noted that, given that the client domain has already generated a dynamic trusted identity payload by fusing the device hardware fingerprint and environmental features into a signature and transmitting it across domains to the provider domain via the X interface, the provider domain needs to verify the authenticity of the payload's source and the integrity of the data. Based on this, a mathematical benchmark capable of characterizing the normal operating state of the device is established to support the continuous quantitative assessment of the degree of deviation of device behavior in subsequent session requests. Simultaneously, credentials strongly associated with this benchmark need to be generated and issued to the client domain as the identity anchor point for subsequent session initiation. Based on this, the technical solution of this application further provides the provider domain operating system with a dynamic trusted identity payload via the X interface, and performs signature verification parsing and unsupervised clustering modeling on the dynamic trusted identity payload to obtain a device trust baseline model stored in the local authentication database and a hardware binding token issued to the client domain. Through the above processing, a unique multi-dimensional feature space baseline profile can be built for each physically verified customer front-end device within the provider domain. This allows subsequent session requests at any time to quantify the degree of trust by comparing the distance with this baseline. The hardware binding token serves as the unique retrieval key of the baseline model, establishing a persistent trust association channel between the customer domain and the provider domain.

[0037] Figure 5 This is a flowchart illustrating a cross-domain authentication method based on the X interface according to an embodiment of this application. The method involves providing a provider domain operating system to receive a session context verification request via the X interface, and performing cross-domain continuous trust assessment and multi-dimensional authentication on the session context verification request and the device trust baseline model to obtain a dynamic trust score. Figure 5 As shown, step S4 includes: S41, stripping and decrypting the message header of the session context verification request based on the symmetric session key to obtain the serialized behavior feature vector and the hardware binding token; S42, retrieving the device trust baseline model in the authentication database using the hardware binding token as the primary key and extracting the baseline centroid coordinates, and calculating the deviation distance parameter between the serialized behavior feature vector and the baseline centroid coordinates; S43, performing nonlinear mapping and percentage-based truncation quantization on the deviation distance parameter based on the attenuation penalty coefficient to obtain the dynamic trust score.

[0038] In step S41, the session context verification request is stripped of its message header and decrypted based on the symmetric session key to obtain the serialized behavioral feature vector and hardware binding token. It should be noted that because the session context verification request undergoes protocol header encapsulation and authentication encryption during cross-domain transmission, the provider domain cannot directly read the real-time behavioral data and identity credentials carried within it. A reverse reconstruction of the protocol and cryptographic layers is necessary to obtain plaintext data objects usable for trust assessment. Therefore, the technical solution of this application further strips and decrypts the message header of the session context verification request based on the symmetric session key to obtain the serialized behavioral feature vector and hardware binding token. Through the above processing, secure reverse parsing of cross-domain encrypted messages can be completed on the provider domain side, separating the real-time behavioral features and identity anchor credentials into two independent plaintext data objects for subsequent processing.

[0039] More specifically, in a specific example of this application, after the provider domain receives a session context verification request via the X interface, it first performs an outer protocol header stripping operation on the request according to the X interface standard message specification, reading metadata information such as the routing address target, protocol version number, and encryption algorithm identifier type from the plaintext protocol header, and then removes the protocol header from the overall message to extract the internal encryption context payload. Subsequently, it retrieves the symmetric session key pre-negotiated with the client domain from the local key management library, and uses this symmetric session key to perform AES-256-GCM decryption on the encryption context payload. During the decryption process, the message authentication code is simultaneously verified to confirm that the ciphertext has not been tampered with during transmission. After successful verification, the plaintext session state set is restored. After obtaining the plaintext session state set, it performs byte stream deserialization and decomposition according to the agreed fixed-length message structure, separating three data components: a serialization behavior feature vector, a hardware binding token, and an additional current system timestamp. Furthermore, the extracted current system timestamp is read and compared with the time difference of the provider domain server clock. The time difference is confirmed to be within the preset security tolerance window to exclude the possibility of replay attacks. After the timestamp verification is passed, it is discarded. Finally, the purified serialized behavior feature vector and the hardware binding token are output as two independent data objects. The former will be used to calculate the deviation distance from the device trust baseline model, and the latter will be used as the primary key to retrieve the corresponding baseline model instance in the authentication database.

[0040] In step S42, the device trust baseline model is retrieved from the authentication database using the hardware binding token as the primary key, and the baseline centroid coordinates are extracted. The deviation distance parameter between the serialized behavior feature vector and the baseline centroid coordinates is then calculated. It should be noted that, given that the previous step separated the serialized behavior feature vector and the hardware binding token from the session context verification request, the serialized behavior feature vector carries the real-time operating status of the client's front-end device at the moment the session is initiated. The hardware binding token, on the other hand, is a retrieval credential generated by the provider domain during the registration phase and uniquely mapped to the device trust baseline model. This credential is needed to locate the corresponding baseline model instance and extract its centroid coordinates. Then, the spatial distance between the real-time feature and the baseline centroid is calculated to quantify the degree to which the device's current behavior deviates from the health benchmark. Based on this, the technical solution of this application further retrieves the device trust baseline model from the authentication database using the hardware binding token as the primary key, extracts the baseline centroid coordinates, and calculates the deviation distance parameter between the serialized behavior feature vector and the baseline centroid coordinates. Through the above processing, the deviation between the real-time behavior status of the device and the historical health benchmark can be transformed into a quantifiable scalar distance value. The larger the distance value, the further the current operating status of the device deviates from the normal baseline, providing accurate mathematical input for the subsequent nonlinear mapping of trust scores.

[0041] Figure 6 This is a flowchart illustrating a cross-domain authentication method based on the X interface according to an embodiment of this application. The method involves retrieving a device trust baseline model from an authentication database using a hardware-bound token as the primary key, extracting the baseline centroid coordinates, and calculating the deviation distance parameter between the serialized behavioral feature vector and the baseline centroid coordinates. Figure 6 As shown, step S42 includes: S421, retrieving and activating the corresponding instance of the device trust baseline model in the authentication database using the hardware binding token as the primary key, and performing joint extraction of the centroid coordinates and covariance structure of the baseline model instance to obtain the baseline centroid coordinates and feature covariance matrix; S422, performing dimension-wise residual calculation on the serialized behavior feature vector and the baseline centroid coordinates to obtain the feature residual vector, and performing matrix inversion on the feature covariance matrix to obtain the precision matrix; S423, determining the deviation distance parameter based on the feature residual vector and the precision matrix.

[0042] In step S421, the corresponding instance of the device trust baseline model is retrieved and activated in the authentication database using the hardware binding token as the primary key. The centroid coordinates and covariance structure of the baseline model instance are jointly extracted to obtain the baseline centroid coordinates and feature covariance matrix. It should be noted that, given that the serialized behavior feature vector and hardware binding token have been separated from the session context verification request in the previous step, it is necessary to use the hardware binding token to locate the corresponding baseline model instance in the authentication database and extract the baseline data for deviation calculation. However, if only the baseline centroid coordinates are extracted, only the location information of where the device is normally located is obtained, while the structural information of how each feature dimension interacts when the device is normally functioning is discarded. This results in the subsequent deviation measurement being unable to distinguish between legitimate cooperative offsets along the feature coupling direction and abnormal reverse offsets that violate the coupling mode. Based on this, the technical solution of this application further retrieves and activates the corresponding instance of the device trust baseline model in the authentication database using the hardware binding token as the primary key, and performs joint extraction of the centroid coordinates and covariance structure of the baseline model instance to obtain the baseline centroid coordinates and feature covariance matrix. Through the above processing, dual benchmark information, namely where the device should be located and how the various features of the device should change in coordination, can be obtained simultaneously in a single model addressing, laying a data foundation for subsequent anisotropic deviation detection.

[0043] More specifically, in a concrete example of this application, using the hardware binding token as the database primary key, secure addressing is performed in the CPE trust baseline model set to extract and activate a baseline model instance specific to the currently requesting device. Subsequently, two data items are jointly extracted from the activated baseline model instance: first, the baseline centroid coordinates, representing the absolutely normal reference anchor point of the device in the multi-dimensional feature space; and second, the feature covariance matrix, whose diagonal elements encode the variance distribution magnitude of each feature dimension, while the off-diagonal elements precisely encode the statistical coupling strength and direction between the feature dimensions. The joint extraction process is expressed as follows: in, Let be the baseline centroid coordinates, representing the mathematical expectation point of the equipment's health status in multidimensional space. The characteristic covariance matrix is A symmetric positive definite matrix encodes the statistical coupling relationships between feature dimensions. For CPE trust baseline model, Bind a token to the hardware. The baseline model uses a joint extraction function, with the token as the primary key, to simultaneously extract the centroid and covariance structure. Taking a customer front-end device monitoring scenario as an example, if the off-diagonal elements corresponding to memory occupancy and packet frequency per second in the feature covariance matrix are positive and large, it indicates that the two exhibit a strongly positively correlated cooperative change pattern under normal operating conditions. That is, when the device is in a normal high-load business period, the increase in packet frequency per second will inevitably be accompanied by a synchronous increase in memory occupancy. This pattern information will be transformed into differentiated penalty weights in subsequent steps, so that cooperative offsets along the positive correlation direction are subject to lower distance penalties and will not be misjudged as anomalies, while offsets that violate this coupling pattern are subject to higher distance penalties to capture covert attack behaviors. Through this joint extraction, subsequent deviation calculations not only know where the device should be, but also have a complete baseline profile of how the device's various features should cooperate and change, laying a dual data foundation for anisotropy detection.

[0044] In step S422, a dimension-wise residual calculation is performed on the serialized behavior feature vector and the baseline centroid coordinates to obtain the feature residual vector, and a matrix inversion operation is performed on the feature covariance matrix to obtain the precision matrix. It should be noted that, given that the baseline centroid coordinates and feature covariance matrix have been jointly extracted in the previous sub-step, it is now necessary to convert the original absolute eigenvalues ​​into a relative deviation representation to eliminate the interference of individual baseline differences between different devices. Simultaneously, the descriptive covariance knowledge needs to be converted into decision-making weights that can directly participate in distance weighting; otherwise, subsequent deviation calculations can only answer the question of how far the deviation is but cannot distinguish whether the offset direction conforms to the inherent coupling pattern between features. Based on this, the technical solution of this application further performs a dimension-wise residual calculation on the serialized behavior feature vector and the baseline centroid coordinates to obtain the feature residual vector, and performs a matrix inversion operation on the feature covariance matrix to obtain the precision matrix. Through the above processing, the feature residual vector carries information about how much deviation is in each dimension, and the precision matrix carries information about the penalty for deviation in each direction; both flow into the final distance quantization stage.

[0045] More specifically, in a concrete example of this application, vector subtraction is first used to perform a dimension-wise residual calculation on the serialized behavior feature vector and the baseline centroid coordinates to obtain the feature residual vector. This transformation eliminates the interference of individual baseline differences between different customer front-end devices, allowing subsequent distance calculations to focus on the extent of deviation rather than the current value. The residual calculation process is expressed as follows: in, The feature residual vector is A column vector representing the dimension-wise deviation of real-time behavior relative to a health baseline. For serialized behavior feature vectors, The coordinates are the baseline centroid coordinates.

[0046] Simultaneously, matrix inversion is performed on the feature covariance matrix to obtain the precision matrix. Specifically, highly positively correlated dimension pairs in the covariance matrix have lower cross-penalty weights in the precision matrix because cooperative shifts along the positive correlation direction are expected and legitimate behavior; while weakly coupled or anti-coupled dimension pairs in the covariance matrix have extremely high cross-penalty weights in the precision matrix because shifts along the anti-correlation direction severely violate the device's inherent operating mode and are highly likely to be intrusion signals. The expression for the inversion operation is as follows: in, For the precision matrix, it is A symmetric positive definite matrix, encoding differentiated penalty weights for each offset direction. The characteristic covariance matrix, This is a matrix inversion function that performs a numerical inversion operation on an input symmetric positive definite matrix.

[0047] Taking a real-world customer front-end device operation scenario as an example, if one device has a baseline memory utilization rate of 45% and a current measured value of 48%, while another device has a baseline of 72% and a current measured value of 75%, the residuals for both are +3%. This allows for a fair comparison under a unified deviation coordinate system, eliminating the absolute value differences caused by different devices having different load levels. Meanwhile, in the feature covariance matrix, the off-diagonal elements corresponding to memory utilization and packet frequency per second are positive and have large values. After matrix inversion, the cross-penalty weights for this dimension pair in the precision matrix become lower. This means that when a device's memory utilization and packet frequency increase synchronously during normal high-load business periods, subsequent distance calculations will apply a smaller penalty to this coordinated offset along the positive correlation direction without misjudging it as an anomaly. Conversely, if an attacker implants a malicious process on the device, causing memory utilization to increase but packet frequency to decrease, this inversely correlated offset corresponds to a very high cross-penalty weight in the precision matrix. Even if the absolute offsets in each dimension are small, they will be amplified and captured in subsequent distance calculations.

[0048] In step S423, the deviation distance parameter is determined based on the feature residual vector and the precision matrix. It should be noted that, given that the feature residual vector and precision matrix have been obtained separately in the previous sub-step, they need to be fused into a single deviation scalar for subsequent trust score quantification. However, if isotropic Euclidean distance is used for fusion, the decision boundary in high-dimensional space appears as an isotropic hypersphere, focusing only on the single dimension of how far the deviation is, and failing to distinguish whether the offset direction conforms to the inherent coupling pattern between features. Therefore, the technical solution of this application further determines the deviation distance parameter based on the feature residual vector and the precision matrix. Through the above processing, the isotropic hypersphere decision boundary of the original Euclidean distance can be reshaped into an anisotropic hyperellipsoidal decision boundary, expanding the deviation measurement from focusing only on the single dimension of how far the deviation is to simultaneously focusing on both the distance of deviation and the direction of deviation.

[0049] More specifically, in a concrete example of this application, given that both the feature residual vector and the precision matrix are ready, they are ultimately fused into a single deviation scalar through a quadratic weighted distance operation. Specifically, the feature residual vector is transposed to obtain its row vector form. This row vector is then multiplied by the precision matrix, and the product is multiplied a second time by the original column vector form of the feature residual vector to obtain a scalar quadratic value. Finally, the square root of this scalar quadratic value is calculated to output the covariance-weighted deviation parameter. The calculation process of Mahalanobis distance is expressed as follows: in, The covariance-weighted deviation parameter is a non-negative scalar value, namely the deviation distance parameter, which serves as the input for subsequent trust score quantification. For the feature residual vector, 3D column vector, This is the transpose of the feature residual vector. 3D row vectors For the precision matrix, 3D symmetric positive definite matrix The arithmetic square root operator restores the scalar value of the quadratic form to a distance metric with the same dimensions as the original feature space.

[0050] Within the quadratic operation, the precision matrix is ​​embedded as a weighting kernel in the inner product calculation of the residual vector, causing the offsets in different directions to be amplified or reduced by different distances. Returning to the actual scenario of monitoring customer front-end devices, when the multidimensional features of the device are offset along the legitimate collaborative offset direction defined by the feature covariance matrix, i.e., the direction of the major axis of the hyperellipsoid, for example, when memory usage and packet frequency rise simultaneously during peak business periods, the Mahalanobis distance gives a small deviation value, avoiding misjudging normal business fluctuations as security threats. However, when the features are offset along the inverse correlation abnormal offset direction, i.e., the direction of the minor axis of the hyperellipsoid, for example, when malicious processes cause memory usage to rise but packet frequency to fall, even if the absolute offset of each dimension is small, the Mahalanobis distance will output an amplified deviation value due to the extremely high cross-penalty weight in the precision matrix, making it impossible for covert attacks to escape detection. Therefore, in industrial settings where cross-domain CPE identity authentication is required, this improvement directly brings two security benefits. On the one hand, for multi-dimensional feature collaborative offsets caused by normal business load fluctuations, the tolerance boundary along the major axis of the hyperellipsoid effectively reduces the false alarm rate, preventing legitimate devices from being incorrectly blocked or downgraded during high-load periods, thus ensuring business continuity. On the other hand, for covert spoofing behavior carefully constructed by attackers with small absolute offsets in each dimension but violating the inherent coupling pattern between features, the stringent boundary along the minor axis of the hyperellipsoid improves the ability to detect false negatives, enabling even disguised inverse correlation offsets to be sensitively identified.

[0051] In step S43, the deviation distance parameter is nonlinearly mapped and quantized using a percentage truncation system based on the attenuation penalty coefficient to obtain a dynamic trust score. It should be noted that since the deviation distance parameter is a continuous scalar with an unfixed range, it cannot be directly used for subsequent interval matching and strategy generation for multi-level security thresholds. It needs to be converted into a standardized score with a unified dimension and clear physical meaning. Based on this, the technical solution of this application further performs nonlinear mapping and percentage truncation quantization on the deviation distance parameter based on the attenuation penalty coefficient to obtain a dynamic trust score. Through the above processing, the continuous distance scalar can be converted into a percentage integer between 0 and 100; the larger the deviation, the lower the score, providing a normalized decision input for the subsequent multi-granularity generation of adaptive access strategies.

[0052] More specifically, in a concrete example of this application, the deviation distance parameter calculated in the previous step is substituted into a preset exponential trust decay penalty function to perform nonlinear mapping calculation. This function, combined with a scenario-specific decay penalty coefficient, applies a negative exponential transformation to the deviation distance parameter, so that when the deviation is small, the trust score remains in a high range and decreases slowly, while when the deviation exceeds a certain threshold, the trust score exhibits an exponentially accelerated decay characteristic, reflecting a zero-tolerance attitude towards abnormal deviations. Subsequently, the calculation result of the exponential decay function is multiplied by 100 for percentage scaling, and floor and upper / lower bound truncation operations are performed to ensure that the final result strictly falls within the standard percentage integer range of 0 to 100. The truncated and mapped percentage scalar is output as the dynamic trust score. The above nonlinear mapping and truncated quantization process is expressed as follows: in, The dynamic trust score is a percentage-based integer between 0 and 100. It is a natural constant. The attenuation penalty coefficient is a preset positive constant that determines the sensitivity to deviation. For the deviation distance parameter, For floor operation, This is a lower bound truncation function to prevent negative values ​​in extreme deviations. In cross-domain identity authentication scenarios for customer front-end devices, when the device is operating normally and the deviation distance parameter is close to 0, the negative exponent term approaches 1, and the dynamic trust score outputs a high score close to 100. When the device behavior slightly deviates, causing a small increase in the deviation distance parameter, the dynamic trust score only decreases moderately in the low-value region due to the relatively gentle decay rate of the exponential function, without triggering an overreaction. However, when the device is attacked or the operating environment changes abruptly, causing a sharp increase in the deviation distance parameter, the non-linear characteristic of exponential decay causes the dynamic trust score to quickly drop to a low score range, ensuring that abnormal states can be reflected in the subsequent policy generation stage in a timely manner.

[0053] Specifically, in step S5, the provider domain operating system performs interval matching and policy generation on the dynamic trust score and preset multi-level security thresholds to obtain an adaptive access policy issued to the network-side gateway execution module and an authentication response message returned to the client domain via the X interface. It should be noted that since the dynamic trust score is a quantified scalar on a percentage scale, it has not yet been converted into a specific access control action executable by the network side, and the client domain also needs to know the authentication result of this session request to complete the cross-domain communication handshake. Based on this, the technical solution of this application further provides a provider domain operating system to perform interval matching and policy generation on the dynamic trust score and preset multi-level security thresholds to obtain an adaptive access policy issued to the network-side gateway execution module and an authentication response message returned to the client domain via the X interface. Through the above processing, continuous trust scores can be converted into multi-granularity network access control actions, and cross-domain status return can be completed simultaneously, achieving end-to-end connectivity from trust quantification to policy execution to communication closed loop.

[0054] More specifically, in a specific example of this application, the dynamic trust score is first compared with preset high-risk blocking thresholds and safe access thresholds based on a piecewise step function. When the dynamic trust score is lower than the high-risk blocking threshold, the device is determined to be in an untrusted state, and a blocking-type policy control instruction is output; when the dynamic trust score is in the critical range between the high-risk blocking threshold and the safe access threshold, the device is determined to be suspicious but not yet constitute a deterministic threat, and a rate limiting and degradation-type policy control instruction is output; when the dynamic trust score is higher than or equal to the safe access threshold, the device is determined to be in a safe and trustworthy state, and a full access-type policy control instruction is output.

[0055] After the policy control instructions are generated, the network resource mapping matrix is ​​used to translate and visualize the policy control instructions into access control rules. Blocking instructions are translated into access control list rules that deny all traffic; rate limiting and degradation instructions are translated into token bucket parameters and permission constraints that limit bandwidth or allow only read-only access; and full allowance instructions are translated into access control list rules that allow all subscribed resources. The translated rule parameters are packaged and output as an adaptive access policy, which is then directed to the physical gateway execution module on the provider's network side for actual traffic control. Simultaneously, a standard protocol status code representing the control result is extracted from the adaptive access policy, and this status code is output as a response construction credential for subsequent cross-domain backhaul.

[0056] After the response credentials are ready, a response timestamp with millisecond precision is generated using the provider domain's local clock. The response credentials and the response timestamp are concatenated and combined. A digital signature authentication operation is performed on this combination based on the provider domain's private key to ensure the authenticity and tamper-proof nature of the returned message. After signing, a protocol header containing an acknowledgment identifier is added according to the X interface standard message specification. Cross-domain protocol encapsulation is performed on the signed data, and the final encapsulated message is output as a verification response message and sent back to the client domain via the X interface. Upon receiving the message, the client domain can confirm the authentication result of this session request based on the status code. This completes a closed loop of cross-domain identity authentication based on dynamic trust assessment.

[0057] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A cross-domain authentication method based on the X interface, characterized in that, include: S1, through the client domain operating system driving the hardware security module, performs irreversible hashing and identity fusion signing on the device hardware fingerprint sequence and dynamic environment context to obtain dynamic trusted identity payload; S2 receives dynamic trusted identity payloads via the X interface from the provider domain operating system, and performs signature verification and unsupervised clustering modeling on the dynamic trusted identity payloads to obtain the device trust baseline model stored in the local authentication database and the hardware binding token issued to the customer domain. S3, before initiating a network session, uses the client domain operating system to perform timestamp-nested encryption and encapsulation of the real-time behavioral feature matrix and the hardware binding token to obtain the session context verification request. S4 receives session context verification requests via the X interface from the provider domain operating system, and performs cross-domain continuous trust assessment and multi-dimensional authentication on the session context verification requests and the device trust baseline model to obtain dynamic trust scores. S5 provides the provider domain operating system to perform interval matching and policy generation on dynamic trust scores and preset multi-level security thresholds to obtain adaptive access policies that are sent to the network-side gateway execution module and verification response messages that are sent back to the customer domain via the X interface.

2. The cross-domain authentication method based on the X interface according to claim 1, characterized in that, The device hardware fingerprint sequence includes the CPU's unique serial number, the TPM chip's embedded public key, and the network card's physical MAC address; the dynamic environment context includes the current access IP address, the base station cell's global identifier, and GPS spatial coordinates; the real-time behavioral feature matrix includes the current memory usage, the number of packets sent per second, and the underlying process status codes.

3. The cross-domain authentication method based on the X interface according to claim 1, characterized in that, Step S1 includes: The hardware security module reads the device hardware fingerprint sequence and dynamic environment context in parallel, and performs a concatenation hash operation on the device hardware fingerprint sequence, dynamic environment context and cryptographic random salt value to obtain the hardware and environment hash value. Based on the cross-domain authentication data standard protocol, key attribute fields of basic identity metadata are extracted, and hardware and environment hash values ​​are embedded into key attribute fields for structured merging to obtain fused identity data. By invoking the hardware-level private key through the trusted platform module, the fused identity data is digitally signed and encrypted to obtain a dynamic trusted identity payload.

4. The cross-domain authentication method based on the X interface according to claim 1, characterized in that, Step S2 includes: Based on the pre-set device public key, the dynamic trusted identity payload is verified, decrypted, and reversed bitwise to obtain hardware and environment hash values ​​and basic identity metadata. The hardware and environment hash values ​​are projected as feature coordinates, and density clustering modeling is performed using an unsupervised clustering algorithm combined with clustering labels transformed from basic identity metadata to obtain a device trust baseline model. Based on the unique index identifier of the device trust baseline model, a joint hash operation is performed on the unique index identifier and a high-entropy random number to obtain the hardware binding token.

5. The cross-domain authentication method based on the X interface according to claim 1, characterized in that, Step S3 includes: The real-time behavior feature matrix is ​​dimensionality reduced to obtain a one-dimensional sequence, and the one-dimensional sequence is mapped to a standard interval to obtain a serialized behavior feature vector; the current system timestamp is appended to the end of the hardware binding token to obtain a time-series binding token. Based on the symmetric session key, authentication encryption operations are performed on the concatenated set of serialized behavior feature vectors and time-bound tokens to obtain the encryption context payload; Based on the X interface standard message specification, a plaintext protocol header is constructed, and the encrypted context payload is encapsulated in a cross-domain protocol to obtain the session context verification request.

6. The cross-domain authentication method based on the X interface according to claim 1, characterized in that, Step S4 includes: Based on the symmetric session key, the message header of the session context verification request is stripped and decrypted to obtain the serialized behavior feature vector and hardware binding token. Using the hardware binding token as the primary key, the device trust baseline model is retrieved from the authentication database and the baseline centroid coordinates are extracted. The deviation distance parameter between the serialized behavior feature vector and the baseline centroid coordinates is calculated. The deviation distance parameter is nonlinearly mapped and quantized using a percentage truncation system based on the attenuation penalty coefficient to obtain a dynamic trust score.

7. The cross-domain authentication method based on the X interface according to claim 1, characterized in that, Step S5 includes: Based on the piecewise step function, the dynamic trust score is compared with the preset high-risk blocking threshold and safe passage threshold to obtain the policy control instruction. By using the network resource mapping matrix, the policy control instructions are translated and visualized into access control rules to obtain the adaptive access policy issued to the network-side gateway execution module. Simultaneously, the status code is extracted from the adaptive access policy to obtain the response and construct credentials. The response is digitally signed and authenticated based on a combination of the provider domain private key and the response timestamp. A confirmation header is then appended for cross-domain encapsulation to obtain a verification response message that is sent back to the client domain via the X interface.

8. The cross-domain authentication method based on the X interface according to claim 6, characterized in that, Using the hardware-bound token as the primary key, the device trust baseline model is retrieved from the authentication database, and the baseline centroid coordinates are extracted. The deviation distance parameter between the serialized behavior feature vector and the baseline centroid coordinates is calculated, including: Using the hardware binding token as the primary key, the corresponding instance of the device trust baseline model is retrieved and activated in the authentication database. The centroid coordinates and covariance structure of the baseline model instance are jointly extracted to obtain the baseline centroid coordinates and feature covariance matrix. The feature residual vector is obtained by performing a dimension-wise residual calculation on the feature vector of the serialized behavior and the coordinates of the baseline centroid, and the precision matrix is ​​obtained by performing a matrix inversion operation on the feature covariance matrix. The deviation distance parameter is determined based on the feature residual vector and the accuracy matrix.

Images