A Cross-Domain Identity Authentication and Key Negotiation Method Based on Consortium Blockchain

Abstract

The present invention discloses a cross-domain identity authentication and key negotiation method based on an alliance chain. First, a trust alliance chain is established to realize the credibility of the root node certificate. Then, each node in the domain uses blockchain technology to perform decentralized storage of node identities and signatures, and uses on-chain access to obtain information and verify signatures for identity authentication. From an attack perspective, this method can resist various common attacks and achieve security requirements such as authentication and key negotiation; and this method reduces the amount of signature calculations through the use of message authentication codes, while basic operations such as XOR and hashing are relatively fast and efficient, thereby improving the efficiency of cross-domain authentication and key negotiation. By using blockchain cross-domain authentication to achieve authentication and key negotiation between nodes, it can be applied in banking, transportation, education, government affairs, medical care and other fields to improve the security and efficiency of cross-domain access.

Description

Technical Field

[0001] The present invention relates to the technical field of entity identity authentication in cyberspace, and in particular to a cross-domain identity authentication and key negotiation method based on an alliance chain. Background Art

[0002] With the rapid development of big data, interactions in network environments are increasing, and the environment is becoming more complex. Cross-domain authentication plays a key role in secure data sharing. However, cross-domain authentication solutions under traditional centralized structures have problems such as over-reliance on trusted third parties, privacy leaks, and low certificate efficiency.

[0003] As an emerging technology, the decentralized nature of blockchain can avoid the drawbacks of traditional centralized trust mechanisms and effectively solve cross-domain authentication problems.

[0004] Therefore, how to apply blockchain technology to cross-domain authentication and realize decentralized cross-domain authentication has become an urgent problem that practitioners in the same field need to solve. Summary of the Invention

[0005] The purpose of the present invention is to provide a cross-domain identity authentication and key agreement method based on alliance chain, which adopts a blockchain-based root CA to establish a trusted alliance chain to ensure the credibility and legitimacy of the root certificate, and realizes identity authentication through on-chain information and off-chain signature verification.

[0006] To achieve the above object, the technical solution adopted by the present invention is:

[0007] The present invention provides a cross-domain identity authentication and key negotiation method based on an alliance chain, comprising the following steps:

[0008] Steps to establish a trust alliance chain: build an alliance chain based on N relatively independent domains, select a root node in each domain as the CA of the domain; each domain has multiple distributed servers and multiple users;

[0009] Storage step: Nodes in each domain use blockchain technology to decentralize the storage of node identities and signatures;

[0010] Authentication steps: Use on-chain access to obtain information and verify the signature for identity authentication.

[0011] Furthermore, the steps of establishing a trust alliance chain specifically include:

[0012] In each of N relatively independent domains, a root node is selected as the CA of the domain. Each domain has multiple distributed servers and multiple users, and each server and user is considered a node.

[0013] The root node CA in each domain establishes a trust alliance chain, selects the elliptic curve group G, and P is the generator of group G; the alliance chain consensus selects the hash function h(·), {0,1} * →{0,1} n ; CA discloses system parameters: {G, P, q, h(·)}, and broadcasts them to nodes within its own domain through consensus.

[0014] Furthermore, the storing step specifically includes:

[0015] 1) Obtain the input biometric features of node A, identify them through the fuzzy extractor and compare them with the template database storage information H(σ); H(·) represents the hash function, {0,1} * →G, σ represents the biometric feature;

[0016] After the comparison is passed, the virtual identity of the node is calculated and the ID A As the true identity hash value of node A; the node selects its own public and private key pair, where Pub = k pri P; Pub represents the public key, k pri Represents a private key;

[0017] Use the private key to calculate the signature Sig of node A A (ID A ,Pub A ); Send identity creation request information through smart device: {ID A , Pub A ,H(σ),Sig A (ID A ,Pub A )}; where Sig(·) represents the signature function; Pub A Represents the public key of node A;

[0018] 2) Domain root node CA receives node A's creation request information and calculates h(ID A ,Pub A ); CA queries the chain information to check whether there is an ID A ,h(ID A ,Pub A );

[0019] If this information is unique, the creation request is approved and H(σ),h(ID A ,Pub A ) Information is stored on the chain; CA broadcasts information on the chain: {ID A ,H(σ),h(ID A ,Pub A ), Sig A (ID A ,Pub A)}.

