A lightweight cross-domain identity authentication and key exchange method based on blockchain technology.

Abstract

This invention discloses a lightweight cross-domain identity authentication and key negotiation method based on blockchain technology. First, a trusted consortium blockchain is established to ensure the trustworthiness of the root node certificate. Then, nodes within each domain broadcast their node identities using blockchain technology, obtain information through on-chain access, and achieve authentication and key negotiation with the help of trusted nodes. This method can resist various common attacks and meets security requirements such as authentication and key negotiation while protecting privacy. Designed to address the timeliness difficulties in cross-domain authentication in fields such as securities and finance, this solution avoids complex operations such as encryption / decryption and signature verification, using lightweight operations such as hashing and XOR. It can be applied in fields such as finance, banking, transportation, education, government affairs, and healthcare, improving the security and efficiency of cross-domain access.

Description

Technical Field

[0001] This invention relates to the field of entity identity authentication technology in cyberspace, and in particular to a lightweight cross-domain identity authentication and key negotiation method based on blockchain technology. Background Technology

[0002] With the rapid development of big data, interactions in the network environment are constantly increasing, and the environment is becoming more complex. Cross-domain authentication plays a crucial role in secure data sharing. In a distributed network environment, cross-domain authentication plays a vital role in secure data sharing and resource services.

[0003] However, traditional centralized cross-domain authentication schemes suffer from problems such as over-reliance on trusted third parties, privacy leaks, and low certificate efficiency.

[0004] Especially in applications such as finance, there are some special requirements for the performance of the entire system, including transaction speed, throughput, and immediacy, as well as privacy protection and cross-domain interoperability.

[0005] As an emerging technology, blockchain's decentralized nature avoids the drawbacks of traditional centralized trust mechanisms and effectively solves cross-domain authentication problems.

[0006] Therefore, how to apply blockchain technology to cross-domain authentication and overcome the drawbacks of decentralized cross-authentication has become an urgent problem for practitioners in the industry. Summary of the Invention

[0007] The purpose of this invention is to provide a lightweight cross-domain identity authentication and key negotiation method based on blockchain technology. It employs a root node based on blockchain technology to establish a trusted consortium blockchain, and achieves cross-domain authentication and key negotiation through on-chain information storage and off-chain authentication. Furthermore, to prevent various network attacks, the solution incorporates a password authentication factor, using timestamps, random numbers, and hash functions.

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

[0009] This invention provides a lightweight cross-domain identity authentication and key negotiation method based on blockchain technology, comprising the following steps:

[0010] Steps to establish a trust consortium blockchain: Build a consortium blockchain based on N relatively independent domains, and select a root node in each domain as the key generation center for that domain; each domain has multiple distributed servers and multiple users;

[0011] Broadcasting steps: Each node in the domain uses blockchain technology to broadcast its node identity;

[0012] Authentication steps: Obtain information through on-chain access, and achieve authentication and key negotiation with the help of trusted nodes.

[0013] Furthermore, the steps for establishing a trust consortium blockchain specifically include:

[0014] In each of the N relatively independent domains, any root node is selected as the key generation center for that domain; each domain has multiple distributed servers and multiple users, and each server and user is considered as a node;

[0015] A trust-based consortium blockchain is established at the key generation centers within each domain, with elliptic curve group G and P as the generators of group G; the consortium blockchain consensus uses a hash function h(·), {0,1}. * →{0,1} n H(·), G1→{0,1} n The key generation center publishes system parameters: {G,P,q,h(·),H(·)}, and broadcasts them to its own nodes within the domain through consensus.

[0016] Furthermore, the broadcasting step specifically includes: a user node creation process and a server node creation process;

[0017] The user node creation process includes:

[0018] 1) User U within domain A i Choose your password PW i Calculate the virtual identity of the user node, and set h(ID) as the virtual identity. i As user U i Real identity hash value; User U i Choose your own public / private key pair P i s i , where P i =s i ·P;P i User U i Public key, s i User U i Private key, P represents generator;

[0019] Calculate password verification information h(ID) i ||PW i Finally, send the identity creation request information: {h(ID)} i ), P i h(ID) i ||PW i )};

[0020] 2) Domain Root Node Key Generation Center (KGC) A After receiving the user node creation request, query the on-chain information to check if h(ID) exists.i );

