An identity authentication method for alliance chain cross-chain

Abstract

The application discloses a kind of identity authentication methods for alliance chain cross-chain, to meet the complete compatibility of user identity authentication in alliance chain cross-chain process, conditional anonymity, un-linkable demand.The present application is divided into two parts: constructing the cross-chain system of alliance chain based on relay chain and designing the cross-chain authentication protocol of privacy protection.Based on the cross-chain system of alliance chain based on relay chain, all the cryptographic configuration information of alliance chain is saved by deploying a relay chain, and the relay chain is responsible for the verification and forwarding of cross-chain transaction, which avoids the problem of not supporting cryptographic configuration in identity authentication on the visited chain, and achieves complete compatibility.The completely cross-chain authentication protocol of privacy protection generates pseudonym for users using homomorphic encryption technology and auditor public key, realizes user identity anonymization while ensuring auditor traceability, and achieves conditional anonymity.Finally, the pseudonym of user is updated with its public key, which can resist link attack based on on-chain record and achieve un-linkability.

Description

Technical Field

[0001] This invention relates to the fields of blockchain technology and applications, and government information management in a big data environment, specifically to the field of blockchain application supervision in industries such as finance, communications, energy, and logistics. Background Technology

[0002] In recent years, consortium blockchain technology, with its characteristics of distributed deployment, data immutability, and transaction traceability, has been widely used in industries vital to national welfare, such as finance, logistics, and healthcare. Driven by mutual interests, organizations of all sizes within these industries often form multiple alliances and build multiple consortium blockchains. Because industry data is stored fragmented across different consortium blockchains, these data silos have become obstacles to business collaboration and information exchange within the industry. Addressing this serious issue, enabling cross-chain data access between consortium blockchains has become a common concern for both industry and academia.

[0003] If a user on consortium blockchain A wants to access data on consortium blockchain B, how blockchain B verifies the user's identity is the first problem that needs to be solved to achieve secure cross-chain data access. Currently, some researchers have paid attention to this problem and attempted to apply existing authentication methods to cross-chain data access scenarios. However, they have not fully considered three key issues.

[0004] First, the authentication scheme must overcome the differences in implementation technologies of consortium blockchains and achieve full compatibility. Some studies have only proposed authentication schemes for cross-chain data access on homogeneous blockchains, without considering the complexities of heterogeneous blockchains. Other studies, for cross-chain data access on heterogeneous blockchains, propose that all participating nodes and users must modify their cryptographic settings to meet uniform requirements. This approach not only incurs significant reconfiguration overhead but also increases the burden on users and nodes managing multiple sets of keys. Full compatibility means that nodes and users on consortium blockchains can complete cross-chain authentication using existing cryptographic settings.

[0005] Secondly, identity authentication schemes must protect user privacy while possessing identity traceability capabilities to achieve conditional anonymity. Some studies on cross-chain asset transactions only consider the privacy protection of transaction information, neglecting the privacy protection of user identity. While some studies have proposed methods for anonymizing user identity, these methods do not provide traceability capabilities. Specifically, conditional anonymity requires that throughout the entire cross-chain process, no other node can obtain the user's real identity, and only the audit node can trace the user's real identity.

[0006] Finally, identity authentication schemes must defend against chaining attacks based on on-chain records to protect user privacy and achieve unlinkability. All nodes on a consortium blockchain jointly maintain a ledger; an attacker could compromise and control some nodes, thereby reading all records in the ledger. Attackers can analyze user behavior patterns by linking multiple records, thus inferring the user's identity. Currently, research has achieved anonymization of user identities, but it cannot defend against chaining attacks. Therefore, cross-chain identity authentication schemes should possess unlinkability.

[0007] To address the aforementioned issues, this invention proposes a cross-chain authentication method for consortium blockchains. By deploying a relay chain to adapt to the cryptographic settings of all consortium blockchains, users can initiate cross-chain transactions using their existing cryptographic configurations, thus achieving full compatibility. Homomorphic encryption and the auditor's public key are used to generate pseudonyms for users, ensuring conditional anonymity, as only the auditor can trace the user's true identity. Users are allowed to generate their own public-private key pairs, with the pseudonym updating along with the public key, thus achieving unlinkability. This invention solves the user authentication needs in cross-chain consortium blockchains and contributes to the healthy development of the blockchain industry. Summary of the Invention

[0008] This invention addresses the challenges of cross-chain identity authentication in current consortium blockchains. It delves into relevant cross-chain technologies and authentication schemes, and proposes a cross-chain identity authentication method for consortium blockchains to meet the requirements of full compatibility, conditional anonymity, and non-linkability in the consortium blockchain cross-chain authentication process. This method consists of two main steps: constructing a consortium blockchain cross-chain system based on a relay chain and designing a privacy-preserving cross-chain authentication protocol.

[0009] S1: Build a cross-chain system for consortium blockchains based on a relay chain. To achieve secure cross-chain access between consortium blockchains, a cross-chain system based on a relay chain will be built. For example... Figure 1 As shown, the system contains a relay chain and several parallel chains. The specific process of building the system can be divided into the following two steps: building the relay chain and connecting the parallel chains.

[0010] S11: Construct the relay chain. For example... Figure 1 As shown, the relay chain is the core component of a cross-chain system, responsible for verifying and forwarding cross-chain transactions. The specific process of building a relay chain can be divided into the following five steps:

