Block chain cross-domain identity authentication method, system and device in 6G heterogeneous network scene and medium

Abstract

The invention discloses a block chain cross-domain identity authentication method, system and device in a 6G heterogeneous network scene and a medium. The method comprises the following steps: constructing a 6G heterogeneous network cross-domain identity authentication model; designing a K-Medoids improved clustering algorithm based on node evaluation and node local density; designing a consensus main node and participating node selection mechanism of the consensus algorithm TBH-PBFT; respectively designing a first-stage consensus flow and a second-stage consensus flow of a consensus algorithm TBH-PBFT; designing a cross-domain identity authentication method based on the block chain; the system, the equipment and the medium are used for implementing the method. According to the invention, in the process that the initiating domain and the target domain reach the consensus, the issuing of the user cross-domain certificate is synchronously completed, and meanwhile, the cross-domain identity authentication is efficiently completed on the premise that the requirements of the 6G heterogeneous network on the security and the communication overhead are met.

Description

Technical Field

[0001] The present invention belongs to the technical field of wireless communication, and particularly relates to a blockchain cross-domain identity authentication method, system, device and medium in a 6G heterogeneous network scenario. Background Art

[0002] In recent years, after the establishment of the IMT-2030 (6G) Promotion Group, more and more experts and scholars have begun to explore and promote the development of China's sixth-generation mobile communication technology. The 6G network constructs a "super-dense heterogeneous" three-dimensional coverage system by deeply integrating cellular base stations, massive Internet of Things (IoT) terminals and high-density wireless local area network (WLAN) access points. In the 6G heterogeneous network scenario, user equipment needs to frequently perform cross-network interaction and resource exchange, and faces the following core problems when performing identity authentication:

[0003] 1) Heterogeneous protocol conflicts lead to the break of the trust chain: The cellular network relies on the fifth-generation authentication and key (5G-AKA) protocol to achieve mutual authentication, and complex key negotiation needs to be completed through the home subscriber server (HSS), with strong time-delay sensitivity; The WLAN uses the Extensible Authentication Protocol (EAP), which is incompatible with the cellular network authentication process, and certificate verification needs to be repeated during cross-network handover; IoT devices are limited by resources and only support the lightweight Constrained Application Protocol (CoAP), and cannot be compatible with the strong identity binding mechanism of the cellular network based on the subscriber identity module (SIM), forming a "protocol island".

[0004] 2) Differences in security policies trigger the cask effect: The cellular network requires users and devices to follow the privacy protection policies defined by 3GPP; The open access feature of the WLAN forces the use of a pre-shared key (PSK) to simplify authentication, which is vulnerable to man-in-the-middle attacks; Due to energy consumption limitations, IoT devices often use static keys, which conflict with the dynamic key update strategy of the cellular network and are prone to becoming security weaknesses during cross-network interaction.

[0005] 3) Resource heterogeneity amplifies the contradiction of security overhead: The imbalance of computing power in heterogeneous networks causes user equipment to be forced to degrade the security level during cross-network interaction; The WLAN has storage space limitations and cannot cache a large number of device certificates, resulting in frequent certificate queries to the cellular core network.

[0006] From the strong security requirements of cellular networks to the open access characteristics of WLANs and then to the terminal resource constraints of IoT, these three differential characteristics together constitute the "impossible triangle" of cross-network authentication. The blockchain's security of immutability and distributed trust transfer mechanism precisely provides a key path to cracking this triangle. For the problem of protocol islands, the blockchain provides an adaptable platform for a unified trust anchor, breaking the protocol islands by designing cross-domain consensus protocols and smart contracts. For the problems of security overhead contradictions and limited storage performance, a blockchain architecture is introduced to unify the security identity authentication method, simplify the identity authentication process, and reduce the identity authentication overhead.

