A blockchain cross-domain identity authentication method, system, device and medium in a 6G heterogeneous network scenario

Abstract

A blockchain cross-domain identity authentication method, system, device and medium in a 6G heterogeneous network scenario, the method comprising: constructing a 6G heterogeneous network cross-domain identity authentication model; designing an improved K-Medoids clustering algorithm based on node evaluation and node local density; designing a consensus master node and participant node selection mechanism of the consensus algorithm TBH-PBFT; designing the first stage and second stage consensus processes of the consensus algorithm TBH-PBFT respectively; and designing a blockchain-based cross-domain identity authentication method; the system, device and medium are used to implement the method; the application realizes the synchronous issuance of user cross-domain credentials in the process of reaching consensus between the initiating domain and the target domain, and ensures efficient cross-domain identity authentication while meeting the security and communication overhead requirements of the 6G heterogeneous network.

Description

Technical Field

[0001] This invention belongs to the field of wireless communication technology, and specifically relates to a blockchain cross-domain identity authentication method, system, device and medium in a 6G heterogeneous network scenario. Background Technology

[0002] In recent years, following the establishment of the IMT-2030 (6G) Promotion Group, an increasing number of experts and scholars have begun to explore and promote the development of China's sixth-generation mobile communication technology. 6G networks, through the deep integration of cellular base stations, massive Internet of Things (IoT) terminals, and high-density wireless local area network (WLAN) access points, construct an "ultra-dense heterogeneous" three-dimensional coverage system. In 6G heterogeneous network scenarios, user equipment needs frequent cross-network interaction and resource exchange, facing the following core challenges during real-time authentication:

[0003] 1) Heterogeneous protocol conflicts lead to a break in the trust chain: Cellular networks rely on the fifth generation authentication and key (5G-AKA) protocol to achieve two-way authentication, which requires complex key negotiation through the Home Subscriber Server (HSS) and is highly sensitive to latency; WLAN uses the Extensible Authentication Protocol (EAP) which is incompatible with the cellular network authentication process, and certificate verification needs to be repeated when switching between networks; IoT devices are limited by resources and only support the Lightweight Restricted Application Protocol (CoAP), which is incompatible with the strong identity binding mechanism of cellular networks based on Subscriber Identity Card (SIM), forming "protocol islands".

[0004] 2) Differences in security policies lead to the "weakest link" effect: Cellular networks require users and devices to follow the privacy protection policies defined by 3GPP; the open access characteristics of WLAN force the use of pre-shared keys (PSK) to simplify authentication, making it vulnerable to man-in-the-middle attacks; IoT devices often use static keys due to power consumption limitations, which conflicts with the dynamic key update policy of cellular networks, and can easily become a security weakness when interacting across networks.

[0005] 3) Resource heterogeneity amplifies security overhead contradictions: The imbalance of computing power in heterogeneous networks forces user devices to downgrade their security level when interacting across networks; WLAN has storage space limitations and cannot cache massive device certificates, resulting in the need to frequently initiate certificate queries to the cellular core network.

[0006] From the stringent security requirements of cellular networks to the open access characteristics of WLANs, and then to the terminal resource constraints of IoT, these three differentiated features together constitute the "impossible triangle" of cross-network authentication. The secure immutability and distributed trust transfer mechanism of blockchain provide a key path to breaking this triangle. Addressing the issue of protocol silos, blockchain provides a suitable platform for a unified trust anchor, breaking down protocol silos through the design of cross-domain consensus protocols and smart contracts. To address the conflict between security overhead and limited storage performance, blockchain architecture is introduced to unify secure identity authentication methods, simplifying the authentication process and reducing authentication overhead.

[0007] Existing research mainly focuses on applying blockchain technology to device identity authentication in IoT scenarios. One relevant study (K. Deng, Y. Gao, J. Yuan, Z. Hou and X. Li, "A Lightweight and RobustCross-Domain Authentication Scheme Based on Master-Slave Blockchain," 2022 IEEE 8th International Conference on Computer and Communications (ICCC), Chengdu, China, 2022, pp. 1339-1343.) proposed an architecture based on a lightweight consortium blockchain to achieve intelligent autonomous access control for IoT devices. Here, "cross-domain" refers to geographically dispersed regions. Although this research proposes a cross-domain solution, it suffers from the drawback of being unable to handle the integration of heterogeneous networks with different structures because each region still belongs to the same network structure. In heterogeneous network scenarios, existing research (H. Luo, Q. Zhang, H. Yu, G. Sun and S. Xu, "Symbiotic PBFT Consensus: Cognitive Backscatter Communications-enabled Wireless PBFT Consensus," GLOBECOM 2023 - 2023 IEEE Global Communications Conference, Kuala Lumpur, Malaysia, 2023, pp. 910-915.) analyzes the cross-domain identity interoperability problem in the scenario of 5G and IoT convergence and proposes corresponding extended protocols. Regarding consensus algorithms, existing research (F. Tang, T. Xu, J. Peng and N. Gan, "TP-PBFT: A Scalable PBFTBased on Threshold Proxy Signature for IoT-Blockchain Applications," IEEE Internet of Things Journal, vol. 11, no. 9, pp. 15434-15449, 2024.) has constructed a two-layer PBFT algorithm for IoT blockchain applications. However, since the consensus algorithm is designed only for IoT and the consensus algorithm process is not optimized, this research suffers from the drawbacks of a simple network structure and high communication overhead.

[0008] In summary, the existing technical problems are as follows:

[0009] (1) Existing identity authentication models are designed for a single network structure and do not consider heterogeneous network scenarios. However, in the future 6G network, there will be the convergence of multiple heterogeneous networks, with a massive number of users and devices accessing the network in heterogeneous modes, forming different trust domains. Existing identity authentication models designed for a single network structure cannot be effectively applied to heterogeneous networks.

[0010] (2) Existing node clustering algorithms K-Medoids and K-Means are susceptible to extreme points. When performing clustering, they only consider a single distance factor and have a high probability of selecting nodes with low evaluation when choosing cluster centers. They cannot be directly applied to complex 6G heterogeneous network scenarios.

[0011] (3) Existing consensus algorithms are designed based on the traditional PBFT method, without taking into account the actual application scenarios and without meeting the requirements of 6G networks in terms of security and communication overhead.

[0012] (4) Existing cross-domain identity authentication schemes adopt a three-party authentication scheme of “initiator-intermediary-target”, which is lengthy. Summary of the Invention

[0013] To overcome the shortcomings of the existing technologies, the present invention aims to provide a blockchain cross-domain identity authentication method, system, device, and medium for 6G heterogeneous network scenarios. By introducing a cross-domain and trust management committee, a cross-domain identity authentication model is designed, along with an improved K-Medoids clustering algorithm based on node evaluation and local node density, and a two-stage consensus algorithm combining BLS threshold signatures. This enables the simultaneous issuance of user cross-domain credentials during the consensus process between the initiating and target domains. Furthermore, the present invention designs a simplified cross-domain credential verification scheme to ensure efficient cross-domain identity authentication while meeting the security and communication overhead requirements of 6G heterogeneous networks.

[0014] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0015] A blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario includes the following steps:

[0016] Step 1: Construct a cross-domain identity authentication model for 6G heterogeneous networks, and define the roles and responsibilities of each entity in the 6G heterogeneous network scenario;

[0017] Step 2: Based on the 6G heterogeneous network cross-domain identity authentication model constructed in Step 1, design an improved K-Medoids clustering algorithm based on node evaluation and local node density to cluster nodes within the trust domain of the heterogeneous network.

[0018] Step 3: Based on the improved K-Medoids clustering algorithm designed in Step 2, which is based on node evaluation and local node density, a cross-domain credential issuance scheme architecture is proposed, and the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT are designed.

[0019] Step 4: Based on the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT designed in Step 3, design the first-stage consensus process of the consensus algorithm TBH-PBFT.

[0020] Step 5: Based on the first-stage consensus process of the TBH-PBFT consensus algorithm designed in Step 4, design the second-stage consensus process of the TBH-PBFT consensus algorithm, including normal mode and special mode;

[0021] Step Six: Based on the first-stage consensus process of the TBH-PBFT consensus algorithm designed in Step Four and the second-stage consensus process of the TBH-PBFT consensus algorithm designed in Step Five, design a blockchain-based cross-domain identity authentication method.

[0022] Furthermore, the process of step one is as follows:

[0023] Constructing a cross-domain identity authentication model for 6G heterogeneous networks, the trust domain in the model and trust domain This refers to any two heterogeneous networks, each maintaining its own blockchain system. Each trust domain contains three roles: Issuer, Verifier, and User (UE). The Issuer is the core role in the heterogeneous network, responsible for the registration of new users or devices within its domain and the issuance of credentials. The Verifier is the role in the heterogeneous network with the authority to query the user's (UE) identity information from the blockchain system. The User (UE) is a direct participant in the 6G heterogeneous network cross-domain identity authentication model, performing trust assessment, applying for identity credentials, applying for cross-domain credentials, applying for privacy protection, identity authentication, certificate authentication, and credential revocation.

[0024] The 6G heterogeneous network cross-domain identity authentication model includes a cross-domain and trust management committee. The members of the cross-domain and trust management committee come from core roles in the heterogeneous network, including base station equipment in cellular networks, core network equipment in IoT, and router equipment in wireless LANs. The members of the cross-domain and trust management committee maintain the trust management blockchain, which is responsible for storing the historical records of node interactions and consensus in the heterogeneous network and maintaining the IPFS network as a storage extension of the trust management blockchain.

[0025] Furthermore, the process of step two is as follows:

[0026] Step 2.1, Design a node evaluation scheme

[0027] The node evaluation index is defined as the comprehensive average trust value. Overall performance ,stability and response speed The definitions and update methods of the four indicators are as follows:

[0028] Overall average trust score Overall average trust score This is a very large indicator, requiring comprehensive trust. It is based on point-to-point evaluation between nodes. After clustering nodes in the trust domain, the nodes are divided into different clusters, and all other nodes in the cluster are evaluated against a given node. The average of the comprehensive trust values ​​is used to obtain the node. Overall average trust score ;

[0029] Overall performance Overall performance This is a very large metric, determined by the processor performance, memory performance, storage performance, and network performance of the actual device running the node;

[0030] stability :stability This is a very large metric, determined by the number of times a node fully participates in consensus; each time a node fully participates in consensus, its stability increases. Increase; the number of times a node fully participates in consensus within each update interval is recorded as follows. The number of times a node is absent from consensus within each update interval is recorded as follows: The node stability update method is as follows ,in It is a penalty factor for different heterogeneous networks;

[0031] Response speed Response speed This is a very small metric. Response speed is defined as the time required from receiving a consensus proposal to a node providing a valid response to the proposal, using the timestamps of each time point. Subtracting them gives the result;

[0032] Based on the characteristics of 6G heterogeneous networks and the overall average trust value Overall performance ,stability and response speed Construct a judgment matrix and calculate the index weights using the geometric mean method, as shown in the following formula:

[0033]

[0034] in, and It determines the values ​​of corresponding rows and columns in a matrix. It calculates the product of each row of the judgment matrix. The power is used to obtain the overall average trust value. Overall performance ,stability and response speed weight After obtaining the weights, a final consistency check is performed; first, the largest eigenvalue is calculated. :

[0035]