[0020] Furthermore, the authentication step specifically includes:

[0021] (1) Every time a user logs into a node, they need to first use a smart device to read and identify their biometrics, and then send a request message to the corresponding server;

[0022] (2) The corresponding server requests assistance from the root node CA in the domain, and uses the block information on the blockchain to verify the user request message, thereby achieving two-way verification and session key negotiation between the user and the server.

[0023] Furthermore, the step (1) includes:

[0024] (1.1) User U A Biometrics are collected and recognized by a smart device equipped with a fuzzy recognizer module. The fuzzy extractor is used to recover the function. If the difference between the biometric and the information in the template database is less than ε, the biometric is successfully recovered and H(σ)∈G is calculated; ε represents an error term that is greater than zero and approaches zero.

[0025] (1.2) User U A Select random number Calculate R A =r A P; User-side computing and R A Signature Represents continuous XOR operations;

[0026] (1.3) User U A To the target server S B Send request information: Where T represents the timestamp.

[0027] Furthermore, the step (2) includes:

[0028] (2.1) Server S B Receive user U A The request information sent, check whether the timestamp T is within the trusted range, and then calculate h(ID A ,Pub A ); then server S B To the root node CA of the domain where the node is located B Send assistance request message: {ID A ,h(ID A ,Pub A )};

[0029] (2.2) Root Node CA B Received from server S B Assist request message to find out whether there is a corresponding identity and hash value information in the block on the chain; if not, no query result will be fed back; if it exists, the root node CA B Send the corresponding block record to S B :{H(σ), Sig A (ID A ,Pub A )};

[0030] (2.3) Server S B Receive verification message and verify signature Sig A (ID A ,Pub A ) is valid; at the same time, use the received D and the chain information H(σ) to calculate Verify signature Is it valid? If the verification is successful, the server S B For user U A Cross-domain authentication.

[0031] Furthermore, the step (2.3) further includes:

[0032] Server S B Select random number Calculate R B =r B P; using the private key and R A calculate As the key of the message authentication code MAC, calculate and h(R B ||r B ·R A ); Complete the above operations, server S B To user U A Send response message:

[0033] Furthermore, the step (2) further includes:

[0034] (2.4) User U A Receive the response message sent by the server, check the legitimacy of the timestamp T, and then calculate h(ID B ,Pub B ); then user U A To the root node CA of the domain where the node is located A Send assistance request message: {ID B ,h(ID B ,PubB )};

[0035] (2.5) Root Node CA A After receiving the user's assistance request message, it searches for the corresponding identity and hash value information in the chain block; if not, it will return no query results; if it exists, the root node CA A Record the corresponding block Sig B (ID B ,Pub B ) is sent to user U A ;

[0036] (2.6) User U A Receive verification message and verify signature Sig B (ID B ,Pub B ) is valid; then use r A and server S B The public key calculation h(r A Pub B ) is calculated and passed through MAC(h(r A Pub B ),R B ) Check the received message R B The authenticity and validity of the hash function h(R B ||r B ·R A ), check whether it is consistent with h(R B ||r B ·R A ) values are equal; if the verification is successful, the user has achieved cross-domain authentication of the server.

[0037] Furthermore, the step (2.6) further includes: user U A Send session key confirmation message: {ID A ,h(ID A ||ID B ||r A ·R B}, to the server S B .

[0038] Furthermore, the step (2) further includes:

[0039] (2.7) Server S B Receive the verification message, calculate and verify h(ID A ||ID B ||r A ·R B ) and h(ID A ||ID B||r B ·R A ) are equal; if the verification is successful, user U A With server S B Key negotiation is completed, session key sk = r B ·R A =r A ·R B .

[0040] Compared with the prior art, the present invention has the following beneficial effects:

[0041] The embodiment of the present invention provides a cross-domain identity authentication and key negotiation method based on the alliance chain. First, a trust alliance chain is established to realize the credibility of the root node certificate. Then, each node in the domain uses blockchain technology to perform decentralized storage of node identities and signatures, and uses on-chain access to obtain information and verify signatures for identity authentication. From an attack perspective, this method can resist various common attacks and achieve security requirements such as authentication and key negotiation. Moreover, this method reduces the amount of signature calculations through the use of message authentication codes. At the same time, basic operations such as XOR and hashing are relatively fast and efficient, which improves the efficiency of cross-domain authentication and key negotiation. By using blockchain cross-domain authentication to achieve authentication and key negotiation between nodes, it can be applied in banking, transportation, education, government affairs, medical care and other fields to improve the security and efficiency of cross-domain access. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 A diagram of the system architecture for entity cross-domain access authentication provided by an embodiment of the present invention;

[0043] Figure 2 A schematic diagram of the creation phase of any node in each domain provided by an embodiment of the present invention;

[0044] Figure 3 This is a process diagram of the authentication and key agreement phase provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0045] In order to make the technical means, creative features, objectives and effects achieved by the present invention easier to understand, the present invention is further described below in conjunction with specific implementation methods.