[0007] Existing research mainly focuses on applying blockchain technology to device identity authentication in the IoT scenario. Existing related research (K. Deng, Y. Gao, J. Yuan, Z. Hou and X. Li, "A Lightweight and Robust Cross-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. The cross-domain in this research refers to the regions divided due to geographical dispersion; although this research proposed a cross-domain solution, since each region still belongs to the same network structure, it has the drawback of being unable to handle the fusion of different structural heterogeneous networks. In terms of the heterogeneous network scenario, existing related 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.) analyzed the cross-domain identity interoperability issue in the scenario of the 5G and IoT fusion and proposed corresponding extended protocols. In terms of the consensus algorithm, existing research (F. Tang, T. Xu, J. Peng and N. Gan, "TP-PBFT: A Scalable PBFT Based on Threshold Proxy Signature for IoT-Blockchain Applications," IEEE Internet of Things Journal, vol. 11, no. 9, pp. 15434-15449, 2024.) constructed a two-layer PBFT algorithm for IoT blockchain applications; since it only designed a consensus algorithm for the IoT and did not optimize the consensus algorithm process, this research has the drawbacks of a single network structure and high communication overhead.

[0008] In summary, the technical problems existing in the current prior art are as follows:

[0009] (1) The existing identity authentication model is designed for a single network structure and does not consider the scenario of heterogeneous networks. In the future 6G network, there will be a convergence of multiple heterogeneous networks, and a large number of users and devices will access the network in a heterogeneous mode, forming different trust domains. The existing identity authentication model for a single network structure cannot be effectively applied in heterogeneous networks.

[0010] (2) The existing node clustering algorithms K-Medoids and K-Means are vulnerable to extreme points. When clustering, they only consider a single distance factor, and there is a high probability of selecting nodes with low evaluation when choosing the clustering center, so they cannot be directly applied to the complex 6G heterogeneous network scenario.

[0011] (3) The existing consensus algorithm is designed based on the traditional PBFT method, without conducting targeted process design in combination with the actual application scenario, and cannot meet the requirements of 6G network in terms of security and communication overhead.

[0012] (4) The existing cross-domain identity authentication scheme adopts a three-party authentication scheme of "initiator-middle party-target party", and the authentication process is lengthy. Summary of the Invention

[0013] In order to overcome the above-mentioned deficiencies of the prior art, the purpose of the present invention is to provide a blockchain cross-domain identity authentication method, system, device and medium in a 6G heterogeneous network scenario. By introducing a cross-domain and trust management committee, designing a cross-domain identity authentication model, a K-Medoids improved clustering algorithm based on node evaluation and node local density, and a two-stage consensus algorithm combined with BLS threshold signature, the issuance of user cross-domain credentials is synchronously completed during the process of reaching a consensus between the initiating domain and the target domain. In addition, the present invention also designs a cross-domain credential verification scheme with a simplified process to ensure the efficient completion of cross-domain identity authentication on the premise of meeting the requirements of 6G heterogeneous network for security and communication overhead.

[0014] In order to achieve the above purpose, the technical solution adopted by the present invention is:

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

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

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

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

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

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

[0021] Step 6: Based on the first-phase consensus process of the consensus algorithm TBH-PBFT designed in Step 4 and the second-phase consensus process of the consensus algorithm TBH-PBFT designed in Step 5, design a blockchain-based cross-domain identity authentication method.

[0022] Furthermore, the process of Step 1 is as follows:

[0023] Construct a 6G heterogeneous network cross-domain identity authentication model. The trust domains X and Y in the model refer to any two heterogeneous networks, each maintaining a blockchain system within the heterogeneous network; each trust domain contains three roles: the credential issuer (Issuer), the credential verifier (Verifier), and the user (UE); the credential issuer (Issuer) is the core role in the heterogeneous network, responsible for the identity registration of new users or devices within their respective domains and the issuance of credentials within the domain; the credential verifier (Verifier) is the role in the heterogeneous network that has the permission to query the identity information of the user (UE) from the blockchain system; the user (UE) is the direct participant, performing trust evaluation, applying for identity credentials, applying for cross-domain credentials, applying for privacy protection, identity authentication, certificate authentication, and revoking credentials in the 6G heterogeneous network cross-domain identity authentication model;

[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 the core roles in the heterogeneous network, including the base station equipment of the cellular network, the core network equipment of the Internet of Things, and the router equipment of the wireless local area network; the members of the cross-domain and trust management committee maintain the trust management blockchain, and the trust management blockchain is responsible for storing the historical records of node interactions and consensus in the heterogeneous network and maintaining the IPFS network as the storage extension of the trust management blockchain.

[0025] Furthermore, the process of Step 2 is as follows:

[0026] Step 2.1, design a node evaluation scheme

[0027] Define the node evaluation index as the comprehensive average trust value Comprehensive performance Φ i , stability ξ i and response speed υ i , and the definitions and update methods of the four indexes are as follows:

[0028] Comprehensive average trust value Comprehensive average trust value Belongs to the extremely large index, and the comprehensive trust TT i Is based on the point-to-point evaluation between nodes. After clustering nodes in the trust domain, the nodes are divided into different clusters, and the average value of the comprehensive trust values of all other nodes in the cluster for a certain node i is obtained to get the comprehensive average trust value of node i

[0029] Comprehensive performance Φ i : Comprehensive performance Φ i Belongs to the extremely large index, which is determined by the processor performance, memory performance, storage performance and network performance of the actual operating equipment of the node;

[0030] Stability ξ i : Stability ξ i Belongs to the extremely large index, which is determined by the number of times the node participates in the consensus completely; Whenever the node participates in the consensus completely once, the corresponding stability ξ of the node i Increases; The number of times the node participates in the consensus completely within each update interval is recorded as η, and the number of times the node absents halfway during the consensus participation within each update interval is recorded as ∈. The node stability update method is ξ′ i =ξ i +η - θ x ∈, where θ x Is the penalty factor for different heterogeneous networks;

[0031] Response speed υ i : Response speed υ i Belongs to the extremely small index. The response speed is defined as the time required from receiving the consensus proposal to the node making an effective feedback on the proposal, which is obtained by subtracting the timestamps TimeStamp of each time node;

[0032] According to the characteristics of 6G heterogeneous networks and the comprehensive average trust value Comprehensive performance Φ i , stability ξ i and response speed υ i , construct a judgment matrix, and obtain the index weights by the geometric mean method. The formula is as follows:

[0033]

[0034] Among them, aij and a kj are the values corresponding to the rows and columns in the judgment matrix, is to calculate the nth power of the product of each row of the judgment matrix to obtain the comprehensive average trust value Comprehensive performance Φ i , stability ξ i and response speed υ i of the weights ω i , after obtaining the weights, perform the final consistency check; first calculate the maximum eigenvalue λ max :

[0035]

[0036] where n represents the number of dimensions, which is the same as the number of rows and columns of the judgment matrix, and (Aw) i represents the value obtained by multiplying the judgment matrix by the standardized weight W i and then accumulating by rows; after obtaining the λ max value, use the consistency index solution formula to calculate the value of the consistency index CI; obtain the RI value through the number of dimensions, and calculate the consistency ratio CR = CI / RI to obtain the consistency ratio CR value; if the consistency ratio is less than 0.10, it is considered that the matrix has satisfactory consistency; therefore, the judgment matrix has satisfactory consistency, and the consistency check result is "passed";

[0037] According to the calculated comprehensive average trust value Comprehensive performance Φ i , stability ξ i and response speed υ i of the weights, the matrix composed of the original evaluation data of each node is as follows:

[0038]

[0039] where each row of the matrix composed of the original evaluation data is the data of one node. Perform positive normalization on each data in the matrix composed of the original evaluation data, and convert all non-maximum type indicators into maximum type indicators. The conversion method is max(X i ) - X i ; normalize the positively normalized matrix. The conversion method is

[0040] Define the maximum value Z + and the minimum value Z - , expressed as:

[0041] Z + =(max{z 11 ,z 21 ,…,z n1}, …, max{z 14 , z 24 , …, z n4 )

[0042] Z - = (min{z 11 , z 21 , …, z n1}, …, min{z 14 , z 24 , …, z n4 )

[0043] Define the distance between the i-th evaluation node and the maximum value and the distance to the minimum value as Expressed as:

[0044]

[0045] Then, according to the distances between the evaluation nodes and the maximum and minimum values, calculate the evaluation E(p i ) of each evaluation node, expressed as:

[0046]

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

[0048] After completing a round of node evaluation updates through the node evaluation scheme designed in Step 2.1, at a certain specific moment, the number of nodes in a network coverage area is N, and the clustering goal is to divide them into K groups of nodes. The evaluation of any node i is S i , and the distance d(i, j) from the node i with two-dimensional coordinates (x 1 , y 1 ) to the node j with two-dimensional coordinates (x 2 , y 2 ) is calculated by the Euclidean distance formula and defined as follows:

[0049]

[0050] Introduce the local density function ρ(i) of nodes to calculate the density of data points around the nodes. The calculation method is as follows:

[0051]

[0052] where d ij is the distance from node i to node j, and σ is a parameter that controls the range of calculating the local density. When σ is larger, the value of the exponential term is closer to 1, making the calculation of the local density smoother. As σ increases, the discrimination of the local density decreases, and the density difference between different regions decreases;

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

[0054] Step 2.3.1. Determine the first clustering center point O 1

[0055] It is known that the node evaluation set E = {E(p 1 ), E(p 2 ), …, E(p N )} in the current heterogeneous network domain, where E(p i ) represents the evaluation of node p i . Sort the evaluation set E in descending order to obtain the sorted node set Satisfying:

[0056]

[0057] Select the node with the highest evaluation in the domain As the first alternative clustering center point Check its local density through the local density function to be greater than the threshold td set in the current network x , if it meets the condition of being greater than the threshold td x , then determine this node as the first clustering center point O 1 , otherwise continue to select the node ranked second in the domain evaluation, and repeat the following formula for judgment until the first clustering center point is selected;

[0058]

[0059] Step 2.3.2. Determine the next clustering center point

[0060] When selecting the next clustering center point O r+1 , it is required that the next clustering center point O r+1 is far from the already selected center points, and at the same time, the node evaluation of the next clustering center point O r+1 should be relatively high. Define the node clustering comprehensive evaluation function D(p i ) as follows:

[0061]

[0062] Among them, r represents the number of already selected center points, P m = {p 1 , p 2 , …, p N} is the set of all points in the domain, O m = {O 1 , O 2 , …, Or} is the set of selected central points, and there is no need to recalculate the central points when calculating D(p i ). κ is the weight that controls node evaluation and distance in the node clustering algorithm. The closer κ is to 1, the more inclined to select nodes with high evaluation as the clustering central points when performing node clustering in the current heterogeneous network; conversely, if κ is closer to 0, it is more inclined to select points with a longer distance as the next clustering central point; the next clustering central point O r+1 is selected as follows:

[0063]

[0064] Select the node with the highest comprehensive evaluation of node clustering from other non-central points within the domain as the alternative node for the next clustering central point, and check whether it satisfies ρ(O r+1 )≥td x . If the local density threshold condition is satisfied, determine the next clustering central point If this condition is not satisfied, it means that the alternative central point is far from the surrounding nodes in the current heterogeneous network scenario. Select the next alternative clustering central point again through the clustering central point selection algorithm;

[0065] Step 2.3.3, Assign the remaining nodes to the clustering clusters

[0066] After confirming each clustering central point, allocate the nodes in the heterogeneous network to the clustering clusters of the determined central points according to the principle of proximity;

[0067]

[0068] Among them, is the clustering cluster of the determined central point O j , indicating the set of all the remaining nodes p j that are closest to O i ;

[0069] Step 2.3.4, Determine the remaining clustering central points and complete the clustering

[0070] Repeat steps 2.3.2 and 2.3.3 until K clustering central points are found and all nodes are clustered.

[0071] Furthermore, the process of the third step is as follows:

[0072] Multiple trusted domain nodes collaborate in decision-making through the consensus algorithm TBH-PBFT to determine whether to issue cross-domain credentials to users (UEs) or devices in a heterogeneous network; before selecting consensus nodes and the primary node, Trust Domain X has completed node clustering based on node scores, and within each cluster, a strong node set, a candidate node set, and a weak node set are defined in descending order of node evaluation. Candidate node set Weak node set Among them, the total number of strong nodes is K, and the cluster centers finally determined by the clustering serve as the strong nodes; the candidate nodes are the two nodes with the highest scores among the nodes other than the strong nodes in each cluster, with a total number of 2K. The candidate nodes are responsible for participating in the first-phase consensus process of the consensus algorithm TBH-PBFT and serving as candidates for strong nodes in the second-phase consensus process of the consensus algorithm TBH-PBFT; the weak nodes are the remaining nodes in the cluster, with a number of N - 3K, and are responsible for participating in the first-phase consensus process of the consensus algorithm TBH-PBFT; the consensus primary node and participating nodes of the consensus algorithm TBH-PBFT are selected from the initiating domain X, the target domain Y, and the remaining trust domain Z. The nodes participating in the first-phase consensus process of the consensus algorithm TBH-PBFT come from the cluster where the node applying for the cross-domain credential is located. Half of the nodes participating in the first-phase consensus process of the consensus algorithm TBH-PBFT come from the initiating domain X, and the other half come from the target domain Y, and are selected by random sampling; in both phases of the consensus, nodes from the trust domain Z record the entire consensus process as observing nodes.

[0073] Furthermore, the process of step 4 is as follows:

[0074] Based on the PBFT algorithm, combined with distributed key generation (DKG) and BLS threshold signature technology, the consensus algorithm TBH-PBFT is designed. The first-phase consensus process of the consensus algorithm TBH-PBFT is as follows:

[0075] Step 4.1, Request phase

[0076] The client represented by the user (UE) sends a request to the primary node The message content is <REQUEST, m, ts, c>, where REQUEST is the request phase identifier, m is the content of this consensus vote, ts represents the timestamp, and c is the client identifier;

[0077] The primary node Determines the scale of this round of consensus according to the current clustering situation. The scale of the first-phase consensus of the consensus algorithm TBH-PBFT is n 1 , and the scale of the second-phase consensus of the consensus algorithm TBH-PBFT is n 2 , and determines the two-phase voting passing thresholds respectively as and Primary node Initialize the parameters related to the BLS threshold signature. By importing the elliptic curve E p The pairing parameters generated by (a, b) where G 1 is a cyclic subgroup on the elliptic curve, is an integer cyclic group, r is a large prime number, and g is a generator of G 1 ;

[0078] Primary node Send a preview message to the strong nodes participating in the second-phase consensus process of the consensus algorithm TBH-PBFT. Its format is:

[0079]

[0080] where SEC-PRE is the identifier of the second-phase consensus preview message of the consensus algorithm TBH-PBFT, ts′ represents the latest timestamp, and s is the primary node identifier;

[0081] Primary node At the same time, send the basic information <RECORD-START, c, s, ts′> of this round of consensus to the record nodes in the third trust domain to record the entire consensus process of the blockchain system;

[0082] Step 4.2, Pre-prepare link

[0083] Primary node Randomly generate a set of coefficients a = {a 0 , a 1 , …, a t-1} and a set of commitment sets Use the coefficients a to generate a polynomial of degree t - 1:

[0084] f i (x) = a 0 + a 1 * x + … + a t-1 * x t-1

[0085] where a 0 is the secret of node i, and the variable x of the polynomial represents a random number determined by the members. After completing the preparation work in the pre-prepare stage, the primary node Broadcast a message within the initiating domain X. Its content is:

[0086]

[0087] where PRE-PREPARE is the identifier of the pre-prepare link, is the asymmetric encryption information contained in the broadcast message, indicating that after node i generates the value of the polynomial with node number j, the value is encrypted by the public key of node j; v is the view number, n is the sequence number, and d is the message digest; the remaining nodes that receive the broadcast message verify the signature σ i The validity of the query is checked to determine whether the current view is v, whether the sequence number n is within the valid range, and whether the request with the same n has not been processed in view v. Finally, the value of hash(m) is verified to be the same as the digest d.

[0088] Step 4.3, Preparation

[0089] Alternative Node Weak Node and Receive and verify the master node After the message is received, the master node in the pre-preparation phase is executed. The same operation is used to generate a private key and construct a t-1 degree polynomial, assign values ​​to the polynomial and perform asymmetric encryption. Spliced ​​into the broadcast message, the specific content is:

[0090]

[0091] Among them, PREPARE is the identifier of the preparation phase. The node collects the broadcast message of the preparation phase and then checks the signature σ i The validity of v, n, d is verified to be consistent with the locally stored pre-prepared message; at this time, each first-stage consensus member sends the encrypted polynomial parameter f to other members i (j), each member also receives n from other members 1 - 1 polynomial parameter;

[0092] The polynomial parameter verification process is:

[0093] (1) Member j receives the polynomial parameter fragment f sent by other member i via asymmetric encryption i (j) and public commitment collection

[0094] (2) Member j uses the formula Calculate the total value of the commitments received;

[0095] (3) Member j passes the verification equation Whether it is established, the polynomial parameter verification result is obtained. If the equation is established, the polynomial parameters received by member j are correct;

[0096] Weak nodes in the first phase of the consensus process of the consensus algorithm TBH-PBFT Is a Byzantine node, if the weak node During the consensus process, deliberately send incorrect information and verify the correctness of polynomial parameters through the polynomial parameter verification algorithm; if a weak node Refuse to participate at a specific time, the primary node Supplement a set of polynomial parameters at the end of the preparation phase;

[0097] Step 4.4, Submission phase

[0098] All consensus nodes independently judge the information of the user (UE) applying for a cross-domain credential in the message m, complete the voting through the BLS threshold signature method, and send the result to the primary node Finally, the primary node aggregates the signature information and judges the voting result;

[0099] Each consensus node queries the comprehensive trust value and historical interaction records of the user (UE) applying for a cross-domain credential through cross-domain and the trust management committee, casts a vote of approval or disapproval. The two voting results vote are respectively described as Agree and Disagree in a consistent manner, calculate the mapping H(vote) of its hash value on the elliptic curve, and each node generates a partial signature through the received polynomial parameters:

[0100]

[0101] Put the calculated signature into the submission message, and the specific content is where COMMIT is the identifier of the submission phase, and the primary node obtains the voting result by verifying whether the bilinear pairing function holds;

[0102]

[0103] Among them, PK is the system public key, which is obtained by operating the sum of the first terms a 0 of the polynomials of each member with the generator g t ; ThresholdSig is the complete signature recovered by interpolation:

[0104]

[0105] Among them, λ i is the Lagrange coefficient, and the complete signature ThresholdSig is the linear combination result of the partial signatures sig i of each member.

[0106] Furthermore, the process of the fifth step is as follows:

[0107] The consensus algorithm TBH-PBFT second-phase consensus process, where the participating nodes are all strong nodes, respectively from the initiating domain X and the target domain Y. The preparation link in the second-phase process of the consensus algorithm TBH-PBFT in normal mode is the same as the preparation link in the first-phase consensus process of the consensus algorithm TBH-PBFT;

[0108] Step 5.1, design the normal mode of the consensus algorithm TBH-PBFT second-phase consensus process

[0109] a) Pre-preparation link

[0110] After the first-phase consensus process of the consensus algorithm TBH-PBFT ends, the primary node sends the second-phase consensus parameters and results to the recording nodes in the pre-preparation link of the second-phase consensus process of the consensus algorithm TBH-PBFT. The recording nodes are committee nodes from a third-party trusted domain, with the permission to access the historical data of the trusted management blockchain and package blocks onto the chain. The recording nodes store the consensus results on the chain for evidence, and the evidence records include information about the consensus participating nodes, the complete list of participating consensus nodes, and the list of malicious nodes;

[0111] b) Submission link

[0112] The voting content changes from Agree / Disagree to m(user) / Disagree, where m(user) is the user (UE) identity information in the voting content m. In the second-phase consensus, if a strong node agrees to issue a cross-domain credential for this user (UE), a partial signature σ is generated for the user (UE)'s identity information; i , if not, a partial signature is generated for the message Disagree; in the submission link of the first-phase consensus of the consensus algorithm TBH-PBFT, weak nodes and alternate nodes send the generated partial signatures point-to-point to the primary node. In the second-phase consensus of the consensus algorithm TBH-PBFT, all participating consensus nodes are strong nodes. Each member broadcasts its own partial signature, simultaneously receives the partial signatures of other members, and independently recovers the complete signature to judge the voting result;

[0113] c) Verification link and reply link

[0114] Other members except the primary node feedback their respective judgment results to the primary node. If the number of those who agree to issue reaches then it is finally determined to agree to issue a cross-domain credential for this user (UE); enter the next reply link, and the primary node signs the information m(user) of the user (UE)'s identity to obtain the cross-domain credential <m(user)> ThresholdSig, send the cross - domain credential to the user (UE), and send the consensus parameters and results of the second phase of the consensus algorithm TBH - PBFT and the cross - domain credential to the recording node, and the recording node completes the on - chain of the consensus result and the user (UE)'s cross - domain credential;

[0115] Step 5.2, design a special mode for the consensus process of the second phase of the consensus algorithm TBH - PBFT

[0116] In the special mode, after the preparation phase ends, if the strong node m(user) crashes and disconnects, and the primary node does not receive 2f + 1 replies in the commit phase, and after the timeout threshold set by the system the node still does not go online to respond, then it switches from the normal mode to the special mode, and successively performs the alternate and resubmission links. The process of the resubmission link is the same as that of the commit link in the normal mode, and the participating roles are changed from the primary node and strong nodes to the primary node, strong nodes and substitute nodes. The process of the alternate link is as follows:

[0117] The work of the alternate link is to confirm the substitute nodes participating in the consensus, re - execute the distributed key generation. If the primary node and the strong nodes do not receive 2f + 1 replies within the timeout threshold, they respectively query the substitute nodes with the highest comprehensive evaluation and idle status in their respective clusters in the trust management blockchain and send point - to - point encrypted information transmissions to the substitute nodes and respectively, and send the parameters of DKG to the substitute nodes. The format of the alternate request is:

[0118]

[0119] Among them, means that after node i generates the value of the polynomial with the number z of the substitute node, it encrypts this value with the public key of node z; after the substitute node receives the message from the primary node , it executes polynomial and commitment generation, and sends the secret shard to the other nodes; after the other online nodes receive the information from the substitute node , they verify the shard parameter f z (i) through the polynomial parameter verification algorithm.

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

[0121] Step 6.1: The user (UE) sends a cross - domain verification request to the verifier within the local trust domain X. The request contains the identifier of the user (UE) and the cross - domain credential;

[0122] Step 6.2: The Verifier is a node in the trusted domain that has the permission to query the blockchain. 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;

[0123] Step 6.3: After completing the verification of the user (UE)'s request in Step 6.2, the Verifier obtains the user (UE)'s identity information from the request and verifies whether the user (UE) is a registered legitimate user in the blockchain system of the trusted domain X;

[0124] 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 the cross-domain credential in the user (UE)'s request is parsed out, signed with the private key, and forwarded to the cross-domain and cross-domain and trust management committee members of the local trusted domain X;

[0125] Step 6.5: The cross-domain and trust management committee members have the permission to access the cross-domain trust management chain. After receiving the request sent by the Verifier in Step 6.4, the cross-domain and trust management committee members verify the legitimacy of the request and the correctness of the Verifier's signature;

[0126] Step 6.6: If both the request sent by the Verifier in Step 6.5 and the Verifier's signature pass the verification, then the cross-domain and trust management committee members send a request for cross-domain credential verification parameters to the cross-domain trust management blockchain node;

[0127] 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;

[0128] Step 6.8: The InterPlanetary File System IPFS obtains the verification parameters according to the query parameters request in Step 6.7, including the generator g, the system public key PK, and the hash H(m(user)) of the user (UE)'s identity credential, and returns the verification parameters to the cross-domain and trust management committee members;

[0129] Step 6.9: The cross-domain and trust management committee members obtain the BLS threshold signature ThresholdSig of the user (UE)'s cross-domain credential from the request sent by the Verifier in Step 6.4, and execute the bilinear pairing function through the verification parameters returned in Step 6.8 to verify the correctness of the threshold signature and judge the legitimacy of the user (UE)'s cross-domain credential;

[0130] Step 6.10: The members of the cross-domain and trust management committee return the verification result obtained in Step 6.9 to the credential verifier (Verifier) and the user (UE), completing the cross-domain credential verification.

[0131] The present invention also provides a blockchain cross-domain identity authentication system in a 6G heterogeneous network scenario, including:

[0132] A 6G heterogeneous network cross-domain identity authentication model construction module, used to construct a 6G heterogeneous network cross-domain identity authentication model and divide the roles and corresponding responsibilities of each entity in the 6G heterogeneous network scenario;

[0133] A node clustering module, used to design an improved K-Medoids clustering algorithm based on node evaluation and node local density according to the 6G heterogeneous network cross-domain identity authentication model, and cluster the nodes within the heterogeneous network trust domain;

[0134] A consensus main node and participating node selection mechanism design module for the consensus algorithm TBH-PBFT, used to propose a cross-domain credential issuance scheme architecture and design a consensus main node and participating node selection mechanism for the consensus algorithm TBH-PBFT according to the improved K-Medoids clustering algorithm based on node evaluation and node local density;

[0135] A first-stage consensus process design module for the consensus algorithm TBH-PBFT, used to design the first-stage consensus process of the consensus algorithm TBH-PBFT according to the consensus main node and participating node selection mechanism of the consensus algorithm TBH-PBFT;

[0136] A second-stage consensus process design module for the consensus algorithm TBH-PBFT, used to implement the first-stage consensus process of the consensus algorithm TBH-PBFT and design the second-stage consensus process of the consensus algorithm TBH-PBFT, including normal mode and special mode;

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

[0138] The present invention also provides a blockchain cross-domain identity authentication device in a 6G heterogeneous network scenario, including:

[0139] A memory: storing a computer program of the above-mentioned blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario, which is a computer-readable device;

[0140] A processor: used to implement the above-mentioned blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario when executing the computer program.

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

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

[0143] 1. Through the 6G heterogeneous network cross-domain identity authentication model designed in step one, the present invention defines the responsibilities of entities in different heterogeneous networks, classifies them into three roles: credential issuer (Issuer), credential verifier (Verifier), and user (UE), designs a cross-domain and trust management committee composed of core roles in 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, which is effectively applicable to the scenario of heterogeneous network fusion identity authentication in 6G.

[0144] 2. Through the improved K-Medoids clustering algorithm based on node evaluation and node local density designed in step two, the present invention designs a method for calculating the data density around nodes. By introducing the local density range control parameter σ, it has the ability to adapt to the distribution characteristics of different heterogeneous network nodes. The improved clustering algorithm can select nodes with high comprehensive evaluation and large local density as clustering centers, and has a good clustering effect in heterogeneous network scenarios with different distribution characteristics.

[0145] 3. Through the consensus primary node and participating node selection mechanism of the consensus algorithm TBH-PBFT designed in step three, the present invention can divide the nodes within 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 appropriate nodes as the primary node and participating nodes of the two-stage consensus algorithm, which can give full play to the advantages of each node and improve the fault tolerance of the consensus algorithm.

[0146] 4. Through the first-stage consensus process of the consensus algorithm TBH-PBFT designed in step four, by combining the cryptographic BLS threshold signature method, the present invention can achieve node consensus within the initiating domain, with lower communication overhead.

[0147] 5. Through the normal mode of the second-stage consensus process of the consensus algorithm TBH-PBFT designed in step five, the present invention integrates the cross-domain strong node consensus voting and cross-chain credential issuance into the same process, without repeatedly allocating resources for two independent processes, and can optimize the data coherence in the cross-domain identity credential issuance process.

[0148] 6. Through the special mode of the second-phase consensus process of the consensus algorithm TBH-PBFT designed in step five, the present invention adds two links of candidate and resubmission, which can increase the decision success rate of cross-domain credential issuance in the case of node downtime and disconnection, and has the ability to quickly resume normal consensus.

[0149] 7. By introducing the cross-domain and trust management committee nodes of the third-party trust domain as recording nodes in step five, the present invention can package and upload the key parameters and node performance in the consensus algorithm TBH-PBFT to the blockchain, enhancing data credibility and immutability.

[0150] 8. Through the blockchain-based cross-domain identity authentication method designed in step six, combining the cross-domain and trust management committee mechanism and blockchain technology, the present invention can simplify the credential verification into a two-party verification scheme of "initiator - committee", reducing the complexity of the identity authentication process and alleviating the system load.

[0151] In summary, by constructing a 6G heterogeneous network cross-domain identity authentication model and designing an improved K-Medoids clustering algorithm based on node evaluation and node local density, the present invention has the advantage of adapting to the distribution characteristics of different heterogeneous network nodes. By designing the consensus algorithm TBH-PBFT through the consensus master node and participating node selection mechanism, it has the advantages of improving the consensus fault tolerance ability and reducing communication overhead. By constructing a two-party verification mechanism through the blockchain-based cross-domain identity authentication method, it has the advantages of reducing system complexity and load. BRIEF DESCRIPTION OF THE DRAWINGS

[0152] Figure 1 is the flow chart of the implementation method of the present invention.

[0153] Figure 2 is the cross-domain identity authentication model diagram of the 6G heterogeneous network provided by the embodiment of the present invention.

[0154] Figure 3 is the judgment matrix for constructing node evaluation indexes provided by the embodiment of the present invention.

[0155] Figure 4 is the schematic diagram of the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT provided by the embodiment of the present invention.

[0156] Figure 5 is the normal mode flow chart of the first-phase consensus process of the consensus algorithm TBH-PBFT and the second-phase consensus process of the consensus algorithm TBH-PBFT provided by the embodiment of the present invention.

[0157] Figure 6 is the special mode flow chart of the second-phase consensus process of the consensus algorithm TBH-PBFT provided by the embodiment of the present invention.

[0158] Figure 7 It is a flowchart of a cross - domain identity authentication method based on blockchain provided by an embodiment of the present invention.

[0159] Figure 8 It is a local density comparison graph under different parameters σ provided by an embodiment of the present invention, where Figure 8 (a) is the local density comparison graph with the parameter σ value of 5, Figure 8 (b) is the local density comparison graph with the parameter σ value of 10, Figure 8 (c) is the local density comparison graph with the parameter σ value of 15.

[0160] Figure 9 It is a comparison graph of the improved K - Medoids clustering algorithm based on node evaluation and node local density with the traditional result in the cellular network scenario provided by an embodiment of the present invention, where Figure 9 (a) is the clustering result graph of the traditional K - Medoids algorithm in the cellular network scenario, Figure 9 (b) is the clustering result graph of the improved K - Medoids clustering algorithm based on node evaluation and node local density of the present invention in the cellular network scenario.

[0161] Figure 10 It is a comparison graph of the improved K - Medoids clustering algorithm based on node evaluation and node local density with the traditional result in the wireless local area network scenario provided by an embodiment of the present invention, where Figure 10 (a) is the clustering result graph of the traditional K - Medoids algorithm in the wireless local area network scenario, Figure 10 (b) is the clustering result graph of the improved K - Medoids clustering algorithm based on node evaluation and node local density of the present invention in the wireless local area network scenario.

[0162] Figure 11 It is a comparison graph of the communication overhead between the consensus algorithm TBH - PBFT and other consensus algorithms provided by an embodiment of the present invention, where Figure 11 (a) is the comparison graph of the communication overhead between the consensus algorithm TBH - PBFT and other consensus algorithms when the number of groups k is 5, Figure 11 (b) is the comparison graph of the communication overhead between the consensus algorithm TBH - PBFT and other consensus algorithms when the number of groups k is 7, Figure 11 (c) is the comparison graph of the communication overhead between the consensus algorithm TBH - PBFT and other consensus algorithms when the number of groups k is 9. Detailed implementation manners

[0163] The present invention will be further described below in conjunction with the accompanying drawings and specific embodiments.

[0164] Aiming at the cross - domain identity interoperability authentication problem in the heterogeneous network scenario of the sixth - generation mobile communication technology (6G), the present invention studies a heterogeneous network scenario composed of a cellular network, a wireless local area network, and the Internet of Things, designs a method for issuing and verifying user cross - domain identity credentials, and realizes the interoperable verification of user identities in different heterogeneous networks. Aiming at the problem of non - interoperability of different heterogeneous network authentication protocols, the present invention designs a 6G heterogeneous network cross - domain identity authentication model and introduces a cross - domain and trust management committee to assist in cross - domain operations. Using the characteristics of the consortium blockchain system, a two - stage consensus algorithm combined with BLS threshold signature is designed to complete cross - domain credential issuance. The communication overhead problem of the traditional Practical Byzantine Fault Tolerance Consensus (PBFT) is solved by an improved node clustering algorithm. The present invention also designs a clustering center node selection mechanism by considering both node evaluation and node distance factors, avoiding extreme cases where the evaluation of the central node is too low or the distance from other nodes is too far, and is applicable to heterogeneous network scenarios with different node distribution characteristics. In addition, the present invention also designs a cross - domain credential verification method based on blockchain to simplify the verification process.

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

[0166] Step 1: Construct a 6G heterogeneous network cross - domain identity authentication model and divide the roles and corresponding responsibilities of each entity in the 6G heterogeneous network scenario;

[0167] Further, as Figure 2 shown, the process of Step 1 is as follows:

[0168] Construct a 6G heterogeneous network cross - domain identity authentication model. The trust domains X and Y in the model refer to any two heterogeneous networks, each maintaining a blockchain system within the heterogeneous network; each trust domain contains three roles: the credential issuer (Issuer), the credential verifier (Verifier), and the user (UE); the credential issuer (Issuer) is the core role in the heterogeneous network, responsible for the identity registration of new users or devices within their respective domains and the issuance of in - domain credentials; the credential verifier (Verifier) is the role in the heterogeneous network that has the permission to query the identity information of the user (UE) from the blockchain system; the user (UE) is the direct participant, performing trust evaluation, applying for identity credentials, applying for cross - domain credentials, applying for privacy protection, identity authentication, certificate authentication, and revoking credentials in the 6G heterogeneous network cross - domain identity authentication model.

[0169] 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 the core roles in the heterogeneous network, including the base station equipment of the cellular network, the core network equipment of the Internet of Things, and the router equipment of the wireless local area network. The members of the cross-domain and trust management committee maintain a trust management blockchain, which is responsible for storing the historical records of node interactions and consensus in the heterogeneous network, providing reliable data support for cross-domain credential issuance and verification. The members of the cross-domain and trust management committee are also responsible for maintaining the IPFS network as a storage extension of the trust management blockchain.

[0170] Step 2: According to 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 node local density to cluster the nodes within the heterogeneous network trust domain.

[0171] Furthermore, the process of Step 2 is as follows:

[0172] In the 6G heterogeneous network scenario, each node is endowed with rich behaviors and attributes, dynamically affecting the evaluation of each node. The nodes selected as the clustering center points have a high evaluation and participate in the consensus stage of cross-domain credential issuance. If only the distance factor is considered during node clustering, there will be a situation where nodes with a lower evaluation are selected as the clustering center. If only the node evaluation factor is considered, there will be problems such as poor clustering effect and too large distance between nodes within the cluster, increasing the communication delay of the system. An improved K-Medoids clustering algorithm based on node evaluation and node local density is proposed to cluster the nodes within the domain, reducing the number of nodes that need to be considered simultaneously during the consensus process of the blockchain system, improving the efficiency of node consensus, and reducing the complexity of the system.

[0173] Step 2.1, design a node evaluation scheme

[0174] Define the node evaluation index as the comprehensive average trust value Comprehensive performance Φ i 、Stability ξ i And response speed υ i , the definitions and update methods of the four indexes are as follows:

[0175] Comprehensive average trust value Comprehensive average trust value Belongs to an extremely large index. The comprehensive trust TT i Is based on the point-to-point evaluation between nodes. After clustering the nodes in the trust domain, the nodes are divided into different clusters. Assume that there are N nodes in the current trust domain, which are divided into K groups through node clustering, and there are Nodes in each cluster, where each node has both a comprehensive trust value for other Nodes, and there are also other The comprehensive trust value of a node is averaged over the comprehensive trust values of all other nodes in the cluster for a certain node i to obtain the comprehensive average trust value of node i.

[0176] Comprehensive performance Φ i : Comprehensive performance Φ i Belongs to an extremely large type of index, which is determined by the processor performance, memory performance, storage performance, and network performance of the actual operating devices of the node; the comprehensive performance of the node is fixed at most times, and the specific measurement indicators can be quantified; that is, the greater the comprehensive performance, the more contribution to the node evaluation.

[0177] Stability ξ i : Stability ξ i Belongs to an extremely large type of index, which is determined by the number of times the node fully participates in the consensus; every time the node fully participates in a consensus, the corresponding stability ξ of the node i Increases; the number of times the node fully participates in the consensus within each update interval is denoted as η. If the node goes offline, such as crashing, during the process of participating in the consensus, its stability parameter will decrease. The number of times the node absents midway during participating in the consensus within each update interval is denoted as ∈, and the node stability update method is ξ′ i = ξ i + η - θ x ∈, where θ x is the penalty factor for different heterogeneous networks;

[0178] Response speed υ i : Response speed υ i Belongs to an extremely small type of index. The response speed is defined as the time required from receiving the consensus proposal to the node making an effective feedback on the proposal, which is obtained by subtracting the timestamps TimeStamp of each time node;

[0179] Such as Figure 3 shown, according to the characteristics of the 6G heterogeneous network and the comprehensive average trust value Comprehensive performance Φ i 、Stability ξ i and response speed υ i , construct a judgment matrix, and obtain the index weights through the geometric mean method. The formula is as follows:

[0180]

[0181] Among them, a ij and a kj are the values corresponding to the rows and columns in the judgment matrix, is the nth power of calculating the product of each row of the judgment matrix to obtain the comprehensive average trust value Comprehensive performance Φ i 、Stability ξ iand the response speed υ i weights ω i , which are 0.497, 0.108, 0.228, and 0.166 respectively. Among them, the weight of the comprehensive trust value of the node is the largest, and the weight of the comprehensive performance is the smallest. After obtaining the weights, a final consistency check is required. First, calculate the maximum eigenvalue λ max :

[0182]

[0183] where n represents the number of dimensions, which is the same as the number of rows and columns of the judgment matrix. (Aw) i represents the value obtained by multiplying the judgment matrix by the normalized weight W i and then accumulating by row; after obtaining λ max , the value is 4.11. Through the consistency index solution formula , the value of the consistency index CI is 0.035; through the number of dimensions, the RI value is 0.92. Calculate the consistency ratio CR = CI / RI, and the value of the consistency ratio CR is 0.038; if the consistency ratio is less than 0.10, it is considered that the matrix has satisfactory consistency; therefore, the judgment matrix has satisfactory consistency, and the consistency check result is "passed";

[0184] According to the calculated comprehensive average trust value Comprehensive performance Φ i , stability ξ i and the response speed υ i weights, the matrix composed of the original evaluation data of each node is as follows:

[0185]

[0186] where each row of the matrix composed of the original evaluation data is the data of a node. The next step is to perform positive normalization on each data in the matrix composed of the original evaluation data, convert all non-maximum type indicators into maximum type indicators, and the conversion method is max(X i ) - X i ; further standardize the matrix that has been positively normalized, and the conversion method is

[0187] Define the maximum value Z + and the minimum value Z - , expressed as:

[0188] Z + =(max{z 11 ,z 21 ,…,z n1},…,max{z 14 ,z 24 ,…,zn4 )

[0189] z - = (min{z 11 , z 21 , …, z n1}, …, min{z 14 , z 24 , …, z n4 )

[0190] Define the distance between the i-th evaluation node and the maximum value And the distance from the minimum value is Expressed as:

[0191]

[0192]

[0193] Then, according to the distances of the evaluation nodes from the maximum and minimum values, calculate the evaluation E(p i ) of each evaluation node, expressed as:

[0194]

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

[0196] After completing a round of node evaluation and update through the node evaluation scheme designed in Step 2.1, at a certain specific moment, the number of nodes in a network coverage area is N, and the clustering goal is to divide them into K groups of nodes. The evaluation of any node i is S i , and the distance d(i, j) from the node i with two-dimensional coordinates (x 1 , y 1 ) to the node j with two-dimensional coordinates (x 2 , y 2 ) is calculated by the Euclidean distance formula, defined as follows:

[0197]

[0198] To exclude the adverse effects of extreme nodes on the selection of the center point of the clustering algorithm, introduce the node local density function ρ(i) to calculate the density of data points around the node. The calculation method is as follows:

[0199]

[0200] Among them, d ijis the distance from node i to node j, and σ is a parameter that controls the range of local density calculation. When σ is larger, the value of the exponential term is closer to 1, making the calculation of local density smoother, having a greater impact on distant points, and more neighbor nodes are considered; however, as σ increases, the discrimination of local density decreases, and the density difference between different regions decreases;

[0201] In the 6G heterogeneous network scenario, there are multiple heterogeneous networks in the same area. Nodes in heterogeneous networks have different location characteristics. In the area covered by a wireless local area network, nodes are usually distributed in the form of high-density clusters. In the area covered by a cellular network, the distribution of nodes is more uniform and random. By introducing the local density range control parameter σ and adjusting the size of the σ parameter according to the characteristics of the heterogeneous network, it can be more flexibly applied in different heterogeneous networks to optimize the selection of clustering center nodes.

[0202] 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 the improved K-Medoids clustering algorithm is as follows:

[0203] Step 2.3.1, determine the first clustering center point O 1

[0204] Given the current node evaluation set E = {E(p 1 ), E(p 2 ), …, E(p N )} in the heterogeneous network domain, where E(p i ) represents the evaluation of node p i . Sort the evaluation set E in descending order to obtain the sorted node set Satisfy:

[0205]

[0206] Select the node with the highest evaluation in the domain as the first alternative clustering center point Check its local density through the local density function to be greater than the threshold td set by the current network x , if it meets the condition of being greater than the threshold td x , then determine this node as the first clustering center point O 1 , otherwise continue to select the node ranked second in the domain evaluation, and repeat the following formula for judgment until the first clustering center point is selected;

[0207]

[0208] Step 2.3.2, determine the next clustering center point

[0209] Except for the first clustering center point O1 In addition, when selecting the remaining central points, two factors, namely node distance and node score, need to be considered simultaneously. Therefore, when selecting the next clustering center point O r+1 , it is required that the next clustering center point O r+1 is far from the selected center points. At the same time, the node evaluation of the next clustering center point O r+1 should be relatively high. Define the node clustering comprehensive evaluation function D(p i ) as follows:

[0210]

[0211] where r represents the number of selected center points, P m = {p 1 , p 2 , …, p N} is the set of all points in the domain, O m = {O 1 , O 2 , …, O r} is the set of selected center points. When calculating D(p i ), there is no need to recalculate the center points. κ is the weight in the node clustering algorithm that controls node evaluation and distance. The closer κ is to 1, the more inclined to select nodes with high evaluation as clustering center points when performing node clustering in the current heterogeneous network; conversely, if κ is closer to 0, it is more inclined to select points with a relatively large distance as the next clustering center point. The selection algorithm for the next clustering center point O r+1 is as follows:

[0212]

[0213] Select the node with the highest node clustering comprehensive evaluation from the other non-center-point nodes in the domain as the alternative node for the next clustering center point, and check whether it satisfies ρ(O r+1 ) ≥ td x . If the local density threshold condition is satisfied, determine the next clustering center point If this condition is not satisfied, it means that the alternative center point is far from the surrounding nodes in the current heterogeneous network scenario. Re-select the next alternative clustering center point through the clustering center point selection algorithm;

[0214] Step 2.3.3, Assign the remaining nodes to the clustering clusters

[0215] After confirming each clustering center point, assign the nodes in the heterogeneous network to the clustering clusters of the determined center points according to the principle of proximity;

[0216]

[0217] Among them, is the determined center point O j of the clustering cluster, representing all the remaining nodes p j nearest to O i in the set;

[0218] Step 2.3.4, determine the remaining clustering center points and complete the clustering

[0219] Repeat Step 2.3.2 and Step 2.3.3 until K clustering center points are found and the clustering of all nodes is completed.

[0220] Step 3: According to the improved K-Medoids clustering algorithm based on node evaluation and node local density designed in Step 2, propose a cross-domain credential issuance scheme architecture, and design a selection mechanism for the consensus master node and participating nodes of the consensus algorithm TBH-PBFT;

[0221] Furthermore, as Figure 4 shown, the process of Step 3 is as follows:

[0222] Multi-trust domain nodes make collaborative decisions through the consensus algorithm TBH-PBFT to determine whether to issue cross-domain credentials to users (UEs) or devices in heterogeneous networks; before selecting participating consensus nodes and the primary node, trust domain X has completed node clustering based on node scoring, and within each cluster, a strong node set candidate node set weak node set are defined in descending order of node evaluation. The total number of strong nodes is K, and the clustering centers finally determined by the clustering are responsible for the duties of strong nodes; candidate nodes are served by the two nodes with the highest scores among the nodes other than strong nodes in each cluster, and the total number is 2K. Candidate nodes are responsible for participating in the first-stage consensus process of the consensus algorithm TBH-PBFT and serving as alternatives for strong nodes in the second-stage consensus process of the consensus algorithm TBH-PBFT; weak nodes are the remaining nodes in the cluster, with a number of N - 3K, and are responsible for participating in the first-stage consensus process of the consensus algorithm TBH-PBFT; the consensus master node and participating nodes of the consensus algorithm TBH-PBFT are selected from the initiating domain X, target domain Y, and the remaining trust domain Z. The nodes participating in the first-stage consensus process of the consensus algorithm TBH-PBFT come from the cluster where the node applying for cross-domain credentials is located. Half of the nodes participating in the first-stage consensus process of the consensus algorithm TBH-PBFT come from the initiating domain X, and the other half come from the target domain Y, and are selected by random sampling; in both stages of the consensus, nodes from trust domain Z record the entire consensus process as observing nodes.

[0223] Step 4: Design the first-phase consensus process of the consensus algorithm TBH-PBFT according to the consensus primary node and participating node selection mechanism of the consensus algorithm TBH-PBFT designed in Step 3;

[0224] Further, as Figure 5 shown, the process of Step 4 is as follows:

[0225] Based on the PBFT algorithm, combined with distributed key generation (DKG) and BLS threshold signature technology, design the consensus algorithm TBH-PBFT. The first-phase consensus process of the consensus algorithm TBH-PBFT is as follows:

[0226] Step 4.1, Request phase

[0227] The client represented by the user (UE) sends a request to the primary node The message content is <REQUEST, m, ts, c>, where REQUEST is the identifier of the request phase, m is the content of this consensus vote, ts represents the timestamp, and c is the client identifier;

[0228] The primary node Determines the scale of this round of consensus according to the current clustering situation. The scale of the first-phase consensus of the consensus algorithm TBH-PBFT is n 1 , and the scale of the second-phase consensus of the consensus algorithm TBH-PBFT is n 2 , and further determines the two-phase voting passing thresholds as and The primary node Initializes the parameters related to BLS threshold signature. By importing the pairing parameters generated by the elliptic curve E p (a, b) where G 1 is a cyclic subgroup on the elliptic curve, is an integer cyclic group, r is a large prime number, and g is a generator of G 1 ;

[0229] The primary node Sends a preview message to the strong nodes participating in the second-phase consensus process of the consensus algorithm TBH-PBFT. Its format is:

[0230]

[0231] where SEC-PRE is the identifier of the second-phase consensus preview message of the consensus algorithm TBH-PBFT, ts′ represents the latest timestamp, and s is the primary node identifier;

[0232] The primary node At the same time, send the basic information of this round of consensus <RECORD-START,c,s,ts′> to the record nodes in the third trusted domain to record the entire process of consensus in the blockchain system;

[0233] Step 4.2, Pre-prepare phase

[0234] Primary node Randomly generate a set of coefficients a = {a 0 , a 1 , …, a t-1} and a set of commitment sets Use the coefficients a to generate a polynomial of degree t - 1:

[0235] f i (x) = a 0 + a 1 * x + … + a t-1 * x t-1

[0236] where a 0 is the secret of node i, the variable x of the polynomial represents a random number determined by the members. After completing the preparatory work in the pre-prepare phase, the primary node broadcasts a message within the initiating domain X, and its content is:

[0237]

[0238] where PRE-PREPARE is the identifier of the pre-prepare phase, is the asymmetric encryption information included in the broadcast message, indicating that after node i generates the value of the polynomial using node number j, it encrypts this value with the public key of node j; v is the view number, n is the sequence number, and d is the message digest; the remaining nodes that receive the broadcast message verify the validity of the signature σ i , determine whether the current view is v, whether the sequence number n is within the valid range, and whether the request with the same n has not been processed in view v. Finally, verify whether the value of hash(m) is the same as the digest d;

[0239] Step 4.3, Prepare phase

[0240] Candidate node Weak node and After receiving and verifying the message from the primary node , perform the same operations as the primary node in the pre-prepare phase, generate private keys and construct a polynomial of degree t - 1, assign values to the polynomial for calculation and perform asymmetric encryption and splice it into the broadcast message. The specific content is:

[0241]

[0242] Among them, PREPARE is the identifier of the preparation link. After the node collects the broadcast messages in the preparation stage, it checks the validity of the signature σ i and verifies that v, n, d are consistent with the pre-prepared messages stored locally; after completing the above process, at this time each consensus member in the first stage sends the encrypted polynomial parameter f i (j) to other members, and each member also receives n 1 -1 polynomial parameters sent by other members; the polynomial parameter verification algorithm is as follows:

[0243]

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

[0245] (1) Member j receives the polynomial parameter shard f i (j) sent by other member i through asymmetric encryption and the public commitment set

[0246] (2) Member j calculates the total received commitment sum through the formula ;

[0247] (3) Member j obtains the polynomial parameter verification result by verifying whether the equation holds. If the equation holds, the polynomial parameters received by member j are correct;

[0248] In the first-stage consensus process of the consensus algorithm TBH-PBFT, the weak node is a Byzantine node. If the weak node deliberately sends incorrect information during the consensus process, the correctness of the polynomial parameters can still be verified through the polynomial parameter verification algorithm; if the weak node refuses to participate at a specific time, for this malicious behavior of selective silence, the primary node supplements a set of polynomial parameters at the end of the preparation stage to ensure that the polynomial parameter verification algorithm can execute normally and does not affect the fairness of the voting link in the subsequent submission stage;

[0249] Step 4.4, Submission link

[0250] Different from traditional PBFT, the consensus algorithm TBH-PBFT simplifies the commit phase of the first-phase consensus. By combining the cryptographic BLS threshold signature, when the nodes participating in the consensus enter the commit phase, the synchronization and verification of various parameters have been completed. The main task of the commit phase is that all consensus nodes independently judge the information of the user (UE) applying for a cross-domain credential in the message m, complete the voting through the BLS threshold signature method, and send the result to the primary node. Finally, the primary node aggregates the signature information and judges the voting result;

[0251] Each consensus node queries the comprehensive trust value and historical interaction records of the user (UE) applying for a cross-domain credential through cross-domain and the trust management committee, casts a vote of approval or disapproval. The two voting results vote are respectively described as Agree and Disagree in a consistent manner, calculates the mapping of its hash value on the elliptic curve H(vote), and each node generates a partial signature through the received polynomial parameters:

[0252]

[0253] Put the calculated signature into the commit message, and the specific content is Among them, COMMIT is the identifier of the commit phase. The primary node obtains the voting result by verifying whether the bilinear pairing function holds;

[0254]

[0255] Among them, PK is the system public key, which is obtained by operating the sum of the first terms a 0 of the polynomials of each member t with the generator g; ThresholdSig is the complete signature recovered by interpolation:

[0256]

[0257] Among them, λ i is the Lagrange coefficient, and the complete signature ThresholdSig is the linear combination result of the partial signatures sig i of each member.

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

[0259] Furthermore, the process of Step 5 is as follows:

[0260] The above steps elaborate in detail the consensus process of the first phase of the consensus algorithm TBH-PBFT. Since this consensus targets cross-domain credential issuance, the first-phase consensus is participated by nodes within the initiating domain X. Therefore, the second-phase consensus is required to finally determine and execute the cross-domain credential issuance. For the consensus process of the second phase of the consensus algorithm TBH-PBFT, all participating nodes are strong nodes, coming from the initiating domain X and the target domain Y respectively. In the normal mode, the preparation link in the second-phase process of the consensus algorithm TBH-PBFT is the same as that in the first-phase consensus process of the consensus algorithm TBH-PBFT. The differences in the pre-preparation link and the submission link, as well as the newly added verification link and response link, are elaborated.

[0261] Step 5.1, design the normal mode of the consensus process of the second phase of the consensus algorithm TBH-PBFT

[0262] a) Pre-preparation link

[0263] After the consensus process of the first phase of the consensus algorithm TBH-PBFT ends, the primary node sends the second-phase consensus parameters and results to the recording node in the pre-preparation link of the consensus process of the second phase of the consensus algorithm TBH-PBFT. The recording node is a committee node from a third-party trusted domain, with the permission to access the historical data of the trust management blockchain and package blocks onto the chain. The recording node stores the consensus result on the chain for evidence. The evidence record includes information on consensus participating nodes, a complete list of nodes participating in the consensus, and a list of malicious nodes.

[0264] b) Submission link

[0265] The voting content changes from Agree / Disagree to m(user) / Disagree, where m(user) is the identity information of the user (UE) in the voting content m. In the second-phase consensus, if a strong node agrees to issue a cross-domain credential for the user (UE), a partial signature σ is generated for the identity information of the user (UE). i , if not, a partial signature is generated for the message Disagree; since the node evaluations of weak nodes and candidate nodes are weaker than those of strong nodes, it is more appropriate for nodes with higher node evaluations to handle the subsequent interpolation to recover the complete signature and verify the signature. In the submission link of the first-phase consensus of the consensus algorithm TBH-PBFT, weak nodes and candidate nodes send the generated partial signatures point-to-point to the primary node. In the second-phase consensus of the consensus algorithm TBH-PBFT, all participating nodes in the consensus are strong nodes with relatively strong comprehensive capabilities. Each member broadcasts its own partial signature, simultaneously receives the partial signatures of other members, independently recovers the complete signature, and judges the voting result.

[0266] c) Verification link and response link

