A blockchain-based identity authentication method and system

Abstract

The application provides a kind of identity authentication method and system based on blockchain, comprising constructing the distributed two-way authentication and secure communication system of fusion PKI center node and blockchain consensus node;Identity information is configured according to user role;All identity information is stored in a decentralized manner using blockchain technology, and the key summary of identity information is stored on chain instead of original data;Client, server start two-way authentication process according to the trusted information stored on chain, and complete the negotiation and generation of session key;Client, server use the generated session key to perform symmetric encryption and decryption processing on the transmission content.The application effectively prevents the risk of personnel rule violation, data tampering and other risks through strict identity verification and operation traceability, and users can independently manage identity authorization range and use scenarios, thereby completely changing the situation that users passively accept information management and control under the traditional system.

Description

Technical Field

[0001] This invention relates to the field of identity authentication and information security technology, specifically to a blockchain-based identity authentication method and system, applicable to cross-institutional and cross-platform identity management and secure communication scenarios. Background Technology

[0002] Traditional identity authentication systems have the following core flaws: 1. Centralized storage risks: Relying on a single institution to manage user identity information makes it vulnerable to data leaks due to attacks, and there is a high risk of unauthorized operations by internal personnel; 2. Lack of user autonomy: Users are required to repeatedly submit identity data to different platforms and have no control over the flow of data usage, leading to excessive collection and abuse; 3. Inefficient cross-platform verification: The identity systems of various institutions are isolated and the standards are not uniform. Users need to repeatedly complete the identity verification process, resulting in low efficiency.

[0003] In existing technologies, some solutions attempt to introduce blockchain technology to achieve decentralized identity management, but these only solve the data storage problem and do not address the security shortcomings of two-way authentication and key negotiation. Other solutions use traditional account password authentication, which is vulnerable to brute-force attacks. Therefore, there is an urgent need for an innovative authentication system that balances identity authority, data trustworthiness, and communication security. Summary of the Invention

[0004] To address the various shortcomings of existing technologies, this invention provides a blockchain-based identity authentication method and system. By integrating the authoritative identity issuance capabilities of PKI with the trusted evidence storage capabilities of blockchain, a distributed two-way authentication and secure communication system is constructed. Through strict identity verification and operation traceability, the risk of unauthorized access and data tampering by personnel is effectively prevented. Users can independently manage the scope of identity authorization and usage scenarios, thereby completely changing the situation where users passively accept information control under the traditional system.

[0005] The present invention achieves the above objectives through the following technical solutions: A blockchain-based identity authentication method includes: Construct a distributed two-way authentication and secure communication system that integrates PKI central nodes and blockchain consensus nodes. The PKI central nodes are used to issue and manage certificate signing requests generated by users, while the blockchain consensus nodes are deployed in a distributed network and act as a trusted third party to maintain a unified identity state ledger. The user role is configured with identity information, where the client is used to configure basic identity authentication information and the server is used to configure identity authentication information that supports the two-way authentication process. Blockchain technology is used to store all identity information in a decentralized manner, and key summaries of the identity information, rather than the original data, are stored on the chain as evidence. During the identity verification phase, the client and server initiate a two-way authentication process based on the trusted information stored on the blockchain and complete the negotiation and generation of the session key: the client uses the first private key to digitally sign the authentication parameters and sends them to the server. The server obtains the public key from the client's certificate from the blockchain to complete the signature verification and generates the first session key. The server uses a second private key to sign the successful authentication response and reply to the client. The client retrieves the server certificate from the blockchain, verifies the signature, and generates a second session key after confirming the server's identity. Before initiating an authentication request, the client queries the blockchain consensus node based on the server's identity identifier to obtain the server's identity information set; the client generates authentication parameters and sends the encapsulated authentication parameters to the obtained server authentication interface address; After completing two-way authentication and key negotiation, the client and server use the generated session key to perform symmetric encryption and decryption on the transmitted content.

[0006] According to the blockchain-based identity authentication method provided by the present invention, after issuing a user certificate or server certificate, the PKI central node does not directly store the complete certificate, but extracts the hash digest, public key information, validity period and revocation status flag of the certificate, generates an identity anchoring transaction and broadcasts it to the blockchain network. After consensus confirmation, it is written into the blockchain ledger to realize the binding of physical identity and digital identity. A smart contract for identity verification is pre-deployed on the blockchain. The smart contract includes standard PKI certificate verification logic, blacklist verification logic, and access control policies. When the server or client initiates an authentication request, the smart contract automatically compares the certificate hash stored on the chain with the current certificate. If the certificate is revoked or not in the whitelist, the smart contract automatically returns a verification failure instruction, blocking subsequent communication.

[0007] According to the blockchain-based identity authentication method provided by this invention, after receiving the authentication parameter CParam, the server parses out the client identity identifier CIdentity and the server identity identifier SIdentity, and then queries the blockchain consensus node respectively to obtain: Client identity information: including client certificate and client account; Server-side identity association information: including a blacklist of identity identifiers bound to the server-side identity identifier SIdentity; The server-side identity information set includes the server-side certificate, the server-side authentication interface address, and the server-side login interface address; The authentication parameter CParam includes: The client-side random factor CFactory is used to prevent replay attacks. The client identity identifier CIdentity is used to uniquely identify the client's identity; The client's temporary public key CTPK is used for key negotiation in this session; The signature information CSign is a data string generated by digitally signing the client's random factor CFactory, the client's identity identifier CIdentity, and the client's temporary public key CTPK using the client's private key.

[0008] According to the blockchain-based identity authentication method provided by the present invention, when determining whether the client has successfully authenticated, the server performs the following verification operation: Public key extraction and decryption: Extract the client public key CPK from the obtained client certificate, use the client public key CPK to verify the signature information CSign in the authentication parameter CParam, and decrypt the client random factor CFactory, client identity identifier CIdentity and client temporary public key CTPK; Consistency check: The client random factor and client identity CIdentity obtained by decryption are compared with the CFactory and CIdentity transmitted in plaintext in the authentication parameter CParam. If they match, it indicates that the data has not been tampered with and the source is legitimate. Blacklist interception: Query the obtained blacklist of identity identifiers and determine whether the decrypted client identity identifier CIdentity exists in the blacklist; Successful authentication feedback: The server determines that the client authentication is successful and allows the client to proceed to the subsequent secure communication stage only if the signature verification is successful, the data comparison is consistent, and the client's identity identifier CIdentity is not in the identity blacklist.