[0021] If this information is unique, the creation request is approved, and h(ID) is set. i ), P i h(ID) i ||PW i Information is stored on the blockchain; KGC A Broadcast on-chain information: {h(ID) i ), P i h(ID) i ||PW i )}.

[0022] The server node creation process includes:

[0023] a) Server S within Domain B j Choose your password PW j Calculate the virtual identity of the server node, and set h(SID) as the virtual identity. j ) as the real identity hash value; server S j Choose your own public / private key pair P j s j , where P j =s j ·P;P j Indicates server S j Public key, s j Indicates server S j Private key, P represents generator;

[0024] Calculate password verification information h(SID) j ||PW j Finally, the smart device sends an identity creation request: {h(SID)} j ), P j h(SID) j ||PW j )};

[0025] b) Domain Root Node Key Generation Center (KGC) B After receiving the server node creation request, query the on-chain information to check if h(SID) exists. j );

[0026] If this information is unique, the creation request is approved, and h(SID) is set. j ), P j h(SID) j ||PW j Information is stored on the blockchain; KGC B Broadcast on-chain information: {h(SID) j ), P j h(SID)j ||PW j )}.

[0027] Furthermore, the authentication steps specifically include:

[0028] (1) Each time a user logs into a node, they need to authenticate their username and password before sending a request message to the corresponding server.

[0029] (2) The corresponding server requests assistance through the root node KGC in the domain, uses the block information on the blockchain to verify the user request message, and realizes two-way authentication and key negotiation between the user and the server.

[0030] Further, step (1) includes:

[0031] (1.1) User U i Login to the node requires a username and password; the smart device calculates h(ID). i ), h(ID) i ||PW i And check the blockchain storage information h(ID) i ) and h(ID) i ||PW i If a match is found, the node login is successful.

[0032] (1.2) User U i Select random number Calculate R i =r i ·P and N ij =r i ·P j The user end uses P i and N ij To calculate session request information u ij =H(P i +N ij ), After the calculation is completed, user U i calculate

[0033] (1.3) User U i To target server S j Send request information: {h(ID) i ), h(SID) j ), P i R i Mi j ,bi j ,T}, where T represents the timestamp.

[0034] Further, step (2) includes:

[0035] (2.1) Server S j Received from user U i The sent request information checks if the timestamp T is within a trusted range; then server S... j To the Key Generation Center (KGC) of the domain where its own node resides B Send assistance request message: {h(ID) i ), P i};

[0036] (2.2) Root node KGC B Received from server S j The system requests assistance to check if the corresponding identity and public key information exist in the on-chain block; if not, it returns no results; if they exist, the key generation center (KGC) responds. B Record the h(ID) of the corresponding block. i ), h(ID) i ||PW i )as well as Send to server S j ;

[0037] (2.3) Server S j Upon receiving the verification message, use the received R i and its own private key s j Calculate N ij ′=s j ·R i u ij ′=H(P j +N ij ′), then calculate This indicates an XOR operation; it verifies whether the received message matches the message stored on the blockchain, and checks if h(ID) is true. i ||PW i ) = h(ID i ||PW i If the verification passes, it confirms the consistency of the identity of the received message; Server S j verify Is it true? If true, then implement server S. j For user U i Cross-domain identity authentication.

[0038] Furthermore, step (2.3) also includes:

[0039] Server S j Select random number Calculate R j =r j ·P and Nji =r j ·P j The server utilizes P j and N ji Calculate session feedback information u ji =H(PI+N) ji ), Server S j calculate and session key sk ji =r j ·R i ; Select the cyclic group calculate After completing the above operations, server S j To user U i Send response information: {h(ID) i ), h(SID) j ), P j R j M ji b ji TK ji ,h(V),T}.

[0040] Furthermore, step (2) also includes:

[0041] (2.4) User U i Upon receiving the response from the server, the validity of the timestamp T is checked, and then user U... i To the key generation center KG in the domain where its own node is located xA Send assistance request message: {h(SID) j ), P j};

[0042] (2.5) Key Generation Center (KGC) A Upon receiving a user's assistance request, the system checks if the corresponding identity and public key information exist in the on-chain block. If not, it reports no query results; if they exist, the key generation center (KGC) responds. A Send the corresponding block record to U i :{h(SID) j ), h(SID) j ||PW j )}, and send them together

