A cross-domain identity authentication method based on a blockchain

Abstract

The application belongs to the technical field of computer network information security, and more particularly to a cross-domain identity authentication method based on a block chain. The method comprises S1, an initialization stage; S2, user certificate issuance chaining, an access user and an accessed user respectively apply for a CA digital certificate to a certificate issuance agency in each domain, the generated CA digital certificate is subjected to a hash operation, and a hash value is uploaded to a smart contract for storage through an upCa function; S3, cross-domain identity authentication, a domain A user Ua sends a cross-domain request to an accessed domain B, the domain B requests a cross-domain user CA digital certificate and verifies the authenticity of the certificate, after verification, the transaction information is uploaded to the chain through a TBFT consensus algorithm, and a synchronization node synchronizes the information on the chain; and S4, a new domain is added to the block chain. The application solves the problems of mutual distrust between different domains, data loss in the transmission process and low authentication process efficiency in the prior art.

Description

Technical Field

[0001] This invention belongs to the field of computer network information security technology, and more specifically, relates to a cross-domain identity authentication method based on blockchain. Background Technology

[0002] Today, information security has become an indispensable technological foundation for the development of network security. Identity authentication is an important mechanism to ensure network information security, providing security services for identity verification from multiple aspects. Certificate Authorities (CAs) centrally manage CA digital certificates. CAs are the certificate issuing authorities and also the core of PKI systems. They conduct activities such as certificate issuance, renewal, and revocation. They issue corresponding CA digital certificates to each user registered locally. Traditional PKI-based identity authentication architectures have problems such as single points of failure and difficulties in mutual trust among multiple CAs. Once a certificate authority is attacked, the certificates issued by the CA become untrustworthy. In a distributed environment, different organizations form different independent domains. Since the resources provided in a domain are very limited, users need to apply for services from other domains across domains, thus giving rise to cross-domain identity authentication problems.

[0003] Blockchain, with its decentralized, immutable, and transparent characteristics, combines the PKI authentication system with blockchain technology to effectively solve the single point of failure problem in PKI. The identity authentication server (AS) and certificate server (CA) of each domain act as blockchain nodes. The root CAs of different domains mutually authenticate each other to generate cross-certificates, so that cross-domain certificates can be generated when users cross domains. The generated certificates are hashed, and the resulting hash value is uploaded to the authentication server in the blockchain. Cross-domain authentication can be performed by checking whether the hash value of the certificate exists in the authentication server. However, due to the lack of trust between different domains, there is still a problem.

[0004] Chinese patent document CN112153608A discloses a cross-domain authentication method for vehicle networks based on a sidechain technology trust model, including the following steps: S10 initialization and registration stage; S20 cross-domain vehicle identity verification stage; S30 repeated cross-domain authentication stage; and S40 identity cancellation stage. If the RSU receives multiple cancellation applications for the same vehicle ID, it will notify the CA center. The CA center will bind the identity ID of the vehicle to be cancelled to the cancellation identifier "REVOKE" and sign and publish it on the main chain layer. Each time vehicle identity authentication is performed, if the smart contract retrieves the vehicle identity ID marked "REVOKE", it indicates that the vehicle identity has been cancelled and cannot be connected to the network.

[0005] In summary, blockchain-based cross-domain authentication still suffers from problems such as distrust between different domains, data loss during transmission, and low efficiency in the authentication process. Summary of the Invention

[0006] The present invention aims to overcome at least one of the defects of the prior art and provide a blockchain-based cross-domain identity authentication method.

[0007] The detailed technical solution of this invention is as follows:

[0008] To address the aforementioned technical problems, this invention provides a blockchain-based cross-domain identity authentication method, further improving the fairness and security of the blockchain system. This solves problems in existing technologies such as difficulties in CA mutual trust, data loss during transmission, single points of failure, and duplicate authentication.