[0046] In the description of the present invention, it should be noted that the terms "upper," "lower," "inner," "outer," "front end," "rear end," "both ends," "one end," "the other end," and the like, indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings and are intended solely to facilitate and simplify the description of the present invention. They are not intended to indicate or imply that the devices or components referred to must have, be constructed, or operate in a specific orientation, and therefore should not be construed as limiting the present invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0047] In the description of the present invention, it should be noted that, unless otherwise expressly specified or limited, the terms "installed," "provided with," "connected," etc., should be understood in a broad sense. For example, "connected" may refer to a fixed connection, a detachable connection, or an integral connection; it may refer to a mechanical connection or an electrical connection; it may refer to a direct connection or an indirect connection through an intermediate medium; it may refer to internal communication between two components. Those skilled in the art will be able to understand the specific meanings of the above terms in the present invention based on the specific circumstances.

[0048] This invention provides a cross-domain identity authentication and key agreement method based on a consortium chain. This method leverages blockchain technology to achieve relatively decentralized identity authentication, enabling all citizen entities, service providers, or platforms to serve as nodes within the blockchain system. Nodes within different branches of the same platform or company often need to conduct business or exchange information. When nodes in different systems need to conduct conversations, transfer information, or provide services across regions, blockchain cross-domain authentication can be used to achieve inter-node authentication and key agreement. This method has applications in banking, transportation, education, government affairs, healthcare, and other fields.

[0049] The present invention provides a cross-domain identity authentication and key agreement method based on a consortium chain. It uses a blockchain-based root CA to establish a trusted consortium chain to ensure the credibility and legitimacy of the root certificate, and implements identity authentication through on-chain information and off-chain signature verification. Specifically, it includes:

[0050] Steps to establish a trust alliance chain: build an alliance chain based on N relatively independent domains, select a root node in each domain as the CA of the domain; each domain has multiple distributed servers and multiple users;

[0051] Storage step: Nodes in each domain use blockchain technology to decentralize the storage of node identities and signatures;

[0052] Authentication steps: Use on-chain access to obtain information and verify the signature for identity authentication.

[0053] This method first establishes a trust alliance chain to ensure the credibility of the root node certificate. Then, each node in the domain uses blockchain technology to decentralize the storage of node identity and signatures, and uses on-chain access to obtain information and verify signatures for identity authentication. The framework is as follows: Figure 1 As shown,

[0054] This method mainly studies the identity authentication and key negotiation problems when entities in different domains need to access each other across domains. A trust architecture based on alliance chain is constructed. Generally, the scheme involves N relatively independent domains. In each domain, a root node is selected as the CA of this domain, and m distributed servers S are used. j (j=1,2,…,m) and n users U i (i=1,2,…,n), where S j Several different access services or application services can be provided. Users use their smart devices to identify their biometrics. After successful identification, they can access a distributed server connected to the Internet. The server, with the assistance of the root CA, uses blockchain information data to authenticate the user and, based on established legal authentication, implements session key negotiation. Initially, this embodiment provides the symbols used in the scheme and their corresponding meanings, as shown in Table 1:

[0055] Table 1. Explanation of symbols

[0056]

[0057]

[0058] Legal user nodes can easily log in to their own nodes and obtain server services. This embodiment includes a user node creation phase, a server node creation phase, and an authentication and key negotiation phase.

[0059] First, the root CA within each domain establishes a trust consortium chain. It then selects an elliptic curve group G, with P being the generator of G. The consortium chain then selects a hash function h(·). Finally, the CA publicly discloses the system parameters: {G, P, q, h(·)}, where q represents the group order. These parameters are then broadcast to nodes within their domain through consensus.