[0043] (2.6) User U i Upon receiving the verification message, use the received R j and its own private key s i Calculate N ji ′=s i ·R j uji ′=H(P j +N ji ′); Calculate after completion Verify whether the received message matches the message stored on the blockchain, i.e., verify h(SID). j ||PW j )=h(SID j ||PW j Is the verification true? If the verification passes, it confirms the consistency of the message receiver's identity; User U i Then verify If the verification passes, it confirms the authenticity and legitimacy of the recipient's identity; then U i Calculate session key sk ij =r i ·R j The user uses the received TK ji calculate A hash operation is performed on V′ and compared with the received message, i.e., it is verified whether h(V) = h(V′) are consistent. If the hash values ​​are consistent, the user terminal considers that authentication and key negotiation have been completed. After all the above operations are successful, user U... i Send session key confirmation information: {h(ID) i ), h(SID) j ), h(V′+1)}.

[0044] Furthermore, step (2) also includes:

[0045] (2.7) Server S j Upon receiving the verification message, calculate and verify whether h(V+1) and h(V′+1) are equal; if the verification passes, user U... i With server S j Key negotiation completed, session key sk = sk ji =sk ij .

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

[0047] This invention provides a lightweight cross-domain identity authentication and key negotiation method based on blockchain technology. First, a trusted consortium blockchain is established to ensure the trustworthiness of the root node certificate. Then, nodes within each domain broadcast their node identities using blockchain technology, obtain information through on-chain access, and achieve authentication and key negotiation with the help of trusted nodes. From an attack perspective, this method can resist various common attacks and achieves security requirements such as authentication and key negotiation, as well as privacy protection. This scheme is designed to address the timeliness difficulties in cross-domain authentication in fields such as securities and finance. It avoids encryption / decryption and signature verification, and reduces key management overhead by leveraging the IBC (Independent Key Authentication) concept. Algorithmically, it utilizes fast algorithms such as hash functions and point addition on elliptic curves. This method avoids complex operations such as encryption / decryption and signature verification, completing the process through lightweight operations such as hashing and XOR. It can be applied in fields such as finance, banking, transportation, education, government affairs, and healthcare, improving the security and efficiency of cross-domain access. Attached Figure Description

[0048] Figure 1 This is a system architecture diagram for entity cross-domain access authentication provided in an embodiment of the present invention;

[0049] Figure 2 This is a schematic diagram illustrating the creation stage of any node within each domain, as provided in an embodiment of the present invention.

[0050] Figure 3 This is a flowchart illustrating the authentication and key negotiation phases provided in an embodiment of the present invention. Detailed Implementation

[0051] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0052] In the description of this invention, it should be noted that the terms "upper," "lower," "inner," "outer," "front end," "rear end," "both ends," "one end," and "the other end," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0053] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installed," "equipped with," "connected," etc., should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0054] This invention provides a lightweight cross-domain identity authentication and key negotiation method based on blockchain technology. Leveraging blockchain technology, it achieves relatively decentralized identity verification, allowing all citizen entities, service providers, or platforms to act as nodes within the blockchain system. Often, nodes within different branches of the same platform or company need to conduct business transactions or exchange information. When nodes in different systems need to conduct cross-domain conversations, transmit information, and provide services, blockchain cross-domain authentication enables authentication and key negotiation between nodes. This method avoids complex operations such as encryption / decryption and signature verification, instead using lightweight operations like hashing and XOR. It can be applied in fields such as finance, banking, transportation, education, government affairs, and healthcare.

[0055] This invention provides a lightweight cross-domain identity authentication and key negotiation method based on blockchain technology. It introduces an identity-based cryptography system and combines it with blockchain technology to achieve cross-domain identity authentication and key negotiation. Specifically, it includes:

[0056] Steps to establish a trust consortium blockchain: Build a consortium blockchain based on N relatively independent domains, and select a root node in each domain as the key generation center for that domain; each domain has multiple distributed servers and multiple users;

[0057] Broadcasting steps: Each node in the domain uses blockchain technology to broadcast its node identity;

[0058] Authentication steps: Obtain information through on-chain access, and achieve authentication and key negotiation with the help of trusted nodes.