[0009] The idea behind this invention is to: make the root node CA of all domains X Cross-certification node (CA) X_Y and the identity authentication server AS X As blockchain nodes, X and Y both refer to different domains within the blockchain, namely domain A, domain B, domain C, ..., CA. X_Y In X_Y, it refers to the cross-authentication of the X domain to the Y domain, where each root CA... X The node acts as a consensus node, participating in the blockchain's TBFT consensus algorithm, and the cross-certification CA... X_Y The node acts as a regular node, and the identity authentication server AS... X As a synchronization node, it synchronizes ledger data in the blockchain, does not participate in consensus, and receives client requests, verifies the legitimacy of the request initiator, and provides fast query services. To address cross-domain issues, this invention uses CA digital certificates for user authentication. These certificates are extended from X.509 certificates, and the extensions include a principal key identifier, blockchain name, CA key identifier, issuer CA identifier, and a hash algorithm. The CA digital certificate is stored in the blockchain as a hash value and authenticated through the Identity Authentication Server (AS). X User authentication is achieved through self-authentication using intra-domain CA digital certificates. Upon successful authentication, the authentication information is consensus-based and uploaded to the blockchain using the TBFT consensus algorithm. Furthermore, to prevent duplicate authentication during the process, this invention introduces an external certificate server (OAS). X Used to store cross-domain user copies of CA digital certificates to avoid duplicate authentication issues caused by certificate data loss during the authentication process.

[0010] To achieve the above objectives, this invention provides a blockchain-based cross-domain identity authentication method, comprising the following steps:

[0011] S1. Initialization Phase: Develop policies for certificate uploading, revocation, and querying, as well as cross-domain user authentication policies; compile and deploy smart contracts.

[0012] S2. User certificate issuance and on-chain: Users in each domain apply for CA digital certificates from their respective domain certificate authorities. The generated CA digital certificates are hashed, and the hash values ​​are uploaded to the smart contract for storage via the upCa function.

[0013] S3. Cross-domain identity authentication: User Ua of domain A sends a cross-domain request to the accessed domain B. Domain B requests the CA digital certificate of cross-domain user Ua of domain A and verifies the authenticity of the certificate. After successful verification, the transaction information (cross-domain identity) is consensus-upon on the blockchain through the TBFT consensus algorithm, and the synchronization node synchronizes the on-chain information.

[0014] S4. A new domain is added to the blockchain. The root of the newly added domain C is CA. C Initiate a request to join the blockchain, and use the TBFT consensus algorithm to establish a root CA for the newly joined node. C A consensus vote is conducted, and once two-thirds of the consensus nodes agree, the node can be added to the blockchain. Simultaneously, other domains in the chain generate a root CA for domain C. C Cross-certification nodes.

[0015] Furthermore, S2. User certificate issuance on the blockchain specifically includes:

[0016] S2-1. The user submits their identity information for registration, and the registration generates a public-private key pair for the user.

[0017] S2-2. Privacy data is encrypted and stored in the blockchain using the public key in the public-private key pair. The private key in the public-private key pair generated during user registration is stored locally and used to decrypt the encrypted information stored in the blockchain to obtain user identity-related information.

[0018] S2-3, Users Ua and Ub respectively send their certificates to the Certificate Authority (CA) within their respective domains. A CA B Apply for a CA digital certificate. Each generated CA digital certificate undergoes a hash operation, and the hash value is uploaded to the blockchain smart contract for storage via the upCa function.

[0019] CA digital certificates are an extension of X.509 certificates. The extension items are used to find the certificate issuing CA. The extension items include the principal key identifier, blockchain name, CA key identifier, issuer CA identifier, and hash algorithm. The issued CA digital certificate is hashed and uploaded to the blockchain through the upCa function.

[0020] Furthermore, the S3 cross-domain identity authentication specifically includes:

[0021] S3-1, For cross-domain users, the CA digital certificate for domain A is self-certified by the certificate issuing domain. Domain A user Ua requests authentication from domain B's identity server AS. BSend a request to access user Ub in domain B, AS B Store the CA digital certificate provided by user Ua to the external certificate server OAS of domain B. B Simultaneously, based on the issuer CA identifier in the CA digital certificate extension, the CA digital certificate of user Ua is sent to the domain A identity authentication server AS. A AS A Verify the CA digital certificate of user Ua;

