Lightweight cross-domain identity authentication method for heterogeneous network
By adopting a collaborative authentication method between edge access points (APs) and TEEs, the computational latency and privacy protection issues of cross-domain authentication in 6G heterogeneous networks are resolved. This achieves cross-domain identity authentication with low latency, low storage pressure, and strong privacy protection, making it a lightweight cross-domain authentication solution suitable for 6G networks.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- UNIV OF ELECTRONICS SCI & TECH OF CHINA
- Filing Date
- 2026-01-30
- Publication Date
- 2026-04-24
AI Technical Summary
Existing technologies for cross-domain authentication schemes in 6G heterogeneous networks suffer from high computational latency and weak privacy protection. In particular, schemes based on bilinear pairing operations are computationally complex and energy-intensive, and pre-synchronization techniques can lead to authentication delays and privacy leaks when trajectory prediction fails.
The authentication method is implemented by the edge access point (AP), which utilizes the Trusted Execution Environment (TEE) and the host operating system (AP Host) to achieve lightweight cross-domain identity authentication by generating temporary key pairs, Merkle tree retrieval, and TEE decryption. User privacy is protected by combining DID signature and TEE hardware isolation.
It achieves low-latency authentication, reduces edge storage pressure, ensures user privacy and security, resists replay attacks and man-in-the-middle attacks, and has forward confidentiality.
Smart Images
Figure CN121923833A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of identity authentication technology, and specifically to a lightweight cross-domain identity authentication method for heterogeneous networks. Background Technology
[0002] In recent years, with the accelerated evolution of global information and communication technologies, sixth-generation mobile communication technology (6G) has gradually become the core engine for building future all-space information infrastructure and driving the high-quality development of the digital economy. In 2021, my country clearly proposed to conduct research on the vision and requirements of 6G and carry out preliminary research on key technologies. Compared with existing mobile communication systems, 6G not only pursues peak rates at the Tbps level, but also strives to control end-to-end latency to the sub-millisecond level to support ultra-reliable and low-latency application scenarios such as the future industrial internet and holographic communication. Its core evolution direction lies in building an integrated air-space-ground ubiquitous coverage network to achieve seamless access for massive heterogeneous devices in various environments, pursuing higher bandwidth, lower latency, stronger reliability, and higher dynamism.
[0003] 6G networks exhibit a highly heterogeneous architecture, composed of multiple different mobile operators, industry private networks, and management domains. In scenarios with multi-domain cross-coverage, traditional centralized trust models face severe challenges: on the one hand, there is a lack of natural mutual trust between different management domains, making cross-domain collaboration difficult; on the other hand, traditional centralized authentication servers struggle to cope with the high concurrency request pressure brought about by the massive access of 6G devices and are prone to becoming single points of failure, making it difficult to guarantee the continuity of trust during cross-domain handover.
[0004] Currently, a hot research direction in academia and industry is combining blockchain technology with the Self-Sovereign Identity (SSI) framework to address the trust gap between multiple administrative domains. One type of cross-domain identity authentication scheme is based on self-sovereign identity and blockchain. It records or anchors identity states on the chain, and during the authentication phase, the requesting party presents attribute credentials, while the verifying party completes anonymous or conditionally anonymous authentication based on on-chain data and cryptographic proofs. For example, Zeng et al. proposed a cross-domain anonymous authentication scheme based on dynamic accumulators and non-interactive zero-knowledge proofs. The underlying construction of this scheme heavily relies on bilinear pairing mappings and exponential operations on groups. For the massive number of lightweight IoT devices in 6G networks, such complex cryptographic operations will lead to significant computational latency and energy consumption burdens. Secondly, the signaling storm problem caused by member revocation is severe, resulting in poor scalability.
[0005] Another type of existing technology addresses the low-latency requirements of cross-domain handover in heterogeneous networks by employing pre-synchronization and pseudonym mechanisms to shorten the authentication link during handover. For example, PECHA uses the Chameleon hash function and the InterPlanetary File System (IPFS) for cross-domain handover authentication. The core idea of this scheme is to pre-synchronize authentication information based on trajectory prediction. However, in handling highly dynamic 6G scenarios, it heavily relies on the accuracy of user trajectory prediction, failing to effectively protect user privacy data and placing significant pressure on edge storage. Because authentication information is pre-pushed to specific target base stations, if the user's movement trajectory changes randomly, causing prediction failure, the pre-synchronized data becomes invalid, and authentication degenerates into a high-latency, conventional process. Summary of the Invention
[0006] To address the aforementioned shortcomings in existing technologies, the lightweight cross-domain identity authentication method for heterogeneous networks provided by this invention solves the problems of high latency due to bilinear pairing operations and weak privacy protection in pre-synchronization techniques during cross-domain authentication.
[0007] Firstly, a lightweight cross-domain identity authentication method for heterogeneous networks is provided, which employs an edge access point (AP) to perform the authentication method. The AP includes a Trusted Execution Environment (TEE) and a host operating system (APHost) running on the AP. The authentication method includes: S1. The AP Host receives the handshake random number generated by the user equipment (UE) after detecting a cross-domain access request or receiving broadcast information from the target domain, and sends it to the TEE. S2 and TEE generate a temporary key pair and a random number based on the handshake random number, and calculate the metric value according to its verification logic; use the handshake random number, the metric value and the public key in the temporary key pair to generate a remote proof report, and send it to the UE through the AP Host; S3, AP Host receives the encrypted text C and credential index generated after the UE verifies the remote authentication report. The authentication message is retrieved and stored in the Merkle tree. If the identity is found, the authentication process terminates; if not found, a Merkle credential is generated and sent to the TEE along with the encrypted message. S4. TEE decrypts the ciphertext C, then verifies the decrypted information and the Merkle credential. If either verification fails, the authentication process terminates. If both verifications pass, the process proceeds to step S5. S5 and TEE extract the session key from the decrypted information and establish a session state. After successful establishment, they generate a handshake completion confirmation message and send it to the user equipment through the AP Host to complete the authentication.
[0008] Furthermore, the AP Host stores a revocation set consisting of several revoked credential identifiers, and constructs a Merkle tree by sorting the credential index consisting of the hash values of the revoked credential identifiers as leaf nodes in lexicographical order. The root of the Merkle tree is sent to the TEE storage. The AP Host retrieves the credential index from its stored Merkle tree. If found, authentication is terminated; otherwise, a Merkle credential is generated and sent along with encrypted data to the TEE. Further details include: S31, AP Host in the ordered leaf sequence of the Merkle tree Perform a binary search. If a leaf is found that directly matches the search result, terminate the identity authentication process. If no leaf is found, proceed to step S32. S32, Confirm Leaf of adjacent boundary of the interval and And satisfy ; S33. Merkle proof for generating leaves on both sides respectively. and and will Send it to the TEE as a Merkle credential.
[0009] Furthermore, the ciphertext C in the authentication message consists of the public key pair credential payload P and signature information from the UE's temporary key pair used by the TEE. The credential payload P is obtained, which includes verifiable credentials. Handshake random number UE-generated session key Random numbers generated by TEE Signature information For the UE to use its DID private key to the credential payload Obtained through signature.
[0010] Furthermore, the TEE stores a root digest of the Merkle tree and uses it as a trusted anchor point; TEE decrypts the ciphertext C, and then verifies the decrypted information and Merkle credentials, including: S41 and TEE receive the Merkle credential and ciphertext C, and decrypt the ciphertext C to obtain the decrypted credential payload. and signature information ; S42. Verify signature information Verifiable credentials The parsed Is it correct? If yes, proceed to step S43; otherwise, terminate the identity authentication. S43, Verification Does it include at least If yes, proceed to step S44; otherwise, terminate identity authentication. S44. Based on the Merkle voucher Perform the revocation verification. If the verification is successful, proceed to step S5; otherwise, terminate the identity authentication process.
[0011] Furthermore, the method for revoking verification includes: S45, TEE according to Within the security domain and Refactor: in, Merkle inclusion verification; and Boundary leaves and The reconstructed root summary; S46, Judgment Is the authentication successful? If yes, proceed to step S47; otherwise, terminate the authentication process. A root summary of the Merkle tree; S47. TEE verifies whether the adjacency of the two boundary sides is satisfied. If yes, proceed to step S48; otherwise, terminate the identity authentication process. Prove Merkle's adjacency; S48, TEE determines whether the interval check is satisfied. If so, then If the data does not belong to the cancellation set, the verification passes; otherwise, the authentication process terminates.
[0012] Furthermore, the method for updating the data stored in the edge access point (AP) includes: A1. When the update time is reached or when the operator updates the general verification data set, the TEE obtains the list of trusted issuer public keys in the blockchain, verifies the policy version number, the revocation list, and the TEE's verification logic. A2. TEE verifies the signature validity and version number monotonicity of the trusted issuer list and revocation list. If both verifications pass, proceed to step A3; otherwise, if the verification fails, retain the previous version data. A3. The TEE stores the list of trusted issuer public keys, the verification policy version number, and the TEE's verification logic in its secure memory, and sends the revocation list to the AP Host. A4. The AP Host updates the Merkle tree according to the revocation list and sends the root summary of the Merkle tree to the TEE for storage.
[0013] Secondly, a lightweight cross-domain authentication method for heterogeneous networks is provided, which employs a cross-domain user equipment (UE) communicating with an access point (AP) to perform the authentication method, the authentication method comprising: B1. A handshake random number is generated upon detecting a cross-domain access request or receiving a broadcast message from the target domain, and then sent to the AP Host; B2. Receive the remote authentication report sent from the AP Host and determine whether the remote authentication report is valid, whether the metric matches the expected verification logic version and whether the remote authentication has its handshake random number. If both are yes, proceed to step B3; otherwise, terminate the authentication process. B3. Generate session key And construct the credential payload , Verifiable credentials; For handshake random numbers, Random numbers generated for the TEE; B4. Use the UE's DID private key to sign the credential payload P to obtain the signature information. And use the public key of the TEE in the remote proof report to pair Encrypt and generate ciphertext C; B5, Yes Perform hash calculation to obtain the voucher index Then index the credentials. The encrypted text C is sent to the AP Host; B6. Receive the handshake completion confirmation message from the AP Host, and use... Decrypt and verify to confirm that it has shared a consistent session key with the AP. And the handshake was completed.
[0014] Compared with existing technologies, the lightweight cross-domain identity authentication method provided by this invention has the following outstanding effects: (1) Low latency: Compared with traditional certificate chain or bilinear pairing schemes, the authentication scheme of the present invention removes complex chain verification and heavy mathematical calculations. Through theoretical analysis and system implementation, it can be seen that the authentication latency of the present invention reaches the millisecond level, which is significantly better than the existing protocol.
[0015] (2) Extremely low edge storage pressure: This solution reduces the internal storage complexity of the TEE from linear growth to constant level based on the undo mechanism of the sorted Merkle tree. For a list containing tens of millions of undo users, the TEE memory usage remains at the KB level, avoiding memory overflow on edge devices.
[0016] (3) Strong privacy protection and security: This scheme ensures that user VC data is decrypted only within the TEE through TEE hardware isolation and atomic binding of DID signature, preventing either network man-in-the-middle attacks or malicious base station operating systems from obtaining user privacy. Furthermore, formal proof based on the Dolev-Yao model demonstrates that the scheme is resistant to replay attacks, man-in-the-middle attacks, and has complete forward confidentiality. Attached Figure Description
[0017] Figure 1 This is a block diagram illustrating the principle of heterogeneous networks.
[0018] Figure 2 A flowchart of an embodiment of a lightweight cross-domain authentication method for heterogeneous networks for edge access points.
[0019] Figure 3 A schematic diagram of the handshake protocol process for binding TEE-DID.
[0020] Figure 4 This is a schematic diagram of the credential revocation verification principle based on a sorted Merkle tree.
[0021] Figure 5 A flowchart of another embodiment of a lightweight cross-domain authentication method for heterogeneous networks for user equipment.
[0022] Figure 6 This is a comparison chart of authentication latency.
[0023] Figure 7 This is a comparison chart of storage pressure.
[0024] Figure 8 This is a formal proof diagram based on the Dolev-Yao model. Detailed Implementation
[0025] The specific embodiments of the present invention are described below to enable those skilled in the art to understand the present invention. However, it should be understood that the present invention is not limited to the scope of the specific embodiments. For those skilled in the art, various changes are obvious as long as they are within the spirit and scope of the present invention as defined and determined by the appended claims. All inventions utilizing the concept of the present invention are protected.
[0026] The lightweight cross-domain authentication method provided in this solution is... Figure 1Implemented in the heterogeneous network shown, the operator agent interacts with the blockchain to maintain and update a common verification data set. This set includes a list of trusted issuer public keys, verification policy version numbers, revocation digests, and the verification logic of the TEE. When the data changes, the operator agent generates corresponding version identifiers and consistency verification information, and stores the list of trusted issuer public keys, verification policy version numbers, revocation digests, and the TEE's verification logic on the blockchain. The edge access point (AP) includes a trusted execution environment (TEE) and a host operating system (AP Host) running on the AP.
[0027] When the edge node AP reaches its update time or receives information from the operator to update the general verification dataset, the following methods are executed to update the data stored in the AP: A1. When the update time is reached or when the operator updates the general verification data set, the TEE obtains the list of trusted issuer public keys in the blockchain, verifies the policy version number, the revocation list, and the TEE's verification logic. A2. TEE verifies the signature validity and version number monotonicity of the trusted issuer list and revocation list. If both verifications pass, proceed to step A3; otherwise, if the verification fails, retain the previous version data. A3. The TEE stores the list of trusted issuer public keys, the verification policy version number, and the TEE's verification logic in its secure memory, and sends the revocation list to the AP Host. A4. The AP Host updates the Merkle tree according to the revocation list and sends the root summary of the Merkle tree to the TEE for storage.
[0028] refer to Figure 2 , Figure 2 A flowchart illustrating an embodiment of a lightweight cross-domain identity authentication method for heterogeneous networks is shown, as follows: Figure 2 As shown, the method S includes steps S1 to S5, which uses an edge access point (AP) to perform the authentication method. The edge access point (AP) includes a trusted execution environment (TEE) and a host operating system (AP Host) running on the AP.
[0029] In step S1, the AP Host receives a handshake random number generated by the user equipment (UE) after detecting a cross-domain access request or receiving broadcast information from the target domain. And send it to the TEE; the AP Host does not parse sensitive content related to identity / credentials, but only acts as a forwarder. Passed to TEE via a controlled interface.
[0030] In step S2, the TEE uses the handshake random number... Generate temporary key pairs With random numbers, These are the private key and the public key; and a metric is calculated based on their verification logic. , To verify the logic, a hash algorithm is used; a remote proof report is generated using the handshake random number, the metric, and the public key from the temporary key pair. And send it to the UE via the AP Host.
[0031] In step S3, the AP Host receives the encrypted text C and credential index generated after the UE verifies the remote authentication report. The authentication message is retrieved and stored in the Merkle tree. If the credential is found, authentication terminates; otherwise, a Merkle credential is generated and sent along with encrypted data to the TEE. The AP Host only handles indexing and credential construction during this process and does not access the verifiable credential. Plain text content.
[0032] In implementation, this scheme preferably uses the ciphertext C in the authentication message as the public key pair credential payload P and signature information from the UE's temporary key pair using the TEE. The credential payload P is obtained, which includes verifiable credentials. Handshake random number UE-generated session key Random numbers generated by TEE Signature information For the UE to use its DID private key to the credential payload Obtained through signature.
[0033] The AP Host stores a revocation set consisting of several revoked credential identifiers. , The hash values obtained by hashing the 1st, 2nd, and nth revoked voucher identifiers in the revocation set are used as leaf nodes to construct a Merkle tree, which is then constructed by sorting the voucher indexes formed by the hash values of the revoked voucher identifiers in lexicographical order. The root digest of the Merkle tree is then used. , To calculate the Merkle tree root corresponding to the undo set using the Merkle Tree algorithm, the Merkle tree root is sent to the TEE storage.
[0034] like Figure 4 As shown, the AP Host retrieves the credential index from its stored Merkle tree. If found, authentication terminates; otherwise, a Merkle credential is generated and sent to the TEE along with encrypted data. Further details include: S31, AP Host in the ordered leaf sequence of the Merkle tree Perform a binary search. If a leaf is found that directly matches the search result, terminate the identity authentication process. If no leaf is found, proceed to step S32. S32, Confirm Leaf of adjacent boundary of the interval and And satisfy ; S33. Merkle proof for generating leaves on both sides respectively. and and will Send it to the TEE as a Merkle credential.
[0035] In step S4, the TEE decrypts the ciphertext C, then verifies the decrypted information and the Merkle credential, and terminates the authentication process if either fails to pass the verification; if both pass the verification, the process proceeds to step S5. In one embodiment of the present invention, the TEE stores a root digest of a Merkle tree and uses it as a trusted anchor point; TEE decrypts the ciphertext C, and then verifies the decrypted information and Merkle credentials, including: S41 and TEE receive the Merkle credential and ciphertext C, and decrypt the ciphertext C to obtain the decrypted credential payload. and signature information ; S42. Verify signature information Verifiable credentials The parsed Is it correct? If yes, proceed to step S43; otherwise, terminate the identity authentication. S43, Verification Does it include at least If yes, proceed to step S44; otherwise, terminate identity authentication. S44. Based on the Merkle voucher Perform the revocation verification. If the verification is successful, proceed to step S5; otherwise, terminate the identity authentication process.
[0036] In step S5, the TEE obtains the information from the decryption (the information obtained from the decryption is...) Extract the session key and establish the session state. After successful establishment, generate a handshake completion confirmation message. It is then sent to the user device via APHost to complete identity authentication.
[0037] like Figure 4 As shown, the method for revoking verification includes: S45, TEE according to Within the security domain and Refactor: in, Merkle inclusion verification; and Boundary leaves and The reconstructed root summary; S46, Judgment Is the authentication successful? If yes, proceed to step S47; otherwise, terminate the authentication process. A root summary of the Merkle tree; S47. TEE verifies whether the adjacency of the two boundary sides is satisfied. If yes, proceed to step S48; otherwise, terminate the identity authentication process. Prove Merkle's adjacency; S48, TEE determines whether the interval check is satisfied. If so, then If the data does not belong to the cancellation set, the verification passes; otherwise, the authentication process terminates.
[0038] refer to Figure 5 This solution also provides a flowchart of a lightweight cross-domain authentication method for heterogeneous networks, which employs a cross-domain user equipment (UE) communicating with the access point (AP) to perform the authentication method, which includes: B1. A handshake random number is generated upon detecting a cross-domain access request or receiving a broadcast message from the target domain, and then sent to the AP Host; B2. Receive the remote authentication report sent from the AP Host and determine whether the remote authentication report is valid, whether the metric matches the expected verification logic version and whether the remote authentication has its handshake random number. If both are yes, proceed to step B3; otherwise, terminate the authentication process. B3. Generate session key And construct the credential payload , Verifiable credentials; For handshake random numbers, Random numbers generated for the TEE; B4. Use the UE's DID private key to sign the credential payload P to obtain the signature information. And use the public key of the TEE in the remote proof report to pair Encrypt and generate ciphertext C; B5, Yes Perform hash calculation to obtain the voucher index Then index the credentials. The encrypted text C is sent to the AP Host; where decryption private key It exists only in the TEE's secure memory and cannot be recovered by the AP Host even with high privileges. and Plaintext, thereby achieving privacy protection of credentials at the point of transmission.
[0039] B6. Receive the handshake completion confirmation message from the AP Host, and use... Decrypt and verify to confirm that it has shared a consistent session key with the AP. Once the handshake is complete, subsequent data communication will be protected using the session key.
[0040] In this scheme, the authentication and coordination between the AP and the UE, which are constituted by steps S1~S5 and B1~B6, can be referred to Figure 3 The diagram shown illustrates the TEE-DID binding handshake protocol process.
[0041] The effectiveness of the lightweight cross-domain authentication method provided in this solution is illustrated below through comparative experiments: To objectively evaluate the differences in computational overhead among different cross-domain authentication schemes, this scheme uses cryptographic operation-level latency analysis to compare the authentication processes of the prior art 1 (Zeng et al. proposed a cross-domain anonymity authentication scheme based on dynamic accumulators and non-interactive zero-knowledge proofs) and prior art 2 (PECHA cross-domain switching authentication based on chameleon hash function and InterPlanetary File System (IPFS)) mentioned in this scheme and the background technology.
[0042] Specifically, the core cryptographic operations required for the authentication phase of each comparison scheme were implemented using C++, including hash operations, symmetric encryption, asymmetric encryption, digital signatures and verification, and bilinear pairing operations, with their execution time timed independently. All cryptographic operations were performed in the same hardware and software environment. To avoid the impact of implementation optimization differences on the results, cryptographic operations of the same type in each scheme were implemented uniformly and run at the same compilation optimization level.
[0043] In the experiment, all algorithms called a unified cryptographic library interface, and a high-precision timing function was used to measure the time taken for each operation. To reduce errors caused by system jitter, each type of operation was repeated multiple times, and the average value was taken as the final result. Based on this, this comparative experiment linearly accumulated the average time taken for each operation according to the number of cryptographic operations required by different authentication schemes in a complete authentication process, thus obtaining the theoretical computational latency of each scheme in the authentication phase. In addition, to eliminate the impact of network jitter and device differences, the experiment ignored network transmission latency, blockchain interaction latency, and system scheduling overhead, aiming to highlight the performance differences of the authentication mechanisms of different schemes. Therefore, the experimental results can be regarded as the theoretical lower bound under ideal communication conditions, and have reference significance for practical deployment environments.
[0044] To verify the security and privacy protection features of the proposed cross-domain authentication protocol, a formal analysis was performed based on the Dolev–Yao attack model. In this model, the attacker is assumed to have complete network control capabilities, meaning they can listen to, intercept, tamper with, replay, and forge communication messages, but cannot compromise the security of the underlying cryptographic primitives. During the formal verification process, the Scyther protocol analysis tool was used to model the protocol, and the authentication processes for both the UE and TEE roles were verified separately.
[0045] During the verification process, the access point host operating system (Host) is treated as an untrusted entity. Attackers can fully control the Host-side logic but cannot access the secure storage and key materials within the TEE, thus conforming to the assumptions of a real-world TEE threat model. Verification objectives include the confidentiality of session keys and credentials (Secret), the liveness of the communicating parties' participation (Alive), the consistency of authentication (Niagree, Weakagree), and the synchronization of protocol execution (Nisynch). The Scyther tool performs an exhaustive search analysis of these security attributes under given attack models and verification boundary conditions.
[0046] like Figure 6 As shown in the diagram, this invention compares the authentication latency of prior art 1, prior art 2, and the present solution. The diagram demonstrates that the present solution completes authentication in just 0.79ms. Compared to traditional solutions based on certificate chains or bilinear pairings, the authentication scheme of this invention eliminates complex chain verification and cumbersome mathematical calculations. Theoretical analysis and system implementation show that the authentication latency of this invention reaches the millisecond level, significantly outperforming existing protocols.
[0047] like Figure 7As shown in the figure, it illustrates the memory usage comparison between using a sorted Merkle tree and not using a sorted Merkle tree. The figure shows that the undo mechanism based on the sorted Merkle tree reduces the storage complexity inside the TEE from linear growth to constant level. For a list containing tens of millions of undo users, the TEE memory usage is only maintained at the KB level, avoiding memory overflow on edge devices.
[0048] Figure 8 A formal proof diagram based on the Dolev-Yao model is presented. This diagram shows that, through the atomic binding of TEE hardware isolation and DID signature, it is ensured that the user's VC data is decrypted only within the TEE, preventing either network man-in-the-middle attacks or malicious base station operating systems from accessing user privacy. Furthermore, the formal proof based on the Dolev-Yao model demonstrates that the scheme possesses resistance to replay attacks, resistance to man-in-the-middle attacks, and complete forward confidentiality.
Claims
1. A lightweight cross-domain identity authentication method for heterogeneous networks, characterized in that, An authentication method is implemented using an edge access point (AP), which includes a trusted execution environment (TEE) and a host operating system (AP Host) running on the AP. The authentication method includes: S1. The AP Host receives the handshake random number generated by the user equipment (UE) after detecting a cross-domain access request or receiving broadcast information from the target domain, and sends it to the TEE. S2 and TEE generate a temporary key pair and a random number based on the handshake random number, and calculate the metric value according to its verification logic; use the handshake random number, the metric value and the public key in the temporary key pair to generate a remote proof report, and send it to the UE through the AP Host; S3, AP Host receives the encrypted text C and credential index generated after the UE verifies the remote authentication report. The authentication message is retrieved and stored in the Merkle tree. If the identity is found, the authentication process terminates; if not found, a Merkle credential is generated and sent to the TEE along with the encrypted message. S4. TEE decrypts the ciphertext C, then verifies the decrypted information and the Merkle credential. If either verification fails, the authentication process terminates. If both verifications pass, the process proceeds to step S5. S5 and TEE extract the session key from the decrypted information and establish a session state. After successful establishment, they generate a handshake completion confirmation message and send it to the user equipment through the AP Host to complete the authentication.
2. The lightweight cross-domain identity authentication method according to claim 1, characterized in that, The AP Host storage contains a revocation set consisting of several revoked credential identifiers, and uses the credential index composed of the hash values of the revoked credential identifiers as leaf nodes to construct a Merkle tree in lexicographical order. The root of the Merkle tree is sent to the TEE storage. The AP Host retrieves the credential index from its stored Merkle tree. If found, authentication is terminated; otherwise, a Merkle credential is generated and sent along with encrypted data to the TEE. Further details include: S31, AP Host in the ordered leaf sequence of the Merkle tree Perform a binary search. If a leaf is found that directly matches the search result, terminate the identity authentication process. If no leaf is found, proceed to step S32. S32, Confirm Leaf of adjacent boundary of the interval and And satisfy ; S33. Merkle proof for generating leaves on both sides respectively. and and will Send it to the TEE as a Merkle credential.
3. The lightweight cross-domain identity authentication method according to claim 2, characterized in that, The ciphertext C in the authentication message is the public key pair credential payload P and signature information from the temporary key pair used by the UE in the TEE. The credential payload P is obtained, which includes verifiable credentials. Handshake random number UE-generated session key Random numbers generated by TEE Signature information For the UE to use its DID private key to the credential payload Obtained through signature.
4. The lightweight cross-domain identity authentication method according to claim 3, characterized in that, The TEE stores the root digest of the Merkle tree and uses it as a trusted anchor point; TEE decrypts the ciphertext C, and then verifies the decrypted information and Merkle credentials, including: S41 and TEE receive the Merkle credential and ciphertext C, and decrypt the ciphertext C to obtain the decrypted credential payload. and signature information ; S42. Verify signature information Verifiable credentials The parsed Is it correct? If yes, proceed to step S43; otherwise, terminate the identity authentication. S43, Verification Does it include at least If yes, proceed to step S44; otherwise, terminate identity authentication. S44. Based on the Merkle voucher Perform the revocation verification. If the verification is successful, proceed to step S5; otherwise, terminate the identity authentication process.
5. The lightweight cross-domain identity authentication method according to claim 4, characterized in that, The method for revoking verification includes: S45, TEE according to Within the security domain and Refactor: in, Merkle inclusion verification; and Boundary leaves and The reconstructed root summary; S46, Judgment Is the authentication successful? If yes, proceed to step S47; otherwise, terminate the authentication process. A root summary of the Merkle tree; S47. TEE verifies whether the adjacency of the two boundary sides is satisfied. If yes, proceed to step S48; otherwise, terminate the identity authentication process. Prove Merkle's adjacency; S48, TEE determines whether the interval check is satisfied. If so, then If the data does not belong to the cancellation set, the verification passes; otherwise, the authentication process terminates.
6. The lightweight cross-domain identity authentication method according to any one of claims 1-5, characterized in that, The method for updating the data stored in the edge access point (AP) includes: A1. When the update time is reached or when the operator updates the general verification data set, the TEE obtains the list of trusted issuer public keys in the blockchain, verifies the policy version number, the revocation list, and the TEE's verification logic. A2. TEE verifies the signature validity and version number monotonicity of the trusted issuer list and revocation list. If both verifications pass, proceed to step A3; otherwise, if the verification fails, retain the previous version data. A3. The TEE stores the list of trusted issuer public keys, the verification policy version number, and the TEE's verification logic in its secure memory, and sends the revocation list to the AP Host. A4. The AP Host updates the Merkle tree according to the revocation list and sends the root summary of the Merkle tree to the TEE for storage.
7. A lightweight cross-domain identity authentication method for heterogeneous networks, characterized in that, The authentication method is performed by a cross-domain user equipment (UE) communicating with an access point (AP), the authentication method including: B1. A handshake random number is generated upon detecting a cross-domain access request or receiving a broadcast message from the target domain, and then sent to the APHost. B2. Receive the remote authentication report sent from the AP Host and determine whether the remote authentication report is valid, whether the metric matches the expected verification logic version and whether the remote authentication has its handshake random number. If both are yes, proceed to step B3; otherwise, terminate the authentication process. B3. Generate session key And construct the credential payload , Verifiable credentials; For handshake random numbers, Random numbers generated for the TEE; B4. Use the UE's DID private key to sign the credential payload P to obtain the signature information. And use the public key of the TEE in the remote proof report to pair Encrypt and generate ciphertext C; B5, Yes Perform hash calculation to obtain the voucher index Then index the credentials. The encrypted text C is sent to APHost; B6. Receive the handshake completion confirmation message from the AP Host, and use... Decrypt and verify to confirm that it has shared a consistent session key with the AP. And the handshake was completed.