[0009] According to the blockchain-based identity authentication method provided by this invention, after the server successfully authenticates the client, it constructs a key negotiation request message, including the following core parameters: Client identity identifier CIdentity; Client public key CPK; Client temporary public key CTPK; Server-side random factor SFactory; Combine random factors SFactory || CFactory, where SFactory is the random factor sent by the server, CFactory is the random factor sent by the client, and || represents byte concatenation; Server-side private key SSK and server-side temporary private key STSK; The server calls the SM2 key negotiation algorithm module, taking CIdentity, CPK, CTPK, combined random factors SFactory || CFactory, SSK, and STSK as input parameters, to perform key negotiation operations and generate the first session key SessionKey1. The operation logic is as follows: SM2Req(CIdentity,CPK,CTPK,SFactory+CFactory,SSK,STSK)=SessionKey1 The server stores the generated first session key, SessionKey1, in the local secure storage area and sends the encapsulated response information to the client. The response information includes the server's identity identifier SIdentity, the server's random factor SFactory, the server's temporary public key STPK, and the server's signature information SSign. Among them, SSign is the encrypted data generated by the server using its private key to digitally sign SIdentity, SFactory, and STPK.

[0010] According to the blockchain-based identity authentication method provided by the present invention, after receiving the response information, the client queries and obtains the server certificate from the blockchain consensus node based on the server identity identifier SIdentity in the response information; The client extracts the server public key SPK from the obtained server certificate, uses SPK to verify the server signature information SSign in the response information, and decrypts it to obtain the candidate server identity identifier SIdentity', candidate server random factor SFactory', and candidate server temporary public key STPK'. If SIdentity' matches the SIdentity in the response information, SFactory' matches the SFactory generated by the server, and STPK' matches the STPK in the response information, then the server identity is determined to be legitimate and the response information has not been tampered with. After the server's legitimacy verification passes, the client calls the SM2 key negotiation algorithm module, using the combined random factor SFactory || CFactory, the server's public key SPK, the server's temporary public key STPK, the client's identity identifier CIdentity, the client's private key CSK, and the client's temporary private key CTSK as input parameters to perform key negotiation operations and generate the second session key SessionKey2. The operation logic is as follows: SM2Resp(SFactory+CFactory,SPK,STPK,CIdentity,CSK,CTSK)=SessionKey2 The client compares the generated second session key, SessionKey2, with the first session key, SessionKey1, stored on the server. If they match, two-way authentication and key negotiation are completed, and a secure communication link is established.

[0011] According to the blockchain-based identity authentication method provided by the present invention, the following further steps are performed: The client obtains the hash digest H of its own PKI certificate from the blockchain consensus node. Cert , where H Cert An identity credential anchored to the blockchain after a certificate is issued to the PKI central node; The client uses a zero-knowledge proof algorithm to generate proof π, which is used to prove that the client possesses the hash digest H without exposing the plaintext content of the PKI certificate. Cert The corresponding client private key CSK; The client encapsulates the zero-knowledge proof π together with the client's identity identifier CIdentity into authentication parameters and sends them to the server; The server obtains H from the blockchain. Cert And call the zero-knowledge proof verification algorithm to verify the validity of π; if the verification of π passes and H Cert If the certificate hash matches the one stored on the blockchain, the server confirms the client's identity is legitimate and that it has not obtained the client's PKI certificate plaintext information.

[0012] According to the blockchain-based identity authentication method provided by the present invention, the CA root certificate hashes of different PKI authentication domains are anchored to the main chain and side chain of the blockchain respectively, and the main chain and side chain achieve real-time synchronization of certificate hashes through cross-chain protocol. Smart contracts deployed on the blockchain maintain a cross-domain identity mapping table, which records the identity identifier CIdentity of domain A. A CIdentity of Domain B B The one-to-one correspondence, and the hash association between the CA root certificates of both parties; When a client in domain A sends an authentication request to a server in domain B, the server performs the following cross-domain verification: The CA root certificate hash of domain A is obtained from the sidechain via a cross-chain protocol to verify whether it has been anchored to the blockchain and has not been revoked. Query CIdentity from the cross-domain mapping table of the smart contract A Corresponding CIdentity B Confirm the mutual recognition status of domain A's identity in domain B; If the CA root certificate is valid and the mapping relationship exists, the server allows the client from domain A to enter the standard authentication process of domain B. The update of the cross-domain mapping table is jointly initiated by the CAs of Domain A and Domain B, and anchored to the blockchain through multi-signature transactions to ensure the immutability of the mapping relationship.

[0013] According to the present invention, a blockchain-based identity authentication method records the client's historical authentication records, operational behaviors, and abnormal events through a blockchain ledger, and calculates a reputation score through a reputation scoring algorithm. Smart contracts have preset reputation thresholds; During authentication, the server obtains the client's reputation score from the blockchain: For high-reputation applicants: simplify the certification process; If it is a China Credit Certification Center: Follow the standard certification process; If the reputation is low: Enhance the certification process.

[0014] A blockchain-based identity authentication system includes: The identity identification platform is used to build a distributed two-way authentication and secure communication system that integrates PKI central nodes and blockchain consensus nodes. Among them, the PKI central nodes are used to issue and manage the certificate signing requests generated by users, and the blockchain consensus nodes are deployed in a distributed network to maintain a unified identity state ledger as a trusted third party. The role-based identity configuration module is used to configure identity information according to user roles; the role-based identity configuration module includes client-side configuration units and server-side configuration units: Client configuration unit: Used to configure basic information for client authentication; Server-side configuration unit: Used to configure basic information for server-side identity authentication and two-way identity authentication information that supports the two-way authentication process; The blockchain decentralized evidence storage module uses blockchain technology to store all identity information in a decentralized manner, storing key summaries of the identity information rather than the original data on the chain for evidence storage. The two-way authentication and key negotiation module is used to initiate the two-way authentication process between the client and the server during the identity verification phase, and to complete the negotiation and generation of the session key. The two-way authentication and key negotiation module includes: Client authentication unit: Used to generate client authentication parameters and send the authentication parameters to the server; Server-side authentication unit: used to obtain the public key from the client certificate from the blockchain, verify the signature information sent by the client, and generate the first session key when the verification is successful and the client's identity is not in a revoked state recorded in the blockchain. Server-side response unit: Used to generate server-side response information and send the response information back to the client; Client response unit: Used to obtain the public key from the server certificate from the blockchain, verify the signature information of the server's reply, and generate a second session key when the verification is successful and the server's identity is not in a revoked state recorded in the blockchain. The secure communication encryption module is used to perform symmetric encryption and decryption of transmitted content using the session key generated through negotiation after the client and server have completed two-way authentication and key negotiation. Therefore, compared with existing technologies, the blockchain-based identity authentication method and system proposed in this invention have the following advantages: 1. This invention uses the PKI central node as the root source of trust and issues user digital certificates through asymmetric encryption technology, ensuring the uniqueness and non-repudiation of identity. Compared to traditional account password authentication, this invention can completely eliminate risks such as password leakage and brute-force attacks, meeting the compliance requirements of high-security scenarios such as finance and government affairs.