[0060] Node creation phase:

[0061] Using blockchain technology, any user U iTo communicate and access, you need to create your own node. First, the user extracts biometrics through the smart device, and then stores the biometrics in the template database. When logging into the node, the biometrics must be identified and compared with the information in the template database. This process is achieved with the help of a fuzzy extractor. If the entity can pass the biometric identification, the smart device will send the user's signature, the user's corresponding identity information, etc. and submit it to the root node CA of its own domain to upload the identity information to the chain. After that, the CA will broadcast some information to the blockchain. For example: the process of the user node creation stage is as follows: Figure 2 shown.

[0062] Step 1: First, user U A Input biometrics, identify them through fuzzy extractor and compare them with template database storage information H(σ). Node virtual identity is calculated by post-user, ID A is the real identity hash value. Then the user selects his own public and private key pair, where Pub = k pri P, then uses the private key to calculate the signature Sig A (ID A ,Pub A ). Finally, the smart device sends an identity creation request message: {ID A , Pub A ,H(σ),Sig A (ID A ,Pub A )}.

[0063] Step 2: The domain root node CA receives the user node creation request information and calculates h(ID A ,Pub A ). CA queries the chain information to check whether there is an ID A ,h(ID A ,Pub A ). If this information is unique, the creation request is approved and H(σ),h(ID A ,Pub A ) and other information are stored on the chain. CA broadcasts chain information: {ID A ,H(σ),h(ID A ,Pub A ), Sig A (ID A ,Pub A )}.

[0064] This solution uses blockchain technology to facilitate cross-domain authentication. j The node creation process of the server is consistent with the user's node creation process. All nodes in the domain have the same attributes and implement different functions. Similarly, the process of the server node creation phase is as follows Figure 2 As shown, no repetition is given here.

[0065] Authentication and key negotiation phase:

[0066] When a user needs to log in to the system to a specific server S j When requesting a service, a cross-domain identity mutual authentication process is required. Every time a user logs into a node, they must first use a smart device to read and identify their biometrics. After that, a specific message is sent to a specific server. The server requests assistance from the root node CA in the domain and uses the block information on the blockchain to verify the user's message, thereby achieving two-way authentication and session key negotiation between the user and the server, ensuring security. The process of the authentication and key negotiation stage is as follows: Figure 3 shown.

[0067] Step 1: First, user U A The biometrics are collected and recognized by a smart device with a fuzzy identifier module, and the fuzzy extractor is used to restore the function. If the difference between the biometrics and the information in the template database is less than ε, where ε represents an error term greater than zero and close to zero, the biometrics can be successfully restored and H(σ)∈G can be calculated. Then U A Select random number Calculate R A =r A P. Last-User Computing and R A Signature Indicates continuous XOR operations. A To the target server S B Send request information:

[0068] Step 2: Server S B After receiving the request information sent by the user, first check whether the timestamp T is within the trusted range, and then calculate h(ID A ,Pub A ). The server then sends a request to the CA of the domain where its node is located. B Send assistance request message: {ID A ,h(ID A ,Pub A )}.

[0069] Step 3: Root CA B After receiving the server assistance request message, it searches for the corresponding identity and hash value information in the chain block. If it does not exist, it will return no query results, otherwise CA B Send the corresponding block record to S B :{H(σ), Sig A (IDA ,Pub A )}.

[0070] Step 4: Server S B Receive verification message and verify signature Sig A (ID A ,Pub A ) is valid. At the same time, the received D and the chain information H(σ) are used to calculate Verify signature Is it valid? If the verification is successful, the server has implemented cross-domain authentication for the user.

[0071] Last server S B choose Calculate R B =r B P. Use the private key and R A calculate As the key of the message authentication code MAC, the lowercase n here represents an n-bit 01 string set; calculate and h(R B ||r B ·R A ). After completing the above operations, the server S B To user U A Send response message:

[0072] Step 5: User U A After receiving the response message from the server, first check the validity of the timestamp T, and then calculate h(ID B ,Pub B ). After that, the user submits a request to the CA of the domain where his / her node is located. A Send assistance request message: {ID B ,h(ID B ,Pub B )}.