[0011] (1) Establishing a Global Trusted Authority (GTA). Before building the relay chain, a Global Trusted Authority (GTA) must first be selected as the trust anchor. Multiple organizations participating in the relay chain construction vote to jointly select a fully trustworthy GTA. The GTA provides a registration interface to the outside world, providing registration services for the relay chain and parachains.

[0012] (2) Deploying Relay Chain Nodes. Relay chain nodes are divided into two categories: validator nodes and audit nodes (AD). Validator nodes are ordinary nodes responsible for verifying and forwarding cross-chain transactions, while AD nodes are privileged nodes on the relay chain responsible for tracing the identity of anonymous cross-chain transaction initiators. First, the regulator deploys an AD node. Then, the multiple organizations participating in building the relay chain determine the number of validator nodes based on the security and scalability requirements of the cross-chain system and deploy them jointly. Next, both validator nodes and audit nodes generate public-private key pairs locally and send certificate issuance requests to the GTA. Finally, the GTA completes the node identity registration and issues digital certificates to them.

[0013] (3) Construct a relay chain network. Using the relay chain node certificate information obtained in step (2), configure the network information of the relay chain on all relay chain nodes to ensure network communication between relay chain nodes.

[0014] (4) Start the relay network. Configure the startup environment for the relay network and initialize the relay network.

[0015] (5) Generate and publish cross-chain system parameters. As a privileged node on the relay chain, AD is responsible for generating and publicly publishing the parameters of the cross-chain system. First, AD generates a pair of Paillier homomorphic public and private keys. <pk AD ,sk AD >, where pk AD =(n, g), sk AD = (λ, μ). Then AD chooses a hash function. Finally, AD publicly releases its homomorphic public key and the selected hash function as a set, and secretly stores sk. AD .

[0016] S12: Connecting Parachains. After completing the relay chain construction, several consortium chains need to be connected as parachains to form a cross-chain system. At this point, the parachains to be connected already possess a complete consortium chain ecosystem, have been configured with cryptographic components that meet business needs, and all on-chain nodes and users possess identity credentials issued by their respective Identity Management Authority (IMA). This step completes the connection of the parachains to the relay chain. The specific process consists of the following four steps:

[0017] (1) Parachain Selection of Verification Nodes. Before connecting to the cross-chain system, the parachain needs to select several verification nodes. Based on the security requirements of the parachain, the number of verification nodes is set to N, and N nodes are randomly selected as verification nodes according to the parachain node identifiers.

[0018] (2) Parachain initiates registration request. The parachain administrator submits a parachain registration request through the GTA registration interface, which includes basic information about the parachain and cryptographic configuration information. The basic information includes parachain business information, number of nodes, and the associated IMA public key pk. IMA Verify the node's IP address and its public key information, as well as the cryptographic configuration information, including the signature algorithm, hash algorithm, etc.

[0019] (3) The relay chain completes the registration process. This involves the following four steps:

[0020] a) GTA generates a unique identifier (CID) for the parachain to be connected, and sets the parachain identifier (CID) and its associated IMA public key (pk) together. IMA It is stored locally as key-value pairs.

[0021] b) GTA stores the cryptographic configurations such as signature algorithms and hash algorithms used by the parachains in the relay chain. The verification nodes on the relay chain need to be configured with relevant cryptographic components to ensure that the cryptographic algorithms used on the parachains can be implemented on the relay chain.

[0022] c) The GTA query verifies the current allocation of nodes, selects the verifier node with the lowest load, and stores the parachain identifier CID, the verifier node IP address and its public key for subsequent communication with that parachain.

[0023] d) GTA sends the parachain identifier CID and the verification node IP address to the assigned verification node, and returns the parachain identifier CID and the assigned verification node IP address to the parachain.

[0024] (4) Parachain completes access connection. After receiving the registration result, the verification node stores the communication information of the assigned verification node locally and publishes the CID within the parachain. Finally, the verification node on the parachain establishes a connection with the corresponding verification node on the relay chain.

[0025] S2: Design a privacy-preserving, fully cross-chain authentication protocol. To achieve full compatibility, conditional anonymity, and non-linkability during the cross-chain process, a privacy-preserving, fully cross-chain authentication protocol is designed. The specific process consists of the following four steps: cross-chain registration of parachain users, cross-chain identity verification, user pseudonym update, and user identity traceability.

[0026] S21: Parachain User Cross-Chain Registration. Users on a parachain can only initiate cross-chain transactions after completing registration in the cross-chain system. The user cross-chain registration process consists of the following 7 steps:

[0027] (1) The user initiates a cross-chain registration request. The user on the parachain sends a cross-chain registration request message Msg1 to the IMA to which it belongs. As shown in formula (1), Msg1 contains the user identity cred, timestamp tst, and the user's signature result σ1 on tst.

[0028] Msg1 = {cred, tst, σ1} (1)

[0029] (2) IMA processes the registration request. After receiving message Msg1, IMA first checks whether the user cred is valid, and then verifies the validity of the signature σ1 based on the user cred. If the verification fails, the registration fails; if the verification succeeds, a unique identity identifier ID = H0(cred||CID) is generated for the user in the cross-chain system, and a parachain user registration request message Msg2 is sent to GTA. As shown in formula (2), Msg2 contains the user identity identifier ID, the user cred, the parachain identifier CID, and σ2 obtained by IMA signing (ID||cred||CID).

[0030] Msg2={ID,cred,CID,σ2} (2)