[0015] 2. This invention stores key information such as certificate hashes and public key digests on the blockchain and uses the immutability of the blockchain to build an identity state ledger. Even if the PKI central node is attacked, the attacker cannot tamper with the identity digest on the chain, effectively preventing internal personnel from making illegal operations and data abuse.

[0016] 3. This invention constructs end-to-end security protection through two-way dynamic authentication and dynamic key negotiation. The client and server must mutually verify each other's identities based on trusted on-chain information, rather than one-way authentication. For example, the server needs to verify the client's certificate validity and blacklist status, while the client needs to verify the server's certificate validity, completely eliminating the risk of centralized institutions' internal personnel impersonating users to access user data.

[0017] 4. This invention generates an independent session key for each communication based on a random factor and a temporary public key. Even if a key is leaked once, an attacker cannot deduce other session keys, significantly improving communication security. Compared to traditional static key schemes, this invention greatly reduces the risk of key cracking.

[0018] 5. Once user identity information is on the blockchain, it can be directly accessed by any platform connected to the blockchain without the need to repeatedly submit data or complete verification processes. For example, after registering on a financial platform, a user can seamlessly use the same identity to access medical, educational, and other scenarios, which is expected to greatly improve the efficiency of cross-platform identity verification.

[0019] 6. Users can dynamically update their identity blacklist to restrict access by unauthorized individuals and authorize the use of their identity information in specific scenarios. For example, a user can prohibit a third-party platform from accessing their medical data while allowing government platforms to access their educational background information, achieving compliance goals of minimal data collection and on-demand authorization.

[0020] 7. This invention stores only the identity digest rather than the original data, which can reduce the cost of putting a single piece of identity information on the blockchain, while reducing the storage pressure on the blockchain network and supporting high-concurrency identity verification scenarios.

[0021] 8. This invention combines SM2 key negotiation with symmetric encryption (such as AES-256) to control communication latency to the millisecond level, meeting the performance requirements of real-time interactive scenarios (such as video conferencing and online payment).

[0022] 9. The system of this invention is divided into independent modules such as PKI-blockchain integration, identity configuration, and two-way authentication, which can be quickly integrated into existing business systems (such as ERP and CRM) and support smooth upgrades for future additions of identity verification rules or encryption algorithms.

[0023] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0024] Figure 1 This is a flowchart of an embodiment of a blockchain-based identity authentication method according to the present invention.

[0025] Figure 2 This is a schematic diagram of an embodiment of an identity authentication method based on blockchain according to the present invention.

[0026] Figure 3 This is a schematic diagram illustrating the implementation principle of the PKI central node and the blockchain network in an embodiment of a blockchain-based identity authentication method of the present invention.

[0027] Figure 4 This is a schematic diagram illustrating the implementation principle of the client authentication step in an embodiment of a blockchain-based identity authentication method according to the present invention.

[0028] Figure 5 This is a flowchart illustrating the verification operation for determining whether a client has successfully authenticated, as described in an embodiment of a blockchain-based identity authentication method of the present invention.

[0029] Figure 6 This is a schematic diagram illustrating the generation of the first session key in an embodiment of a blockchain-based identity authentication method of the present invention.

[0030] Figure 7 This is a schematic diagram illustrating the generation of a second session key in an embodiment of a blockchain-based identity authentication method of the present invention.

[0031] Figure 8 This is a flowchart illustrating the specific steps of two-way authentication between the client and the server in an embodiment of a blockchain-based identity authentication method of the present invention.

[0032] Figure 9This is a schematic diagram illustrating the implementation principle of the identity authentication platform in an embodiment of a blockchain-based identity authentication system of the present invention. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0034] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0035] An embodiment of a blockchain-based identity authentication method See Figure 1 and Figure 2 This embodiment provides a blockchain-based identity authentication method, including the following steps: Step S1: Construct a distributed two-way authentication and secure communication system that integrates PKI central nodes and blockchain consensus nodes. The PKI central node is used to issue and manage the certificate signing requests generated by users, and the blockchain consensus nodes are deployed in a distributed network to maintain a unified identity state ledger as a trusted third party. Step S2: Configure identity information according to user roles, where the client is used to configure basic identity authentication information and the server is used to configure identity authentication information that supports two-way authentication process. Step S3: Use blockchain technology to store all identity information in a decentralized manner, and put the key summary of the identity information, rather than the original data, on the chain for evidence storage to ensure the immutability and traceability of key configuration information. Step S4: During the identity verification phase, the client and server initiate a two-way authentication process based on the trusted information stored on the blockchain and complete the negotiation and generation of the session key: The client uses the first private key to digitally sign the authentication parameters and sends them to the server. The server obtains the public key from the client's certificate from the blockchain to complete the signature verification and generates the first session key. The server uses a second private key to sign the successful authentication response and reply to the client. The client retrieves the server certificate from the blockchain, verifies the signature, and generates a second session key after confirming the server's identity. Step S5: After completing two-way authentication and key negotiation, the client and server use the generated session key to perform symmetric encryption and decryption on the transmitted content to ensure the confidentiality of data and transmission efficiency throughout the communication process. The session key is generated based on the private key and temporary private key of each party, as well as the other party's public key and temporary public key. The SM2 key negotiation algorithm enables both communication ends to generate the same session key.

[0036] In this embodiment, as Figure 3 As shown, after issuing user certificates or server certificates, the PKI central node does not directly store the complete certificate. Instead, it extracts the certificate's hash digest, public key information, validity period, and revocation status flag, generates identity-anchored transactions, and broadcasts them to the blockchain network. After consensus confirmation, the transactions are written into the blockchain ledger, thus achieving the binding of physical identity and digital identity. A smart contract for identity verification is pre-deployed on the blockchain. The smart contract includes standard PKI certificate verification logic, blacklist verification logic, and access control policies. When the server or client initiates an authentication request, the smart contract automatically compares the certificate hash stored on the chain with the current certificate. If the certificate is revoked or not in the whitelist, the smart contract automatically returns a verification failure instruction, blocking subsequent communication. By leveraging the immutability of blockchain to replace traditional LDAP or OCSP servers, both communicating parties can directly query the real-time status of each other's certificates and public key information through blockchain nodes during two-way authentication, eliminating the need to rely on centralized query services and preventing single points of failure and man-in-the-middle attacks.