[0022] S3-2, Certificate Issuance Domain Authentication and Cross-Domain CA Digital Certificates Issued by the Accessed Domain. Domain A Identity Authentication Server AS A The blockchain is queried using the CA digital certificate query function queryCa(user CA digital certificate hash value), and the query result is returned. If the query result is "issued", the verification is successful. After successful verification, the user's Ua identity information is obtained from the blockchain, and a signature is sent to the domain B authentication server AS using the user's Ua private key. B The domain B authentication server verifies the integrity of the CA digital certificate data of user Ua in domain A. After successful verification, it uses the domain B cross-authentication node CA. B_A Issue a cross-domain CA digital certificate for user Ua, upload the cross-domain CA digital certificate to the blockchain for storage, and forward the cross-domain CA digital certificate to user Ua in domain A.

[0023] S3-3. Reverse authentication of the accessed domain to achieve two-way authentication. User Ub of domain B repeats steps 3-1 to 3-2 to complete the reverse authentication from user Ub of domain B to user Ua of domain A, thus achieving two-way authentication.

[0024] S3-4, the master node leader packages the transactions and records them on the blockchain for consensus. After two-way authentication is completed, the domain B identity authentication server AS... B As the master node leader, the above transaction information (two-way authentication) is packaged and sent to the consensus node, and then the TBFT algorithm is used to reach consensus and put it on the chain;

[0025] Furthermore, S3-1 specifically includes:

[0026] S3-1-1, Domain A user Ua sends an authentication request to Domain B authentication server AS. B Send a request to access user Ub in domain B;

[0027] S3-1-2, Domain B Identity Authentication Server AS B Upon receiving an access request, a random number R1 is generated and sent to user Ua in domain A. At the same time, user Ua's CA digital certificate is requested from user Ua.

[0028] After receiving the request, S3-1-3 Domain A user Ua uses their private key to sign the CA digital certificate and random number R1, generating SigskUa, and then sends the CA digital certificate, R1, and the signed SigskUa to the domain B authentication server AS. B ;

[0029] S3-1-4, Domain B Authentication Server AS B Upon receiving the message, verify the validity of R1. If R1 is valid, parse user Ua's CA digital certificate, copy user Ua's CA digital certificate, and store the generated copy CA digital certificate on the external certificate server OAS in domain B. B If R1 is invalid, then wait for valid information from user Ua;

[0030] S3-1-5, Domain B Authentication Server AS B Upon receiving the message, verify the validity of R1. If R1 is valid, parse the CA digital certificate, determine the relevant issuing domain based on the information in the CA digital certificate, generate a random number R2, and send user Ua's CA digital certificate and the random number R2 to the identity authentication server AS of domain A. A If R1 is invalid, wait for valid information from user Ua.

[0031] S3-2 specifically includes:

[0032] S3-2-1, Domain A Identity Authentication Server AS A Parse user Ua's CA digital certificate, perform a hash operation on user Ua's CA digital certificate, and query the blockchain using the queryCa(user CA digital certificate hash value) function to obtain the query result:

[0033] If no query results are found, then user Ua does not belong to domain A, and authentication fails.

[0034] If the query result is "revoked", then user Ua's CA digital certificate has been revoked and authentication has failed.

[0035] If the query result indicates that the application has been published, then user Ua is a legitimate user in domain A, and authentication is successful.

[0036] S3-2-2, After user Ua successfully authenticates in domain A, AS A Retrieve the user's private key (Ua) locally and decrypt the user's identity-related information stored in the blockchain. Sign the user information (InfoUa), the random number (R2), and the CA digital certificate using the user's private key (Ua), and send them to the domain B authentication server (AS). B AS B Verify the signature and parse the CA digital certificate of user Ua;

[0037] S3-2-3, the S3-2-2 Domain B Identity Authentication Server AS B After parsing, the user's (Ua's) CA digital certificate is compared with the local OAS. B Compare the copied user's Ua copy with the CA digital certificate stored in the database;

[0038] If the comparison results are the same, it means that the CA digital certificate is intact and the data has not been lost.

[0039] If the comparison results are different, the locally copied CA digital certificate will be used as the CA digital certificate for user Ua. Based on the certificate issuing domain, the corresponding cross-certification node CA in domain B will be used. B_A Issue cross-domain CA digital certificates for cross-domain users (Ua);

[0040] S3-2-4, Domain B Cross-Authentication Node CA B_A Send the issued cross-domain CA digital certificate to the domain B identity authentication server AS. B AS B Perform hash calculations on cross-domain CA digital certificates and upload the hash value of cross-domain CA digital certificates to the blockchain using the upCa(user CA digital certificate hash value) function;