[0031] (3) GTA verifies the registration request. After receiving the request message Msg2, GTA first uses the IMA public key corresponding to the CID to verify the validity of the signature σ2. Then, GTA calculates ID′=H0(cred||CID) based on cred and CID, and determines whether it is the same as the ID in Msg2. Finally, it checks whether the user is in the blacklist based on the user's identity ID. If all verifications pass, proceed to step (5); otherwise, proceed to step (4).

[0032] (4) The GTA rejects the registration request. The GTA returns a user registration rejection message Msg3 = {InvalidID} to the IMA. Upon receiving Msg3, the IMA immediately returns a registration failure message Msg4 = {Resigtration Failure} to the user;

[0033] (5) GTA generates cross-chain identity information. GTA generates cross-chain identity information for users, which includes k tokens and a pseudonym generator Psg.

[0034] a) GTA generates k masks for the user's identity ID. K random numbers m are randomly selected. i ∈ Calculate the mask M i =(m i ·ID) -1 .

[0035] b) GTA generates a random number for the user. And generate k tokens for it. i The calculation process for (i = 1, 2, ..., k) is shown in formula (3). Wherein, Indicates the use of pk AD Perform encryption operations. After generating the token, store it in the relay chain to obtain k block addresses B = {bid1, bid2, ..., bid}. k}

[0036]

[0037] c) GTA constructs a pseudonym generator for the user and calculates Psg according to formula (4).

[0038]

[0039] d) GTA encrypts B with the user's public key to obtain the cipher and returns the user registration result Msg5 to IMA. As shown in formula (5), Msg5 contains the user's identity ID, the user's pseudonym generator Psg, and the address cipher.

[0040] Msg5={ID, Psg, cipher} (5)

[0041] (6) IMA processes cross-chain identity information. After receiving message Msg5, IMA first stores the user's identity ID and pseudonym generator Psg locally as key-value pairs. Then, it retrieves the user's public key pk based on the user's identity ID and generates the user's pseudonym PS according to formula (6). Finally, IMA returns message Msg6 to the user, as shown in formula (7), which contains the user's pseudonym PS and the address cipher.

[0042]

[0043] Msg6 = {PS, cipher} (7)

[0044] (7) The user receives and saves the cross-chain identity information. The user receives message Msg6, decrypts the cipher to obtain the block address set B, and saves PS and B.

[0045] S22: Cross-chain authentication. To ensure the security of cross-chain transactions within a consortium blockchain, user authentication is required for initiating such transactions. The authentication process is integrated throughout the cross-chain transaction flow and consists of the following six steps:

[0046] (1) User initiates cross-chain transaction. The user initiates a cross-chain transaction request message Msg7 to the parachain, as shown in formula (8), which includes the destination chain identifier dChainId, the access resource identifier dSourceId, the user's signature result σ3 of (dChainId||dSourceId), and the user's identity information. Among them, the user's identity information includes the user's public key pk, the user's pseudonym PS, and the randomly selected block address bid. i .

[0047] Msg7={dChainId, dSourceId, pk, PS, bid i ,σ3} (8)

[0048] (2) Verification nodes forward cross-chain transactions. After capturing Msg7, the verification node adds the parachain identifier CID to the message. Then, the verification node uses a threshold signature algorithm to sign (Msg7||CID) to obtain σ4. Finally, the verification node sends a cross-chain transaction request message Msg8 to the corresponding verification node on the relay chain. As shown in formula (9), Msg8 contains the message Msg7, the parachain identifier CID, and the signature σ4.

[0049] Msg8 = {Msg7, CID, σ4} (9)

[0050] (3) Verification nodes broadcast cross-chain transactions. Upon receiving Msg8, the verification node looks up the verification node's public key information based on the pre-stored CID and verifies the validity of σ4. If the signature is valid, Msg9 = {Msg7, CID} is broadcast to all verification nodes participating in the consensus; otherwise, it is discarded.

[0051] (4) Verification nodes verify cross-chain transactions. After receiving the broadcast message Msg9, other verification nodes verify it. As shown in Algorithm 1, the specific process consists of the following two steps.

[0052] a) Verify the public key's legitimacy. First, the verification node verifies the user's identity information based on the bid in the cross-chain transaction. i Obtain Tokens on the Relay Chain i Then, the verification node checks the equation. Is the equation true? If the equation is true, proceed to step (4)b; otherwise, the transaction is deemed invalid.

[0053] b) Verify the transaction signature. First, the verification node retrieves the signature algorithm and hash algorithm used by the parachain on the relay chain based on the parachain identifier CID in the message. Then, it uses the obtained signature algorithm, hash algorithm, and user public key pk to verify the validity of the transaction signature σ3. If the verification is successful, proceed to step (5); otherwise, the transaction is deemed invalid.

[0054] (5) Cross-chain transaction forwarding. After the verification nodes reach a consensus on the cross-chain transaction, they package and store it on the chain, and broadcast the valid transaction to the verification nodes of the destination parachain.

[0055] (6) Cross-chain transaction execution. After the verification node of the destination parachain verifies the source of the message, it broadcasts the transaction to the destination parachain. The destination parachain executes the cross-chain transaction.

[0056]

[0057] S23: User pseudonym update. To achieve the unlinkability of user identities, user pseudonyms need to be updated. The specific process consists of the following 5 steps:

[0058] (1) User generates public-private key pair. The user generates a new public-private key pair using the original cryptographic algorithm.<pk′,sk′> , secret storage sk′.