[0037] In the two-way authentication process, such as Figure 4 As shown, the client authentication steps include: Before the client initiates an authentication request, it queries the blockchain consensus node based on the server's identity identifier SIdentity to obtain a set of server identity information, which includes the server certificate, the server authentication interface address (authentication URL), and the server login interface address (login URL). The client generates authentication parameters CParam, which include: The client-side random factor CFactory is used to prevent replay attacks. The client identity identifier CIdentity is used to uniquely identify the client's identity; The client's temporary public key CTPK is used for key negotiation in this session; The signature information CSign is a data string generated by digitally signing the client's random factor CFactory, the client's identity identifier CIdentity, and the client's temporary public key CTPK using the client's private key. The client sends the encapsulated authentication parameters CParam to the obtained server authentication interface address (authentication URL); After receiving the authentication parameter CParam, the server parses out the client's identity identifier CIdentity and the server's identity identifier SIdentity, and then queries the blockchain consensus nodes respectively to obtain: Client identity information: including client certificate and client account; Server-side identity association information: This includes a blacklist of identity identifiers bound to the server-side identity identifier SIdentity.

[0038] When determining whether client authentication was successful, such as Figure 5 As shown, the server performs the following verification operations: Public key extraction and decryption: Extract the client public key CPK from the obtained client certificate, use the client public key CPK to verify the signature information CSign in the authentication parameter CParam, and decrypt the client random factor CFactory, client identity identifier CIdentity and client temporary public key CTPK; Consistency check: The client random factor and client identity CIdentity obtained by decryption are compared with the CFactory and CIdentity transmitted in plaintext in the authentication parameter CParam. If they match, it indicates that the data has not been tampered with and the source is legitimate. Blacklist interception: Query the obtained blacklist of identity identifiers and determine whether the decrypted client identity identifier CIdentity exists in the blacklist; Successful authentication feedback: The server determines that the client authentication is successful and allows the client to proceed to the subsequent secure communication stage only if the signature verification is successful, the data comparison is consistent, and the client's identity identifier CIdentity is not in the identity blacklist.

[0039] like Figure 6 As shown, after the server successfully authenticates the client, it constructs a key negotiation request message, which includes the following core parameters: Client identity identifier CIdentity; Client public key CPK (extracted from the client certificate obtained on-chain); Client temporary public key CTPK (from client authentication parameter CPAram); Server-side random factor SFactory (generated locally on the server); Combine random factors SFactory || CFactory, where SFactory is the random factor sent by the server, CFactory is the random factor sent by the client, and || represents byte concatenation; Server-side private key SSK and server-side temporary private key STSK; The server calls the SM2 key negotiation algorithm module, taking CIdentity, CPK, CTPK, combined random factors SFactory || CFactory, SSK, and STSK as input parameters, to perform key negotiation operations and generate the first session key SessionKey1. The operation logic is as follows: SM2Req(CIdentity,CPK,CTPK,SFactory+CFactory,SSK,STSK)=SessionKey1 The server stores the generated first session key, SessionKey1, in the local secure storage area and sends the encapsulated response information to the client. The response information includes the server's identity identifier SIdentity, the server's random factor SFactory, the server's temporary public key STPK, and the server's signature information SSign. Among them, SSign is the encrypted data generated by the server using its private key to digitally sign SIdentity, SFactory, and STPK.

[0040] After receiving the response information, the client queries and obtains the server certificate from the blockchain consensus node based on the server identity identifier SIdentity in the response information; The client extracts the server public key SPK from the obtained server certificate, uses SPK to verify the server signature information SSign in the response information, and decrypts it to obtain the candidate server identity identifier SIdentity', candidate server random factor SFactory', and candidate server temporary public key STPK'. If SIdentity' matches the SIdentity in the response information, SFactory' matches the SFactory generated by the server, and STPK' matches the STPK in the response information, then the server identity is determined to be legitimate and the response information has not been tampered with. like Figure 7 As shown, after the server's legitimacy verification passes, the client calls the SM2 key negotiation algorithm module, using the combined random factor SFactory || CFactory, the server's public key SPK, the server's temporary public key STPK, the client's identity identifier CIdentity, the client's private key CSK, and the client's temporary private key CTSK as input parameters to perform key negotiation operations and generate the second session key SessionKey2. The operation logic is expressed as follows: SM2Resp(SFactory+CFactory,SPK,STPK,CIdentity,CSK,CTSK)=SessionKey2 The client compares the generated second session key, SessionKey2, with the first session key, SessionKey1, stored on the server. If they match, two-way authentication and key negotiation are completed, and a secure communication link is established. Subsequent communication data is transmitted using either SessionKey1 or SessionKey2 with symmetric encryption.

[0041] In this embodiment, the execution process of the SM2 key negotiation algorithm module includes the following steps: Receive input parameters, including: combined random factor SFactory || CFactory, server public key SPK, server temporary public key STPK, client identity identifier CIdentity, client private key CSK, and client temporary private key CTSK; where: CIdentity is the client identity anchoring information obtained from the blockchain node, and is an identity credential issued by the PKI central node and anchored to the blockchain; the server certificates corresponding to SPK and STPK have been issued by the PKI central node, and the certificate hash digests have been stored in the blockchain ledger. First, verify the validity of the certificate chain between SPK and STPK. This can be done by querying the certificate status through the blockchain to confirm that it has not been revoked, and verify the binding relationship between CIdentity and SPK through the identity-public key mapping table stored on the blockchain. Based on the 256-bit prime-domain elliptic curve (e.g., sm2p256v1) and the base point G specified by the SM2 algorithm, perform the following operations: Based on the client's long-term private key CSK, generate the client's long-term public key CPK using elliptic curve dot product: CPK = CSK G; Generate a client temporary public key CTPK based on the client's temporary private key CTSK: CTPK = CTSK G; where CTPK has already been used in server-side key negotiation, this is a key pair association operation within the algorithm module; By combining long-term keys, temporary keys, random factors, and identity identifiers, the following elliptic curve operation is performed to generate the shared secret point K: Calculate the weighted sum of the client keys: d A = CSK + CTSK H(CIdentity || Z A ), where Z ACFactory is the client-side random factor, and H is the SM3 hash function. The identity is bound to the random factor to prevent key impersonation. Calculate the linear combination of the server's public key: P Btotal = SPK + STPK H(SIdentity || Z B ), where Z B SFactory is the server-side random factor, and SIdentity is the server-side identity identifier, which can be obtained from the response information; Perform the elliptic curve dot product operation: K = d A P Btotal Here, the hash value of the identity identifier is used as a weighting factor to achieve a strong binding between identity and key, ensuring that the shared secret can only be calculated by the two parties with legitimate identities. Convert the shared secret point K into a byte string, concatenate the x and y coordinates of K, and generate the second session key SessionKey2 using the identity-bound key derivation function KDF: The inputs to KDF include: a shared secret byte string, a client identity identifier (CIdentity), a server identity identifier (SIdentity), and a combined random factor (Z). KDF uses the SM3 hash function for iterative expansion, such as KDF(K || CIdentity || SIdentity || Z, 256), which outputs a 256-bit SessionKey2. The introduction of identity identifiers makes the session key uniquely bound to the identities of both parties, so that even if the key material is leaked, attackers cannot reuse it in sessions with other identities.