[0036] in, This represents the number of dimensions, which is the same as the number of rows and columns in the judgment matrix. Represents the judgment matrix and the standardized weights After multiplying, sum the results row by row; to obtain the final value. The value is obtained by solving the consistency index formula. Find the consistency index The value; obtained through the number of dimensions. Value, calculate the consistency ratio To obtain the consistency ratio If the consistency ratio is less than 0.10, the matrix is ​​considered to have satisfactory consistency; therefore, the matrix is ​​judged to have satisfactory consistency, and the consistency test result is "passed".

[0037] Based on the calculated comprehensive average trust value Overall performance ,stability and response speed The weights, and the matrix formed by the original evaluation data of each node, are as follows:

[0038]

[0039] The matrix composed of the original evaluation data has one row for each node. Each data point in the matrix undergoes a positive transformation process, converting all non-maximum indicators into maximum indicators. The transformation method is as follows: Standardize the normalized matrix using the following transformation method: ;

[0040] Define the maximum value of the indicator and minimum value , represented as:

[0041]

[0042]

[0043] Definition of the first Distance between each evaluation node and the maximum value The distance from the minimum value is , is represented as:

[0044]

[0045]

[0046] Then, based on the distance between the evaluation node and the maximum and minimum values, calculate the evaluation for each evaluation node. , represented as:

[0047] ;

[0048] Step 2.2, Design the local density of nodes

[0049] After completing one round of node evaluation updates using the node evaluation scheme designed in step 2.1, at a specific moment, the number of nodes within a network coverage area is: The clustering objective is to divide into Group of nodes, any one of the nodes The evaluation is Two-dimensional coordinates nodes to two-dimensional coordinates nodes distance Calculated using the Euclidean distance formula, defined as follows:

[0050]

[0051] Introducing the local density function of nodes The density of data points surrounding a node is calculated as follows:

[0052]

[0053] in, It is a node To the node distance, It is a parameter that controls the range of local density calculation. As the value of the exponent increases, it gets closer to 1, making the calculation of local density smoother. As density increases, the distinguishability of local density decreases, and the density difference between different regions diminishes.

[0054] Step 2.3, based on the node evaluation scheme designed in Step 2.1 and the node local density designed in Step 2.2, the specific process of designing the improved K-Medoids clustering algorithm is as follows:

[0055] Step 2.3.1, determine the first cluster center.

[0056] Given the current evaluation set of nodes in the heterogeneous network domain. ,in Represents a node The evaluation, for the evaluation set Sort the nodes in descending order to obtain the sorted set of nodes. ,satisfy:

[0057]

[0058] Select the node with the highest evaluation within the domain. As the first candidate cluster center The local density function is used to check if the local density is greater than the threshold set by the current network. If it satisfies the threshold If the condition is met, then that node is determined as the first cluster center. Otherwise, continue to select the node ranked second in the domain evaluation and repeat the following formula to make judgments until the first cluster center is selected.

[0059]

[0060] Step 2.3.2, determine the next cluster center.

[0061] Selecting the next cluster center When, the next cluster center point is required. The distance from the already selected center point is relatively far, and the next cluster center point is also relatively far. The node evaluation should be high, and a node clustering comprehensive evaluation function should be defined. as follows:

[0062]

[0063] in, This indicates the number of center points that have been selected. It is the set of all points within the domain. It is the set of selected center points, in the calculation It is not necessary to recalculate the center point. These are the weights that control node evaluation and distance in node clustering algorithms. The closer a value is to 1, the more likely it is to select nodes with high evaluations as cluster centers when clustering nodes in the current heterogeneous network; conversely, if... The closer the value is to 0, the more likely it is to choose a point that is farther away as the next cluster center; the next cluster center The selection algorithm is as follows:

[0064]

[0065] Select the nodes with the highest overall clustering evaluation from the other nodes that are not central points within the domain. As a candidate node for the next cluster center, check whether it satisfies... If the local density threshold condition is met, then the next cluster center point is determined. If this condition is not met, it means that the candidate cluster center is far away from the surrounding nodes in the current heterogeneous network scenario, and the next candidate cluster center is selected again through the cluster center selection algorithm.

[0066] Step 2.3.3: Assign the remaining nodes to clusters.

[0067] Once a cluster center point is confirmed, the nodes in the heterogeneous network are assigned to the clusters of the confirmed center point according to the principle of proximity.

[0068]

[0069] in, It is a determined center point. The clusters represent all the clusters that are derived from the previous one. Recent remaining nodes A set;

[0070] Step 2.3.4: Determine the remaining cluster centers and complete the clustering.

[0071] Repeat steps 2.3.2 and 2.3.3 until the problem is found. Find cluster centers and complete the clustering of all nodes.

[0072] Furthermore, the process of step three is as follows:

[0073] Multi-trust domain nodes collaboratively decide whether to issue cross-domain credentials to users (UEs) or devices in heterogeneous networks using the TBH-PBFT consensus algorithm. Before selecting participating consensus nodes and a primary node, the trust domains... Node clustering has been completed based on node scores. Within each cluster, a set of strong nodes has been defined in descending order of node scores. Candidate Node Set Weak node set The total number of strong nodes is The strong nodes are determined by the cluster centers in the final clustering process; the candidate nodes are the two nodes with the highest node scores (excluding the strong nodes) within each cluster, for a total of [number missing]. Alternate nodes are responsible for participating in the first phase of the TBH-PBFT consensus algorithm and serving as candidates for strong nodes in the second phase of the TBH-PBFT consensus algorithm; weak nodes are the remaining nodes within the cluster, numbering [number missing]. The consensus master node and participating nodes of the TBH-PBFT consensus algorithm are responsible for participating in the first phase of the consensus process; the TBH-PBFT consensus master node and participating nodes are from the initiating domain. Target domain and remaining trust domain The nodes selected for the first phase of the TBH-PBFT consensus algorithm come from the cluster where the node that initiated the cross-domain credential request resides. Half of the nodes participating in the first phase of the TBH-PBFT consensus algorithm come from the initiating domain. The other half comes from the target domain. The selection is done through random sampling; both phases of consensus have trust domains. The nodes record the entire consensus process as observer nodes.

[0074] Furthermore, the process of step four is as follows:

[0075] Based on the PBFT algorithm, a consensus algorithm TBH-PBFT is designed by combining distributed key generation (DKG) and BLS threshold signature technology. The first-stage consensus process of the TBH-PBFT consensus algorithm is as follows:

[0076] Step 4.1, Request Phase

[0077] The client represented by the user (UE) sends a message to the master node. Send a request, the message content is ,in It is the request stage identifier. This is the content of this consensus vote. Represents a timestamp. It is the client identifier;

[0078] Master node Based on the current clustering situation, the scale of this round of consensus is determined, where the scale of the first stage consensus of the TBH-PBFT consensus algorithm is [scale value missing]. The second-stage consensus size of the consensus algorithm TBH-PBFT is... The thresholds for passing the two-stage voting were determined as follows: and Master node Initialize the parameters related to BLS threshold signature by importing elliptic curves. Generated pairing parameters ,in It is a cyclic subgroup on an elliptic curve. It is a cyclic group of integers. It is a large prime number. yes A generator;

[0079] Master node Send a pre-announcement message to the strong nodes participating in the second phase of the TBH-PBFT consensus algorithm. The format is as follows:

[0080]

[0081] in It is the identifier for the second-phase consensus announcement message of the TBH-PBFT consensus algorithm. Indicates the latest timestamp, It is the master node identifier;

[0082] Master node At the same time, the basic information of this round of consensus will be... It is sent to the recording node in the third trusted domain to realize the entire process of recording consensus in the blockchain system;

[0083] Step 4.2, Preparatory Stage

[0084] Master node Randomly generate a set of coefficients and a set of commitments Use coefficient Generate a Polynomial of degree:

[0085]

[0086] in, It is a node The secret of polynomial variables This represents a random number determined by a member. After completing the pre-preparation phase, the master node... Initiation domain The internal broadcast message contained the following:

[0087]

[0088] in, It is an identifier for the pre-preparation stage. It is asymmetric encrypted information contained in the broadcast message, representing the node. Use node numbering After generating the value of the polynomial, through the node The value is encrypted using the public key; It is the view number. It's a serial number. It is a message digest; the remaining nodes that receive the broadcast message verify the signature. The validity of the view is determined by checking if the current view is valid. Serial number Does it meet the requirements of being within the valid range and not in the view? The same process has been handled in the middle. The request was ultimately verified. Is the value related to the summary? same;

[0089] Step 4.3, Preparation

[0090] Alternate Nodes Weak nodes and Receive and verify master node Following the message, the master node in the execution and preparation phase The same operation is performed to generate a private key and build... A polynomial of degree 1, performing polynomial assignment calculations and asymmetric encryption. When spliced ​​into a broadcast message, the specific content is as follows:

[0091]

[0092] in, It is the identifier for the preparation phase; nodes check the signature after collecting broadcast messages during the preparation phase. Validity, verification Consistent with the locally stored pre-prepared message; at this point, each Phase 1 consensus member sends encrypted polynomial parameters to the other members. Each member also received messages from other members. One polynomial parameter;

[0093] The polynomial parameter verification process is as follows:

[0094] (1) Members Received from other members Fragments of polynomial parameters sent via asymmetric encryption and a set of public commitments ;

[0095] (2) Members Through formula Calculate the total value of the commitments received. ;

[0096] (3) Members By verifying the equation To determine if the equation holds true, we obtain the polynomial parameter verification result. If the equation holds true, then the members... The received polynomial parameters are correct;

[0097] Weak nodes in the first phase of the consensus process of the TBH-PBFT consensus algorithm It is a Byzantine node, if a weak node During the consensus process, incorrect information is intentionally sent, and the correctness of the polynomial parameters is verified using a polynomial parameter verification algorithm; if weak nodes... The master node refuses to participate at specific times. At the end of the preparation phase, a set of polynomial parameters is added;

[0098] Step 4.4, Submission Stage

[0099] All consensus nodes are targeting the message. The system independently assesses the information of users (UEs) applying for cross-domain credentials, completes the voting through BLS threshold signature, and sends the results to the master node. Finally, the master node aggregates the signature information and determines the voting result.

[0100] Each consensus node queries the comprehensive trust value and historical interaction records of the user (UE) applying for cross-domain credentials through the Cross-Domain and Trust Management Committee, and casts a vote in favor or against. There are two possible voting results. Use consistent descriptions respectively and Calculate the mapping of its hash value on the elliptic curve. Each node generates a partial signature using the received polynomial parameters:

[0101]

[0102] The calculated signature is included in the commit message, specifically: ,in It is the identifier for the commit phase. The master node determines the voting result by verifying whether the bilinear pairing function is true.

[0103]

[0104] in, It is the system public key, obtained through the first term of the polynomial of each member. Summation with generator The calculation yielded the following results: , , This is the complete signature recovered through interpolation:

[0105]

[0106] in, It is the Lagrange coefficient, complete signature. These are partial signatures of each member. The result of a linear combination.

[0107] Furthermore, the process of step five is as follows:

[0108] In the second phase of the consensus process of the TBH-PBFT consensus algorithm, all participating nodes are strong nodes, each originating from the initiating domain. and target domain In normal mode, the preparation phase in the second phase of the consensus algorithm TBH-PBFT is the same as the preparation phase in the first phase of the consensus algorithm TBH-PBFT.

[0109] Step 5.1: Design the normal mode of the second-stage consensus process of the TBH-PBFT consensus algorithm.

[0110] a) Preparatory Stage