[0059] (2) The user initiates a pseudonym update request. On the parachain, the user initiates a pseudonym update request (Msg) to their respective IMA. 10 As shown in formula (10), Msg 10 It contains the user's new public key pk′, the user's original identity cred, the timestamp tst′, and the signature σ5 of (pk′||tst′) using the original private key sk.

[0060] Msg 10 ={pk′,cred,tst′,σ5} (10)

[0061] (3) IMA verifies the pseudonym update request. First, IMA verifies the validity of the user certificate. Then, IMA extracts the original public key pk from the user certificate and verifies the validity of the user signature. If both verifications are successful, proceed to step (4); otherwise, return "reject update".

[0062] (4) IMA updates user pseudonyms. First, IMA calculates the user's identity ID and retrieves the user pseudonym generator Psg locally. Then, IMA generates a new pseudonym for the user and calculates... Finally, IMA returned the new pseudonym PS′ to the user.

[0063] (5) The user stores the new pseudonym. The user receives the returned new pseudonym PS′ and stores it locally for use in the next cross-chain transaction.

[0064] S24: User Identity Tracing. When an abnormal cross-chain transaction is detected, the audit node can trace the identity of the initiator of the abnormal cross-chain transaction on the relay chain based on the transaction identifier. The specific process consists of the following two steps:

[0065] (1) Parsing Abnormal Cross-Chain Transactions. The audit node retrieves abnormal cross-chain transactions from the relay chain based on the transaction identifier, and parses them to obtain relevant identity information, including the user's public key pk, user pseudonym PS, and block address bid. i .

[0066] (2) User identity is revealed. Only audit nodes can use their own private key sk. AD Revealing user identity. First, the audit node bids based on the block address. i Obtain Tokens on the Relay Chain i , from Token i Take the second element from the list and denote it as Token. i [1]. Then, the audit node obtains the user's real identity based on pk and PS, and calculates the user's identity identifier ID according to formula (11). Indicates the use of sk AD Perform the decryption operation.

[0067]

[0068] Compared with the prior art, the advantages of the present invention are as follows:

[0069] This invention proposes a cross-chain identity authentication method for consortium blockchains, comprising two main steps: constructing a cross-chain system based on a relay chain and designing a privacy-preserving, fully cross-chain authentication protocol. Compared with current consortium blockchain cross-chain identity authentication methods, this method has the following advantages:

[0070] (1) Constructing a consortium blockchain cross-chain system based on a relay chain. In S1, the cryptographic configuration information of all parallel chains is stored on the relay chain, which is responsible for verifying cross-chain transactions, avoiding the problem of unsupported cryptographic configurations when performing identity authentication on the visited chain. In S1, the separation of responsibilities among relay chain nodes is implemented. The relay chain has GTA, verification nodes, and audit nodes, which are responsible for user identity registration, verification, and traceability, respectively. These three services are independent of each other, avoiding the concentration and abuse of power and improving the security of the cross-chain system.

[0071] (2) Design a privacy-preserving, fully cross-chain authentication protocol. In S2, the public key of the audit node and homomorphic encryption are used to generate pseudonyms for users, thus ensuring that while anonymizing the user's identity, the auditor can still trace the user's true identity using their private key. S2 not only updates the user's pseudonym with changes to their public key, but also uses homomorphic encryption to reduce update costs. By using different pseudonyms for cross-chain access, users can resist chain attacks and prevent their identity from being exposed. Attached Figure Description

[0072] Figure 1Cross-chain system architecture diagram based on relay chain;

[0073] Figure 2 Cross-chain system deployment architecture diagram;

[0074] Figure 3 A diagram illustrating the cross-chain registration interaction between parallel chain users;

[0075] Figure 4 Cross-chain authentication flowchart;

[0076] Figure 5 A diagram illustrating the user pseudonym update process. Detailed Implementation

[0077] The technical solutions in the embodiments will be described in detail below with reference to the accompanying drawings. Obviously, the embodiments described below are merely one embodiment of the method of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the following embodiments without creative effort are within the scope of protection of the present invention.

[0078] Example 1:

[0079] Before introducing the embodiments of the present invention, it is necessary to first describe the architecture of the parachains in the embodiments. The two parachains in the embodiments need to be connected to the relay chain to achieve cross-chain access. Taking the construction of one parachain as an example, four peer nodes are deployed on the parachain, belonging to two different organizations, Org1 and Org2, respectively. Each organization corresponds to a real-world enterprise or institution. Each organization has two peer nodes. All nodes on the parachain join a channel, Channel1, in the Hyperledger Fabric network to maintain the same business ledger. In terms of cryptographic configuration, the parachain adopts a PKI authentication system, using the RSA algorithm as the signature algorithm and the SHA1 function as the hash function. In addition, the parachain also has an IMA program, running on an independent server, which, while undertaking CA work, also participates in user cross-chain registration and user pseudonym updates.

[0080] S1: Build a consortium blockchain cross-chain system based on a relay chain. The deployment architecture of the cross-chain system is as follows: Figure 2 As shown. Specifically, it can be divided into the following two steps: relay chain construction and parallel link installation.

[0081] S11: Establishing the relay chain. The specific process can be divided into the following 5 steps:

[0082] (1) Construct a Global Trusted Organization (GTA). A Global Trusted Organization (GTA) program was written based on the OpenSSL and PBC libraries and ran on a standalone server. It provides three basic functional interfaces to the outside world, including relay node registration relaynode_reg(), parachain registration parachain_reg(), and parachain user registration parauser_reg().