[0042] Perform the following validations on the generated SessionKey2: Length verification: It was confirmed that SessionKey2 is 256 bits, which meets the security strength requirements of SM2 key negotiation; Randomness verification: The randomness of the key is confirmed through entropy detection (such as the NIST SP 800-22 standard); Consistency pre-verification: If the server has already generated SessionKey1, the consistency between SessionKey2 and SessionKey1 can be preliminarily verified through the pre-shared key consistency identifier (such as the hash value of the random factors of both parties). If the verification is successful, SessionKey2 is output and stored in the client's local secure storage area, such as the TEE trusted execution environment; if the verification fails, the key negotiation retry process is triggered.

[0043] In this embodiment, the following is also performed: The client obtains the hash digest H of its own PKI certificate from the blockchain consensus node. Cert , where H Cert An identity credential anchored to the blockchain after a certificate is issued to the PKI central node; The client uses zero-knowledge proof algorithms (such as zk-SNARKs) to generate proof π. Proof π is used to prove that the client possesses the same certificate as H without exposing the plaintext content of the PKI certificate. Cert The corresponding private key CSK; The client encapsulates the zero-knowledge proof π together with the client's identity identifier CIdentity into authentication parameters and sends them to the server; The server obtains H from the blockchain. Cert And call the zero-knowledge proof verification algorithm to verify the validity of π; if the verification of π passes and H Cert If the certificate hash matches the one stored on the blockchain, the server confirms the client's identity is legitimate and that it has not obtained the client's PKI certificate plaintext information.

[0044] It is evident that traditional PKI authentication requires exposing the plaintext of the certificate, and while blockchain is immutable, storing identity information on the chain can easily lead to privacy leaks. This embodiment uses zero-knowledge proofs (ZKP) to prove that the client possesses a legitimate private key without exposing the content of the PKI certificate. Combined with the certificate hash anchoring of the blockchain, it achieves the dual goals of identity trust and privacy protection.