[0041] S3-2-5, the S3-2-4 Domain B Identity Authentication Server AS B The issued cross-domain CA digital certificate is sent to user Ua in domain A for cross-domain access.

[0042] Furthermore, the S3-4 consensus algorithm TBFT algorithm is as follows: the consensus node is the root CA of each domain. X Consensus nodes participate in the consensus algorithm; the total number of consensus nodes is N, and the root CA of domain A, domain B...domain n is... X Let N0, N1, ..., Nn-1 be the numbers respectively, and let f be the number of Byzantine nodes. The maximum number of Byzantine nodes that N can tolerate satisfies N≥3f+1.

[0043] The selection of the S3-4 master node leader depends on the current block height h, the number of consensus nodes N in the blockchain, and the current view V. V starts from zero and only increases until the consensus node is a Byzantine node, at which point V automatically changes from V to V+1. Unselected consensus nodes act as slave nodes and participate in consensus voting. The master node leader selection process is as follows: master node leader = Ni, i = (V+h+N)mod N.

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

[0045] (1) The present invention provides a cross-domain identity authentication method based on blockchain. This scheme solves the problem of mutual distrust between different domains by using the domain authentication server to self-authenticate the user's CA digital certificate. By defining the X.509 certificate extension field, the issuer CA identifier in the extension field can send the user's CA digital certificate to the user's certificate issuing domain. The domain identity authentication server AS queries and verifies the user's CA digital certificate. If the verification is successful, the user is a trusted user.

[0046] (2) The present invention provides a cross-domain identity authentication method based on blockchain. This solution introduces an off-domain certificate server in the cross-domain authentication process. Data loss occurs during data transmission. By setting up an off-domain certificate server in the domain to store the off-domain user copy CA digital certificate of the access request, when the user CA digital certificate data is lost, the relevant cross-domain CA digital certificate can be generated by the backup user copy CA digital certificate stored in the off-domain certificate server. This avoids the user from re-authenticating to a certain extent and improves the authentication efficiency.

[0047] (3) The present invention provides a cross-domain identity authentication method based on blockchain. In this scheme, newly added nodes and newly published transaction data are consensus-uploaded to the chain through the TBFT consensus algorithm. In the TBFT consensus algorithm, the leader is rotated. Every n blocks submitted (which can be configured), the leader will be rotated to the next node, which ensures the fairness and security of blockchain data. Attached Figure Description

[0048] Figure 1 This is a flowchart illustrating the overall process of cross-domain identity authentication based on blockchain in this invention.

[0049] Figure 2 This is a diagram of the X509 certificate extension certificate of this invention;

[0050] Figure 3 This is a flowchart of the cross-domain identity authentication process of this invention;

[0051] Figure 4 This is a flowchart of the process for selecting the leader node in this invention. Detailed Implementation

[0052] The present disclosure will be further described below with reference to the accompanying drawings and embodiments.

[0053] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of this disclosure. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0054] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this disclosure. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms “comprising” and / or “including” are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0055] Where there is no conflict, the embodiments and features described herein can be combined with each other.

[0056] Example 1

[0057] This embodiment provides a blockchain-based cross-domain identity authentication method, such as... Figure 1 As shown:

[0058] Table 1 Field Symbol Explanation

[0059]

[0060] S1. Initialization Phase

[0061] Develop policies for certificate uploading, revocation, and querying, as well as cross-domain user authentication policies, and compile and deploy smart contracts.

[0062] S2. User certificate issuance and on-chain processing

[0063] Users within each domain apply for CA digital certificates from their respective domain's certificate authority. The generated CA digital certificates undergo hash calculations, and the hash values ​​are uploaded to the smart contract for storage via the upCa function.

[0064] S2-1. Users submit their identity information for registration, and a public-private key pair is generated. Registered users submit their information through the front-end interface. The system generates a public-private key pair for the registered user using national cryptographic algorithms. This generated public-private key pair is then used to encrypt and decrypt user information using an asymmetric encryption algorithm. This public-private key pair serves as the user's sole method of logging into the system.