[0083] (2) Deploy relay chain nodes. Configure four peer nodes on the relay chain, denoted as peer0, peer1, peer2, and peer3. Peer0 is the auditor, and the other nodes are validators. The relay chain nodes use ssh-keygen to generate asymmetric key pairs and, based on these key pairs, use OpenSSH to construct a Certificate Identity Request (CSR) file. Finally, the CSR file is used to call the GTA's relaynode_reg() interface to register the relay chain node identity. The relay chain nodes store their own identity certificates.

[0084] (3) Construct the relay chain network. Store the relay chain node certificates generated in step (2) in crypto-config / peerOrganizations / <peer domain> In the / msp folder, configure the core.yaml file, including the port used by peer nodes, the address for storing the blockchain ledger, and the address for storing identity certificates. Additionally, install a cross-chain proxy program on each validator node to enable it to communicate with nodes on other chains.

[0085] (4) Start the relay network. Configure the docker-compose.yaml file, including environment variables, the location of the genesis block generated file, and relay node parameters. Start the relay network using the docker-compose up command.

[0086] (5) Generate and publish public parameters for the cross-chain system. The Audit Node (AD) locally calls the PBC library to perform large number operations. To ensure an 80-bit security level, AD first calls the mpz_urandomb() and mpz_nextprime() functions to generate two 512-bit large prime numbers p and q, and then calls the mpz_mul() function to calculate n = p·q. Next, it calls the mpz_lcm() function to calculate λ = lcm(p-1, q-1). For ease of calculation, g = n+1 is chosen. Finally, it calls the mpz_inverse() function to calculate μ = L(g λ mod n 2 ) -1mod n, where L(u) = (u-1) / n. At this point, the Paillier key for AD has been calculated, and SHA256 is selected as the secure hash function H0(·). AD is then broadcast on the relay chain.<n,g,sha256> And secretly store (λ, μ) locally.

[0087] S12: Connecting to the parachain. The specific process can be divided into the following 4 steps:

[0088] (1) Parallel chain selection of verification nodes. Set the number of verification nodes to 1, select peer0.org1 as the verification node, and install the cross-chain proxy program on it.

[0089] (2) The parachain initiates a registration request. The parachain administrator calls the GTA's parachain_reg() interface, with the input parameter param1 including the signature algorithm name signAlgo, the hash function name hashFunc, the business information BussInfo, the number of nodes on the chain nodeNum, and the public key pk of the associated IMA. IMA The verification node's IP address cltIpAddr and its public key cltPk are used. The signature algorithm is RSA and the hash algorithm is SHA1.

[0090] (3) The relay chain completes the registration process. This involves the following four steps:

[0091] a) GTA is used to calculate a unique identifier CID = sha256(param1) for the parachain, and key-value pairs are stored locally. <CID:pk IMA >

[0092] b) GTA will invoke the blockchain SDK to...<CID:rsa,sha1> Stored on the relay chain.

[0093] c) GTA calls the select_miniload() function to select the verification node with the lowest load. In this case, peer1 is selected, and peer1 stores...<CID:cltIpAddr,cltPk> .

[0094] d) Return the parachain identifier CID and peer1 node IP address vldIpAddr to the interface.

[0095] (4) Parallel chains complete the access connection. Verification nodes store (CID, vldIpAddr) locally, and verification nodes and corresponding validation nodes establish a socket connection through a cross-chain proxy program.

[0096] S2: A fully cross-chain authentication protocol that achieves privacy protection. The specific process consists of four steps: cross-chain registration for parachain users, cross-chain identity verification, user pseudonym update, and user identity traceability.

[0097] S21: Parachain user cross-chain registration. The specific interaction process is as follows: Figure 3 As shown, it consists of the following 7 steps:

[0098] (1) User initiates cross-chain registration request. The user initiates a cross-chain registration request RegReq={cert,tst1,Sig_u(*)} to their IMA, which includes the user's identity certificate, timestamp and user signature.

[0099] (2) IMA processes the registration request. IMA verifies the validity of the user's signature, verifies the legitimacy of the certificate presented by the user through MSP, and checks the certificate revocation list to determine if the certificate has been revoked. If verification fails, a registration failure message FailRegResp = {InvalidRequest} is returned. IMA generates a unique identifier for the user, calculating ID = sha256(cert||CID). IMA calls the GTA interface parauser_reg(), with the input parameters being param = {ID, cert, CID, Sig_ima(*)}.

[0100] (3) GTA verifies the registration request. GTA retrieves the key-value pair locally from the relay chain based on the CID, indicating that the chain uses the RSA signature algorithm and SHA1 hash function. <CID:pk IMA > Call the RSA signature verification function and pk IMA Determine if the signature is valid. Then GTA calculates r = sha256(cert||CID) and checks if ID == r. Finally, GTA checks if the user's ID is in the blacklist. If all verifications pass, proceed to step (5); otherwise, proceed to step (4).

[0101] (4) GTA rejects the registration request. The GTA response to reject the registration is RegResp = {InvalidID}, and IMA returns a registration failure message FailRegResp = {InvalidRequest} to the user.

[0102] (5) GTA generates cross-chain identity information. GTA generates 10 tokens and 1 pseudonym generator for the user.

[0103] a) Call the pbc_mpz_random() function to generate 10 random numbers less than n {m1, m2, ..., mn}. 10}, call the mpz_inverse() and mpz_mul() functions to calculate the mask M. i =(m i ·ID) -1 mod n.