[0111] After the first phase of the consensus process of the TBH-PBFT consensus algorithm is completed, the master node sends the second phase consensus parameters and results to the recording node in the pre-preparation stage of the second phase consensus process of the TBH-PBFT consensus algorithm. The recording node is a committee node from a third-party trust domain, which has the authority to access the historical data of the trust management blockchain and package blocks for on-chain storage. The recording node stores the consensus results on the chain, and the storage record includes information on the consensus participating nodes, a complete list of consensus participating nodes, and a list of malicious nodes.

[0112] b) Submission process

[0113] Voting content is Become ,in The voting content In the second phase of consensus, if a strong node agrees to issue a cross-domain credential to the user (UE) based on their identity information, a partial signature will be generated for that user (UE)'s identity information. If you disagree, then this is a message. Generate partial signatures; In the first stage of consensus submission in the TBH-PBFT consensus algorithm, weak nodes and candidate nodes send the generated partial signatures to the master node point-to-point. In the second stage of consensus in the TBH-PBFT consensus algorithm, all participating nodes are strong nodes. Each member broadcasts its own partial signature, receives partial signatures from other members, recovers the complete signature independently, and judges the voting results.

[0114] c) Verification and Response Phase

[0115] All members other than the master node will report their judgment results back to the master node. If the result of agreeing to issue the certificate is achieved... If the request is approved, the master node will then agree to issue cross-domain credentials to the user (UE); the process will proceed to the next response stage, where the master node will request information regarding the user's (UE's) identity. Sign the document to obtain a cross-domain credential. The cross-domain credential is sent to the user (UE), and the consensus parameters and results of the second phase of the consensus algorithm TBH-PBFT, along with the cross-domain credential, are sent to the recording node. The recording node then completes the on-chaining of the consensus result and the user (UE) cross-domain credential.

[0116] Step 5.2, Design a special mode for the second-stage consensus process of the TBH-PBFT consensus algorithm.

[0117] In special mode, after the preparation phase, strong nodes... In the event of a system crash or disconnection, the master node... No submission received. The reply, after exceeding the system's timeout threshold... If no response is received online, the system switches from normal mode to special mode, proceeding through the waiting list and resubmission stages. The resubmission process is identical to the submission process in normal mode, except that the participating roles are changed from primary node and strong node to primary node, strong node, and substitute node. The waiting list process is as follows:

[0118] The work of the alternate node phase involves confirming the alternate nodes to participate in the consensus, re-executing the distributed key generation, and the master node... and strong nodes None were received within the timeout threshold Each reply queries the trust management blockchain for the highest-rated and available candidate node within its respective cluster. and to the candidate node and Each node initiates a peer-to-peer encrypted message transmission, sending the DKG parameters to the candidate node. The candidate request format is as follows:

[0119]

[0120] in, Represents a node Use the candidate node number After generating the value of the polynomial, through the node The public key is used to encrypt the value; candidate node Received from master node After receiving the message, the polynomial and commitment generation are performed, and the secret shard is sent to the remaining nodes; the remaining online nodes receive the candidate node. The information is used to verify the sharding parameters through a polynomial parameter verification algorithm. .

[0121] In step six, the specific process of the user (UE) initiating cross-domain authentication is as follows:

[0122] Step 6.1: The user (UE) initiates a cross-domain authentication request to the authenticator in the local trust domain X. The request includes the user (UE)'s identifier and cross-domain credentials.

[0123] Step 6.2: The Verifier is a node in the trust domain that has blockchain query permissions. After receiving the cross-domain verification request sent by the user (UE) in Step 6.1, the Verifier uses its private key to verify the legitimacy of the request.

[0124] Step 6.3: After verifying the user (UE) request in Step 6.2, the Verifier obtains the user (UE)'s identity information from the request and places it in the trust domain. The blockchain system verifies whether the user (UE) is a registered legitimate user (UE).

[0125] Step 6.4: If both the cross-domain request verification in Step 6.2 and the user (UE) legitimacy verification in Step 6.3 pass, then parse the cross-domain credentials from the user (UE) request, sign them using the private key, and forward them to the local trust domain. Member of the Cross-Domain and Cross-Domain Trust Management Committee;

[0126] Step 6.5: Members of the Cross-Domain and Trust Management Committee have the authority to access the Cross-Domain Trust Management Chain. After receiving the request sent by the Verifier in Step 6.4, members of the Cross-Domain and Trust Management Committee verify the legality of the request and the correctness of the Verifier's signature.

[0127] Step 6.6: If the request sent by the Verifier in Step 6.5 and the signature of the Verifier are both verified, then the members of the Cross-Domain and Trust Management Committee send a request to the Cross-Domain Trust Management Blockchain Node to apply for cross-domain credential verification parameters.

[0128] Step 6.7: After receiving the request sent in step 6.6, the cross-domain trust management blockchain node queries the parameters through the InterPlanetary File System (IPFS);

[0129] Step 6.8: The InterPlanetary File System (IPFS) obtains the verification parameters, including the generator, based on the query parameter request in Step 6.7 using the user (UE) identifier. System public key Hash of User (UE) Identity Credentials The verification parameters will be returned to the members of the Cross-Domain and Trust Management Committee;

[0130] Step 6.9: The Cross-Domain and Trust Management Committee members obtain the BLS threshold signature of the user's (UE) cross-domain credentials from the request sent by the credential verifier in Step 6.4. The correctness of the threshold signature is verified by executing the bilinear pairing function based on the verification parameters returned in step 6.8, and the validity of the user's (UE) cross-domain credentials is determined.

[0131] Step 6.10: The members of the Cross-Domain and Trust Management Committee return the verification results obtained in Step 6.9 to the Verifier and the User (UE) to complete the cross-domain credential verification.

[0132] This invention also provides a blockchain cross-domain identity authentication system for 6G heterogeneous network scenarios, comprising:

[0133] The 6G heterogeneous network cross-domain identity authentication model construction module is used to build a 6G heterogeneous network cross-domain identity authentication model and delineate the roles and responsibilities of each entity in the 6G heterogeneous network scenario.

[0134] The node clustering module is used to design an improved K-Medoids clustering algorithm based on node evaluation and local node density according to the cross-domain identity authentication model of 6G heterogeneous network, and to cluster nodes in the trust domain of heterogeneous network.

[0135] The consensus master node and participating node selection mechanism design module of the consensus algorithm TBH-PBFT is used to propose a cross-domain credential issuance scheme architecture based on the K-Medoids improved clustering algorithm based on node evaluation and node local density, and to design the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT.

[0136] The first-stage consensus process design module of the consensus algorithm TBH-PBFT is used to design the first-stage consensus process of the consensus algorithm TBH-PBFT based on the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT.

[0137] The second-stage consensus process design module of the consensus algorithm TBH-PBFT is used to implement the first-stage consensus process based on the consensus algorithm TBH-PBFT and design the second-stage consensus process of the consensus algorithm TBH-PBFT, including normal mode and special mode.

[0138] The blockchain-based cross-domain identity authentication method design module is used to implement the first-stage consensus process and the second-stage consensus process based on the TBH-PBFT consensus algorithm, and to design a blockchain-based cross-domain identity authentication method.

[0139] This invention also provides a blockchain cross-domain identity authentication device for 6G heterogeneous network scenarios, comprising:

[0140] Memory: A computer program that stores the blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario described above, and is a computer-readable device;

[0141] Processor: Used to implement the blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario when executing the computer program.

[0142] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the aforementioned blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario.

[0143] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0144] 1. This invention, through the 6G heterogeneous network cross-domain identity authentication model designed in step one, defines the responsibilities of entities in different heterogeneous networks and classifies them into three roles: credential issuer, credential verifier, and user (UE). It designs a cross-domain and trust management committee composed of core roles of heterogeneous networks, and realizes cross-domain credential issuance and verification through the members of the cross-domain and trust management committee and the trust management blockchain. It is effectively applicable to the scenario of heterogeneous network converged identity authentication in 6G.

[0145] 2. This invention, through the improved K-Medoids clustering algorithm based on node evaluation and local node density designed in step two, proposes a method for calculating the data density around a node by introducing a local density range control parameter. It has the ability to adapt to the distribution characteristics of nodes in different heterogeneous networks. The improved clustering algorithm can select nodes with high comprehensive evaluation and high local density as cluster centers, and has good clustering and grouping effects in heterogeneous network scenarios with different distribution characteristics.

[0146] 3. Through the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT designed in step three, this invention can divide the nodes in the cluster into a strong node set, a candidate node set, and a weak node set according to node clustering and node evaluation, and select suitable nodes as the master node and participating nodes of the two-stage consensus algorithm. This can give full play to the advantages of each node and improve the fault tolerance of the consensus algorithm.

[0147] 4. This invention, through the first-stage consensus process of the consensus algorithm TBH-PBFT designed in step four, combined with the cryptographic BLS threshold signature method, can achieve node consensus within the initiating domain, resulting in lower communication overhead.

[0148] 5. The present invention integrates cross-domain strong node consensus voting and cross-chain credential issuance into the same process through the normal mode of the second-stage consensus process of the consensus algorithm TBH-PBFT designed in step five. This eliminates the need to repeatedly allocate resources for two independent processes and optimizes the data continuity in the cross-domain identity credential issuance process.

[0149] 6. This invention, through the special mode of the second-stage consensus process of the consensus algorithm TBH-PBFT designed in step five, adds two steps: alternative and resubmission. This can increase the success rate of cross-domain credential issuance decisions in the event of node downtime or disconnection, and has the ability to quickly restore normal consensus.

[0150] 7. By using the cross-domain and trust management committee node of the third-party trust domain introduced in step five as a recording node, the present invention can package the key parameters and node performance of the consensus algorithm TBH-PBFT into blocks and upload them to the blockchain, thereby enhancing the credibility and immutability of the data.

[0151] 8. The present invention, through the blockchain-based cross-domain identity authentication method designed in step six, combined with the cross-domain and trust management committee mechanism and blockchain technology, can simplify credential verification into a two-party verification scheme of "initiator-committee", reduce the complexity of the identity authentication process and reduce the system load.

[0152] In summary, this invention constructs a cross-domain identity authentication model for 6G heterogeneous networks and designs an improved K-Medoids clustering algorithm based on node evaluation and local node density, which has the advantage of adapting to the node distribution characteristics of different heterogeneous networks. The consensus algorithm TBH-PBFT is designed through a consensus master node and participating node selection mechanism, which has the advantages of improving consensus fault tolerance and reducing communication overhead. Furthermore, a blockchain-based cross-domain identity authentication method is constructed using a two-party verification mechanism, which has the advantage of reducing system complexity and load. Attached Figure Description

[0153] Figure 1 This is a flowchart of the implementation method of the present invention.

[0154] Figure 2 This is a diagram of a 6G heterogeneous network cross-domain identity authentication model provided in an embodiment of the present invention.

[0155] Figure 3 It is a judgment matrix constructed from the node evaluation index provided in the embodiments of the present invention.

[0156] Figure 4 This is a schematic diagram of the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT provided in this embodiment of the invention.

[0157] Figure 5 This is a flowchart of the normal mode of the first-stage consensus process and the second-stage consensus process of the consensus algorithm TBH-PBFT provided in the embodiments of the present invention.

[0158] Figure 6 This is a flowchart of a special mode of the second-stage consensus process of the consensus algorithm TBH-PBFT provided in this embodiment of the invention.

[0159] Figure 7 This is a flowchart of a blockchain-based cross-domain identity authentication method provided in an embodiment of the present invention.