[0267] Other members except the primary node will feedback their respective judgment results to the primary node. If the number of consents to issue reaches then it is finally determined to consent to issue a cross-domain credential for the user (UE); enter the next reply session. The primary node signs the information m(user) of the user (UE) identity to obtain the cross-domain credential <m(user)> ThresholdSig , send the cross-domain credential to the user (UE), and send the consensus parameters and results of the second phase of the consensus algorithm TBH-PBFT and the cross-domain credential to the recording node, and the recording node completes the on-chain of the consensus result and the user (UE)'s cross-domain credential;

[0268] If Figure 6 As shown in

[0269] Traditional PBFT completely loses security and liveness when the number of Byzantine nodes exceeds f, resulting in network forking or stagnation. When selecting consensus nodes, the comprehensive score and trust of the nodes are considered, which can reduce the possibility of Byzantine nodes, but there is still a probability of sudden downtime or node disconnection caused by network factors. Therefore, a special mode is proposed for the second-phase consensus process of the consensus algorithm TBH-PBFT, allowing standby nodes to act as substitutes for offline strong nodes and continue to participate in the second-phase consensus of this round. The reasons for designing a special mode only for the second phase are as follows:

[0270] a) Enhance the decision-making success rate of cross-domain credential issuance, avoid a large number of situations where the first phase is successful while the second phase fails frequently, resulting in a large waste of system resources and node occupation.

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