[0059] This method first establishes a trusted consortium blockchain to ensure the trustworthiness of the root node certificate. Then, nodes within each domain use blockchain technology to broadcast their node identities, obtain information through on-chain access, and achieve authentication and key negotiation with the help of trusted nodes. The framework is as follows: Figure 1 As shown,

[0060] This method primarily studies the authentication and key negotiation issues when users or servers in different domains need to access each other across domains. A trusted architecture based on a consortium blockchain is constructed. Typically, the scheme involves N relatively independent domains, with a root node selected as the KGC in each domain, and m distributed servers S.j (j = 1, 2, ..., m) and n users U i (i = 1, 2, ..., n), where S j Several different access or application services can be provided. Users verify their legitimacy through username and password. After successful verification, they can access a distributed server connected to the Internet. With the assistance of the root KGC, the server uses blockchain information data to verify user identity and negotiates session keys based on the established legitimate authentication.

[0061] This method proposes a lightweight, password-based cross-domain authentication scheme, allowing legitimate user nodes to easily log in to their own nodes and access server services. This embodiment includes a user node creation phase, a server node creation phase, and an authentication and key negotiation phase.

[0062] At the outset, this embodiment provides the symbols used in the scheme and their corresponding meanings, as shown in Table 1:

[0063] Table 1 Symbol Explanation

[0064]

[0065] First, the root node KGC in each domain establishes a trusted consortium blockchain. Then, an elliptic curve group G is selected, where P is the generator of group G. The consortium blockchain consensus selects hash functions h(·) and H(·). Finally, KGC broadcasts the system parameters {G, P, q, h(·), H(·)}, where q represents the order of the group, to its own domain nodes via consensus.

[0066] Node creation phase:

[0067] Using blockchain technology, any user U i To communicate and access the network, users need to create their own node. First, users choose their own password to verify their identity using information stored on the blockchain when logging into the node later. Then, users select a public-private key pair and submit the public key, identity information, and other relevant information to the root node KGC of their domain to upload their identity information to the blockchain. Afterwards, KGC broadcasts some of the information to the blockchain. The user node creation process is as follows: Figure 2 As shown.

[0068] Step 1: First, user U in domain A... i Choose your password PW i The initial password selection during node identity creation is for later user login verification using a username and password. Afterwards, the user calculates the node's virtual identity, h(ID). i The hash value is the real identity hash. Then the user selects their own public / private key pair P. i s i, where P i =s i ·P, then calculate the password verification information h(ID) i ||PW i Finally, send the identity creation request information: {h(ID)} i ), P i h(ID) i ||PW i )}.

[0069] Step 2: Domain Root Node KGC A After receiving the user node creation request, query the on-chain information to check if h(ID) exists. i If this information is unique, the creation request is approved, and h(ID) is set. i ), P i h(ID) i ||PW i Information such as ) is stored on the blockchain. KGC A Broadcast on-chain information: {h(ID) i ), P i h(ID) i ||PW i )}.

[0070] This solution uses blockchain technology. To facilitate cross-domain authentication, any server S... j The node creation process is consistent with the user's node creation process. All nodes within the domain have the same attributes, but implement different functions. Similarly, the server node creation process is as follows: Figure 2 As shown.

[0071] Step 1: First, server S within domain B... j Choose your password PW j The initial password selection for node identity creation is for later login authentication via username and password when logging into the node on the server. Afterwards, the server calculates the node's virtual identity, h(SID). j The hash value is the real identity. Then the server selects its own public / private key pair P. j s j , where P j =s j ·P, then calculate the password verification information h(SID) j ||PW j Finally, the smart device sends an identity creation request: {h(SID)} j ), P j h(SID) j ||PW j )}.

[0072] Step 2: Domain Root Node KGC B After receiving the server node creation request, query the on-chain information to check if h(SID) exists. j If this information is unique, the creation request is approved, and h(SID) is set. j ), P j h(SID) j ||PW j Information such as ) is stored on the blockchain. KGC B Broadcast on-chain information: {h(SID) j ), P j h(SID) j ||PW j )}.

[0073] Authentication and key negotiation phase:

[0074] When a user needs to log in to the system, they need to contact a specific server. j When requesting a service, a cross-domain mutual authentication process is required. Each time a user logs into a node, they must first authenticate with their username and password, and then send a specific message to a specific server. The server requests assistance from the root node KGC within the domain, using block information on the blockchain to verify the user message, thereby achieving two-way authentication and key negotiation between the user and the server, ensuring security. The authentication and key negotiation process is as follows: Figure 3 As shown.