[0073] Step 6: Root CA A After receiving the user's assistance request message, the CA searches for the corresponding identity and hash value information in the chain. If it does not exist, the CA will respond with no query results. Otherwise, the CA will A Record the corresponding block Sig B (ID B ,Pub B )Send to U A .

[0074] Step 7: User U A Receive verification message and verify signature Sig B(ID B ,Pub B ) is valid. Then use r A and server S B The public key calculation h(r A Pub B ) is calculated and passed through MAC(h(r A Pub B ),R B ) Check the received message R B The authenticity and validity of the hash function h(R B ||r B ·R A ), check whether it is consistent with h(R B ||r B ·R A ) values are equal. If the verification is successful, the user has achieved cross-domain authentication of the server. A Send session key confirmation message: {ID A ,h(ID A ||ID B ||r A ·R B}.

[0075] Step 8: Server S B Receive the verification message, calculate and verify h(ID A ||ID B ||r A ·R B ) and h(ID A ||ID B ||r B ·R A ) are equal. If the verification is successful, the user and the server complete the key negotiation, and the session key sk = r B ·R A =r A ·R B .

[0076] From the perspective of attacks, the following theoretical analysis shows that the solution of the embodiment of the present invention can resist various common attacks and achieve security requirements such as authentication and key agreement.

[0077] (1) Anti-replay attack: The timestamp T and other elements are added in the identity authentication process to avoid replay attacks. At the same time, the present invention uses a query response mechanism to A ,R B By introducing the verification message, the validity of the signature or message authentication code is verified to ensure that the message of the present invention is authentic and has not been tampered with, thereby resisting replay attacks.

[0078] (2) Anti-masquerade attack: In the scheme design, the node identity and the signature of the public key information are stored in the blockchain, and the signature transmitted by the node is compared with the signature information in the blockchain. The node determines the authenticity of the identity of the message sender based on the validity of the signature. At the same time, the present invention adds a numerical value D related to the biometric feature to the user node and a message authentication code MAC value related to the node identity to the server node. The signature and message authentication code ensure the integrity of the information. Information signed by the owner's private key and the message authentication code calculated using the owner's private key as a partial key cannot be forged by an attacker.

[0079] (3) Resistance to internal attacks: The solution of the present invention is based on blockchain. Even if the attacker is an internal user or server, since the private key of the present invention is controlled by the user, and the biometrics are unique, internal malicious users cannot complete signature verification and message authentication code forgery. Internal malicious servers are also unable to complete signature verification and crack user biometrics. Therefore, the solution can effectively resist internal attacks.

[0080] (4) Anti-DDoS attack: The solution is built on the blockchain, which uses the blockchain to achieve a decentralized architecture. At the same time, due to the consensus and distributed storage of nodes in the blockchain, all participants have the complete ledger and transaction records of the system. Therefore, even if a malicious adversary attacks some nodes of the system or some nodes fail, the entire system will not be affected.

[0081] (5) Anti-Sybil Attack: The scheme uses a fuzzy extractor and uses biometric calculation H(σ) in the identity creation phase to ensure that any entity can only master a unique node on the chain; at the same time, if an attacker tries to forge other identities through his own node, the first step of the scheme's authentication process is through the first signature Sig A (ID A ,Pub A ) Complete the correspondence between node A’s identity and public key to ensure the authenticity of the identity. The second step is to pass the second signature Ensure the legitimacy of node A's identity. The above three-layer design fully guarantees that attackers cannot successfully forge identities without knowing the private key of a legitimate node, and there is no Sybil attack.

[0082] (6) Forward security: In a cross-domain authentication session, the user and the server must each select a random number r to negotiate the session key. On this basis, even if the master key used for a long time is leaked, the past session key will not be leaked.

[0083] (7) Bidirectional authentication: In the consortium blockchain model built with multiple trust domains, the signature information of users and servers is stored as records in the blockchain. With the assistance of the root node CA, users and servers can achieve mutual authentication and key negotiation.

[0084] (8) Anti-double-spending attack (51% attack): Nodes need to calculate H(σ) through biometrics to ensure the uniqueness of the entity to which the node belongs. This attack cannot be implemented, and malicious nodes cannot occupy more than half of the system nodes. In addition, the present invention believes that under the reasonable use of the system, the secure consensus and incentive mechanism can also ensure that collusion cannot be achieved.

[0085] The complexity is analyzed below:

[0086] 1) No Verification Table Storage Required: Blockchain, as a distributed ledger, records all user registration information and signatures in blocks. This eliminates the need for a central management center to store verification tables to verify user authenticity, saving significant storage space. Furthermore, this invention incorporates biometrics and uses fuzzy extraction to identify and recover legitimate users, enhancing authentication efficiency.