[0272] c) Provide more nodes with the opportunity to participate in the consensus and improve the enthusiasm of nodes in the blockchain system to participate in various affairs.

[0273] The special mode has two additional links, standby and resubmission, compared to the normal mode. After the preparation link is completed, if a strong node m(user) experiences downtime and drops offline, and the primary node does not receive 2f + 1 replies in the submission phase and still does not come online to respond after the timeout threshold set by the system then it switches from the normal mode to the special mode, and the standby and resubmission links are carried out in sequence. The process of the resubmission link is the same as that of the submission link in the normal mode, except that the participating roles are changed from the primary node and strong nodes to the primary node, strong nodes, and standby nodes. The process of the standby link is as follows:

[0274] The main work of the candidate session is to confirm the candidate nodes participating in the consensus, re-execute the distributed key generation. If the primary node and the strong node do not receive 2f + 1 replies within the timeout threshold, respectively query the candidate node with the highest comprehensive evaluation and idle status within the cluster in the trust management blockchain and send point-to-point encrypted information transmission to the candidate nodes and respectively, and send the DKG parameters to the candidate nodes. The candidate request format is:

[0275]

[0276] Among them, represents that after node i generates the value of the polynomial with the candidate node number z, encrypts the value with the public key of node z; after the candidate node receives the message from the primary node , executes polynomial and commitment generation, and sends the secret shard to the other nodes; after the other online nodes receive the information from the candidate node , verify the shard parameter f through the polynomial parameter verification algorithm z (i).