[0065] S2-2. Privacy data such as user identity and attributes are encrypted and stored in the blockchain using the public key in the public-private key pair. The private key in the public-private key pair generated during user registration is stored locally. When querying user identity information, the locally stored user private key decrypts the encrypted information stored in the blockchain to obtain the user identity-related information.

[0066] S2-3, Users Ua and Ub respectively send their certificates to the Certificate Authority (CA) within their respective domains. A CA BApply for a CA digital certificate, perform a hash operation on the generated CA digital certificate, and upload the hash value to the smart contract in the blockchain for storage through the upCa(user CA digital certificate hash value) function;

[0067] CA digital certificates are an extension of the X.509 certificate system. The extensions are used to locate the Certificate Authority (CA), such as... Figure 2 As shown, the extended items include the principal key identifier, blockchain name, CA key identifier, issuer CA identifier, and hash algorithm. The hash algorithm has one-way and collision resistance. The issued CA digital certificate is hashed and uploaded to the blockchain through the upCa(user CA digital certificate hash value) function.

[0068] The S2-3 hash algorithm is one-way. Given a user's CA digital certificate CertAa and H, it is not feasible to calculate CertAa from H according to Hash(CertAa) = H.

[0069] The S2-3 hash algorithm is collision resistant. Given the algorithm Hash(), user CA digital certificate CertAa and user CA digital certificate CertBb, and CertAa ≠ CertBb, it is not feasible to make Hash(CertAa) = Hash(CertBb).

[0070] S3. Cross-domain identity authentication: User Ua in domain A sends a cross-domain request to the accessed domain B. Domain B requests the CA digital certificate of cross-domain user Ua in domain A and verifies the authenticity of the certificate. After successful verification, the transaction information (cross-domain identity) is consensus-upon uploaded to the blockchain through the TBFT consensus algorithm, and the synchronization node synchronizes the information on the blockchain.

[0071] The role of the consensus node is to participate in TBFT consensus algorithm voting and transaction execution in the blockchain network;

[0072] The role of the synchronization node is to synchronize ledger data in the blockchain, not to participate in consensus, and to receive client requests, verify the legitimacy of the request initiator, and provide fast query services.

[0073] For example, if user Ua in domain A wants to establish a cross-domain connection with user Ub in domain B, the specific process is as follows: Figure 3 The process is as follows:

[0074] S3-1. The CA digital certificate for cross-domain users is self-certified by the certificate issuing domain. Domain A user Ua sends an authentication certificate to Domain B's identity authentication server AS. B Send a request to access user Ub in domain B, AS B Store the CA digital certificate provided by user Ua to the external certificate server OAS of domain B. BSimultaneously, based on the issuer CA identifier in the CA digital certificate extension, the CA digital certificate of user Ua is sent to the domain A identity authentication server AS. A AS A Verify user Ua's CA digital certificate as follows:

[0075] S3-1-1, User Ua of Domain A in 3-1 sends an authentication request to the Identity Authentication Server AS of Domain B. B Send a request to access user Ub in domain B;

[0076] S3-1-2, the 3-1-1 Domain B Identity Authentication Server AS B Upon receiving an access request, a random number R1 is generated and sent to user Ua in domain A. At the same time, user Ua's CA digital certificate is requested from user Ua.

[0077] S3-1-3, After receiving the request, the domain A user Ua in 3-1-2 uses its private key to sign the CA digital certificate and random number R1 to generate SigskUa, and sends the CA digital certificate, R1, and the signed SigskUa to the domain B authentication server AS. B S3-1-4, the 3-1-3 domain B authentication server AS B Verify that R1 is valid after receiving the message;

[0078] If R1 is valid, it resolves user Ua's CA digital certificate, copies user Ua's CA digital certificate, and stores the resulting copy of the CA digital certificate on the external certificate server OAS in domain B. B middle;

[0079] If R1 is invalid, wait for valid information from user Ua;

[0080] S3-1-5, the 3-1-4 Domain B Authentication Server AS B Verify that R1 is valid after receiving the message;

[0081] If R1 is valid, the CA digital certificate of user Ua is parsed, the relevant issuing domain is determined based on the information in the CA digital certificate, a random number R2 is generated, and user Ua's CA digital certificate and the random number R2 are sent to the identity authentication server AS of domain A. A；

[0082] If R1 is invalid, wait for valid information from user Ua.