[0045] In this embodiment, the CA root certificate hashes of different PKI authentication domains (such as domain A and domain B) are anchored to the main chain and side chain of the blockchain, respectively. The main chain and side chain achieve real-time synchronization of certificate hashes through cross-chain protocols (such as Polkadot's relay chain). Smart contracts deployed on the blockchain maintain a cross-domain identity mapping table, which records the identity identifier CIdentity of domain A. A CIdentity of Domain B B The one-to-one correspondence, and the hash association between the CA root certificates of both parties; When a client in domain A sends an authentication request to a server in domain B, the server performs the following cross-domain verification: The CA root certificate hash of domain A is obtained from the sidechain via a cross-chain protocol to verify whether it has been anchored to the blockchain and has not been revoked. Query CIdentity from the cross-domain mapping table of the smart contract A Corresponding CIdentity B Confirm the mutual recognition status of domain A's identity in domain B; If the CA root certificate is valid and the mapping relationship exists, the server allows the client from domain A to enter the standard authentication process of domain B. The update of the cross-domain mapping table is jointly initiated by the CAs of Domain A and Domain B, and anchored to the blockchain through multi-signature transactions to ensure the immutability of the mapping relationship.

[0046] It is evident that identities cannot be mutually recognized between different PKI domains (such as Enterprise A and Enterprise B) or blockchain consortia (such as banking chains and government chains), requiring repeated authentication. This embodiment uses a blockchain cross-chain protocol (sidechain / relay chain) to anchor the root certificate hashes of different CAs, and maintains a cross-domain identity mapping table through smart contracts to achieve decentralized cross-domain identity mutual recognition, solving the problems of low efficiency and poor reliability of cross-domain authentication.

[0047] In this embodiment, extended fields of the PKI certificate, such as Role, ValidPeriod, and AccessScope, are associated with the smart contract. When the PKI central node updates the extended fields of the certificate, a permission change transaction is automatically generated and broadcast to the blockchain. The smart contract updates the permission status of the identity based on the transaction content, such as allowing access to service X or prohibiting access to service Y, and stores the updated permission status in the blockchain ledger; During the authentication process, in addition to verifying the validity of the PKI certificate, the server also obtains the real-time permission status of the smart contract stored on the blockchain. If the permission status does not meet the access requirements, such as role mismatch or expiration, the authentication request will be rejected directly. Smart contracts support condition-triggered permission adjustments: when a client's behavior reputation score falls below a threshold, permission downgrade is automatically triggered, such as downgrading from administrator to ordinary user; or when the time exceeds ValidPeriod, permission is automatically revoked and updated to the blockchain.

[0048] As can be seen, traditional PKI permissions are static, with permissions fixed within the certificate's validity period, making them unsuitable for dynamic scenarios such as role changes and temporary authorizations. This embodiment binds the extended fields of the PKI certificate (role, validity period, access scope) to a blockchain smart contract, enabling real-time automatic adjustment of permissions and solving the problems of manual intervention and delayed updates in traditional permission management.

[0049] In this embodiment, user behavior reputation data is stored on the blockchain, and the authentication strength is dynamically adjusted through smart contracts: The blockchain ledger records the client's historical authentication records, operational behaviors (such as access counts and operation types), and abnormal events (such as failed authentication attempts and permission violations), and calculates a reputation score (0-100 points) using a reputation scoring algorithm (such as weighted summation). Smart contracts have preset reputation thresholds, such as 80 points or above being high reputation, 50-80 points being medium reputation, and below 50 points being low reputation. During authentication, the server obtains the client's reputation score from the blockchain: For high-reputation applications: simplify the authentication process, such as skipping the blockchain blacklist lookup or reducing the parameters for key negotiation; If it is a China Credit Certification Center: Follow the standard certification process; For low reputation: enhance the authentication process, such as adding biometric verification, requiring hardware tokens, and shortening the session key validity period; Reputation scores are dynamically updated based on behavior, and smart contracts automatically adjust authentication strength to achieve a balance between security and efficiency.

[0050] As can be seen, traditional authentication methods use the same process for all users, failing to balance security and efficiency. For example, high-reputation users require repeated verification, while the process for low-reputation users is too simplified. This embodiment uses blockchain to store user behavior and reputation data (historical authentications, operation logs, and abnormal events), and dynamically adjusts the authentication strength through smart contracts. For instance, it simplifies the process for high-reputation users and strengthens the verification for low-reputation users. By leveraging the immutable reputation data of the blockchain and the automatic execution of smart contracts, dynamic adjustment of authentication strength is achieved, solving the problem of traditional authentication methods that struggle to balance efficiency and security. In this embodiment, multi-factor authentication (PKI certificate + biometrics + hardware token) is integrated into the authentication process: When generating the authentication parameter CParam, the client adds the following: Biometric hash H Bio Such as SM3 hashes of fingerprints / faces; Hash H of the hardware token dynamic code Token Such as the SM3 hash of the TOTP code; H pre-anchored client on the blockchain Bio Along with the hardware token public key, used to verify the signature of the dynamic code; During the authentication process, in addition to verifying the PKI certificate and blockchain status, the server also performs the following multi-factor authentication: Obtain H from the blockchain Bio This verifies the consistency between the biometric hash sent by the client and the data stored on the blockchain. Verify the validity of the dynamic code's signature using a hardware token public key; Client authentication is considered successful only when the PKI certificate is valid, the biometric signature matches, and the dynamic code is valid.

[0051] It is evident that single PKI authentication is easily counterfeited (e.g., private key leakage), requiring the combination of multiple factors (biometrics, hardware tokens) but lacking a trusted anchor. This embodiment anchors the hashes of biometric hashes (fingerprint / face) and hardware token dynamic codes (TOTP) to the blockchain, simultaneously verifying the legitimacy of the PKI certificate, biometrics, and hardware token during authentication. This solves the problems of easy tampering and difficulty in tracing multi-factor information, thus improving authentication security.

[0052] In practical applications, such as Figure 8 As shown, Figure 8 The document describes the specific steps of two-way authentication between the client and the server. The implementation details of these steps are as follows. A1 begins with the client accessing the server, retrieving the server's identity information from the blockchain based on the server's identity identifier SIdentity, including the server certificate, authentication URL, and login URL; A2 encapsulates the client parameter CParam, including the client random factor CFactory, the client identity identifier CIdentity, the client temporary public key CTPK, and the signature information CSign encrypted with the client private key. A3, the client sends the CParam parameter to the server's authentication URL to authenticate the client; A4. Parse the client parameter CParam, and retrieve the client identity information and server identity information from the blockchain based on the client identity identifier CIdentity and the server identity identifier SIdentity, as follows: [1] Client identity information: client certificate, client account; [2] Server-side identity information: Identity identifier blacklist; A5 extracts the client's public key CPK from the client certificate, encrypts the client's random factor CFactory, client identity identifier CIdentity, and client temporary public key CTPK, and verifies the signature with the signature information CSign. If they are equal, it means that the server considers the client to be legitimate, and the client identity identifier CIdentity is not in the identity blacklist, which means that the server has successfully authenticated the client. A6, the server transmits the client's identity identifier CIdentity, client's public key CPK, client's temporary public key CTPK, server's random factor SFactory + client's random factor CFactory, server's private key SSK and server's temporary private key STSK, and uses SM2 key negotiation (initiation) to generate and save the session key SessionKey1. A7, the server encapsulates the response information, including the server identity identifier SIdentity, the server random factor SFactory, the server temporary public key STPK, and the signature information SSign, which is encrypted with the server private key. A8. After successful server-side authentication, the response information will be returned to the client. A9 obtained the server's certificate from A1, so A9 extracts the server's public key from it, encrypts the server's identity identifier SIdentity, server's random factor SFactory, and server's temporary public key STPK, and verifies the signature with the signature information SSign. If they are equal, it means that the server is legitimate. A10. Based on the server-side random factor SFactory + client-side random factor CFactory, server-side public key SPK, server-side temporary public key STPK, client-side identity identifier CIdentity, client-side private key CSK, and client-side temporary private key CTSK transmitted in the response, generate and save the session key SessionKey2 using SM2 key negotiation (response). In A11, the session keys SessionKey1 and SessionKey2 must be equal. For example, in A11, the client encapsulates the client identity identifier CIdentity and the encrypted account encAccount using SessionKey2 as parameters to request the server login URL. The server authentication service obtains the corresponding client account Account and SessionKey1 based on the client identity identifier CIdentity, and uses SessionKey1 to decrypt and obtain the client account decAccount, and verifies whether Account and decAccount are equal. In A12, if the decrypted decAccount is equal to the original Account, the server-side authentication service generates a login token and returns it to the client via SessionKey1. The client then uses SessionKey2 to decrypt and obtain the login token.

[0053] An embodiment of a blockchain-based identity authentication system This embodiment provides a blockchain-based identity authentication system, including: The identity identification platform is used to build a distributed two-way authentication and secure communication system that integrates PKI central nodes and blockchain consensus nodes. Among them, the PKI central node is used to issue, update and revoke user-generated certificate signing requests, while the blockchain consensus nodes are deployed in a distributed network and act as a trusted third party to maintain a unified identity status ledger. The identity status ledger records identity identifiers, certificate hash digests, public key information and revocation status markers. The role-based identity configuration module is used to configure identity information according to user roles (client / server); the role-based identity configuration module includes client configuration units and server configuration units: Client configuration unit: Used to configure the basic information for client authentication, including client identity identifier, client account information, and client long-term key pair (client private key / client public key). Server-side configuration unit: Used to configure the basic information for server-side identity authentication and the two-way identity authentication information that supports the two-way authentication process. The basic information includes server-side identity identifier, server-side account information, and server-side long-term key pair (server-side private key / server-side public key). The two-way identity authentication information includes server-side temporary key pair (server-side temporary private key / server-side temporary public key) and authentication interface address. The blockchain decentralized evidence storage module is used to store all identity information in a decentralized manner using blockchain technology. The blockchain decentralized evidence storage module stores the key digest of the identity information on the blockchain instead of the original data. The key digest includes: the hash mapping relationship between the identity identifier and the certificate, the public key digest, the hash value of the temporary key pair, and the identity status marker (valid / revoked). The two-way authentication and key negotiation module is used to initiate the two-way authentication process between the client and the server during the identity verification phase, and to complete the negotiation and generation of the session key. The two-way authentication and key negotiation module includes: Client authentication unit: Used to generate client authentication parameters, which include client random factor, client identity identifier, client temporary public key and client private key signature information, and send the authentication parameters to the server; Server-side authentication unit: used to obtain the public key from the client certificate from the blockchain, verify the signature information sent by the client, and generate the first session key when the verification is successful and the client's identity is not in a revoked state recorded in the blockchain. Server-side response unit: Used to generate server-side response information, which includes server-side identity identifier, server-side random factor, server-side temporary public key and server-side private key signature information, and reply to the client with the response information; Client response unit: Used to obtain the public key from the server certificate from the blockchain, verify the signature information of the server's reply, and generate a second session key when the verification is successful and the server's identity is not in a revoked state recorded in the blockchain. The secure communication encryption module is used to perform symmetric encryption and decryption of transmitted content using the session key generated through negotiation after the client and server complete two-way authentication and key negotiation. The secure communication encryption module supports dynamic updates of the session key and triggers a renegotiation process when the random factor expires or the identity status changes.

[0054] In the distributed two-way authentication and secure communication system, users can generate asymmetric encryption public and private key pairs independently. The private key is kept independently by the user. When generating a Certificate Signing Request (CSR), the complete CSR file is generated directly on the local machine without transmitting the private key to an external server. Users register and log in to the identity verification platform, upload CSR files to apply for certificate issuance, and the identity verification platform administrator reviews and issues the certificate; It provides a blacklist configuration function, allowing users to set specific identities that need to be restricted according to actual scenarios, so as to accurately block access behavior of abnormal or unauthorized identities.

[0055] In practical applications, such as Figure 9 As shown, this embodiment provides users with end-to-end identity service support by building a unified identity identification platform, including the following core functions: Certificate Management: Certificate issuance and full lifecycle management provide authoritative credentials to support the authenticity of user identities; Blacklist Management: The identity blacklist configuration can accurately mark abnormal or illegal identities, strengthening risk prevention and control; Configuration Management: Simplified identity information configuration, allowing users to set and adjust identity-related information according to actual scenario needs; On-chain function: Identity information is stored on the blockchain, and blockchain technology is used to ensure the immutability and reliable traceability of configuration information, further consolidating the security foundation of identity services.

[0056] Furthermore, this embodiment supports users to generate asymmetric encryption public and private key pairs independently. The private key is kept independently by the user. When generating a certificate signing request (CSR), the necessary information required for the CSR file (such as identity subject name, organization, domain name, etc.) is configured and the generated public and private keys are imported. The complete CSR file is generated directly on the local machine without the need to transmit the private key to an external server. Furthermore, in this embodiment, the user registers and logs into the identity identification platform, uploads the CSR file, applies for a certificate in the certificate management system, and the identity identification platform administrator reviews and issues the certificate. Furthermore, this embodiment provides a blacklist configuration function, which allows users to set specific identities that need to be restricted according to actual scenarios, thereby achieving precise blocking of access behavior by such identities; Furthermore, this embodiment requires users to complete basic information configuration, the core of which includes certificates, identity blacklists, and a customizable unique ID identity identifier; at the same time, corresponding configurations need to be supplemented according to the user's role: if the user is a client, additional account information for login is required; if the user is a server, authentication path and access path need to be further configured to meet the requirements of subsequent identity verification and communication authorization. Furthermore, this solution does not use a centralized database to store user identity information, but instead puts the identity information on the blockchain, allowing users to obtain their identity information based on their identity identifiers.

[0057] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0058] The above embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of protection of the present invention. Any non-substantial changes and substitutions made by those skilled in the art based on the present invention shall fall within the scope of protection claimed by the present invention.