[0277] Step 6: Design a cross-domain identity authentication method based on the blockchain based on the first-phase consensus process of the consensus algorithm TBH-PBFT designed in Step 4 and the second-phase consensus process of the consensus algorithm TBH-PBFT designed in Step 5.

[0278] Furthermore, as Figure 7 shown, in the said Step 6, the specific process for the user (UE) to initiate cross-domain identity authentication is as follows:

[0279] Step 6.1: The user (UE) sends a cross-domain verification request to the verifier within the local trust domain X. The request contains the user's identifier and the cross-domain credential; to ensure the security of the transmission process, all subsequent requests are encrypted using the recipient's public key;

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

[0281] Step 6.3: After completing the verification of the user (UE)'s request in Step 6.2, the Credential Verifier obtains the user (UE)'s identity information from the request and verifies whether the user (UE) is a registered legitimate user in the blockchain system of Trust Domain X;

[0282] 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 credential in the user (UE)'s request, sign it with the private key, and forward it to the cross-domain and cross-domain and Trust Management Committee members of the local Trust Domain X;

[0283] Step 6.5: The cross-domain and Trust Management Committee members have the permission to access the cross-domain trust management chain. After receiving the request sent by the Credential Verifier in Step 6.4, the cross-domain and Trust Management Committee members verify the legitimacy of the request and the correctness of the signature of the Credential Verifier;