[0083] S3-2, Certificate Issuance Domain Authentication and Cross-Domain CA Digital Certificates Issued by the Accessed Domain. Domain A Identity Authentication Server AS AThe blockchain is queried using the CA digital certificate query function queryCa(user CA digital certificate hash value), and the query result is returned. If the query result is "issued", the verification is successful. After successful verification, the user's Ua identity information is obtained from the blockchain, and a signature is sent to the domain B authentication server AS using the user's Ua private key. B The domain B authentication server verifies the integrity of the CA digital certificate data of user Ua in domain A. After successful verification, it uses the domain B cross-authentication node CA. B_A Issuing a cross-domain CA digital certificate for user Ua, uploading the cross-domain CA digital certificate to the blockchain for storage, and simultaneously forwarding the cross-domain CA digital certificate to user Ua in domain A, specifically including:

[0084] S3-2-1, the S3-2 domain A identity authentication server AS A Parse user Ua's CA digital certificate, perform a hash operation on user Ua's CA digital certificate, and query the blockchain using the queryCa(user CA digital certificate hash value) function to obtain the query result:

[0085] If no query results are found, then user Ua does not belong to domain A, and authentication fails.

[0086] If the query result is "revoke", then user Ua's CA digital certificate has been revoked and authentication has failed.

[0087] If the query result is "issued", then user Ua is a legitimate user in domain A, and authentication is successful.

[0088] S3-2-2, after user Ua in S3-2-1 successfully authenticates in domain A, AS A Retrieve the user's private key (Ua) locally and decrypt the user's identity-related information stored in the blockchain. Sign the user information (InfoUa), the random number (R2), and the CA digital certificate using the user's private key (Ua), and send them to the domain B authentication server (AS). B AS B Verify the signature and parse the CA digital certificate of user Ua;

[0089] S3-2-3, the S3-2-2 Domain B Identity Authentication Server AS B After parsing, the user's (Ua's) CA digital certificate is compared with the local OAS. B Compare the user's ID copy with the CA digital certificate stored in the database;

[0090] If the comparison results are the same, it means that the CA digital certificate is intact and no data has been lost.

[0091] If the comparison results are different, the locally copied CA digital certificate will be used as the CA digital certificate for user Ua. Based on the certificate issuing domain, the corresponding cross-certification node CA in domain B will be used. B_A Issue cross-domain CA digital certificates for cross-domain users (Ua);

[0092] S3-2-4, the S3-2-3 domain B cross-certification node CA B_A Send the issued cross-domain CA digital certificate to the domain B identity authentication server AS. B AS B Perform hash calculations on cross-domain CA digital certificates and upload the hash value of cross-domain CA digital certificates to the blockchain using the upCa(user CA digital certificate hash value) function;

[0093] S3-2-5, the S3-2-4 Domain B Identity Authentication Server AS B The issued cross-domain CA digital certificate is sent to user Ua in domain A for cross-domain access.

[0094] S3-3. Reverse authentication of the accessed domain to achieve two-way authentication. User Ub of domain B repeats steps 3-1 to 3-2 to complete the reverse authentication from user Ub of domain B to user Ua of domain A, thus achieving two-way authentication.

[0095] S3-4, the master node leader packages the transactions and uploads them to the blockchain for consensus. After two-way authentication is completed, the domain B identity authentication server AS... B As the master node leader, the above transaction information is packaged and sent to the consensus node, and then the blockchain is reached through consensus using the TBFT algorithm. In the TBFT algorithm, the leader is rotated, and every n blocks the leader will rotate to become the next node, which ensures the fairness and security of blockchain data.

[0096] The S3-4 consensus algorithm, TBFT, has a consensus node as the root CA of each domain. X Consensus nodes participate in the consensus algorithm. Assuming the total number of consensus nodes is N, and the root CA of domain A, domain B...domain n is... X Let N0, N1, ..., Nn-1 be the numbers respectively, and let f be the number of Byzantine nodes. The maximum number of Byzantine nodes that N can tolerate satisfies N≥3f+1.