[0075] Step 1: First, user U i Login to the node requires a username and password; the smart device calculates h(ID). i ), h(ID) i ||PW i And check the blockchain storage information h(ID) i ) and h(ID) i ||PW i If a match is found, the node login is successful. Then U i Select random number Calculate R i =r i ·P and N ij =r i ·P j Finally, the user end uses P i and N ij To calculate session request information u ij =H(P i +N ij ), After completing the above calculations, user U i calculate After completing the above operations, user Ui To target server S j Send request information: {h(ID) i ), h(SID) j ), P i R i M ij b ij ,T}. Among them, This represents the public key pub of KGC within domain B.

[0076] Step 2: Server S j Upon receiving a request from a user, the server first checks if the timestamp T is within a trusted range. Then, the server sends a request to the KGC (Knowledge, Collection, and Controller) of its own node's domain. B Send assistance request message: {h(ID) i ), P i}

[0077] Step 3: Root Node KGC B Upon receiving a server assistance request message, the system searches for the corresponding identity and public key information in an on-chain block. If the information does not exist, it reports "no query results"; otherwise, KGC... B Record the h(ID) of the corresponding block. i ), h(ID) i ||PW i )as well as Send to S j . This is a dot product operation, representing the private key multiplication P within field B. i .

[0078] Step 4: Server S j Received verification message. First, use the received R... i and its own private key s j Calculate N ij ′=s j ·R i u ij ′=H(P j +N ij Once completed, calculations can be performed. Verify that the received message matches the message stored on the blockchain, and confirm whether h(ID) is true. i ||PW i ) = h(ID i ||PW i If the verification passes, it confirms the consistency of the identity of the recipient. Server S j verify Is it true? Because M ij Through user U i private keyi The calculated value, if verified, confirms the authenticity and legitimacy of the recipient's identity. Then S... j Select random number Calculate R j =r j P and N ji =r j ·P j Finally, the server uses P j and N ji To calculate session feedback information u ji =H(P i +N ji ), This represents the KGC public key within domain A. Server S j calculate and session key sk ji =r i ·R i To ensure the security of the session key, S j Select the cyclic group calculate Server S j To user U i Send response information: {h(ID) i ), h(SID) j ), P j R j M ji b ji TK ji ,h(V),T}.

[0079] Step 5: User U i Upon receiving the response from the server, the system first checks the validity of the timestamp T, and then sends a request to the KGC of its own node's domain. A Send assistance request message: {h(SID) j ), P j}

[0080] Step 6: Root Node KGC A Upon receiving a user's request for assistance, the system searches the on-chain block for the corresponding identity and public key information. If the information does not exist, it reports "no search results found"; otherwise, it sends a KGC response. A Send the corresponding block record to U i :{h(SID) j ), h(SID) j ||PW j )}, and send them together

[0081] Step 7: User U i Upon receiving the verification message, first utilize the received R j and its own private key s i Calculate N ji ′=s i ·R j u ji ′=H(P j +N ji Once completed, calculations can be performed. Verify whether the received message matches the message stored on the blockchain, i.e., verify h(SID). j ||PW j )=h(SID j ||PW j Is the verification valid? If the verification passes, the identity of the message receiver is confirmed to be consistent. User U i Then verify Is it true? Because M ji Through server S j private key j The calculated value, if verified, confirms the authenticity and legitimacy of the recipient's identity. Then U i Calculate session key sk ij =r i ·R j The user uses the received TK ji calculate A hash operation is performed on V′ and compared with the received message; that is, it is verified whether h(V) = h(V′) matches. If the hash values ​​match, the user considers that authentication and key negotiation have been completed. To achieve server-side confirmation, after all the above operations are successful, user U... i Send session key confirmation information: {h(ID) i ), h(SID) j ), h(V′+1)}.

[0082] Step 8: Service S j Upon receiving the verification message, calculate and verify whether h(V+1) is equal to the received h(V′+1). If the verification passes, the user and server complete key negotiation, and the session key sk = sk ji =sk ij .

[0083] From an attack perspective, the following theoretical analysis demonstrates that the solution of this invention can resist various common attacks and achieve security requirements such as authentication and key negotiation, as well as privacy protection.

[0084] (1) Replay Attack Resistance: The addition of elements such as a timestamp T during the authentication process helps prevent replay attacks. Simultaneously, this invention employs a query-response mechanism to... ij ,R i ,R j The verification message is incorporated into the authentication process. The validity of the bilinear pair ensures that the message is authentic and has not been tampered with, thus resisting replay attacks.

[0085] (2) Resistance to Impersonation Attacks: The scheme design stores the node's identity, password, and public key information in the blockchain, and compares the personal password and identity information transmitted by the node with the information in the blockchain. The node determines the authenticity of the message sender's identity based on the validity of the received message. Meanwhile, M... ij With the user's private key i This is related to the public key of the root node KGC of the accessed domain. The user's private key is known only to the user, thus ensuring security. On the other hand, due to Pub... KGC This is a public parameter, which can be used by legitimate internal users without knowing the user's private key. However, this invention utilizes a cross-domain access mechanism, meaning only users of the accessed domain can use this parameter. But if the two nodes in the cross-domain access belong to different synchronization domains, the domain root node KGC will refuse the service when assisting with the access.

[0086] (3) Resistance to internal attacks: The solution of this invention is based on blockchain. Even if the attacker is an internal user or server, because the private key of this invention is controlled by the user and a password authentication factor is introduced, malicious internal users and servers cannot perform bilinear operations or calculate the session key. Therefore, the solution can effectively resist internal attacks.

[0087] (4) Anti-DDoS attack: The solution is built on the blockchain and uses the blockchain to achieve a decentralized architecture. At the same time, the consensus and distributed storage of nodes in the blockchain ensure that all participants have a 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.

[0088] (5) Resistance to Sybil Attacks: The solution is based on a password factor design, implementing basic verification using username plus password; simultaneously, if an attacker attempts to forge other identities through their own node, the first step of the authentication process will fail. Calculate h(ID) i ||PW i The system compares the information on the blockchain with the identity, public key, and password to ensure the authenticity of the identity. It is important to note here that... ij ′ is with the help of N ij The result is calculated from N. ij′ is calculated by the server using its own private key, and an adversary cannot calculate the correct N. ij The second step involves calculation. The system verifies identity by checking if the statement is valid. This verification includes the user node's private key, and only legitimate users can pass the verification, ensuring the legitimacy of the identity. This three-layer design completely guarantees that attackers cannot successfully forge an identity without knowing the legitimate node's private key, thus eliminating the possibility of Sybil attacks.

[0089] (6) Forward security: In cross-domain authentication sessions, both the user and the server must select a random number r to negotiate the session key. Based on this, even if the master key used for a long time is leaked, it will not cause the leakage of past session keys.

[0090] (7) Two-way authentication: In the consortium blockchain model built with multiple trust domains, the public keys and passwords of users and servers are stored as records in the blockchain. With the assistance of the root node KGC, users and servers can achieve mutual authentication and key negotiation by using bilinear pairs.

[0091] (8) Anti-double-spending attack (51% attack): The scheme incorporates a password authentication factor. Only the node itself knows the password and private key, and there is no password attack. Therefore, double-spending attacks cannot be achieved, and malicious nodes cannot occupy more than half of the system's nodes. Furthermore, this invention believes that under reasonable use, the secure consensus and incentive mechanism can also ensure that collusion cannot be achieved.

[0092] The following is an analysis of the complexity:

[0093] 1) No need to store verification tables: As a distributed ledger, blockchain broadcasts all user registration information and signatures as records in blocks, eliminating the need for the management center to verify whether a user is a system user by storing verification tables, thus saving a lot of storage space.

[0094] 2) Consortium Trust: In the cross-domain authentication of this invention, a trust network based on a consortium blockchain is established. The recognition of the KGC within each domain by each node extends to the recognition of all root nodes in the consortium blockchain, realizing trust throughout the entire system. This avoids the cost of certificate management and maintenance under traditional PKI, while the consortium blockchain has higher performance than public blockchains, greatly reducing communication overhead.