[0104] b) Call the mpz_mul() and mpz_powm() functions to calculate as well as Thus, a token was obtained. GTA calls SDK to {Token1, Token2,...,Token 10 The data is stored in the relay chain, resulting in block address B = {bid1, bid2, ..., bid}. 10}

[0105] c) GTA calls the mpz_mul() and mpz_powm() functions to generate a pseudonym generator for the user and calculates Psg = g α·ID α n modn 2 .

[0106] d) GTA extracts the user's public key pk from the user certificate cert and calculates cipher = E pk (B) Return a registration response RegResp = {Psg, cipher} to the API interface.

[0107] (6) IMA processes cross-chain identity information. IMA obtains the registration response from the API interface and converts the key-value pairs...<ID:Psg> Stored locally. Next, IMA also extracts the user's public key pk from the user certificate cert, calls mpz_mul() and mpz_powm() to generate a pseudonym for the user, and calculates... Finally, IMA returns the registration result SuccResp = {PS, cipher} to the user.

[0108] (7) The user receives and saves the cross-chain identity information. The user decrypts the cipher using their private key sk to obtain B=D. sk (cipher) stores (PS, B) locally for use in initiating cross-chain transactions.

[0109] S22: Cross-chain authentication. The cross-chain authentication process is as follows: Figure 4 As shown, it can be divided into the following 6 steps:

[0110] (1) User initiates cross-chain transaction. The user initiates a cross-chain transaction request crossTxReq = {desCID, desSourId, PS, pk, bid} to the parachain network. i ,σ}.

[0111] (2) Verification nodes forward cross-chain transactions. Verification nodes capture cross-chain transaction requests on parachains and use an RSA-based threshold signature algorithm to sign (crossTxReq||CID) to obtain σ′. Verification nodes establish a socket connection with peer1 node on the relay chain through a cross-chain proxy program and send userCrossTxReq={crossTxReq,CID,σ′}.

[0112] (3) Verification nodes broadcast cross-chain transactions. After receiving userCrossTxReq, the peer1 node on the relay chain retrieves cltPk locally based on the CID and uses cltPk to verify whether σ′ is valid. If the verification is successful, it broadcasts toBeVerifiedReq = {crossTxReq, CID} to all verification nodes participating in the consensus; otherwise, it discards the transaction.

[0113] (4) Verification nodes verify cross-chain transactions. Other verification nodes verify cross-chain transactions after receiving them.

[0114] a) Verify the validity of the public key. First, the verification node obtains the identity information {PS, pk, bid} from the message toBeVerifiedReq. i Then, the validator node bids based on the block address. i Call the query() function to get Finally, the verification node calls the mpz_cmp(), mpz_mul(), and mpz_powm() functions to verify the equation. Is it valid? If it is valid, proceed to step (4)b; if it is invalid, the transaction is deemed invalid.

[0115] b) Verify the transaction signature. First, the verification node retrieves the RSA signature algorithm and SHA1 hash function used by the parachain in the relay chain based on the CID, and calls the RSA signature verification function and PK to verify whether σ is valid. If the verification passes, proceed to step (5); otherwise, the transaction is deemed invalid.

[0116] (5) Cross-chain transaction forwarding. After the validator nodes reach a consensus on the cross-chain transaction, they package it and store it on the chain. Then, they forward it to the entry point of the destination parachain according to the destination chain identifier desCID in the transaction. Here, it is implemented as a peer3 node. The peer3 node on the relay chain and the validator node on the destination parachain establish a socket connection through the cross-chain proxy program to forward the cross-chain transaction.

[0117] (6) Cross-chain transaction execution. The verification node on the destination parachain broadcasts the transaction to the destination parachain, and the destination parachain executes the cross-chain transaction.

[0118] S23: User pseudonym update. The specific process is as follows: Figure 5 As shown, it can be divided into the following 5 steps:

[0119] (1) The user generates a public-private key pair. A new public-private key pair is generated using the cryptogen tool and the crypto-config.yaml file. The new public-private key pair can be found in the crypto-config subdirectory.<pk′,sk′> .

[0120] (2) The user initiates a pseudonym update request. The user initiates a pseudonym update request UpdReq={cert,pk′,tst2,Sig_u(*)} to the IMA to which the user belongs, which includes the user's original identity certificate, the user's new public key, the timestamp, and the user's signature signed with the original private key.

[0121] (3) IMA verifies the pseudonym update request. First, IMA calls MSP to verify the certificate's validity. Then, IMA extracts the user's original public key pk from the cert and verifies whether the signature is valid and matches the pk. Next, IMA queries the certificate revocation list to determine if the certificate has been revoked. If all verifications are successful, proceed to step (4); otherwise, return a failupdResp = {InvalidRequest} response.

[0122] (4) IMA updates user pseudonyms. First, IMA calculates the user identity ID = sha256(cert||CID) and retrieves the key-value pair locally.<ID:Psg> Then, IMA calls the mpz_mul() and mpz_powm() functions to calculate... Finally, IMA returns a successful update response to the user: SuccUpdResp={PS′}.

[0123] (5) The user stores the new pseudonym. The user stores (PS′, pk′) locally for the next cross-chain transaction.

[0124] S24: User Identity Tracing. The specific process can be divided into the following two steps:

[0125] (1) Parse abnormal cross-chain transactions. The audit node retrieves abnormal cross-chain transactions from the relay chain, and obtains {PS, pk, bid} from the transaction request. i}