[0160] Figure 8 These are different parameters provided in the embodiments of the present invention. The local density comparison image below shows that, Figure 8 (a) in the text is a parameter. Local density comparison map with a value of 5. Figure 8 (b) in the text is a parameter. Local density contrast map with a value of 10. Figure 8 (c) in the text is a parameter. Local density comparison map with a value of 15.

[0161] Figure 9This is a comparison of the results of the improved K-Medoids clustering algorithm based on node evaluation and local node density provided in this embodiment of the invention with traditional methods in a cellular network scenario. Figure 9 (a) in the figure is the clustering result of the traditional K-Medoids algorithm in a cellular network scenario. Figure 9 (b) in the figure is the clustering result of the K-Medoids improved clustering algorithm based on node evaluation and local node density in the cellular network scenario.

[0162] Figure 10 This is a comparison of the results of the improved K-Medoids clustering algorithm based on node evaluation and local node density provided in this embodiment of the invention with traditional methods in a wireless local area network scenario. Figure 10 (a) in the figure is the clustering result of the traditional K-Medoids algorithm in a wireless LAN scenario. Figure 10 (b) in the figure is the clustering result of the improved K-Medoids clustering algorithm based on node evaluation and local node density in the wireless local area network scenario.

[0163] Figure 11 This is a comparison chart of the communication overhead of the consensus algorithm TBH-PBFT provided in this embodiment of the invention with other consensus algorithms. Figure 11 (a) in the figure represents the number of groups. The graph shows a comparison of the communication overhead of the TBH-PBFT consensus algorithm with other consensus algorithms at time 5. Figure 11 (b) in the diagram represents the number of groups. The graph shows a comparison of the communication overhead of the TBH-PBFT consensus algorithm with other consensus algorithms at time 7. Figure 11 (c) in the figure represents the number of groups. The graph shows the communication overhead comparison between the TBH-PBFT consensus algorithm and other consensus algorithms at time 9. Detailed Implementation

[0164] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0165] To address the interoperability and authentication problem of cross-domain identities in heterogeneous network scenarios of 6G mobile communication technology, this invention studies a heterogeneous network scenario composed of cellular networks, wireless LANs, and IoT, and designs a method for issuing and verifying user cross-domain identity credentials, achieving interoperability and verifiability of user identities across different heterogeneous networks. To address the incompatibility of authentication protocols across different heterogeneous networks, this invention designs a 6G heterogeneous network cross-domain identity authentication model, introducing a cross-domain and trust management committee to assist in cross-domain operations. Utilizing the characteristics of consortium blockchain systems, a two-phase consensus algorithm combining BLS threshold signatures is designed to complete the issuance of cross-domain credentials. An improved node clustering algorithm solves the problem of high communication overhead in traditional Practical Byzantine Fault-Tolerant Consensus (PBFT). This invention also employs a clustering center node selection mechanism based on both node evaluation and node distance factors to avoid extreme cases where the center node has an excessively low evaluation or is too far from other nodes, making it suitable for heterogeneous network scenarios with different node distribution characteristics. Furthermore, this invention designs a cross-domain credential verification method based on blockchain, simplifying the verification process.

[0166] like Figure 1 As shown, a blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario includes the following steps:

[0167] Step 1: Construct a cross-domain identity authentication model for 6G heterogeneous networks, and define the roles and responsibilities of each entity in the 6G heterogeneous network scenario;

[0168] Furthermore, such as Figure 2 As shown, the process of step one is as follows:

[0169] Constructing a cross-domain identity authentication model for 6G heterogeneous networks, the trust domain in the model and trust domain This refers to any two heterogeneous networks, each maintaining its own blockchain system. Each trust domain contains three roles: Issuer, Verifier, and User (UE). The Issuer is the core role in the heterogeneous network, responsible for the registration of new users or devices within its domain and the issuance of credentials. The Verifier is the role in the heterogeneous network with the authority to query the user's (UE) identity information from the blockchain system. The User (UE) is a direct participant in the 6G heterogeneous network cross-domain identity authentication model, performing trust assessment, applying for identity credentials, applying for cross-domain credentials, applying for privacy protection, identity authentication, certificate authentication, and credential revocation.

[0170] The 6G heterogeneous network cross-domain identity authentication model includes a cross-domain and trust management committee. Committee members come from core roles within the heterogeneous network, including cellular base station equipment, IoT core network equipment, and wireless LAN router equipment. Committee members maintain a trust management blockchain, which stores historical records of node interactions and consensus within the heterogeneous network, providing trusted data support for cross-domain credential issuance and verification. Committee members also maintain the IPFS network as a storage extension for the trust management blockchain.

[0171] Step 2: Based on the 6G heterogeneous network cross-domain identity authentication model constructed in Step 1, design an improved K-Medoids clustering algorithm based on node evaluation and local node density to cluster nodes within the trust domain of the heterogeneous network.

[0172] Furthermore, the process of step two is as follows:

[0173] In 6G heterogeneous network scenarios, each node is endowed with rich behaviors and attributes, dynamically influencing its evaluation. Nodes selected as cluster centers have higher evaluations and participate in the consensus phase of cross-domain credential issuance. If only distance is considered during node clustering, nodes with lower evaluations may be selected as cluster centers; if only node evaluation is considered, poor clustering results and excessively large distances between nodes within clusters will increase system communication latency. This paper proposes an improved K-Medoids clustering algorithm based on node evaluation and local node density to cluster nodes within a domain, reducing the number of nodes that need to be considered simultaneously during blockchain consensus, improving node consensus efficiency, and reducing system complexity.

[0174] Step 2.1, Design a node evaluation scheme

[0175] The node evaluation index is defined as the comprehensive average trust value. Overall performance ,stability and response speed The definitions and update methods of the four indicators are as follows:

[0176] Overall average trust score Overall average trust score This is a very large indicator, requiring comprehensive trust. It is based on point-to-point evaluation between nodes. After clustering the nodes in the trust domain, the nodes are divided into different clusters. Assuming there are a total of [number missing] nodes in the current trust domain. The nodes are clustered into groups based on node clustering. Groups, each cluster contains There are 10 nodes, each of which has access to 100 nodes and 100 nodes that have access to 10 The overall trust value of each node, and other factors as well. The overall trust value of a node towards a given node, and the trust value of all other nodes in the cluster towards that given node. The average of the comprehensive trust values ​​is used to obtain the node. Overall average trust score ;

[0177] Overall performance Overall performance It is a very large indicator, determined by the processor performance, memory performance, storage performance and network performance of the actual running device of the node; the overall performance of the node is fixed most of the time, and the specific measurement indicators can be quantified; that is, the greater the overall performance, the more it contributes to the node evaluation.

[0178] stability :stability This is a very large metric, determined by the number of times a node fully participates in consensus; each time a node fully participates in consensus, its stability increases. Increase; the number of times a node fully participates in consensus within each update interval is recorded as follows. If a node goes offline or crashes during consensus participation, its stability parameter will decrease. The number of times a node is absent from consensus participation within each update interval is recorded as follows: The node stability update method is as follows ,in It is a penalty factor for different heterogeneous networks;

[0179] Response speed Response speed This is a very small metric. Response speed is defined as the time required from receiving a consensus proposal to a node providing a valid response to the proposal, using the timestamps of each time point. Subtracting them gives the result;

[0180] like Figure 3 As shown, based on the characteristics of 6G heterogeneous networks and the overall average trust value... Overall performance ,stability and response speed Construct a judgment matrix and calculate the index weights using the geometric mean method, as shown in the following formula:

[0181]

[0182] in, and It determines the values ​​of corresponding rows and columns in a matrix. It calculates the product of each row of the judgment matrix. The power is used to obtain the overall average trust value. Overall performance ,stability and response speed weight The weights are 0.497, 0.108, 0.228, and 0.166, respectively, with the node's overall trust value having the largest weight and the overall performance having the smallest weight. After obtaining the weights, a final consistency check is required. First, the largest eigenvalue is calculated. :

[0183]

[0184] in, This represents the number of dimensions, which is the same as the number of rows and columns in the judgment matrix. Represents the judgment matrix and the standardized weights After multiplying, sum the results row by row; to obtain the final value. The value is 4.11, calculated using the consistency index formula. Find the consistency index The value is 0.035; obtained through the number of dimensions. The value is 0.92, and the consistency ratio is calculated. To obtain the consistency ratio The value is 0.038; if the consistency ratio is less than 0.10, the matrix is ​​considered to have satisfactory consistency; therefore, the matrix is ​​judged to have satisfactory consistency, and the consistency test result is "passed".

[0185] Based on the calculated comprehensive average trust value Overall performance ,stability and response speed The weights, and the matrix formed by the original evaluation data of each node, are as follows:

[0186]

[0187] The matrix composed of the original evaluation data has one row for each node. The next step is to perform a forward transformation on each data point in the matrix, converting all non-maximum indicators into maximum indicators. The transformation method is as follows: Further standardize the already positiveized matrix, the transformation method is as follows: ;

[0188] Define the maximum value of the indicator and minimum value , represented as:

[0189]

[0190]

[0191] Definition of the first Distance between each evaluation node and the maximum value The distance from the minimum value is , represented as:

[0192]

[0193]

[0194] Then, based on the distance between the evaluation node and the maximum and minimum values, calculate the evaluation for each evaluation node. , represented as:

[0195] ;

[0196] Step 2.2, Design the local density of nodes

[0197] After completing one round of node evaluation updates using the node evaluation scheme designed in step 2.1, at a specific moment, the number of nodes within a network coverage area is: The clustering objective is to divide into Group of nodes, any one of the nodes The evaluation is Two-dimensional coordinates nodes to two-dimensional coordinates nodes distance Calculated using the Euclidean distance formula, defined as follows:

[0198]

[0199] To eliminate the adverse effects of extreme nodes on the selection of clustering center points, a local density function is introduced. The density of data points surrounding a node is calculated as follows:

[0200]

[0201] in, It is a node To the node distance, It is a parameter that controls the range of local density calculation. When the value of the exponent is larger, it is closer to 1, making the calculation of local density smoother, having a greater impact on distant points, and incorporating more neighboring nodes; however, as... As density increases, the distinguishability of local density decreases, and the density difference between different regions diminishes.

[0202] In 6G heterogeneous network scenarios, multiple heterogeneous networks exist within the same area, and the nodes in these networks have different location characteristics. Within areas covered by Wi-Fi, nodes are typically distributed in high-density clusters. Within areas covered by cellular networks, the distribution of nodes is more uniform and random. This can be addressed by introducing local density range control parameters. Adjusting based on the characteristics of heterogeneous networks The parameter size allows for more flexible application in different heterogeneous networks, optimizing the selection of cluster center nodes.

[0203] Step 2.3, based on the node evaluation scheme designed in Step 2.1 and the node local density designed in Step 2.2, the specific process of designing the improved K-Medoids clustering algorithm is as follows:

[0204] Step 2.3.1, determine the first cluster center.

[0205] Given the current evaluation set of nodes in the heterogeneous network domain. ,in Represents a node The evaluation, for the evaluation set Sort the nodes in descending order to obtain the sorted set of nodes. ,satisfy:

[0206]

[0207] Select the node with the highest evaluation within the domain. As the first candidate cluster center The local density function is used to check if the local density is greater than the threshold set by the current network. If it satisfies the threshold If the condition is met, then that node is determined as the first cluster center. Otherwise, continue to select the node ranked second in the domain evaluation and repeat the following formula to make judgments until the first cluster center is selected.

[0208]

[0209] Step 2.3.2, determine the next cluster center.