[0097] The selection of the S3-4 master node leader depends on the current block height h, the number of consensus nodes N in the blockchain, and the current view V. V starts from zero and only increases. When a consensus node is found to be a Byzantine node, V automatically changes from V to V+1. Unselected consensus nodes become slave nodes and participate in consensus voting. The master node leader selection process is as follows: Figure 4As shown, the leader of the master node is Ni, and i = (V + h + N) mod N. By rotating the master node, the fairness of the TBFT algorithm is improved, and Byzantine nodes can be checked and removed in a timely manner, thus improving the security of the system.

[0098] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the technical solutions of the present invention, and are not intended to limit the specific implementation of the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the claims of the present invention should be included within the protection scope of the claims of the present invention.

Claims

1. A blockchain-based cross-domain identity authentication method, characterized in that, include; S1. Initialization phase: Formulate policies for certificate uploading, revocation, and querying, as well as cross-domain authentication policies for users; compile and deploy smart contracts. S2. User certificate issuance and on-chain: The accessing user and the accessed user apply for CA digital certificates from their respective certificate authorities in their domains. The generated CA digital certificates are hashed, and the hash values ​​are uploaded to the smart contract for storage via the upCa function. S3. Cross-domain identity authentication: User Ua of domain A sends a cross-domain request to the accessed domain B. Domain B requests the CA digital certificate of cross-domain user Ua of domain A and verifies the authenticity of the certificate. After the verification is successful, the transaction information is uploaded to the chain through the TBFT consensus algorithm, and the synchronization node synchronizes the information on the chain. S4. A new domain is added to the blockchain. The new domain C is added to the blockchain, and the root CA of domain C is... C Initiate a request to join the blockchain, and use the TBFT consensus algorithm to establish a root CA for the newly joined node. C A consensus vote is conducted, and once two-thirds of the consensus node members agree, the node can be added to the blockchain. Simultaneously, other domains in the chain generate a root CA for domain C. C Cross-certification nodes; The consensus nodes are composed of root CAs in each domain. X composition; The S3 cross-domain identity authentication specifically includes: S3-1, Domain A user Ua sends an authentication request to Domain B authentication server AS. B Send a request to access user Ub in domain B, AS B Store the CA digital certificate provided by user Ua to the external certificate server OAS of domain B. B Simultaneously, based on the issuer CA identifier in the CA digital certificate extension, the CA digital certificate is sent to the domain A identity authentication server AS. A AS A Verify the CA digital certificate; S3-2, Domain A Identity Authentication Server AS A The blockchain is queried using the CA digital certificate query function `queryCa`, and the query result is returned. If the query result indicates that the certificate has been published, the verification is successful. After successful verification, the user's identity information (Ua) is retrieved from the blockchain, and the user's Ua private key is used to sign and send the certificate to the domain B authentication server (AS). B The domain B authentication server verifies the integrity of the CA digital certificate data of user Ua in domain A. After successful verification, it uses the domain B cross-authentication node CA. B_A Issue a cross-domain CA digital certificate for user Ua, upload the cross-domain CA digital certificate to the blockchain for storage, and forward the cross-domain CA digital certificate to user Ua in domain A. S3-3, Domain B user Ub repeats steps 3-1 to 3-2 to complete the reverse authentication from domain B user Ub to domain A user Ua, thus achieving two-way authentication; S3-4. After two-way authentication is completed, the domain B identity authentication server AS B As the master node leader, you package transactions and send them to the consensus nodes, where they are then put on the blockchain through the TBFT algorithm.

2. The blockchain-based cross-domain identity authentication method according to claim 1, characterized in that, S2. User certificate issuance and on-chain specifically includes: S2-1. The user submits their identity information for registration, and the registration generates a public-private key pair for the user. S2-2. Privacy data is encrypted and stored in the blockchain using the public key in the public-private key pair. The private key in the public-private key pair generated during user registration is stored locally and used to decrypt the encrypted information stored in the blockchain to obtain user identity-related information. S2-3, Users Ua and Ub respectively send their certificates to the Certificate Authority (CA) within their respective domains. A CA B Apply for a CA digital certificate, perform a hash operation on the generated CA digital certificate, and upload the hash value to the smart contract for storage via the upCa function.