[0087] 2) Alliance Trust: In this cross-domain authentication, a trust network based on the alliance chain is established. Each node in the domain extends its recognition of its own CA to all root nodes in the alliance chain, achieving trust across the entire system. This eliminates the cost of certificate management and maintenance under traditional PKI. Furthermore, the alliance chain offers higher performance than public chains, significantly reducing communication overhead.

[0088] 3) Computational Complexity: First, this invention uses biometrics combined with a fuzzy extractor to effectively verify legitimate users. Second, the authentication process utilizes block records, which are accepted by all nodes. Users only need to determine whether the signature in the block record is legitimate. Furthermore, this invention introduces a message authentication code, which reduces unnecessary signature operations and improves efficiency.

[0089] The use of message authentication codes reduces the computational complexity of signatures. At the same time, basic operations such as XOR and hashing are relatively fast and efficient, so the scheme also performs well in terms of efficiency.

[0090] This invention proposes a cross-domain identity authentication and key agreement method based on a consortium chain, designed to achieve identity authentication and privacy protection for users accessing services or resources across multiple domains in a multi-domain environment. This method utilizes a fuzzy extractor and biometrics to ensure the authenticity and uniqueness of user identities. The irregularity and irreversibility of biometrics also protect the privacy of user nodes. The consortium chain constructs a trust network, ensuring the reliability of the root node. Identity information is stored in a blockchain, and nodes authenticate the identities of other nodes and complete session key agreement through signature verification and message authentication codes. Through this approach, the present invention ensures the security and rationality of requesting services or acquiring resources in a distributed multi-domain network environment. Furthermore, the use of a consortium chain ensures the decentralized and tamper-proof characteristics of blockchain technology while also inheriting its advantages of high efficiency and scalability. Analysis of this solution not only effectively prevents various attacks, such as masquerade and replay attacks, ensuring security, but also demonstrates greater rationality and robustness than traditional PKI and Kerberos domain-based solutions. Finally, this method can be applied in banking, transportation, education, government affairs, healthcare, and other fields to improve the security and efficiency of cross-domain access.

[0091] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if such changes and modifications fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. A cross-domain identity authentication and key agreement method based on alliance chain, characterized in that: The following steps are involved: Steps to establish a trust alliance chain: build an alliance chain based on N relatively independent domains, select a root node in each domain as the CA of the domain; each domain has multiple distributed servers and multiple users; Storage step: Nodes in each domain use blockchain technology to decentralize the storage of node identities and signatures; Authentication steps: Use on-chain access to obtain information and verify the signature for identity authentication; The steps of establishing a trust alliance chain specifically include: In each of N relatively independent domains, a root node is selected as the CA of the domain. Each domain has multiple distributed servers and multiple users, and each server and user is considered a node. The root node CA in each domain establishes a trust alliance chain, selects the elliptic curve group G, and P is the generator of group G; the alliance chain consensus selects the hash function h(·), {0,1} * →{0,1} n ;CA discloses system parameters: {G,P,q,h(·)}, and broadcasts them to nodes in its own domain through consensus; The storing step specifically includes: 1) Obtain the input biometric features of node A, identify them through the fuzzy extractor and compare them with the template database storage information H(σ); H(·) represents the hash function, {0,1} * →G, σ represents the biometric feature; After the comparison is passed, the virtual identity of the node is calculated and the ID A As the real identity hash value of node A; the node selects its own public and private key pair, where Pub = k pri P; Pub represents the public key, k pri Represents a private key; Use the private key to calculate the signature Sig of node A A (ID A ,Pub A ); Send identity creation request information through smart device: {ID A , Pub A ,H(σ),Sig A (ID A ,Pub A )}; where Sig(·) represents the signature function; Pub A Represents the public key of node A; 2) Domain root node CA receives node A's creation request information and calculates h(ID A ,Pub A ); CA queries the chain information to check whether there is an ID A ,h(ID A ,Pub A ); If this information is unique, the creation request is approved and H(σ),h(ID A ,Pub A ) Information is stored on the chain; CA broadcasts information on the chain: {ID A ,H(σ),h(ID A ,Pub A ), Sig A (ID A ,Pub A )}.