[0210] Except for the first cluster center In addition, the selection of the remaining cluster centers needs to consider both node distance and node score. Therefore, when selecting the next cluster center... When, the next cluster center point is required. The distance from the already selected center point is relatively far, and the next cluster center point is also relatively far. The node evaluation should be high, and a node clustering comprehensive evaluation function should be defined. as follows:

[0211]

[0212] in, This indicates the number of center points that have been selected. It is the set of all points within the domain. It is the set of selected center points, in the calculation It is not necessary to recalculate the center point. These are the weights that control node evaluation and distance in node clustering algorithms. The closer a value is to 1, the more likely it is to select nodes with high evaluations as cluster centers when performing node clustering in the current heterogeneous network; conversely, if... The closer the value is to 0, the more likely it is to choose a point that is farther away as the next cluster center; the next cluster center The selection algorithm is as follows:

[0213]

[0214] Select the nodes with the highest overall clustering evaluation from the other nodes that are not central points within the domain. As a candidate node for the next cluster center, check whether it satisfies... If the local density threshold condition is met, then the next cluster center point is determined. If this condition is not met, it means that the candidate cluster center is far away from the surrounding nodes in the current heterogeneous network scenario, and the next candidate cluster center is selected again through the cluster center selection algorithm.

[0215] Step 2.3.3: Assign the remaining nodes to clusters.

[0216] Once a cluster center point is confirmed, the nodes in the heterogeneous network are assigned to the clusters of the confirmed center point according to the principle of proximity.

[0217]

[0218] in, It is a determined center point. The clusters represent all the clusters that are derived from the previous one. Recent remaining nodes A set;

[0219] Step 2.3.4: Determine the remaining cluster centers and complete the clustering.

[0220] Repeat steps 2.3.2 and 2.3.3 until the problem is found. Find cluster centers and complete the clustering of all nodes.

[0221] Step 3: Based on the improved K-Medoids clustering algorithm designed in Step 2, which is based on node evaluation and local node density, a cross-domain credential issuance scheme architecture is proposed, and the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT are designed.

[0222] Furthermore, such as Figure 4 As shown, step three is as follows:

[0223] Multi-trust domain nodes collaboratively decide whether to issue cross-domain credentials to users (UEs) or devices in heterogeneous networks using the TBH-PBFT consensus algorithm. Before selecting participating consensus nodes and a primary node, the trust domains... Node clustering has been completed based on node scores. Within each cluster, a set of strong nodes has been defined in descending order of node scores. Candidate Node Set Weak node set The total number of strong nodes is The strong nodes are determined by the cluster centers in the final clustering process; the candidate nodes are the two nodes with the highest node scores (excluding the strong nodes) within each cluster, for a total of [number missing]. Alternate nodes are responsible for participating in the first phase of the TBH-PBFT consensus algorithm and serving as candidates for strong nodes in the second phase of the TBH-PBFT consensus algorithm; weak nodes are the remaining nodes within the cluster, numbering [number missing]. The consensus master node and participating nodes of the TBH-PBFT consensus algorithm are responsible for participating in the first phase of the consensus process; the TBH-PBFT consensus master node and participating nodes are from the initiating domain. Target domain and remaining trust domain The nodes selected for the first phase of the TBH-PBFT consensus algorithm come from the cluster where the node that initiated the cross-domain credential request resides. Half of the nodes participating in the first phase of the TBH-PBFT consensus algorithm come from the initiating domain. The other half comes from the target domain. The selection is done through random sampling; both phases of consensus have trust domains. The nodes record the entire consensus process as observer nodes.

[0224] Step 4: Based on the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT designed in Step 3, design the first-stage consensus process of the consensus algorithm TBH-PBFT.

[0225] Furthermore, such as Figure 5 As shown, step four is as follows:

[0226] Based on the PBFT algorithm, a consensus algorithm TBH-PBFT is designed by combining distributed key generation (DKG) and BLS threshold signature technology. The first-stage consensus process of the TBH-PBFT consensus algorithm is as follows:

[0227] Step 4.1, Request Phase

[0228] The client represented by the user (UE) sends a message to the master node. Send a request, the message content is ,in It is the request stage identifier. This is the content of this consensus vote. Represents a timestamp. It is the client identifier;

[0229] Master node Based on the current clustering situation, the scale of this round of consensus is determined, where the scale of the first stage consensus of the TBH-PBFT consensus algorithm is [scale value missing]. The second-stage consensus size of the consensus algorithm TBH-PBFT is... The thresholds for passing the two-stage voting were further determined as follows: and Master node Initialize the parameters related to BLS threshold signature by importing elliptic curves. Generated pairing parameters ,in It is a cyclic subgroup on an elliptic curve. It is a cyclic group of integers. It is a large prime number. yes A generator;

[0230] Master node Send a pre-announcement message to the strong nodes participating in the second phase of the TBH-PBFT consensus algorithm. The format is as follows:

[0231]

[0232] in It is the identifier for the second-phase consensus announcement message of the TBH-PBFT consensus algorithm. Indicates the latest timestamp, It is the master node identifier;

[0233] Master node At the same time, the basic information of this round of consensus will be... It is sent to the recording node in the third trusted domain to realize the entire process of recording consensus in the blockchain system;

[0234] Step 4.2, Preparatory Stage

[0235] Master node Randomly generate a set of coefficients and a set of commitments Use coefficient Generate a Polynomial of degree:

[0236]

[0237] in, It is a node The secret of polynomial variables This represents a random number determined by a member. After completing the pre-preparation phase, the master node... Initiation domain The internal broadcast message contained the following:

[0238]

[0239] in, It is an identifier for the pre-preparation stage. It is asymmetric encrypted information contained in the broadcast message, representing the node. Use node numbering After generating the value of the polynomial, through the node The value is encrypted using the public key; It is the view number. It's a serial number. It is a message digest; the remaining nodes that receive the broadcast message verify the signature. The validity of the view is determined by checking if the current view is valid. Serial number Does it meet the requirements of being within the valid range and not in the view? The same process has been handled in the middle. The request was ultimately verified. Is the value related to the summary? same;

[0240] Step 4.3, Preparation

[0241] Alternate Nodes Weak nodes and Receive and verify master node Following the message, the master node in the execution and preparation phase The same operation is performed to generate a private key and build... A polynomial of degree 1, performing polynomial assignment calculations and asymmetric encryption. When spliced ​​into a broadcast message, the specific content is as follows:

[0242]

[0243] in, It is the identifier for the preparation phase; nodes check the signature after collecting broadcast messages during the preparation phase. Validity, verification Consistent with the locally stored pre-prepared message; after completing the above process, each member of the first-phase consensus then sends the encrypted polynomial parameters to the other members. Each member also received messages from other members. There are ___ polynomial parameters; the polynomial parameter verification algorithm is as follows:

[0244]

[0245] The polynomial parameter verification process is as follows:

[0246] (1) Members Received from other members Fragments of polynomial parameters sent via asymmetric encryption and a set of public commitments ;

[0247] (2) Members Through formula Calculate the total value of the commitments received. ;

[0248] (3) Members By verifying the equation To determine if the equation holds true, we obtain the polynomial parameter verification result. If the equation holds true, then the members... The received polynomial parameters are correct;

[0249] Weak nodes in the first phase of the consensus process of the TBH-PBFT consensus algorithm It is a Byzantine node, if a weak node Even if incorrect information is intentionally sent during the consensus process, the correctness of the polynomial parameters can still be verified using a polynomial parameter verification algorithm; however, if weak nodes... The master node refuses to participate at specific times; this selective silence is a malicious act. At the end of the preparation phase, a set of polynomial parameters is added to ensure that the polynomial parameter verification algorithm can be executed normally and will not affect the fairness of the voting process in the subsequent submission phase.

[0250] Step 4.4, Submission Stage

[0251] Unlike the traditional PBFT, the consensus algorithm TBH-PBFT simplifies the commit phase of the first-stage consensus. By combining cryptographic BLS threshold signatures, participating nodes have already completed the synchronization and verification of all parameters when they enter the commit phase. The main task of the commit phase is for all consensus nodes to re-sign the message. The system independently assesses the information of users (UEs) applying for cross-domain credentials, completes the voting through BLS threshold signature, and sends the results to the master node. Finally, the master node aggregates the signature information and determines the voting result.

[0252] Each consensus node queries the comprehensive trust value and historical interaction records of the user (UE) applying for cross-domain credentials through the Cross-Domain and Trust Management Committee, and casts a vote in favor or against. There are two possible voting results. Use consistent descriptions respectively and Calculate the mapping of its hash value on the elliptic curve. Each node generates a partial signature using the received polynomial parameters:

[0253]

[0254] The calculated signature is included in the commit message, specifically: ,in It is the identifier for the commit phase. The master node determines the voting result by verifying whether the bilinear pairing function is true.

[0255]

[0256] in, It is the system public key, obtained through the first term of the polynomial of each member. Summation with generator The calculation yielded the following results: , , This is the complete signature recovered through interpolation:

[0257]

[0258] in, It is the Lagrange coefficient, complete signature. These are partial signatures of each member. The result of a linear combination.

[0259] Step 5: Based on the first-stage consensus process of the TBH-PBFT consensus algorithm designed in Step 4, design the second-stage consensus process of the TBH-PBFT consensus algorithm, including normal mode and special mode;

[0260] Furthermore, step five is as follows:

[0261] The above steps detail the first-phase consensus process of the TBH-PBFT consensus algorithm. Since this consensus addresses cross-domain credential issuance, the first-phase consensus is initiated by the domain... Since nodes within the same domain participate, a second-phase consensus is needed to finalize and execute the issuance of cross-domain credentials. The second-phase consensus process of the TBH-PBFT consensus algorithm involves strong nodes from the initiating domain. and target domain In normal mode, the preparation phase in the second phase of the TBH-PBFT consensus algorithm is the same as the preparation phase in the first phase of the TBH-PBFT consensus algorithm. The focus is on explaining the differences between the pre-preparation phase and the submission phase, as well as the newly added verification and response phases.

[0262] Step 5.1: Design the normal mode of the second-stage consensus process of the TBH-PBFT consensus algorithm.

[0263] a) Preparatory Stage

[0264] After the first phase of the consensus process of the TBH-PBFT consensus algorithm is completed, the master node sends the second phase consensus parameters and results to the recording node in the pre-preparation stage of the second phase consensus process of the TBH-PBFT consensus algorithm. The recording node is a committee node from a third-party trust domain, which has the authority to access the historical data of the trust management blockchain and package blocks for on-chain storage. The recording node stores the consensus results on the chain, and the storage record includes information on the consensus participating nodes, a complete list of consensus participating nodes, and a list of malicious nodes.

[0265] b) Submission process

[0266] Voting content is Become ,in The voting content In the second phase of consensus, if a strong node agrees to issue a cross-domain credential to the user (UE) based on their identity information, a partial signature will be generated for that user (UE)'s identity information. If you disagree, then this is a message. Generating partial signatures; since the node evaluation of weak nodes and candidate nodes is weaker than that of strong nodes, it is more appropriate for the subsequent interpolation to restore the complete signature and the verification of the signature to be handled by nodes with higher node evaluation. In the first stage of consensus submission of the TBH-PBFT consensus algorithm, weak nodes and candidate nodes send the generated partial signatures to the master node point-to-point. In the second stage of consensus of the TBH-PBFT consensus algorithm, the nodes participating in the consensus are all strong nodes with strong comprehensive capabilities. Each member broadcasts its own partial signature, receives partial signatures from other members, restores the complete signature independently, and judges the voting results.