[0284] Step 6.6: If both the request sent by the Credential Verifier in Step 6.5 and the signature of the Credential Verifier pass the verification, then the cross-domain and Trust Management Committee members send a request for cross-domain credential verification parameters to the cross-domain trust management blockchain node;

[0285] 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;

[0286] Step 6.8: The InterPlanetary File System IPFS obtains the verification parameters according to the query parameters request in Step 6.7, including the generator g, the system public key PK, and the hash H(m(user)) of the user (UE)'s identity credential, and returns the verification parameters to the cross-domain and Trust Management Committee members;

[0287] Step 6.9: The cross-domain and Trust Management Committee members obtain the BLS threshold signature ThresholdSig of the user (UE)'s cross-domain credential from the request sent by the Credential Verifier in Step 6.4, and execute the bilinear pairing function through the verification parameters returned in Step 6.8 to verify the correctness of the threshold signature and judge the legitimacy of the user (UE)'s cross-domain credential;

[0288] Step 6.10: The cross-domain and Trust Management Committee members return the verification result obtained in Step 6.9 to the Credential Verifier and the user (UE) to complete the cross-domain credential verification.

[0289] The key credential parameters are chained and stored by the recording node during the credential issuance phase. During the cross-domain credential verification process, the verification can be completed with only two parties involved, namely the initiating trust domain X and the Cross-Domain and Trust Management Committee, which improves the verification efficiency of the credential.

[0290] As Figure 8 shown, it demonstrates the influence of different values of σ on the local density of nodes in the scenario of the same node distribution. There is an extreme point in the upper left corner of the figure. As Figure 8 (a) shows, when the value of σ is 5, the calculated local density result of this extreme point is 0.14; as Figure 8 (b) shows, when the value of σ increases to 10, the local density of the extreme point increases to 6.23 accordingly, meaning that more nodes are included in the consideration range. As Figure 8 (c) shows, when the value of σ is 15, the local density of the extreme point has increased to 16.72. At this time, it can be considered that all nodes in the entire area are included in the calculation of the local density of the extreme point.

[0291] Figure 9 (a) is the result graph of clustering using the traditional K-Medoids clustering algorithm in a heterogeneous network of the cellular network type. Figure 9 (b) is the result of clustering using the improved K-Medoids clustering algorithm based on node evaluation and node local density designed by the present invention in a heterogeneous network of the cellular network type. It can be seen in Figure 9 (a) simulation graph that there is a clustering center point with a relatively low evaluation value, and the evaluation value is 0.323. In Figure 9 (b) simulation graph, the evaluations of the clustering center points are generally high, and they perform better than Figure 9 (a) traditional clustering algorithm in terms of distance and area division. Thus, it can be seen that the improved K-Medoids clustering algorithm based on node evaluation and node local density designed by the present invention can select nodes with high evaluations as clustering center points in the cellular network scenario, and has a good clustering and clustering effect.

[0292] Figure 10 (a) is the result graph of clustering using the traditional K-Medoids clustering algorithm in a heterogeneous network of the wireless local area network type. Figure 10 (b) is the result of clustering using the improved K-Medoids clustering algorithm based on node evaluation and node local density designed by the present invention in a heterogeneous network of the wireless local area network type. It can be seen in Figure 10 (a) simulation graph that there are clustering center points with relatively low evaluation values, and the evaluation values are 0.398 and 0.523. In Figure 10 (b) simulation graph, the evaluations of the clustering center points are generally high, and the scores all exceed 0.9. And in terms of distance and area division, they are Figure 10(a) is similar to the traditional clustering algorithm. It can be seen that the improved K-Medoids clustering algorithm based on node evaluation and node local density designed by the present invention can be applied to the wireless local area network scenario with concentrated node distribution.

[0293] Figure 11 Shows the comparison of communication overheads between the consensus algorithm TBH-PBFT designed by the present invention, the traditional PBFT, and the existing hierarchical PBFT algorithm. Figure 11 (a), Figure 11 (b), and Figure 11 (c) are the communication overhead comparison diagrams when the number of groups K is 5, 7, and 9 respectively. It can be seen that as the number of groups K increases, the communication overheads of the hierarchical PBFT algorithms other than the traditional PBFT decrease, and the communication overhead of the consensus algorithm TBH-PBFT of the present invention is the lowest. It can be seen that the consensus algorithm TBH-PBFT designed by the present invention has lower communication overhead and can effectively reduce the system burden of cross-domain credential issuance.

[0294] The key points and protected points of the present invention include but are not limited to:

[0295] 1. The cross-domain identity authentication model of the 6G heterogeneous network constructed by the present invention, the roles played by each entity and the corresponding responsibilities. That is, the content in step one.

[0296] 2. The improved K-Medoids clustering algorithm based on node evaluation and node local density of the present invention, which can be applied to heterogeneous network scenarios with different node distributions. That is, the content in step two.

[0297] 3. The two-stage consensus algorithm TBH-PBFT combined with BLS threshold signature of the present invention, and the key points include the consensus node selection mechanism, the first stage of the consensus algorithm TBH-PBFT, the normal mode and special mode of the second stage of the consensus algorithm TBH-PBFT. That is, the contents corresponding to steps three, four, and five respectively.

[0298] 4. The simplified user cross-domain credential verification method based on blockchain. That is, the content in step six.

[0299] Existing identity authentication schemes are all designed for single-structured network models, distinguishing the relationship between domains according to geographical location factors in a single network, and there is no cross-domain identity authentication scheme designed for the 6G heterogeneous network scenario yet. In the 6G scenario, user equipment needs to frequently cross-network interact and exchange resources. Designing a secure and efficient cross-domain identity authentication mechanism can escort node interaction and resource access. Therefore, there is no other alternative solution that can fully achieve the purpose of the present invention.

[0300] The present invention also provides a blockchain cross-domain identity authentication system in a 6G heterogeneous network scenario, including:

[0301] The 6G heterogeneous network cross-domain identity authentication model construction module is used to implement the construction of the 6G heterogeneous network cross-domain identity authentication model in Step 1, and divide the roles and corresponding responsibilities of each entity in the scenario;

[0302] The node clustering module is used to implement the improved K-Medoids clustering algorithm based on node evaluation and node local density designed in Step 2 according to the 6G heterogeneous network cross-domain identity authentication model constructed in Step 1, and cluster the nodes within the heterogeneous network trust domain;

[0303] The consensus master node and participating node selection mechanism design module of the consensus algorithm TBH-PBFT is used to implement the cross-domain credential issuance scheme architecture and design the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT in Step 3 according to the improved K-Medoids clustering algorithm based on node evaluation and node local density designed in Step 2;

[0304] The first-phase consensus process design module of the consensus algorithm TBH-PBFT is used to implement the first-phase consensus process of the consensus algorithm TBH-PBFT designed in Step 4 according to the consensus master node and participating node selection mechanism of the consensus algorithm TBH-PBFT designed in Step 3;