3. The blockchain-based cross-domain identity authentication method according to claim 1, characterized in that, S3-1 specifically includes: S3-1-1, Domain A user Ua sends an authentication request to Domain B authentication server AS. B Send a request to access user Ub in domain B; S3-1-2, Domain B Identity Authentication Server AS B Upon receiving an access request, a random number R1 is generated and sent to the cross-domain requesting user Ua in domain A. At the same time, the user's CA digital certificate is requested from the cross-domain requesting user Ua. S3-1-3. After receiving the request, domain A user Ua uses its private key to sign the CA digital certificate and random number R1, generating SigskUa, and then sends the CA digital certificate, R1, and the signed SigskUa to the domain B authentication server AS. B ; S3-1-4, Domain B Authentication Server AS B Verify that R1 is valid after receiving the message; If R1 is valid, it resolves Ua's CA digital certificate and copies Ua's CA digital certificate to create a duplicate. The CA digital certificate is then stored on an external certificate server, OAS. B middle; If R1 is invalid, wait for valid information from user Ua; S3-1-5, Domain B Authentication Server AS B Verify that R1 is valid after receiving the message; If R1 is valid, the CA digital certificate is parsed, the relevant issuing domain is determined based on the information in the CA digital certificate, a random number R2 is generated, and user Ua's CA digital certificate and the random number R2 are sent to the identity authentication server AS of domain A. A ; If R1 is invalid, wait for valid information from user Ua.

4. The blockchain-based cross-domain identity authentication method according to claim 1, characterized in that, S3-2 specifically includes: S3-2-1, Domain A Identity Authentication Server AS A Parse user Ua's CA digital certificate, perform a hash operation on user Ua's CA digital certificate, and query the blockchain using the queryCa function to obtain the query result: If no query results are found, then user Ua does not belong to domain A, and authentication fails. If the query result is "revoked", then user Ua's CA digital certificate has been revoked and authentication has failed. If the query result indicates that the application has been published, then user Ua is a legitimate user in domain A, and authentication is successful. S3-2-2, After user Ua successfully authenticates in domain A, AS A Retrieve the user's private key (Ua) locally and decrypt the user's identity-related information stored in the blockchain. Sign the user information (InfoUa), the random number (R2), and the CA digital certificate using the user's private key (Ua), and send them to the domain B authentication server (AS). B AS B Verify the signature and parse the CA digital certificate of user Ua; S3-2-3, the Domain B Identity Authentication Server AS B After parsing, the CA digital certificate of user Ua is compared with the external certificate server OAS. B Compare the stored copy of the CA digital certificate; If the comparison results are the same, it means that the CA digital certificate is intact and no data has been lost. If the comparison results are different, the locally copied CA digital certificate will be used as the CA digital certificate for user Ua. Based on the certificate issuing domain, the corresponding cross-certification node CA in domain B will be used. B_A Issue cross-domain CA digital certificates for cross-domain users (Ua); S3-2-4, Domain B Cross-Authentication Node CA B_A Send the issued cross-domain CA digital certificate to the domain B identity authentication server AS. B AS B Perform hash calculations on cross-domain CA digital certificates and upload the hash value of cross-domain CA digital certificates to the blockchain using the upCa function; S3-2-5, the Domain B Identity Authentication Server AS B The issued cross-domain CA digital certificate is sent to user Ua in domain A for cross-domain access.

5. The blockchain-based cross-domain identity authentication method according to claim 1, characterized in that, The S3-4 consensus algorithm, TBFT, is as follows: the consensus node is the root CA of each domain. X Where X refers to the distinct domains in the blockchain, and consensus nodes participate in the consensus algorithm; the total number of consensus nodes is N, and the root CA of domain A, domain B...domain n is... X Let N0, N1, ..., Nn-1 be the numbers respectively, and let f be the number of Byzantine nodes. The maximum number of Byzantine nodes that N can tolerate satisfies N≥3f+1. The selection of the master node leader depends on the current block height h, the number of consensus nodes N in the blockchain, and the current view V. V starts from zero and only increases until the consensus node is a Byzantine node, at which point V automatically changes from V to V+1. Unselected consensus nodes act as slave nodes and participate in consensus voting. The master node leader selection process is as follows: master node leader = Ni, i = (V+h+N) mod N.

6. The blockchain-based cross-domain identity authentication method according to claim 1, characterized in that, The CA digital certificate is an extension based on the X.509 certificate, and the extension includes the principal key identifier, blockchain name, CA key identifier, issuer CA identifier, and hash algorithm.

Images