[0095] 3) Computational complexity: First, this scheme uses bilinear pairing operations, which can effectively verify the legitimacy of users and improve efficiency. Second, the authentication process relies on block records, and this information is accepted by all nodes. Users only need to determine whether the information in the obtained information field block record is consistent. At the same time, this invention introduces a password authentication factor, which reduces signature and encryption / decryption operations, realizing a lightweight scheme.

[0096] This invention proposes a lightweight cross-domain identity authentication and key negotiation method based on blockchain technology to achieve identity authentication for users accessing services or resources across domains in a multi-domain environment. This method primarily addresses identity authentication issues in fields such as finance and securities, where users need to obtain data instantly and respond and operate quickly. The lightweight solution can rapidly achieve system authentication, breaking down information silos between institutions or units and enabling business collaboration through blockchain. The solution utilizes password authentication factors for login authentication, ensuring the authenticity of user identities. A trust network is built using a consortium blockchain to ensure the reliability of root nodes. Identity information is stored on the blockchain, and nodes verify the legitimacy of other nodes' identities by comparing the information obtained from the blockchain with the received information. Simultaneously, the solution uses the received information and existing on-chain information to complete the authenticity and integrity authentication of node identities through hash and dot-matrix operations. Session key negotiation is completed between communicating parties using the discrete logarithm problem and the concept of key sharing. Through these methods, the solution of this invention ensures the security and legitimacy of requesting services or obtaining resources in a distributed multi-domain network environment. On the one hand, the solution utilizes a consortium blockchain, ensuring the decentralized and immutable characteristics of blockchain technology and protecting user information privacy, while also inheriting the advantages of consortium blockchains such as high efficiency and strong scalability. On the other hand, the solution uses hash functions and XOR to achieve lightweight authentication. Analysis shows that this solution not only effectively avoids various attacks such as spoofing and replay attacks, ensuring security, but is also more efficient than traditional encryption and decryption schemes.