[0267] c) Verification and Response Phase

[0268] All members other than the master node will report their judgment results back to the master node. If the result of agreeing to issue the certificate is achieved... If the request is approved, the master node will then agree to issue cross-domain credentials to the user (UE); the process will proceed to the next response stage, where the master node will request information regarding the user's (UE's) identity. Sign the document to obtain a cross-domain credential. The cross-domain credential is sent to the user (UE), and the consensus parameters and results of the second phase of the consensus algorithm TBH-PBFT, along with the cross-domain credential, are sent to the recording node. The recording node then completes the on-chaining of the consensus result and the user (UE) cross-domain credential.

[0269] like Figure 6 As shown in step 5.2, a special mode for the second-stage consensus process of the TBH-PBFT consensus algorithm is designed:

[0270] Traditional PBFT exceeds Byzantine nodes The network may completely lose security and activity, leading to forks or stagnation. While considering the comprehensive rating and trust level of nodes during consensus node selection reduces the likelihood of Byzantine nodes, sudden outages or node disconnections due to network factors still exist. Therefore, a special mode is proposed for the second-phase consensus process of the TBH-PBFT consensus algorithm, allowing candidate nodes to replace disconnected strong nodes and continue participating in the second-phase consensus. The reasons for designing this special mode only for the second phase are as follows:

[0271] a) Enhance the success rate of cross-domain credential issuance decisions to avoid situations where the first phase succeeds but the second phase fails frequently, resulting in a large waste of system resources and the occupation of nodes.

[0272] b) Nodes participating in the second phase of consensus have a higher probability of performing better in the consensus process, that is, demonstrating stronger computing power and faster response speed, and having the ability to quickly restore normal consensus.

[0273] c) Provide more nodes with opportunities to participate in consensus, thereby increasing the enthusiasm of nodes in the blockchain system to participate in various transactions.

[0274] Compared to normal mode, special mode adds two more stages: waiting and resubmission. After the preparation stage, the strong node... In the event of a system crash or disconnection, the master node... No submission received. The reply, after exceeding the system's timeout threshold... If no response is received online, the system switches from normal mode to special mode, proceeding through the waiting list and resubmission stages. The resubmission process is identical to the submission process in normal mode, except that the participating roles are changed from primary node and strong node to primary node, strong node, and substitute node. The waiting list process is as follows:

[0275] The main tasks of the alternate node phase are to confirm the alternate nodes participating in the consensus, re-execute the distributed key generation, and the master node. and strong nodes None were received within the timeout threshold Each reply queries the trust management blockchain for the highest-rated and available candidate node within its respective cluster. and to the candidate node and Each node initiates a peer-to-peer encrypted message transmission, sending the DKG parameters to the candidate node. The candidate request format is as follows:

[0276]

[0277] in, Represents a node Use the candidate node number After generating the value of the polynomial, through the node The public key is used to encrypt the value; candidate node Received from master node After receiving the message, the polynomial and commitment generation are performed, and the secret shard is sent to the remaining nodes; the remaining online nodes receive the candidate node. The information is used to verify the sharding parameters through a polynomial parameter verification algorithm. .

[0278] Step Six: Based on the first-stage consensus process of the TBH-PBFT consensus algorithm designed in Step Four and the second-stage consensus process of the TBH-PBFT consensus algorithm designed in Step Five, design a blockchain-based cross-domain identity authentication method.

[0279] Furthermore, such as Figure 7As shown, in step six, the specific process of the user (UE) initiating cross-domain identity authentication is as follows:

[0280] Step 6.1: The user (UE) initiates a cross-domain authentication request to the authenticator in the local trust domain X. The request includes the user's identifier and cross-domain credentials. To ensure the security of the transmission process, all subsequent requests are encrypted using the recipient's public key.

[0281] Step 6.2: The Verifier is a node in the trust domain that has blockchain query permissions. After receiving the cross-domain verification request sent by the user (UE) in Step 6.1, the Verifier uses its private key to verify the legitimacy of the request.

[0282] Step 6.3: After verifying the user (UE) request in Step 6.2, the Verifier obtains the user (UE)'s identity information from the request and places it in the trust domain. The blockchain system verifies whether the user (UE) is a registered legitimate user (UE).

[0283] Step 6.4: If both the cross-domain request verification in Step 6.2 and the user (UE) legitimacy verification in Step 6.3 pass, then parse the cross-domain credentials from the user (UE) request, sign them using the private key, and forward them to the local trust domain. Member of the Cross-Domain and Cross-Domain Trust Management Committee;

[0284] Step 6.5: Members of the Cross-Domain and Trust Management Committee have the authority to access the Cross-Domain Trust Management Chain. After receiving the request sent by the Verifier in Step 6.4, members of the Cross-Domain and Trust Management Committee verify the legality of the request and the correctness of the Verifier's signature.

[0285] Step 6.6: If the request sent by the Verifier in Step 6.5 and the signature of the Verifier are both verified, then the members of the Cross-Domain and Trust Management Committee send a request to the Cross-Domain Trust Management Blockchain Node to apply for cross-domain credential verification parameters.

[0286] Step 6.7: After receiving the request sent in step 6.6, the cross-domain trust management blockchain node queries the parameters through the InterPlanetary File System (IPFS);

[0287] Step 6.8: The InterPlanetary File System (IPFS) obtains the verification parameters, including the generator, based on the query parameter request in Step 6.7 using the user (UE) identifier. System public key Hash of User (UE) Identity Credentials The verification parameters will be returned to the members of the Cross-Domain and Trust Management Committee;

[0288] Step 6.9: The Cross-Domain and Trust Management Committee members obtain the BLS threshold signature of the user's (UE) cross-domain credentials from the request sent by the credential verifier in Step 6.4. The correctness of the threshold signature is verified by executing the bilinear pairing function based on the verification parameters returned in step 6.8, and the validity of the user's (UE) cross-domain credentials is determined.

[0289] Step 6.10: The members of the Cross-Domain and Trust Management Committee return the verification results obtained in Step 6.9 to the Verifier and the User (UE) to complete the cross-domain credential verification.

[0290] Key credential parameters are stored on the blockchain by the recording node during the credential issuance phase. During cross-domain credential verification, only the initiating party's trusted domain is verified. Verification can be completed with the participation of both parties, namely the Cross-Domain and Trust Management Committee, which improves the efficiency of credential verification.

[0291] like Figure 8 As shown, this illustrates different scenarios with the same node distribution. The value of affects the local density of nodes. There is an extreme point in the upper left corner of the region in the figure, such as... Figure 8 As shown in (a) in the figure, when When the value is 5, the calculated local density at this extreme point is 0.14; for example... Figure 8 As shown in (b) in the figure, when When the value is increased to 10, the local density of extreme points increases to 6.23, meaning that more nodes are included in the consideration. For example... Figure 8 As shown in (c), when When the value is 15, the local density of the extreme points has increased to 16.72. At this point, it can be considered that all nodes in the entire region are included in the calculation of the local density of the extreme points.

[0292] Figure 9 (a) in the figure shows the clustering results of using the traditional K-Medoids clustering algorithm in a heterogeneous network of cellular type. Figure 9 (b) shows the clustering results in a heterogeneous network of cellular type using the improved K-Medoids clustering algorithm based on node evaluation and local node density designed in this invention. Figure 9 The simulation diagram (a) shows cluster centers with low evaluation value, with a score of 0.323. Figure 9 In simulation diagram (b), the cluster centroids generally received higher evaluations and performed better than in distance and region partitioning. Figure 9(a) shows that the traditional clustering algorithm is superior. Therefore, the improved K-Medoids clustering algorithm based on node evaluation and local node density designed in this invention can select nodes with high evaluation as cluster centers in cellular network scenarios, achieving better clustering results.

[0293] Figure 10 (a) in the figure shows the clustering results of using the traditional K-Medoids clustering algorithm in a heterogeneous wireless LAN network. Figure 10 (b) shows the clustering results in a heterogeneous wireless LAN network using the improved K-Medoids clustering algorithm based on node evaluation and local node density designed in this invention. Figure 10 The simulation diagram in (a) shows cluster centers with low evaluation value, with scores of 0.398 and 0.523. Figure 10 In simulation diagram (b), the cluster centroids generally received high ratings, all exceeding 0.9, and were significantly better than the cluster centers in terms of distance and region partitioning. Figure 10 The proposed K-Medoids improved clustering algorithm (a) is similar to the traditional clustering algorithm in (a). Therefore, the proposed algorithm, based on node evaluation and local node density, is applicable to wireless LAN scenarios with concentrated node distribution.

[0294] Figure 11 The invention demonstrates a comparison of the communication overhead of the consensus algorithm TBH-PBFT designed in this invention with that of traditional PBFT and existing hierarchical PBFT algorithms. Figure 11 (a) Figure 11 (b) and Figure 11 (c) in the text represents the number of groups. The graph compares the communication overhead at times 5, 7, and 9, showing how it increases with the number of packets. In addition to the traditional PBFT, the communication overhead of all hierarchical PBFT algorithms has decreased, and the consensus algorithm TBH-PBFT of this invention has the lowest communication overhead. Therefore, the consensus algorithm TBH-PBFT designed in this invention has lower communication overhead and can effectively reduce the system burden of cross-domain credential issuance.

[0295] Key points and protections of this invention include, but are not limited to:

[0296] 1. The 6G heterogeneous network cross-domain identity authentication model constructed in this invention defines the roles and responsibilities of each entity, as described in step one.

[0297] 2. This invention utilizes an improved K-Medoids clustering algorithm based on node evaluation and local node density, which is applicable to heterogeneous network scenarios with different node distributions. This corresponds to the content in step two.

[0298] 3. This invention incorporates the two-stage consensus algorithm TBH-PBFT based on BLS threshold signatures. Key aspects include the consensus node selection mechanism, the first stage of the TBH-PBFT consensus algorithm, and the normal and special modes of the second stage of the TBH-PBFT consensus algorithm. These correspond to steps three, four, and five, respectively.

[0299] 4. A simplified method for cross-domain user credential verification based on blockchain. This is the content of step six.

[0300] Existing identity authentication schemes are designed for single-structure network models, distinguishing domain relationships based on geographical location within a single network. There is currently no cross-domain identity authentication scheme designed for 6G heterogeneous network scenarios. In 6G scenarios, user equipment needs to frequently interact across networks and exchange resources. Designing a secure and efficient cross-domain identity authentication mechanism can safeguard node interactions and resource access. Therefore, there are currently no other alternatives that can fully achieve the objectives of this invention.

[0301] This invention also provides a blockchain cross-domain identity authentication system for 6G heterogeneous network scenarios, comprising:

[0302] The 6G heterogeneous network cross-domain identity authentication model construction module is used to realize the construction of the 6G heterogeneous network cross-domain identity authentication model in step one, and to divide the roles and responsibilities of each entity in the scenario.

[0303] The node clustering module is used to implement the 6G heterogeneous network cross-domain identity authentication model constructed in step one in step two. It designs an improved K-Medoids clustering algorithm based on node evaluation and local node density to cluster nodes within the trust domain of the heterogeneous network.

[0304] The consensus master node and participating node selection mechanism design module of the consensus algorithm TBH-PBFT is used to implement the K-Medoids improved clustering algorithm based on node evaluation and local node density designed in step 3, propose a cross-domain credential issuance scheme architecture, and design the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT.