[0126] (2) Revealing user identity. First, the audit node bids based on the block address. i Call the query() function to get Then, the audit node calls the mpz_mul(), mpz_div(), and mpz_powm() functions to obtain the user's real identity ID and calculates ID = αμ·L(PS λ modn2 )modn, where It should be noted that the above embodiments are not intended to limit the scope of protection of the present invention. Equivalent transformations or substitutions made based on the above technical solutions all fall within the scope of protection of the claims of the present invention.

Claims

1. A cross-chain identity authentication method for consortium blockchains, characterized in that, The method includes the following steps: S1: Build a consortium blockchain cross-chain system based on a relay chain. S2: Design a fully cross-chain authentication protocol with privacy protection; Step S2 involves designing a privacy-preserving, fully cross-chain authentication protocol, which consists of the following four steps: S21: Parachain users register across chains. S22: Cross-chain authentication, S23: User pseudonym update S24: User identity tracing; S21: Parachain user cross-chain registration. Users on parachains register with the cross-chain system to obtain permission to initiate cross-chain transactions. The specific process consists of the following 7 steps: (1) When a user initiates a cross-chain registration request, the user on the parachain sends a cross-chain registration request message to the identity management authority (IMA) to which they belong. As shown in formula (1), Includes user identity credentials timestamp And users' opinions Signature results , （1） (2) The IMA processes the registration request and receives the message. Then, first query the user credentials. Whether it is within the validity period, and then based on the user credentials. Verify signature The validity of the verification is checked; if the verification fails, a registration failure is returned; if the verification passes, a unique identity identifier is generated for the user in the cross-chain system. And send a request message to GTA to register a parachain user. As shown in formula (2), Includes user identification User credentials Parallel chain identifier And IMA's )Signature obtained , （2） (3) Global Trusted Authority (GTA) verifies the registration request. The GTA receives the request message. Then, first use Corresponding IMA public key verification signature The validity of the data, and then GTA based on... and calculate Determine whether it is related to In Similarly, finally, based on user identification. Check if it is in the blacklist. If all verifications pass, proceed to step (5); otherwise, proceed to step (4). (4) GTA rejects the registration request and sends a message to IMA rejecting the user registration. IMA received Then, immediately return a registration failure message to the user. , (5) GTA generates cross-chain identity information. GTA generates cross-chain identity information for users, including... tokens and kana generator , a) GTA serves as a user identification identifier generate A mask, randomly selected. random numbers Calculate the mask , b) GTA generates a random number for the user. and generate One token, token The calculation process is shown in formula (3). After generating the token, it is stored in the relay chain to obtain... Block address , （3） c) GTA constructs a pseudonym generator for the user, and calculates according to formula (4). , （4） d) GTA uses user public key encryption Obtain the ciphertext Return user registration results to IMA As shown in formula (5), Includes user identification User pseudonym generator and address ciphertext （5） (6) IMA processes cross-chain identity information, and IMA receives the message. Then, first identify the user. and user pseudonym generator Stored locally as key-value pairs, then based on user identity. Obtain user public key And generate the user's pseudonym according to formula (6). Finally, IMA returned a message to the user. As shown in formula (7), it contains user pseudonyms. and address ciphertext , （6） （7） (7) The user receives and saves the cross-chain identity information, and the user receives the message. Decryption Get the block address set ,save and .

2. The identity authentication method for cross-chain consortium blockchains according to claim 1, characterized in that, Step S1: Construct a consortium blockchain cross-chain system based on a relay chain, as detailed below: S11: Construct the relay chain, S12: Connect to the parachain.

3. The identity authentication method for cross-chain consortium blockchains according to claim 2, characterized in that, Step S11: Construct the relay chain, which consists of the following 5 steps: (1) Construct a Global Trusted Organization (GTA). Before constructing the relay chain, a Global Trusted Organization (GTA) must be selected as the trust anchor. Multiple organizations participating in the construction of the relay chain vote to jointly select a fully trustworthy GTA. The GTA provides a registration interface to the outside world, providing registration services for the relay chain and parachains. (2) Deploy relay chain nodes. Relay chain nodes are divided into two categories: verification nodes and audit nodes (AD). Verification nodes are ordinary nodes responsible for verifying and forwarding cross-chain transactions, while AD are privileged nodes on the relay chain responsible for tracing the identity of the initiator of anonymous cross-chain transactions. First, the regulator deploys an AD node. Then, multiple organizations participating in the construction of the relay chain determine the number of verification nodes based on the security and scalability requirements of the cross-chain system and deploy them together. Next, both verification nodes and audit nodes generate public-private key pairs locally and send certificate issuance requests to GTA. Finally, GTA completes the registration of the node's identity and issues a digital certificate to it. (3) Construct a relay chain network. Using the relay chain node certificate information obtained in step (2), configure the network information of the relay chain on all relay chain nodes to ensure network communication between relay chain nodes. (4) Start the relay network, configure the startup environment for the relay network, and initialize the relay network. (5) Generate and publish cross-chain system public parameters. As a privileged node on the relay chain, AD is responsible for generating cross-chain system parameters and publishing them publicly. First, AD generates a pair of Paillier homomorphic public and private keys. ,in Then AD selects a hash function. Finally, AD publicly releases its homomorphic public key and the selected hash function as a set, and keeps them secretly. .