[0097] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A lightweight cross-domain identity authentication and key negotiation method based on blockchain technology, characterized in that, Includes the following steps: Steps to establish a trust consortium blockchain: Build a consortium blockchain based on N relatively independent domains, and select a root node in each domain as the key generation center for that domain; Each domain contains multiple distributed servers and multiple users; Broadcasting steps: Each node in the domain uses blockchain technology to broadcast its node identity; Specifically, this includes: the user node creation process and the server node creation process; The user node creation process includes: 1) User U within domain A i Choose your password PW i Calculate the virtual identity of the user node, and set h(ID) as the virtual identity. i As user U i Real identity hash value; User U i Choose your own public / private key pair P i s i , where P i =s i ·P;P i User U i Public key, s i User U i Private key, P represents generator; Calculate password verification information h(ID) i ||PW i Finally, send the identity creation request information: {h(ID)} i ), P i h(ID) i ||PW i )}; 2) Domain Root Node Key Generation Center (KGC) A After receiving the user node creation request, query the on-chain information to check if h(ID) exists. i ); If this information is unique, the creation request is approved, and h(ID) is set. i ), P i h(ID) i ||PW i Information is stored on the blockchain; KGC A Broadcast on-chain information: {h(ID) i ), P i h(ID) i ||PW i )}; The server node creation process includes: a) Server S within Domain B j Choose your password PW j Calculate the virtual identity of the server node, and set h(SID) as the virtual identity. j ) as the real identity hash value; server S j Choose your own public / private key pair P j s j , where P j =s j ·P;P j Indicates server S j Public key, s j Indicates server S j Private key, P represents generator; Calculate password verification information h(SID) j ||PW j Finally, the smart device sends an identity creation request: {h(SID)} j ), P j h(SID) j ||PW j )}; b) Domain Root Node Key Generation Center (KGC) B After receiving the server node creation request, query the on-chain information to check if h(SID) exists. j ); If this information is unique, the creation request is approved, and h(SID) is set. j ), P j h(SID) j ||PW j Information is stored on the blockchain; KGG B Broadcast on-chain information: {h(SID) j ), P j h(SID) j ||PW j )}; Authentication steps: Information is obtained through on-chain access, and authentication and key negotiation are achieved with the help of trusted nodes; specifically including: (1) Each time a user logs into a node, they need to authenticate their username and password before sending a request message to the corresponding server. (2) The corresponding server requests assistance from the root node KGC within the domain, verifies the user request message using block information on the blockchain, and realizes two-way authentication and key negotiation between the user and the server; specifically including: (2.1) Server S j Received from user U i The sent request information checks if the timestamp T is within a trusted range; then server S... j To the Key Generation Center (KGC) of the domain where its own node resides B Send assistance request message: {h(ID) i ), P i }; (2.2) Root node KGC B Received from server S j The system requests assistance to check if the corresponding identity and public key information exist in the on-chain block; if not, it returns no results; if they exist, the key generation center (KGC) responds. B Record the h(ID) of the corresponding block. i ), h(ID) i ||PW i )as well as Send to server S j ; (2.3) Server S j Upon receiving the verification message, use the received R i and its own private key s j Calculate N ij ′=s j ·R i u ij ′=H(P j +N ij ′), then calculate This represents an XOR operation to check whether the received message matches the message stored on the blockchain, verifying whether h(ID) is true. i ||PW i ) = h(ID i ||PW i If the verification passes, it confirms the consistency of the identity of the received message; Server S j verify Is it true? If true, then implement server S. j For user U i Cross-domain identity authentication; Server S j Select random number Calculate R j =r j ·P and N ji =r j ·P j The server utilizes P j and N ji Calculate session feedback information u ji =H(P i +N ji ), Server S j calculate and session key sk ji =r j ·R i ; Select the cyclic group calculate After completing the above operations, server S j To user U i Send response information: {h(ID) i ), h(SID) j ), P j R j M ji b ji TK ji ,h(V),T}; (2.4) User U i Upon receiving the response from the server, the validity of the timestamp T is checked, and then user U... i To the Key Generation Center (KGC) of the domain where its own node resides A Send assistance request message: {h(SID) j ), P j }; (2.5) Key Generation Center (KGC) A Upon receiving a user's assistance request, the system checks if the corresponding identity and public key information exist in the on-chain block. If not, it reports no query results; if they exist, the key generation center (KGC) responds. A Send the corresponding block record to U i :{h(SID) j ), h(SID) j ||PW j )}, and send them together (2.6) User U i Upon receiving the verification message, use the received R j and its own private key s i Calculate N ji ′=s i ·R j u ji ′=H(P j +N ji ′); Calculate after completion Verify whether the received message matches the message stored on the blockchain, i.e., verify h(SID). j ||PW j )=h(SID j ||PW j Is the verification true? If the verification passes, it confirms the consistency of the message receiver's identity; User U i Then verify If the verification passes, it confirms the authenticity and legitimacy of the recipient's identity; then U i Calculate session key sk ij =r i ·R j The user uses the received TK ji calculate A hash operation is performed on V′ and compared with the received message, i.e., it is verified whether h(V) = h(V′) are consistent. If the hash values ​​are consistent, the user terminal considers that authentication and key negotiation have been completed. After all the above operations are successful, user U... i Send session key confirmation information: {h(ID) i ), h(SID) j ), h(V′+1)}; (2.7) Server S j Upon receiving the verification message, calculate and verify whether h(V+1) and h(V′+1) are equal; if the verification passes, user U... i With server S j Key negotiation completed, session key sk = sk ji =sk ij .