Claims

1. A blockchain-based identity authentication method, characterized in that, Includes the following steps: Construct a distributed two-way authentication and secure communication system that integrates PKI central nodes and blockchain consensus nodes; The user role is configured with identity information, where the client is used to configure basic identity authentication information and the server is used to configure identity authentication information that supports the two-way authentication process. Blockchain technology is used to store all identity information in a decentralized manner, and key summaries of the identity information, rather than the original data, are stored on the chain as evidence. During the identity verification phase, the client and server initiate a two-way authentication process based on trusted information stored on the blockchain and complete the negotiation and generation of session keys: The client uses its first private key to digitally sign the authentication parameters and sends them to the server. The server retrieves the public key from the client's certificate in the blockchain to verify the signature and generates the first session key. The server uses its second private key to sign the successful authentication response and replies to the client. The client retrieves the server's certificate from the blockchain to verify the signature, confirms the server's identity, and generates the second session key. Before initiating an authentication request, the client queries the blockchain consensus node based on the server's identity identifier to obtain the server's identity information set. The client generates authentication parameters and sends the encapsulated authentication parameters to the obtained server authentication interface address. After completing two-way authentication and key negotiation, the client and server use the generated session key to perform symmetric encryption and decryption on the transmitted content.

2. The method according to claim 1, characterized in that: After issuing user certificates or server certificates, the PKI central node does not directly store the complete certificate. Instead, it extracts the certificate's hash digest, public key information, validity period, and revocation status marker, generates identity-anchored transactions, and broadcasts them to the blockchain network. After consensus confirmation, the transactions are written into the blockchain ledger, thus achieving the binding of physical identity and digital identity. A smart contract for identity verification is pre-deployed on the blockchain. The smart contract includes standard PKI certificate verification logic, blacklist verification logic, and access control policies. When the server or client initiates an authentication request, the smart contract automatically compares the certificate hash stored on the chain with the current certificate. If the certificate is revoked or not in the whitelist, the smart contract automatically returns a verification failure instruction, blocking subsequent communication.

3. The method according to claim 1, characterized in that: After receiving the authentication parameter CParam, the server parses out the client's identity identifier CIdentity and the server's identity identifier SIdentity, and then queries the blockchain consensus nodes respectively to obtain: Client identity information: including client certificate and client account; Server-side identity association information: including a blacklist of identity identifiers bound to the server-side identity identifier SIdentity; The server-side identity information set includes the server-side certificate, the server-side authentication interface address, and the server-side login interface address; The authentication parameter CParam includes: The client-side random factor CFactory is used to prevent replay attacks. The client identity identifier CIdentity is used to uniquely identify the client's identity; The client's temporary public key CTPK is used for key negotiation in this session; The signature information CSign is a data string generated by digitally signing the client's random factor CFactory, the client's identity identifier CIdentity, and the client's temporary public key CTPK using the client's private key.

4. The method according to claim 3, characterized in that, When determining whether client authentication was successful, the server performs the following verification operations: Public key extraction and decryption: Extract the client public key CPK from the obtained client certificate, use the client public key CPK to verify the signature information CSign in the authentication parameter CParam, and decrypt the client random factor CFactory, client identity identifier CIdentity and client temporary public key CTPK; Consistency check: The client random factor and client identity CIdentity obtained by decryption are compared with the CFactory and CIdentity transmitted in plaintext in the authentication parameter CParam. If they match, it indicates that the data has not been tampered with and the source is legitimate. Blacklist interception: Query the obtained blacklist of identity identifiers and determine whether the decrypted client identity identifier CIdentity exists in the blacklist; Successful authentication feedback: The server determines that the client authentication is successful and allows the client to proceed to the subsequent secure communication stage only if the signature verification is successful, the data comparison is consistent, and the client's identity identifier CIdentity is not in the identity blacklist.