4. The identity authentication method for cross-chain consortium blockchains according to claim 1, characterized in that, Step S12: Connect to the parachain. The specific process consists of the following four steps: (1) Parallel chains select verification nodes. Before connecting to the cross-chain system, the parallel chains need to select several verification nodes. Based on the security requirements of the parallel chains, the number of verification nodes is set to [number missing]. Randomly selected based on the parachain node identifier Each node serves as a verification node. (2) Parachain initiates registration request. The parachain administrator submits a parachain registration request through the GTA registration interface, which includes basic information of the parachain and cryptographic configuration information. The basic information includes parachain business information, number of nodes, and the public key of the associated IMA. Verify the node's IP address and its public key information, and the cryptographic configuration information including the signature algorithm and hash algorithm used. (3) The relay chain completes the registration process, which consists of the following four steps: a) GTA generates a unique identifier for the parachain to be connected. and mark the parallel chain and the associated IMA public key Stored locally as key-value pairs. b) GTA stores the signature and hash algorithm cryptographic configurations used by the parachains in the relay chain. Verification nodes on the relay chain need to be configured with the relevant cryptographic components to ensure that the cryptographic algorithms used on the parachains can all be implemented on the relay chain. c) Query the current allocation of verification nodes using GTA, select the verification node with the lowest load, and store its parachain identifier. Verify the node's IP address and its public key for subsequent communication with this parachain. d) GTA will identify parachains The verification node's IP address is sent to the assigned verification node, and a parachain identifier is returned. And the IP addresses of the assigned verification nodes to the parachains, (4) After the parachain completes the access connection and receives the registration result, the verification node stores the communication information of the assigned verification node locally and publishes it within the parachain. Finally, the verification nodes on the parachain establish connections with the corresponding verification nodes on the relay chain.

5. The identity authentication method for cross-chain consortium blockchains according to claim 4, characterized in that, S22: Cross-chain authentication, the specific process consists of the following 6 steps: (1) When a user initiates a cross-chain transaction, the user sends a request message for a cross-chain transaction to the parachain in which the user resides. As shown in formula (8), it includes the destination chain identifier. Access Resource Identifier User Signature results And user identity information, which includes the user's public key. User pseudonym and randomly selected block addresses , （8） (2) Verification nodes forward cross-chain transactions, and verification nodes capture them. Then, add a parachain identifier to the message. Then, the verification node uses a threshold signature algorithm to verify the signature. Signature obtained Finally, the verification node sends a cross-chain transaction request message to the corresponding verification node on the relay chain. As shown in formula (9), Contains messages Parallel chain identifier and signature , （9） (3) The verification node broadcasts the cross-chain transaction and receives it. The verification node is based on the pre-stored Find and verify the public key information of the verification node. The validity of the signature; if the signature is valid, then... Broadcast to all validator nodes participating in consensus; otherwise, discard. (4) The verification node verifies the cross-chain transaction, and other verification nodes receive the broadcast message. Then, it is verified, and the specific process consists of the following two steps. a) To verify the legitimacy of the public key, the verification node first verifies the user's identity information from the cross-chain transaction. Obtain on the relay chain Then, verify the node to determine the equation. Check if the equation is true. If it is true, proceed to step b; otherwise, determine that the transaction is invalid. b) Verify the transaction signature. First, the verification node verifies the parachain identifier in the message. The signature algorithm and hash algorithm used by the parachain are retrieved from the relay chain. Then, the retrieved signature algorithm, hash algorithm, and user public key are used. Verify transaction signature The validity of the transaction is verified. If the verification is successful, proceed to step (5); otherwise, the transaction is deemed invalid. (5) Cross-chain transaction forwarding: After the verification nodes reach a consensus on the cross-chain transaction, they package and store it on the chain, and broadcast the valid transaction to the verification nodes of the destination parachain. (6) Cross-chain transaction execution: After the verification node of the destination parachain verifies the source of the message, it broadcasts the transaction to the destination parachain, and the destination parachain executes the cross-chain transaction.

6. The identity authentication method for cross-chain consortium blockchains according to claim 5, characterized in that, S23: User pseudonym update, the specific process consists of the following 5 steps: (1) The user generates a public-private key pair. The user generates a new public-private key pair using the original cryptographic algorithm. Secret storage , (2) When a user initiates a pseudonym update request, the user on the parachain initiates a pseudonym update request to their respective IMA. As shown in formula (10), Includes the user's new public key Original user identity credentials timestamp and using the original private key right signature , （10） (3) IMA verifies the pseudonym update request. First, IMA verifies the validity of the user certificate. Then, IMA extracts the original public key from the user certificate. Verify the validity of the user's signature. If all verifications are successful, proceed to step (4); otherwise, return "Update refused". (4) IMA updates user pseudonyms. First, IMA calculates the user's identity identifier. The user pseudonym generator was retrieved locally. Then, IMA generates new pseudonyms for the user and calculates... Finally, IMA returned the new pseudonym to the user. , (5) The user stores the new pseudonym, and the user receives the returned new pseudonym. It is stored locally for use in the next cross-chain transaction.

7. The identity authentication method for cross-chain consortium blockchains according to claim 6, characterized in that, S24: User identity tracing, the specific process consists of the following two steps: (1) Parse abnormal cross-chain transactions. The audit node obtains abnormal cross-chain transactions from the relay chain based on the transaction identifier, and parses them to obtain relevant identity information, including the user's public key. User pseudonym and block address , (2) Expose user identity; only audit nodes can use their private keys. To reveal a user's identity, the audit node first determines the identity based on the block address. Obtained on the relay chain ,from Take the second element from the middle and denote it as Then, the audit node is based on and After obtaining the user's real identity, calculate the user's identity identifier according to formula (11). , （11）。

Images