2. The lightweight cross-domain identity authentication and key negotiation method based on blockchain technology according to claim 1, characterized in that, The steps for establishing a trust alliance chain specifically include: In each of the N relatively independent domains, any root node is selected as the key generation center for that domain; each domain has multiple distributed servers and multiple users, and each server and user is considered as a node; A trust-based consortium blockchain is established at the key generation centers within each domain, with elliptic curve group G and P as the generators of group G; the consortium blockchain consensus uses a hash function h(·), {0,1}. * →{0,1} n H(·), G1→{0,1} n The key generation center publishes system parameters: {G,P,q,h(·),H(·)}, and broadcasts them to its own nodes within the domain through consensus.

3. The lightweight cross-domain identity authentication and key negotiation method based on blockchain technology according to claim 1, characterized in that, Step (1) includes: (1.1) User U i Login to the node requires a username and password; the smart device calculates h(ID). i ), h(ID) i ||PW i And check the blockchain storage information h(ID) i ) and h(ID) i ||PW i If a match is found, the node login is successful. (1.2) User U i Select random number Calculate R i =r i ·P and N ij =r i ·P j The user end uses P i and N ij To calculate session request information u ij =H(P i +N ij ), After the calculation is completed, user U i calculate (1.3) User U i To target server S j Send request information: {h(ID) i ), h(SID) j ), P i R i M ij b ij ,T}, where T represents the timestamp.

Images