[0305] The second-phase consensus process design module of the consensus algorithm TBH-PBFT is used to implement the second-phase consensus process of the consensus algorithm TBH-PBFT, including the normal mode and the special mode, based on the first-phase consensus process of the consensus algorithm TBH-PBFT designed in Step 5;

[0306] The cross-domain identity authentication method design module based on blockchain is used to implement the cross-domain identity authentication method based on blockchain designed in Step 6 according to the first-phase consensus process of the consensus algorithm TBH-PBFT designed in Step 4 and the second-phase consensus process of the consensus algorithm TBH-PBFT designed in Step 5.

[0307] The present invention also provides a blockchain cross-domain identity authentication device in a 6G heterogeneous network scenario, including:

[0308] A memory: storing a computer program of the above-mentioned blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario, which is a computer-readable device;

[0309] A processor: used to implement the above-mentioned blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario when executing the computer program.

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

Claims

1. A blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario, characterized in that: The following steps are involved: Step 1: Build a 6G heterogeneous network cross-domain identity authentication model to divide the roles and corresponding 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, a K-Medoids improved clustering algorithm based on node evaluation and node local density is designed to cluster the nodes in the heterogeneous network trust domain; Step 3: Based on the K-Medoids improved clustering algorithm based on node evaluation and node local density designed in Step 2, 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 is designed; Step 4: Design the first phase 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 designed in step 3; Step 5: Based on the first-phase consensus process of the consensus algorithm TBH-PBFT designed in step 4, design the second-phase consensus process of the consensus algorithm TBH-PBFT, including normal mode and special mode; Step 6: Based on the first-phase consensus process of the consensus algorithm TBH-PBFT designed in step 4 and the second-phase consensus process of the consensus algorithm TBH-PBFT designed in step 5, design a cross-domain identity authentication method based on blockchain.

2. According to a blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario according to claim 1, it is characterized in that: The process of step one is as follows: A 6G heterogeneous network cross-domain identity authentication model is constructed. The trust domain X and trust domain Y in the model refer to any two heterogeneous networks, each of which maintains a blockchain system within the heterogeneous network. Each trust domain contains three roles: the credential issuer (Issuer), the credential verifier (Verifier), and the user (UE). The credential issuer (Issuer) is the core role in the heterogeneous network, responsible for the identity registration of new users or devices in their respective domains and the issuance of credentials within the domain. The credential verifier (Verifier) ​​is a role in the heterogeneous network that has the authority to query the user (UE) identity information from the blockchain system. The user (UE) is a direct participant and performs trust evaluation, identity credential application, cross-domain credential application, privacy protection application, identity authentication, certificate authentication, and credential revocation in the 6G heterogeneous network cross-domain identity authentication model. 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 the core roles in the heterogeneous network, including cellular network base station equipment, IoT core network equipment, and wireless LAN router equipment; Members of the Cross-Domain and Trust Management Committee maintain the trust management blockchain, which is responsible for storing the history of node interactions and consensus in heterogeneous networks and maintaining the IPFS network as a storage extension of the trust management blockchain.

3. According to a blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario according to claim 1, it is characterized in that: The process of step 2 is as follows: Step 2.1, design node evaluation plan Define the node evaluation index as the comprehensive average trust value Comprehensive performance i , stability i and response speed v i , the definition and update methods of the four indicators are as follows: Comprehensive average trust value Comprehensive average trust value It is a very large indicator, and TT is trusted comprehensively. i 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. The comprehensive trust values ​​of all other nodes in the cluster for a certain node i are averaged to obtain the comprehensive average trust value of node i. Comprehensive performance i :Comprehensive performanceΦ i It is a very large indicator, which is determined by the processor performance, memory performance, storage performance and network performance of the node's actual running device; Stability i : Stability i It is a very large indicator, which is determined by the number of times a node fully participates in consensus. Every time a node fully participates in a consensus, the corresponding stability of the node is ξ i Increase; the number of times a node fully participates in consensus in each update interval is recorded as η, the number of times a node is absent from consensus in each update interval is recorded as ∈, and the node stability update method is ξ′ i =ξ i +η-θ x ∈, where θ x is the penalty factor for different heterogeneous networks; Response speed i : Response speed v i It is a very small indicator. The response speed is defined as the time required from receiving the consensus proposal to the node making effective feedback on the proposal, which is obtained by subtracting the timestamp of each time node. According to the characteristics of 6G heterogeneous networks and the comprehensive average trust value Comprehensive performance i , stability i and response speed v i , construct a judgment matrix, and use the geometric mean method to find the indicator weights. The formula is as follows: Among them, a ij and a kj are the values ​​of the corresponding rows and columns in the judgment matrix, It is to calculate the nth power of the product of each row of the judgment matrix to obtain the comprehensive average trust value Comprehensive performance i , stability i and response speed v i The weight ω i , after obtaining the weight, the final consistency check is performed; first calculate the maximum characteristic root λ max : Where n represents the number of dimensions, which is the same as the number of rows and columns of the judgment matrix. (Aw) i Represents the judgment matrix and the standardized weight W i After multiplication, the values ​​are accumulated row by row; λ is obtained max Value, solve the formula through consistency index Calculate the value of consistency index CI; obtain the RI value through the number of dimensions, calculate the consistency ratio CR = CI / RI, and obtain the consistency ratio CR value; if the consistency ratio is less than 0.10, it is considered that the matrix has satisfactory consistency; therefore, it is judged that the matrix has satisfactory consistency, and the consistency test result is "passed"; Based on the calculated comprehensive average trust value Comprehensive performance i , stability i and response speed v i The weight of each node, the matrix composed of the original evaluation data is as follows: Each row of the matrix composed of the original evaluation data is the data of a node. Each data in the matrix composed of the original evaluation data is forward processed, and all non-maximum indicators are converted to maximum indicators. The conversion method is max(X i )-X i ; Normalize the normalized matrix, the conversion method is Define the maximum value of the indicator Z + and the minimum value Z - , expressed as: From+=(max{from 11 ,With 21 ,…,With n1 },…,max{from 14 ,With 24 ,…,With n4 }) WITH - =(min{z 11 ,With 21 ,…,With n1 },…,min{z 14 ,With 24 ,…,With n4 }) Define the distance between the i-th evaluation node and the maximum value The distance to the minimum value is It is expressed as: Then, according to the distance between the evaluation node and the maximum and minimum values, the evaluation E(p i ), expressed as: Step 2.2, design node local density After completing a round of node evaluation updates through the node evaluation scheme designed in step 2.1, at a specific moment, the number of nodes in a network coverage area is N, and the clustering goal is to divide the nodes into K groups, where the evaluation of any node i is S i , the distance d(i,j) from node i with two-dimensional coordinates (x1,y1) to node j with two-dimensional coordinates (x2,y2) is calculated using the Euclidean distance formula, which is defined as follows: The node local density function ρ(i) is introduced to calculate the density of data points around the node. The calculation method is as follows: Among them, d ij is the distance from node i to node j, σ is a parameter that controls the range of local density calculation. When σ is larger, the value of the exponential term is closer to 1, making the calculation of local density smoother. As σ increases, the discrimination of local density decreases, and the density difference between different regions decreases. 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 K-Medoids improved clustering algorithm is as follows: Step 2.3.1, determine the first cluster center O1 It is known that the node evaluation set E = {E(p1), E(p2), …, E(p N )}, where E(p i ) represents node p i The evaluation set E is sorted in descending order to obtain the sorted node set satisfy: Select the node with the highest evaluation in the domain As the first candidate cluster center Through the local density function, it is checked that its local density is greater than the threshold td set by the current network x , if it is greater than the threshold td x If the condition is met, the node is determined to be the first cluster center O1. Otherwise, the node with the second highest evaluation in the domain is selected, and the following formula is repeated for judgment until the first cluster center is selected. Step 2.3.2, determine the next cluster center point When selecting the next cluster center point O r+1 When the next cluster center point O is required r+1 The distance from the selected center point is far, and the next cluster center point O r+1 The node evaluation should be high, and the node clustering comprehensive evaluation function D(p i )as follows: Among them, r represents the number of selected center points, P m ={p1,p2,…,p N } is the set of all points in the domain, O m ={O1,O2,…,O r } is the set of selected center points. i ), there is no need to repeatedly calculate the center point. κ is the weight that controls the node evaluation and distance in the node clustering algorithm. The closer κ is to 1, the more inclined it is to select nodes with high evaluation as cluster centers when clustering nodes in the current heterogeneous network. On the contrary, if κ is closer to 0, it is more inclined to select points with farther distance as the next cluster center. The next cluster center O r+1 The selection algorithm is as follows: Filter out the nodes with the highest comprehensive cluster evaluation from other non-central nodes in the domain As a candidate node for the next cluster center, check whether it satisfies ρ(O r+1 )≥td x , if the local density threshold condition is met, the next cluster center point is determined If the condition is not met, it means that the candidate center point is far away from the surrounding nodes in the current heterogeneous network scenario, and the next candidate cluster center point is selected again through the cluster center point selection algorithm; Step 2.3.3, assign the remaining nodes to clusters After each cluster center is confirmed, the nodes in the heterogeneous network are assigned to the determined center cluster according to the proximity principle; in, is the determined center point O j The clusters of O j The nearest remaining node p i A collection of; Step 2.3.4, determine the remaining cluster centers and complete clustering Repeat steps 2.3.2 and 2.3.3 until K cluster centers are found and all nodes are clustered.

4. According to a blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario according to claim 1, it is characterized in that: The process of step three is as follows: The nodes in multiple trust domains make collaborative decisions through the consensus algorithm TBH-PBFT to determine whether to issue cross-domain credentials to users (UE) or devices in heterogeneous networks; before selecting the participating consensus nodes and the primary node (Primary), the trust domain X has completed the node clustering according to the node score, and in each cluster, the strong node set is defined in descending order according to the node evaluation. Candidate node set Weak Node Set The total number of strong nodes is K, and the cluster center finally determined by clustering and sub-clustering serves as a strong node; the two nodes with the highest node scores in each sub-cluster except the strong nodes serve as candidate nodes, with a total number of 2K. The candidate nodes are responsible for participating in the first-phase consensus process of the consensus algorithm TBH-PBFT, and serve as alternatives for strong nodes in the second-phase consensus process of the consensus algorithm TBH-PBFT; Weak nodes are the remaining nodes in the cluster, with a number of N-3K, responsible for participating in the first phase of the consensus process of the consensus algorithm TBH-PBFT; The consensus master node and participating nodes of the consensus algorithm TBH-PBFT are selected from the initiating domain X, the target domain Y and the remaining trust domain Z. The nodes participating in the first phase of the consensus process of the consensus algorithm TBH-PBFT come from the cluster where the node that initiates the cross-domain credential application is located. Half of the nodes participating in the first phase of the consensus process of the consensus algorithm TBH-PBFT come from the initiating domain X, and the other half come from the target domain Y, which are selected by random selection. In both phases of consensus, nodes in the trust domain Z record the entire consensus process as observation nodes.