[0305] The first-stage consensus process design module of the consensus algorithm TBH-PBFT is used to implement the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT designed in step three in step four, and to design the first-stage consensus process of the consensus algorithm TBH-PBFT.

[0306] The second-stage consensus process design module of the consensus algorithm TBH-PBFT is used to implement the first-stage consensus process of the consensus algorithm TBH-PBFT designed in step five based on step four, and to design the second-stage consensus process of the consensus algorithm TBH-PBFT, including normal mode and special mode.

[0307] The blockchain-based cross-domain identity authentication method design module is used to implement the first-stage consensus process of the consensus algorithm TBH-PBFT designed in step four and the second-stage consensus process of the consensus algorithm TBH-PBFT designed in step five in step six, and to design a blockchain-based cross-domain identity authentication method.

[0308] This invention also provides a blockchain cross-domain identity authentication device for 6G heterogeneous network scenarios, comprising:

[0309] Memory: A computer program that stores the blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario described above, and is a computer-readable device;

[0310] Processor: Used to implement the blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario when executing the computer program.

[0311] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the aforementioned blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario.

Claims

1. A blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario, characterized in that, Includes the following steps: Step 1: Construct a cross-domain identity authentication model for 6G heterogeneous networks, and define the roles and responsibilities of each entity in the 6G heterogeneous network scenario; Step 2: Based on the 6G heterogeneous network cross-domain identity authentication model constructed in Step 1, design an improved K-Medoids clustering algorithm based on node evaluation and local node density to cluster nodes within the trust domain of the heterogeneous network. Step 3: Based on the improved K-Medoids clustering algorithm designed in Step 2, which is based on node evaluation and local node density, a cross-domain credential issuance scheme architecture is proposed, and the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT are designed. Step 4: Based on the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT designed in Step 3, design the first-stage consensus process of the consensus algorithm TBH-PBFT. Step 5: Based on the first-stage consensus process of the TBH-PBFT consensus algorithm designed in Step 4, design the second-stage consensus process of the TBH-PBFT consensus algorithm, including normal mode and special mode; Step Six: Based on the first-stage consensus process of the TBH-PBFT consensus algorithm designed in Step Four and the second-stage consensus process of the TBH-PBFT consensus algorithm designed in Step Five, design a blockchain-based cross-domain identity authentication method; The process of step three is as follows: Multi-trust domain nodes collaboratively decide whether to issue cross-domain credentials to users (UEs) or devices in heterogeneous networks using the TBH-PBFT consensus algorithm. Before selecting participating consensus nodes and a primary node, the trust domains... Node clustering has been completed based on node scores. Within each cluster, a set of strong nodes has been defined in descending order of node scores. Candidate Node Set Weak node set The total number of strong nodes is The strong nodes are determined by the cluster centers in the final clustering process; the candidate nodes are the two nodes with the highest node scores (excluding the strong nodes) within each cluster, for a total of [number missing]. The alternate nodes are responsible for participating in the first stage of the consensus process of the TBH-PBFT consensus algorithm and serving as candidates for strong nodes in the second stage of the consensus process of the TBH-PBFT consensus algorithm. Weak nodes are the remaining nodes within a cluster, and their number is... Responsible for participating in the first phase of the consensus process of the consensus algorithm TBH-PBFT; The consensus algorithm TBH-PBFT's consensus master node and participating nodes are derived from the initiating domain. Target domain and remaining trust domain The nodes selected for the first phase of the TBH-PBFT consensus algorithm come from the cluster where the node that initiated the cross-domain credential request resides. Half of the nodes participating in the first phase of the TBH-PBFT consensus algorithm come from the initiating domain. The other half comes from the target domain. The selection is done through random sampling; both phases of consensus have trust domains. The nodes record the entire consensus process as observer nodes; The process of step four is as follows: Based on the PBFT algorithm, a consensus algorithm TBH-PBFT is designed by combining distributed key generation (DKG) and BLS threshold signature technology. The first-stage consensus process of the TBH-PBFT consensus algorithm is as follows: Step 4.1, Request Phase The client represented by the user (UE) sends a message to the master node. Send a request, the message content is ,in It is the request stage identifier. This is the content of this consensus vote. Represents a timestamp. It is the client identifier; Master node Based on the current clustering situation, the scale of this round of consensus is determined, where the scale of the first stage consensus of the TBH-PBFT consensus algorithm is [scale value missing]. The second-stage consensus size of the consensus algorithm TBH-PBFT is... The thresholds for passing the two-stage voting were determined as follows: and Master node Initialize the parameters related to BLS threshold signature by importing elliptic curves. Generated pairing parameters ,in It is a cyclic subgroup on an elliptic curve. It is a cyclic group of integers. It is a large prime number. yes A generator; Master node Send a pre-announcement message to the strong nodes participating in the second phase of the TBH-PBFT consensus algorithm. The format is as follows: in It is the identifier for the second-phase consensus announcement message of the TBH-PBFT consensus algorithm. Indicates the latest timestamp, It is the master node identifier; Master node At the same time, the basic information of this round of consensus will be... It is sent to the recording node in the third trusted domain to realize the entire process of recording consensus in the blockchain system; Step 4.2, Preparatory Stage Master node Randomly generate a set of coefficients and a set of commitments Use coefficient Generate a Polynomial of degree: in, It is a node The secret of polynomial variables This represents a random number determined by a member. After completing the pre-preparation phase, the master node... Initiation domain The internal broadcast message contained the following: in, It is an identifier for the pre-preparation stage. It is asymmetric encrypted information contained in the broadcast message, representing the node. Use node numbering After generating the value of the polynomial, through the node The value is encrypted using the public key; It is the view number. It's a serial number. It is a message digest; the remaining nodes that receive the broadcast message verify the signature. The validity of the view is determined by checking if the current view is valid. Serial number Does it meet the requirements of being within the valid range and not in the view? The same process has been handled in the middle. The request was ultimately verified. Is the value related to the summary? same; Step 4.3, Preparation Alternate Nodes Weak nodes and Receive and verify master node Following the message, the master node in the execution and preparation phase The same operation is performed to generate a private key and build... A polynomial of degree 1, performing polynomial assignment calculations and asymmetric encryption. When spliced ​​into a broadcast message, the specific content is as follows: in, It is the identifier for the preparation phase; nodes check the signature after collecting broadcast messages during the preparation phase. Validity, verification Consistent with the locally stored pre-prepared message; at this point, each Phase 1 consensus member sends encrypted polynomial parameters to the other members. Each member also received messages from other members. One polynomial parameter; The polynomial parameter verification process is as follows: (1) Members Received from other members Fragments of polynomial parameters sent via asymmetric encryption and a set of public commitments ; (2) Members Through formula Calculate the total value of the commitments received. ; (3) Members By verifying the equation To determine if the equation holds true, we obtain the polynomial parameter verification result. If the equation holds true, then the members... The received polynomial parameters are correct; Weak nodes in the first phase of the consensus process of the TBH-PBFT consensus algorithm It is a Byzantine node, if a weak node During the consensus process, incorrect information is intentionally sent, and the correctness of the polynomial parameters is verified using a polynomial parameter verification algorithm; if weak nodes... The master node refuses to participate at specific times. At the end of the preparation phase, a set of polynomial parameters is added; Step 4.4, Submission Stage All consensus nodes are targeting the message. The system independently assesses the information of users (UEs) applying for cross-domain credentials, completes the voting through BLS threshold signature, and sends the results to the master node. Finally, the master node aggregates the signature information and determines the voting result. Each consensus node queries the comprehensive trust value and historical interaction records of the user (UE) applying for cross-domain credentials through the Cross-Domain and Trust Management Committee, and casts a vote in favor or against. There are two possible voting results. Use consistent descriptions respectively and Calculate the mapping of its hash value on the elliptic curve. Each node generates a partial signature using the received polynomial parameters: The calculated signature is included in the commit message, specifically: ,in It is the identifier for the commit phase. The master node determines the voting result by verifying whether the bilinear pairing function is true. in, It is the system public key, obtained through the first term of the polynomial of each member. Summation with generator The calculation yielded the following results: , , This is the complete signature recovered through interpolation: in, It is the Lagrange coefficient, complete signature. These are partial signatures of each member. The linear combination result; The process of step five is as follows: In the second phase of the consensus process of the TBH-PBFT consensus algorithm, all participating nodes are strong nodes, each originating from the initiating domain. and target domain In normal mode, the preparation phase in the second phase of the consensus algorithm TBH-PBFT is the same as the preparation phase in the first phase of the consensus algorithm TBH-PBFT. Step 5.1: Design the normal mode of the second-stage consensus process of the TBH-PBFT consensus algorithm. a) Preparatory Stage After the first phase of the consensus process of the TBH-PBFT consensus algorithm is completed, the master node sends the second phase consensus parameters and results to the recording node in the pre-preparation stage of the second phase consensus process of the TBH-PBFT consensus algorithm. The recording node is a committee node from a third-party trust domain, which has the authority to access the historical data of the trust management blockchain and package blocks for on-chain storage. The recording node stores the consensus results on the chain, and the storage record includes information on the consensus participating nodes, a complete list of consensus participating nodes, and a list of malicious nodes. b) Submission process Voting content is Become ,in The voting content In the second phase of consensus, if a strong node agrees to issue a cross-domain credential to the user (UE) based on their identity information, a partial signature will be generated for that user (UE)'s identity information. If you disagree, then this is a message. Generate partial signatures; In the first stage of consensus submission in the TBH-PBFT consensus algorithm, weak nodes and candidate nodes send the generated partial signatures to the master node point-to-point. In the second stage of consensus in the TBH-PBFT consensus algorithm, all participating nodes are strong nodes. Each member broadcasts its own partial signature, receives partial signatures from other members, recovers the complete signature independently, and judges the voting results. c) Verification and Response Phase All members other than the master node will report their judgment results back to the master node. If the result of agreeing to issue the certificate is achieved... If the request is approved, the master node will then agree to issue cross-domain credentials to the user (UE); the process will proceed to the next response stage, where the master node will request information regarding the user's (UE's) identity. Sign the document to obtain a cross-domain credential. The cross-domain credential is sent to the user (UE), and the consensus parameters and results of the second phase of the consensus algorithm TBH-PBFT, along with the cross-domain credential, are sent to the recording node. The recording node then completes the on-chaining of the consensus result and the user (UE) cross-domain credential. Step 5.2, Design a special mode for the second-stage consensus process of the TBH-PBFT consensus algorithm. In special mode, after the preparation phase, strong nodes... In the event of a system crash or disconnection, the master node... No submission received. The reply, after exceeding the system's timeout threshold... If no response is received online, the system switches from normal mode to special mode, proceeding through the waiting list and resubmission stages. The resubmission process is identical to the submission process in normal mode, except that the participating roles are changed from primary node and strong node to primary node, strong node, and substitute node. The waiting list process is as follows: The work of the alternate node phase involves confirming the alternate nodes to participate in the consensus, re-executing the distributed key generation, and the master node... and strong nodes None were received within the timeout threshold Each reply queries the trust management blockchain for the highest-rated and available candidate node within its respective cluster. and to the candidate node and Each node initiates a peer-to-peer encrypted message transmission, sending the DKG parameters to the candidate node. The candidate request format is as follows: in, Represents a node Use the candidate node number After generating the value of the polynomial, through the node The public key is used to encrypt the value; candidate node Received from master node After receiving the message, the polynomial and commitment generation are performed, and the secret shard is sent to the remaining nodes; the remaining online nodes receive the candidate node. The information is used to verify the sharding parameters through a polynomial parameter verification algorithm. ; In step six, the specific process of the user (UE) initiating cross-domain authentication is as follows: Step 6.1: The user (UE) initiates a cross-domain authentication request to the authenticator in the local trust domain X. The request includes the user (UE)'s identifier and cross-domain credentials. Step 6.2: The Verifier is a node in the trust domain that has blockchain query permissions. After receiving the cross-domain verification request sent by the user (UE) in Step 6.1, the Verifier uses its private key to verify the legitimacy of the request. Step 6.3: After verifying the user (UE) request in Step 6.2, the Verifier obtains the user (UE)'s identity information from the request and places it in the trust domain. The blockchain system verifies whether the user (UE) is a registered legitimate user (UE). Step 6.4: If both the cross-domain request verification in Step 6.2 and the user (UE) legitimacy verification in Step 6.3 pass, then parse the cross-domain credentials from the user (UE) request, sign them using the private key, and forward them to the local trust domain. Member of the Cross-Domain and Cross-Domain Trust Management Committee; Step 6.5: Members of the Cross-Domain and Trust Management Committee have the authority to access the Cross-Domain Trust Management Chain. After receiving the request sent by the Verifier in Step 6.4, members of the Cross-Domain and Trust Management Committee verify the legality of the request and the correctness of the Verifier's signature. Step 6.6: If the request sent by the Verifier in Step 6.5 and the signature of the Verifier are both verified, then the members of the Cross-Domain and Trust Management Committee send a request to the Cross-Domain Trust Management Blockchain Node to apply for cross-domain credential verification parameters. Step 6.7: After receiving the request sent in step 6.6, the cross-domain trust management blockchain node queries the parameters through the InterPlanetary File System (IPFS); Step 6.8: The InterPlanetary File System (IPFS) obtains the verification parameters, including the generator, based on the query parameter request in Step 6.7 using the user (UE) identifier. System public key Hash of User (UE) Identity Credentials The verification parameters will be returned to the members of the Cross-Domain and Trust Management Committee; Step 6.9: The Cross-Domain and Trust Management Committee members obtain the BLS threshold signature of the user's (UE) cross-domain credentials from the request sent by the credential verifier in Step 6.

4. The correctness of the threshold signature is verified by executing the bilinear pairing function based on the verification parameters returned in step 6.8, and the validity of the user's (UE) cross-domain credentials is determined. Step 6.10: The members of the Cross-Domain and Trust Management Committee return the verification results obtained in Step 6.9 to the Verifier and the User (UE) to complete the cross-domain credential verification.

2. The blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario according to claim 1, characterized in that, The process of step one is as follows: Constructing a cross-domain identity authentication model for 6G heterogeneous networks, the trust domain in the model and trust domain This refers to any two heterogeneous networks, each maintaining its own blockchain system. Each trust domain contains three roles: Issuer, Verifier, and User (UE). The Issuer is the core role in the heterogeneous network, responsible for the registration of new users or devices within its domain and the issuance of credentials. The Verifier is the role in the heterogeneous network with the authority to query the user's (UE) identity information from the blockchain system. The User (UE) is a direct participant in the 6G heterogeneous network cross-domain identity authentication model, performing trust assessment, applying for identity credentials, applying for cross-domain credentials, applying for privacy protection, identity authentication, certificate authentication, and credential revocation. The 6G heterogeneous network cross-domain identity authentication model includes a cross-domain and trust management committee. The members of the cross-domain and trust management committee come from core roles in heterogeneous networks, including base station equipment of cellular networks, core network equipment of IoT, and router equipment of wireless LAN. The Cross-Domain and Trust Management Committee maintains the Trust Management Blockchain, which is responsible for storing the historical records of node interactions and consensus in heterogeneous networks and maintaining the IPFS network as a storage extension of the Trust Management Blockchain.

3. The blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario according to claim 1, characterized in that, The process of step two is as follows: Step 2.1, Design a node evaluation scheme The node evaluation index is defined as the comprehensive average trust value. Overall performance ,stability and response speed The definitions and update methods of the four indicators are as follows: Overall average trust score Overall average trust score This is a very large indicator, requiring comprehensive trust. It is based on point-to-point evaluation between nodes. After clustering nodes in the trust domain, the nodes are divided into different clusters, and all other nodes in the cluster are evaluated against a given node. The average of the comprehensive trust values ​​is used to obtain the node. Overall average trust score ; Overall performance Overall performance This is a very large metric, determined by the processor performance, memory performance, storage performance, and network performance of the actual device running the node; stability :stability This is a very large metric, determined by the number of times a node fully participates in consensus; each time a node fully participates in consensus, its stability increases. Increase; the number of times a node fully participates in consensus within each update interval is recorded as follows. The number of times a node is absent from consensus within each update interval is recorded as follows: The node stability update method is as follows ,in It is a penalty factor for different heterogeneous networks; Response speed Response speed This is a very small metric. Response speed is defined as the time required from receiving a consensus proposal to a node providing a valid response to the proposal, using the timestamps of each time point. Subtracting them gives the result; Based on the characteristics of 6G heterogeneous networks and the overall average trust value Overall performance ,stability and response speed Construct a judgment matrix and calculate the index weights using the geometric mean method, as shown in the following formula: in, and It determines the values ​​of corresponding rows and columns in a matrix. It calculates the product of each row of the judgment matrix. The power is used to obtain the overall average trust value. Overall performance ,stability and response speed weight After obtaining the weights, a final consistency check is performed; first, the largest eigenvalue is calculated. : in, This represents the number of dimensions, which is the same as the number of rows and columns in the judgment matrix. Represents the judgment matrix and the standardized weights After multiplying, sum the results row by row; to obtain the final value. The value is obtained by solving the consistency index formula. Find the consistency index The value; obtained through the number of dimensions. Value, calculate the consistency ratio To obtain the consistency ratio If the consistency ratio is less than 0.10, the matrix is ​​considered to have satisfactory consistency; therefore, the matrix is ​​judged to have satisfactory consistency, and the consistency test result is "passed". Based on the calculated comprehensive average trust value Overall performance ,stability and response speed The weights, and the matrix formed by the original evaluation data of each node, are as follows: The matrix composed of the original evaluation data has one row for each node. Each data point in the matrix undergoes a positive transformation process, converting all non-maximum indicators into maximum indicators. The transformation method is as follows: Standardize the normalized matrix using the following transformation method: ; Define the maximum value of the indicator and minimum value , represented as: Definition of the first Distance between each evaluation node and the maximum value The distance from the minimum value is , represented as: Then, based on the distance between the evaluation node and the maximum and minimum values, calculate the evaluation for each evaluation node. , represented as: ； Step 2.2, Design the local density of nodes After completing one round of node evaluation updates using the node evaluation scheme designed in step 2.1, at a specific moment, the number of nodes within a network coverage area is: The clustering objective is to divide into Group of nodes, any one of the nodes The evaluation is Two-dimensional coordinates nodes to two-dimensional coordinates nodes distance Calculated using the Euclidean distance formula, defined as follows: Introducing the local density function of nodes The density of data points surrounding a node is calculated as follows: in, It is a node To the node distance, It is a parameter that controls the range of local density calculation. As the value of the exponent increases, it gets closer to 1, making the calculation of local density smoother. As density increases, the distinguishability of local density decreases, and the density difference between different regions diminishes. Step 2.3, based on the node evaluation scheme designed in Step 2.1 and the node local density designed in Step 2.2, the specific process of designing the improved K-Medoids clustering algorithm is as follows: Step 2.3.1, determine the first cluster center. Given the current evaluation set of nodes in the heterogeneous network domain. ,in Represents a node The evaluation, for the evaluation set Sort the nodes in descending order to obtain the sorted set of nodes. ,satisfy: Select the node with the highest evaluation within the domain. As the first candidate cluster center The local density function is used to check if the local density is greater than the threshold set by the current network. If it satisfies a threshold If the condition is met, then that node is determined as the first cluster center. Otherwise, continue to select the node ranked second in the domain evaluation and repeat the following formula to make judgments until the first cluster center is selected. Step 2.3.2, Determine the next cluster center. Selecting the next cluster center When, the next cluster center point is required. The distance from the already selected center point is relatively far, and the next cluster center point is also relatively far. The node evaluation should be high, and a node clustering comprehensive evaluation function should be defined. as follows: in, This indicates the number of center points that have been selected. It is the set of all points within the domain. It is the set of selected center points, in the calculation It is not necessary to recalculate the center point. These are the weights that control node evaluation and distance in node clustering algorithms. The closer a value is to 1, the more likely it is to select nodes with high evaluations as cluster centers when clustering nodes in the current heterogeneous network; conversely, if... The closer the value is to 0, the more likely it is to choose a point that is farther away as the next cluster center; the next cluster center The selection algorithm is as follows: Select the nodes with the highest overall clustering evaluation from the other nodes that are not central points within the domain. As a candidate node for the next cluster center, check whether it satisfies... If the local density threshold condition is met, then the next cluster center point is determined. If this condition is not met, it means that the candidate node is far away from the surrounding nodes in the current heterogeneous network scenario, and the next candidate cluster center point is selected again by the cluster center point selection algorithm. Step 2.3.3: Assign the remaining nodes to clusters. Once a cluster center point is confirmed, the nodes in the heterogeneous network are assigned to the clusters of the confirmed center point according to the principle of proximity. in, It is a determined center point. The clusters represent all the clusters that are derived from the previous one. Recent remaining nodes A set; Step 2.3.4: Determine the remaining cluster centers and complete the clustering. Repeat steps 2.3.2 and 2.3.3 until the problem is found. Find cluster centers and complete the clustering of all nodes.

4. A blockchain cross-domain identity authentication system for a 6G heterogeneous network scenario based on the method of any one of claims 1 to 3, characterized in that, include: The 6G heterogeneous network cross-domain identity authentication model construction module is used to build a 6G heterogeneous network cross-domain identity authentication model and delineate the roles and responsibilities of each entity in the 6G heterogeneous network scenario. The node clustering module is used to design an improved K-Medoids clustering algorithm based on node evaluation and local node density according to the cross-domain identity authentication model of 6G heterogeneous network, and to cluster nodes in the trust domain of heterogeneous network. The consensus master node and participating node selection mechanism design module of the consensus algorithm TBH-PBFT is used to propose a cross-domain credential issuance scheme architecture based on the K-Medoids improved clustering algorithm based on node evaluation and node local density, and to design the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT. The first-stage consensus process design module of the consensus algorithm TBH-PBFT is used to design the first-stage consensus process of the consensus algorithm TBH-PBFT based on the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT. The second-stage consensus process design module of the consensus algorithm TBH-PBFT is used to implement the first-stage consensus process based on the consensus algorithm TBH-PBFT and design the second-stage consensus process of the consensus algorithm TBH-PBFT, including normal mode and special mode. The blockchain-based cross-domain identity authentication method design module is used to implement the first-stage consensus process and the second-stage consensus process based on the TBH-PBFT consensus algorithm, and to design a blockchain-based cross-domain identity authentication method.

5. A blockchain cross-domain identity authentication device for a 6G heterogeneous network scenario, characterized in that, include: Memory: A computer program for a blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario as described in any one of claims 1-3, which is a computer-readable device; Processor: Used to implement the blockchain cross-domain identity authentication method in any one of claims 1-3 when executing the computer program.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, enables the implementation of the blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario as described in any one of claims 1-3.

Images