2. A cross-domain identity authentication and key agreement method based on alliance chain according to claim 1, characterized in that: The authentication steps specifically include: (1) Every time a user logs into a node, they need to first use a smart device to read and identify their biometrics, and then send a request message to the corresponding server; (2) The corresponding server requests assistance from the root node CA in the domain, and uses the block information on the blockchain to verify the user request message, thereby achieving two-way verification and session key negotiation between the user and the server.

3. A cross-domain identity authentication and key agreement method based on alliance chain according to claim 2, characterized in that: The step (1) comprises: (1.1) User U A Biometrics are collected and recognized by a smart device equipped with a fuzzy recognizer module. The fuzzy extractor is used to recover the function. If the difference between the biometric and the information in the template database is less than ε, the biometric is successfully recovered and H(σ)∈G is calculated; ε represents an error term that is greater than zero and approaches zero. (1.2) User U A Select random number Calculate R A =r A P; User-side computing and R A Signature Represents continuous XOR operations; (1.3) User U A To the target server S B Send request information: Where T represents the timestamp.

4. A cross-domain identity authentication and key agreement method based on alliance chain according to claim 3, characterized in that: The step (2) comprises: (2.1) Server S B Receive user U A The request information sent, check whether the timestamp T is within the trusted range, and then calculate h(ID A ,Pub A ); then server S B To the root node CA of the domain where the node is located B Send assistance request message: {ID A ,h(ID A ,Pub A )}; (2.2) Root Node CA B Received from server S B Assist request message to find out whether there is a corresponding identity and hash value information in the block on the chain; if not, no query result will be fed back; if it exists, the root node CA B Send the corresponding block record to S B :{H(σ), Sig A (ID A ,Pub A )}; (2.3) Server S B Receive verification message and verify signature Sig A (ID A ,Pub A ) is valid; at the same time, use the received D and the chain information H(σ) to calculate Verify signature Is it valid? If the verification is successful, the server S B For user U A Cross-domain authentication.

5. A cross-domain identity authentication and key agreement method based on alliance chain according to claim 4, characterized in that: The step (2.3) further comprises: Server S B Select random number Calculate R B =r B P; using the private key and R A calculate As the key of the message authentication code MAC, calculate and h(R B ||r B ·R A ); Complete the above operations, server S B To user U A Send response message:

6. A cross-domain identity authentication and key agreement method based on alliance chain according to claim 5, characterized in that: The step (2) further comprises: (2.4) User U A Receive the response message sent by the server, check the legitimacy of the timestamp T, and then calculate h(ID B ,Pub B ); then user U A To the root node CA of the domain where the node is located A Send assistance request message: {ID B ,h(ID B ,Pub B )}; (2.5) Root Node CA A After receiving the user's assistance request message, it searches for the corresponding identity and hash value information in the chain block; if not, it will return no query results; if it exists, the root node CA A Record the corresponding block Sig B (ID B ,Pub B ) is sent to user U A ; (2.6) User U A Receive verification message and verify signature Sig B (ID B ,Pub B ) is valid; then use r A and server S B The public key calculation h(r A Pub B ) is calculated and passed through MAC(h(r A Pub B ),R B ) Check the received message R B The authenticity and validity of the hash function h(R B ||r B ·R A ), check whether it is consistent with h(R B ||r B ·R A ) values are equal; if the verification is successful, the user has achieved cross-domain authentication of the server.

7. A cross-domain identity authentication and key agreement method based on alliance chain according to claim 6, characterized in that: The step (2.6) also includes: user U A Send session key confirmation message: {ID A ,h(ID A ||ID B ||r A ·R B }, to the server S B .

8. A cross-domain identity authentication and key agreement method based on alliance chain according to claim 7, characterized in that: The step (2) further comprises: (2.7) Server S B Receive the verification message, calculate and verify h(ID A ||ID B ||r A ·R B ) and h(ID A ||ID B ||r B ·R A ) are equal; if the verification is successful, user U A With server S B Key negotiation is completed, session key sk = r B ·R A =r A ·R B .

Images