5. According to a blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario according to claim 1, it is characterized in that: The process of step 4 is as follows: Based on the PBFT algorithm, the consensus algorithm TBH-PBFT is designed in combination with distributed key generation (DKG) and BLS threshold signature technology. The first phase consensus process of the consensus algorithm TBH-PBFT is as follows: Step 4.1, Request phase The client represented by the user (UE) sends a request to the master node Send a request, the message content is<REQUEST,m,ts,c> , where REQUEST is the request link identifier, m is the content of this consensus vote, ts is the timestamp, and c is the client identifier; Master Node According to the current clustering situation, the scale of this round of consensus is determined. The first-stage consensus scale of the consensus algorithm TBH-PBFT is n1, and the second-stage consensus scale of the consensus algorithm TBH-PBFT is n2. The two-stage voting pass thresholds are determined as follows: and Master Node Initialize the BLS threshold signature related parameters by importing the elliptic curve E p (a,b) Generated pairing parameters where G1 is a cyclic subgroup on the elliptic curve, is a cyclic group of integers, r is a large prime number, and g is a generator of G1; Master Node Send a notice message to the strong nodes participating in the second phase of the consensus process of the consensus algorithm TBH-PBFT. The format is: Where SEC-PRE is the identifier of the second phase consensus notice message of the consensus algorithm TBH-PBFT, ts′ represents the latest timestamp, and s is the master node identifier; Master Node At the same time, the basic information of this round of consensus<RECORD-START,c,s,ts′> Send it to the recording node of the third trust domain to realize the whole process of blockchain system recording consensus; Step 4.2, Preparatory stage Master Node Randomly generate a set of coefficients a={a0,a1,…,a t-1 } and a set of promises Generate a t-1 degree polynomial using coefficients a: f i (x)=a0+a1*x+…+a t-1 *x t-1 Among them, a0 is the secret of node i, and the polynomial variable x represents a random number determined by the members. After completing the preparatory work in the preparatory phase, the master node Broadcast a message in the initiating domain X, the content of which is: Among them, PRE-PREPARE is the identifier of the pre-preparation phase. is the asymmetric encryption information contained in the broadcast message, indicating that after node i generates the value of the polynomial with node number j, the value is encrypted by the public key of node j; v is the view number, n is the sequence number, and d is the message digest; the remaining nodes that receive the broadcast message verify the signature σ i The validity of the query is checked to determine whether the current view is v, whether the sequence number n is within the valid range, and whether the request with the same n has not been processed in view v. Finally, the value of hash(m) is verified to be the same as the digest d. Step 4.3, Preparation Alternative Node Weak Node and Receive and verify the master node After the message is received, the master node in the pre-preparation phase is executed. The same operation is used to generate a private key and construct a t-1 degree polynomial, assign values ​​to the polynomial and perform asymmetric encryption. Spliced ​​into the broadcast message, the specific content is: Among them, PREPARE is the identifier of the preparation phase. The node collects the broadcast message of the preparation phase and then checks the signature σ i The validity of v, n, d is verified to be consistent with the locally stored pre-prepared message; at this time, each first-stage consensus member sends the encrypted polynomial parameter f to other members i (j), each member also receives n1-1 polynomial parameters sent by other members; The polynomial parameter verification process is: (1) Member j receives the polynomial parameter fragment f sent by other member i via asymmetric encryption i (j) and public commitment collection (2) Member j uses the formula Calculate the total value of the commitments received; (3) Member j passes the verification equation Whether it is established, the polynomial parameter verification result is obtained. If the equation is established, the polynomial parameters received by member j are correct; Weak nodes in the first phase of the consensus process of the consensus algorithm TBH-PBFT Is a Byzantine node, if the weak node Intentionally send wrong information during the consensus process, and verify the correctness of the polynomial parameters through the polynomial parameter verification algorithm; if the weak node Refusing to participate at a specific time, the master node Supplementing a set of polynomial parameters at the end of the preparation phase; Step 4.4, Submission All consensus nodes independently judge the information of the user (UE) applying for cross-domain credentials in message m, complete the voting through BLS threshold signature, and send the result to the master node Finally, the master node summarizes the signature information and determines the voting results; Each consensus node queries the comprehensive trust value and historical interaction records of the user (UE) applying for the cross-domain credential through the cross-domain and trust management committee, and casts a vote in favor or against. The two voting results, vote, use consistent descriptions Agree and Disagree, respectively, and calculate the mapping H(vote) of their hash values ​​on the elliptic curve. Each node generates a partial signature through the received polynomial parameters: Put the calculated signature in the commit message, which is COMMIT is the identifier of the commit phase. The master node verifies whether the bilinear pairing function holds and obtains the voting result. Among them, P is the system public key, which is the sum of the first term a0 of each member's polynomial. t By operating with the generator g, we get ThresholdSig is the complete signature restored by interpolation: Among them, λ i is the Lagrange coefficient, and the complete signature ThresholdSig is the partial signature sig of each member i The linear combination result of .

6. According to a blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario according to claim 1, it is characterized in that: The process of step five is as follows: In the second phase of the consensus process of the consensus algorithm TBH-PBFT, all participating nodes are strong nodes, coming from the initiating domain X and the target domain Y respectively. The preparation steps in the second phase of the consensus algorithm TBH-PBFT in normal mode are the same as those in the first phase of the consensus algorithm TBH-PBFT. Step 5.1, design the normal mode of the second phase consensus process of the consensus algorithm TBH-PBFT a) Preparatory stage After the first phase of the consensus process of the consensus algorithm TBH-PBFT is completed, the master node sends the second phase consensus parameters and results to the recording node in the pre-preparation phase of the second phase of the consensus process of the consensus algorithm TBH-PBFT. The recording node is a committee node from a third-party trust domain, and has the authority to access the historical data of the trust management blockchain and package blocks on the chain. The recording node stores the consensus results on the chain, and the evidence record includes the consensus participating node information, the complete consensus participating node list, and the malicious node list; b) Submission The voting content changes from Agree / Disagree to m(user) / Disagree, where m(user) is the identity information of the user (UE) in the voting content m. In the second phase of consensus, if the strong node agrees to issue a cross-domain certificate to the user (UE), a partial signature σ is generated for the identity information of the user (UE). i , if not agreed, a partial signature is generated for the message Disagree; In the first phase of the consensus submission process of the consensus algorithm TBH-PBFT, weak nodes and candidate nodes send the generated partial signatures point-to-point to the master node. In the second phase of the consensus of the consensus algorithm TBH-PBFT, all the participating consensus nodes are strong nodes. Each member broadcasts its own partial signature and receives partial signatures of other members at the same time. It restores the complete signature independently and determines the voting results. c) Verification and response phase Other members except the master node will feed back their respective judgment results to the master node. If the result agreed to be issued reaches Finally, it is determined that the cross-domain certificate is issued to the user (UE); the next response link is entered, and the master node signs the user (UE) identity information m(user) to obtain the cross-domain certificate<m(user)> ThresholdSig , send the cross-domain certificate to the user (UE), send the consensus parameters and results of the second phase of the consensus algorithm TBH-PBFT and the cross-domain certificate to the recording node, and the recording node completes the consensus result and the user (UE) cross-domain certificate on the chain; Step 5.2: Design a special mode for the second phase consensus process of the consensus algorithm TBH-PBFT In the special mode, after the preparation phase is completed, the strong node m(user) goes offline, and the master node No 2f+1 responses were received during the submission phase, and after the timeout threshold set by the system If there is still no response from the online team, the normal mode will be switched to the special mode, and the standby and resubmission phases will be carried out in sequence. The process of the resubmission phase is the same as the submission phase in the normal mode, and the participating roles will be changed from the main node and strong node to the main node, strong node and substitute node. The process of the standby phase is as follows: The work of the candidate link is to confirm the candidate nodes participating in the consensus, re-execute the distributed key generation, and the master node and strong nodes If none of them received 2f+1 replies within the timeout threshold, they would query the trust management blockchain for the candidate node with the highest comprehensive evaluation and free space in their cluster. and To the candidate node and Initiate point-to-point encrypted information transmission respectively, send the DKG parameters to the candidate nodes, and the candidate request format is: in, It means that node i generates the value of the polynomial using the candidate node number z and then encrypts the value using the public key of node z. Received from the master node After receiving the message, the polynomial and commitment generation are executed, and the secret shard is sent to the remaining nodes; the remaining online nodes receive the standby node The information of the sharding parameter f is verified by the polynomial parameter verification algorithm z (i).

7. According to a blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario according to claim 1, it is characterized in that: In step 6, the specific process of the user (UE) initiating cross-domain identity authentication is as follows: Step 6.1: The user (UE) initiates a cross-domain authentication request to the verifier in the local trust domain X. The request includes the identifier of the user (UE) and the cross-domain credential. Step 6.2: The credential verifier (Verifier) ​​is a node in the trust domain that has blockchain query authority. After receiving the cross-domain verification request sent by the user (UE) in step 6.1, the credential verifier (Verifier) ​​uses the private key to verify the legitimacy of the request; Step 6.3: After completing the verification of the user (UE) request in step 6.2, the credential verifier (Verifier) ​​obtains the identity information of the user (UE) from the request and verifies whether the user (UE) is a registered legitimate user (UE) in the blockchain system of trust domain X; Step 6.4: If the cross-domain request verification in step 6.2 and the user (UE) legitimacy verification in step 6.3 are both passed, the cross-domain credential in the user (UE) request is parsed, signed with a private key, and forwarded to the cross-domain and cross-domain trust management committee member of the local trust domain X; Step 6.5: The 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 credential verifier (Verifier) ​​in step 6.4, the members of the cross-domain and trust management committee verify the legitimacy of the request and the correctness of the signature of the credential verifier (Verifier); Step 6.6: If the request sent by the credential verifier (Verifier) ​​and the signature of the credential verifier (Verifier) ​​in step 6.5 are both verified, the cross-domain and trust management committee member sends a request to apply for cross-domain credential verification parameters to the cross-domain trust management blockchain node; Step 6.7: After receiving the request sent in step 6.6, the cross-domain trust management blockchain node queries the parameters through the Interstellar File System IPFS; Step 6.8: The Interplanetary File System IPFS obtains the verification parameters, including the generator g, the system public key PK, and the hash H(m(user)) of the user (UE) identity credential according to the query parameter request in step 6.7, and returns the verification parameters 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 ThresholdSig of the user (UE) cross-domain credential from the request sent by the credential verifier (Verifier) ​​in step 6.4, and perform the bilinear pairing function to verify the correctness of the threshold signature through the verification parameters returned in step 6.8, and determine the legitimacy of the cross-domain credential of the user (UE); Step 6.10: The cross-domain and trust management committee members return the verification result obtained in step 6.9 to the credential verifier (Verifier) ​​and the user (UE), completing the cross-domain credential verification.

8. A blockchain cross-domain identity authentication system in a 6G heterogeneous network scenario based on the method described in any one of claims 1 to 7, characterized in that: include: 6G heterogeneous network cross-domain identity authentication model construction module, used to build a 6G heterogeneous network cross-domain identity authentication model and divide the roles and corresponding responsibilities of each entity in the 6G heterogeneous network scenario; The node clustering module is used to design a K-Medoids improved clustering algorithm based on node evaluation and node local density according to the 6G heterogeneous network cross-domain identity authentication model, and cluster the nodes in the heterogeneous network trust domain; The consensus master node and participating node selection mechanism design module of the consensus algorithm TBH-PBFT is used to improve the clustering algorithm based on K-Medoids based on node evaluation and node local density, 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; The first-phase consensus process design module of the consensus algorithm TBH-PBFT is used to design the first-phase consensus process of the consensus algorithm TBH-PBFT according to 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 cross-domain identity authentication method design module based on blockchain is used to implement the first-phase consensus process based on the consensus algorithm TBH-PBFT and the second-phase consensus process based on the consensus algorithm TBH-PBFT, and design a cross-domain identity authentication method based on blockchain.

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

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed by a processor, can implement a blockchain cross-domain identity authentication method in a 6G heterogeneous network scenario as described in any one of claims 1-7.

Images