5. The method according to claim 4, characterized in that: After the server successfully authenticates the client, it constructs a key negotiation request message, including the following core parameters: Client identity identifier CIdentity; Client public key CPK; Client temporary public key CTPK; Server-side random factor SFactory; Combine random factors SFactory || CFactory, where SFactory is the random factor sent by the server, CFactory is the random factor sent by the client, and || represents byte concatenation; Server-side private key SSK and server-side temporary private key STSK; The server calls the SM2 key negotiation algorithm module, taking CIdentity, CPK, CTPK, combined random factors SFactory || CFactory, SSK, and STSK as input parameters, to perform key negotiation operations and generate the first session key SessionKey1. The operation logic is as follows: SM2Req(CIdentity,CPK,CTPK,SFactory+CFactory,SSK,STSK)=SessionKey1 The server stores the generated first session key, SessionKey1, in the local secure storage area and sends the encapsulated response information to the client. The response information includes the server's identity identifier SIdentity, the server's random factor SFactory, the server's temporary public key STPK, and the server's signature information SSign. Among them, SSign is the encrypted data generated by the server using its private key to digitally sign SIdentity, SFactory, and STPK.

6. The method according to claim 5, characterized in that: After receiving the response information, the client queries and obtains the server certificate from the blockchain consensus node based on the server identity identifier SIdentity in the response information; The client extracts the server public key SPK from the obtained server certificate, uses SPK to verify the server signature information SSign in the response information, and decrypts it to obtain the candidate server identity identifier SIdentity', candidate server random factor SFactory', and candidate server temporary public key STPK'. If SIdentity' matches the SIdentity in the response information, SFactory' matches the SFactory generated by the server, and STPK' matches the STPK in the response information, then the server identity is determined to be legitimate and the response information has not been tampered with. After the server's legitimacy verification passes, the client calls the SM2 key negotiation algorithm module, using the combined random factor SFactory || CFactory, the server's public key SPK, the server's temporary public key STPK, the client's identity identifier CIdentity, the client's private key CSK, and the client's temporary private key CTSK as input parameters to perform key negotiation operations and generate the second session key SessionKey2. The operation logic is as follows: SM2Resp(SFactory+CFactory,SPK,STPK,CIdentity,CSK,CTSK)=SessionKey2 The client compares the generated second session key, SessionKey2, with the first session key, SessionKey1, stored on the server. If they match, two-way authentication and key negotiation are completed, and a secure communication link is established.

7. The method according to claim 6, characterized in that, Also execute: The client obtains the hash digest H of its own PKI certificate from the blockchain consensus node. Cert , where H Cert An identity credential anchored to the blockchain after a certificate is issued to the PKI central node; The client uses a zero-knowledge proof algorithm to generate proof π, which is used to prove that the client possesses the hash digest H without exposing the plaintext content of the PKI certificate. Cert The corresponding client private key CSK; The client encapsulates the zero-knowledge proof π together with the client's identity identifier CIdentity into authentication parameters and sends them to the server; The server obtains H from the blockchain. Cert And call the zero-knowledge proof verification algorithm to verify the validity of π; if the verification of π passes and H Cert If the certificate hash matches the one stored on the blockchain, the server confirms the client's identity is legitimate and that it has not obtained the client's PKI certificate plaintext information.

8. The method according to claim 2, characterized in that: The root certificate hashes of CAs in different PKI authentication domains are anchored to the main chain and side chain of the blockchain, respectively. The main chain and side chain achieve real-time synchronization of certificate hashes through a cross-chain protocol. Smart contracts deployed on the blockchain maintain a cross-domain identity mapping table, which records the identity identifier CIdentity of domain A. A CIdentity of Domain B B The one-to-one correspondence, and the hash association between the CA root certificates of both parties; When a client in domain A sends an authentication request to a server in domain B, the server performs the following cross-domain verification: The CA root certificate hash of domain A is obtained from the sidechain via a cross-chain protocol to verify whether it has been anchored to the blockchain and has not been revoked. Query CIdentity from the cross-domain mapping table of the smart contract A Corresponding CIdentity B Confirm the mutual recognition status of domain A's identity in domain B; If the CA root certificate is valid and the mapping relationship exists, the server allows the client from domain A to enter the standard authentication process of domain B. The update of the cross-domain mapping table is jointly initiated by the CAs of Domain A and Domain B, and anchored to the blockchain through multi-signature transactions to ensure the immutability of the mapping relationship.

9. The method according to claim 2, characterized in that: The blockchain ledger records the client's historical authentication records, operational behaviors, and abnormal events, and calculates a reputation score using a reputation scoring algorithm. Smart contracts have preset reputation thresholds; During authentication, the server obtains the client's reputation score from the blockchain: For high-reputation applicants: simplify the certification process; If it is a China Credit Information Center: Follow the standard certification process; If the reputation is low: Enhance the certification process.

10. A blockchain-based identity authentication system, characterized in that, include: The identity identification platform is used to build a distributed two-way authentication and secure communication system that integrates PKI central nodes and blockchain consensus nodes. Among them, the PKI central nodes are used to issue and manage the certificate signing requests generated by users, and the blockchain consensus nodes are deployed in a distributed network to maintain a unified identity state ledger as a trusted third party. The role-based identity configuration module is used to configure identity information according to user roles; the role-based identity configuration module includes client-side configuration units and server-side configuration units: Client configuration unit: Used to configure basic information for client authentication; Server-side configuration unit: Used to configure basic information for server-side identity authentication and two-way identity authentication information that supports the two-way authentication process; The blockchain decentralized evidence storage module uses blockchain technology to store all identity information in a decentralized manner, storing key summaries of the identity information rather than the original data on the chain for evidence storage. The two-way authentication and key negotiation module is used to initiate the two-way authentication process between the client and the server during the identity verification phase, and to complete the negotiation and generation of the session key. The two-way authentication and key negotiation module includes: Client authentication unit: Used to generate client authentication parameters and send the authentication parameters to the server; Server-side authentication unit: used to obtain the public key from the client certificate from the blockchain, verify the signature information sent by the client, and generate the first session key when the verification is successful and the client's identity is not in a revoked state recorded in the blockchain. Server-side response unit: Used to generate server-side response information and send the response information back to the client; Client response unit: Used to obtain the public key from the server certificate from the blockchain, verify the signature information of the server's reply, and generate a second session key when the verification is successful and the server's identity is not in a revoked state recorded in the blockchain. The secure communication encryption module is used to perform symmetric encryption and decryption of transmitted content using the session key generated through negotiation after the client and server have completed two-way authentication and key negotiation.

Images