On-chain off-chain identity verification method and system based on trusted execution environment

Abstract

The application discloses a kind of on-chain off-chain identity verification method and system based on trusted execution environment, the method includes: obtaining the decentralized identity of user and chain identity certificate, the binding relationship between chain identity certificate and decentralized identity is established by smart contract, and the trusted execution environment authentication information for generating the chain identity certificate is associated with the decentralized identity and then recorded to block chain;Establish off-chain trust state channel and exchange initial trust state snapshot;The party to be verified generates zero-knowledge proof in trusted execution environment and completes signature;The verifier verifies zero-knowledge proof and signature result, updates trust state snapshot;When trust state channel is closed or dispute occurs, final trust state snapshot is submitted to smart contract verification and evidence recording.The application realizes the collaborative verification of identity trust, device trust and privacy protection, improves the security and verification efficiency of identity authentication.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, specifically relating to an on-chain and off-chain authentication method and system based on a trusted execution environment. Background Technology

[0002] With the widespread application of blockchain technology in fields such as digital identity management, decentralized finance, and supply chain traceability, blockchain identity verification faces challenges including the continuous growth of identity data, the increasing frequency of verification, and the growing demands for privacy protection. Traditional blockchain technology, with its decentralized, immutable, and traceable characteristics, provides a new technological path to solve trust issues. However, existing blockchain identity verification schemes still have many shortcomings. For example, publicly storing identity information can easily lead to privacy leaks; the on-chain verification process relies on smart contract execution, resulting in high computational overhead and high verification latency, making it difficult to meet the needs of high-frequency identity authentication scenarios. Furthermore, most existing solutions lack effective verification mechanisms for the trustworthiness of terminal devices, and there is a lack of trusted coordination between on-chain and off-chain identity states, making it difficult to simultaneously address the needs of identity authenticity verification, device trustworthiness verification, and user privacy protection, thus limiting the further application and promotion of blockchain identity verification technology. Summary of the Invention

[0003] Based on the above background and the problems existing in the prior art, this invention proposes to design a multi-technology integrated on-chain and off-chain collaborative identity verification system. This system can achieve low latency, high security, and enhanced privacy decentralized identity verification while maintaining the decentralized characteristics of blockchain, and complete the trusted association and collaborative interaction between on-chain and off-chain identities.

[0004] An on-chain and off-chain authentication method based on a trusted execution environment includes the following steps:

[0005] Obtain the user's decentralized identity and on-chain identity certificate, establish a binding relationship between the on-chain identity certificate and the decentralized identity through a smart contract, and record the trusted execution environment authentication information used to generate the on-chain identity certificate and the decentralized identity in the blockchain. In a blockchain network, the verifier and the verifier establish an off-chain trust state channel and exchange initial trust state snapshots, which include identity information, association information, and trusted execution environment authentication digest information. The party being verified generates a zero-knowledge proof within the Trusted Execution Environment (TEE) based on the verification strategy and the signature statement from an authoritative institution, and then signs the zero-knowledge proof using the TEE's intrinsic key to obtain the signature result. The verified party sends zero-knowledge proof and signature results to the verifier through the off-chain trust state channel. The verifier verifies the zero-knowledge proof and signature results and updates the trust state snapshot after the verification is successful. When the trust state channel is closed or a dispute occurs, the final trust state snapshot is submitted to the smart contract for verification. If the verification is successful, the submitted trust state snapshot is determined to be the final valid trust state and recorded on the blockchain for notarization. Otherwise, the submitted trust state snapshot is rejected, and a dispute resolution process is triggered to resubmit the trust state snapshot for verification.

[0006] As one possible implementation, establishing the binding relationship between the on-chain identity credential and the decentralized identity through a smart contract includes the following steps: Obtain the user's decentralized identity and the corresponding decentralized identity identifier; parse the public key information, server endpoint information, and identity declaration information in the corresponding identity document based on the decentralized identity identifier; obtain the on-chain identity credential held by the user and the corresponding identity credential identifier. A binding relationship is established between the on-chain identity credential identifier and the decentralized identity identifier through a smart contract, and the binding relationship is recorded in the blockchain ledger.

[0007] As one possible implementation, after establishing a binding relationship between on-chain identity credentials and decentralized identity, and associating the trusted execution environment authentication information used to generate the on-chain identity credentials with the decentralized identity, the smart contract records the binding transaction hash, binding timestamp, and binding block height generated when establishing the binding relationship. Generate a binding digest value based on the decentralized identity identifier, identity credential identifier, trusted execution environment authentication digest, binding transaction hash, and binding block height:

[0008] Wherein, BindHash represents the binding digest value; DID represents the decentralized identity identifier; CID represents the identity credential identifier; AttHash represents the trusted execution environment authentication digest; TxHash represents the binding transaction hash; and Height represents the binding block height.

[0009] As one possible implementation, the process of associating the trusted execution environment authentication information used to generate the on-chain identity credential with the decentralized identity and then recording it on the blockchain includes the following steps: Obtain the Trusted Execution Environment (TEE) authentication report used to generate the on-chain identity credential; parse the device public key, device measurement value, and device identity identifier in the authentication report; verify the validity of the authentication report signature; and verify the TEE operating status based on the device measurement value. Once the authentication report is verified, the trusted execution environment authentication information is associated with the decentralized identity via a smart contract, and the association is recorded in the blockchain ledger to form a trusted association between the decentralized identity and the trusted execution environment used to generate the on-chain identity credential.

[0010] As one possible implementation, the verifier and the verifier in the blockchain network establish an off-chain trust state channel and exchange initial trust state snapshots, including the following steps: The verifier and the verifier exchange their respective decentralized identity identifiers and verify the corresponding on-chain identity credentials, decentralized identity association records, and trusted execution environment authentication digest information. After successful verification, an initial trust state snapshot is generated and exchanged. The initial trust state snapshot includes at least the identity identifier, the block height corresponding to the identity credential and the decentralized identity association record, the trusted execution environment authentication digest value, the state version number, and the timestamp, in order to establish an off-chain trust state channel between the two parties.

[0011] As one possible implementation, the verified party generates a zero-knowledge proof within a trusted execution environment (TEE) based on a verification strategy and a signature statement from an authoritative body, and then signs the zero-knowledge proof using the TEE's intrinsic key to obtain a signature result, including the following steps: The system receives a verification strategy sent by the verification party and parses the attribute requirements and constraints in the verification strategy. The verification strategy includes at least one of the following: attribute type to be verified, attribute threshold condition, attribute range condition, and logical constraint relationship. Based on the verification strategy, corresponding verification constraints and verification circuits are constructed, and attribute data corresponding to the verification strategy is extracted from the authoritative institution signature declaration stored within the trusted execution environment. A zero-knowledge proof algorithm is then executed using the attribute data to generate a zero-knowledge proof that proves its attributes meet the verification strategy requirements. The authoritative institution signature declaration includes at least one of identity attribute declaration, qualification attribute declaration, reputation attribute declaration, and authority attribute declaration. The zero-knowledge proof is expressed as follows:

[0012] The zero-knowledge proof is digitally signed using a device private key generated internally within the trusted execution environment and not exportable, generating a corresponding signature result, which is expressed as follows:

[0013] in, This represents the private key of the trusted execution environment device. π represents the signature result, C represents the verification circuit, PK represents the proof key, PI represents the privacy input information, and AI represents the auxiliary input information.

[0014] As one possible implementation, the verifier verifies the zero-knowledge proof and signature results, and updates the trust state snapshot after successful verification, including the following steps: The verifier uses the device public key corresponding to the trusted execution environment to verify the validity of the signature result:

[0015] After the signature verification is successful, the zero-knowledge proof is verified:

[0016] When all the above verification results are True, it is confirmed that the verified party meets the verification policy requirements, and the local trust state snapshot is updated; a state commitment value is generated based on the updated trust state:

[0017] Among them, PK TEE This represents the public key of the trusted execution environment device. The signature result is represented by π, the zero-knowledge proof by π, and the verification key for the zero-knowledge proof by VK. Snapshot new This represents the updated trust state snapshot.

[0018] As one possible implementation, when the trust state channel is closed or a dispute occurs, a final trust state snapshot is submitted to the smart contract for verification. If the verification passes, the submitted trust state snapshot is determined to be the final valid trust state and recorded on the blockchain for notarization. Otherwise, the submitted trust state snapshot is rejected, and a dispute resolution process is triggered to resubmit the trust state snapshot for verification, including the following steps: When the trust state channel is closed or a dispute occurs, either the verifier or the verifier shall submit the final trust state snapshot, the state commitment value and the corresponding signature information to the smart contract. The smart contract verifies the state commitment value, state version number, timestamp, and signature information. If the verification result is successful, the submitted trust state snapshot is determined to be the final valid trust state, and the final valid trust state is recorded in the blockchain ledger to complete on-chain notarization. Otherwise, the submitted trust state snapshot is rejected, and a dispute resolution process is triggered. In the dispute resolution process, the verifier and the verifier resubmit the trust state snapshot and corresponding signature information, and the smart contract re-executes the verification. When the verification is successful, the resubmitted trust state snapshot is determined as the final valid trust state and recorded in the blockchain ledger to complete the evidence storage.

[0019] An on-chain and off-chain identity verification system based on a trusted execution environment includes an identity binding module, a trust state channel module, a proof generation module, a state verification module, and a state storage module. The identity binding module obtains the user's decentralized identity and on-chain identity certificate, establishes a binding relationship between the on-chain identity certificate and the decentralized identity through a smart contract, and records the trusted execution environment authentication information used to generate the on-chain identity certificate with the decentralized identity and then records it to the blockchain. The trust state channel module establishes an off-chain trust state channel between the verifier and the verifier in the blockchain network and exchanges an initial trust state snapshot, which includes identity information, association information and trusted execution environment authentication digest information. The proof generation module allows the verified party to generate a zero-knowledge proof within a trusted execution environment based on the verification strategy and the signature statement of an authoritative institution, and then sign the zero-knowledge proof using the native key of the trusted execution environment to obtain a signature result. In the state verification module, the verified party sends zero-knowledge proof and signature results to the verifier through the off-chain trust state channel. The verifier verifies the zero-knowledge proof and signature results and updates the trust state snapshot after the verification is successful. When the trust state channel is closed or a dispute occurs, the state notarization module submits the final trust state snapshot to the smart contract for verification. If the verification is successful, the submitted trust state snapshot is determined to be the final valid trust state and recorded on the blockchain to complete the notarization. Otherwise, the submitted trust state snapshot is rejected, and a dispute resolution process is triggered to resubmit the trust state snapshot for verification.

[0020] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any one of the following ways: Obtain the user's decentralized identity and on-chain identity certificate, establish a binding relationship between the on-chain identity certificate and the decentralized identity through a smart contract, and record the trusted execution environment authentication information used to generate the on-chain identity certificate and the decentralized identity in the blockchain. In a blockchain network, the verifier and the verifier establish an off-chain trust state channel and exchange initial trust state snapshots, which include identity information, association information, and trusted execution environment authentication digest information. The party being verified generates a zero-knowledge proof within the Trusted Execution Environment (TEE) based on the verification strategy and the signature statement from an authoritative institution, and then signs the zero-knowledge proof using the TEE's intrinsic key to obtain the signature result. The verified party sends zero-knowledge proof and signature results to the verifier through the off-chain trust state channel. The verifier verifies the zero-knowledge proof and signature results and updates the trust state snapshot after the verification is successful. When the trust state channel is closed or a dispute occurs, the final trust state snapshot is submitted to the smart contract for verification. If the verification is successful, the submitted trust state snapshot is determined to be the final valid trust state and recorded on the blockchain for notarization. Otherwise, the submitted trust state snapshot is rejected, and a dispute resolution process is triggered to resubmit the trust state snapshot for verification.

[0021] This invention, by adopting the above technical solutions, has significant technical effects: By combining a trusted execution environment with zero-knowledge proof technology, identity verification is completed without disclosing the user's original identity attribute information. At the same time, the trusted execution environment ensures the security of the proof generation process and the key usage process, effectively improving the security, credibility, and privacy protection capabilities of identity authentication. This solves the problems of easy leakage of identity data and insufficient credibility of the proof process in traditional identity authentication schemes. By establishing an off-chain trusted state channel to complete the identity verification interaction, on-chain evidence is stored only when the channel is closed or a dispute occurs, reducing on-chain computational overhead and improving identity verification efficiency. At the same time, it ensures the traceability, consistency, and immutability of the verification results, realizing trusted collaborative management of on-chain and off-chain identity states. Attached Figure Description

[0022] Figure 1 This is a schematic flowchart of the method of the present invention; Figure 2 This is a schematic diagram of the system modules of the present invention. Detailed Implementation Plan To clearly illustrate the present invention and make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the content of the embodiments of the present invention, so that those skilled in the art can implement them by referring to the text of the specification.

[0023] In the context of this invention, the blockchain technology-related concepts involved, such as TEE (Trusted Execution Environment) and ZKP (zero knowledge proof), are known in principle to those skilled in the art. However, those skilled in the art will understand how to apply these technologies in this context after reading this application, and will clearly understand that these technologies, combined with other features in the specific context, have novelty.

[0024] The technology of the present invention will be described in detail below.

[0025] Example 1: An on-chain and off-chain authentication method based on a trusted execution environment, such as Figure 1 As shown, it includes the following steps: S100. Obtain the user's decentralized identity and on-chain identity certificate, establish a binding relationship between the on-chain identity certificate and the decentralized identity through a smart contract, and record the trusted execution environment authentication information used to generate the on-chain identity certificate with the decentralized identity to the blockchain. S200. The verifier and the verifier in the blockchain network establish an off-chain trust state channel and exchange initial trust state snapshots. The initial trust state snapshots include identity information, association information, and trusted execution environment authentication summary information. S300. The verified party generates a zero-knowledge proof within the Trusted Execution Environment (TEE) based on the verification strategy and the signature statement of the authoritative institution, and signs the zero-knowledge proof using the TEE's intrinsic key to obtain a signature result. S400. The verified party sends zero-knowledge proof and signature results to the verifier through the off-chain trust state channel. The verifier verifies the zero-knowledge proof and signature results and updates the trust state snapshot after the verification is successful. S500. When the trust state channel is closed or a dispute occurs, the final trust state snapshot is submitted to the smart contract for verification. If the verification is successful, the submitted trust state snapshot is determined to be the final valid trust state and recorded on the blockchain for notarization. Otherwise, the submitted trust state snapshot is rejected, and a dispute resolution process is triggered to resubmit the trust state snapshot for verification.

[0026] S100. Obtain the user's decentralized identity and on-chain identity credential; establish a binding relationship between the on-chain identity credential and the decentralized identity through a smart contract; and record the trusted execution environment authentication information used to generate the on-chain identity credential, along with the decentralized identity, onto the blockchain. This includes the following steps: Obtain the user's decentralized identity and the corresponding decentralized identity identifier; parse the public key information, server endpoint information, and identity declaration information in the corresponding identity document based on the decentralized identity identifier; obtain the on-chain identity credential held by the user and the identity credential identifier corresponding to the on-chain identity credential; establish a binding relationship between the identity credential identifier and the decentralized identity identifier through a smart contract. During the process of establishing the mapping relationship, the binding transaction hash, binding timestamp, and binding block height generated when establishing the binding relationship are recorded; a binding digest value is generated based on the decentralized identity identifier, identity credential identifier, trusted execution environment authentication digest, binding transaction hash, and binding block height.

[0027] Among them, BindHash represents the binding digest value; DID represents the decentralized identity identifier; CID represents the identity credential identifier; AttHash represents the trusted execution environment authentication digest; TxHash represents the binding transaction hash; and Height represents the binding block height.

[0028] Obtain the Trusted Execution Environment (TEE) authentication report used to generate the on-chain identity credential; parse the device public key, device measurement value, and device identity identifier in the authentication report; verify the validity of the authentication report signature; and verify the TEE operating status based on the device measurement value. Once the authentication report is verified, generate the corresponding TEE authentication digest AttHash. The trusted execution environment authentication digest is associated with the decentralized identity through a smart contract, and the association is recorded in the blockchain ledger, thus completing the trusted association between the trusted execution environment authentication information used to generate the on-chain identity credential and the decentralized identity.

[0029] In this embodiment, by establishing the association between decentralized identity, on-chain identity credentials, and trusted execution environment authentication information, user identity, identity credentials, and trusted hardware form a unified trusted identity entity. At the same time, the binding digest value is used to realize the integrity verification of the association relationship, providing a trusted foundation for the subsequent establishment of off-chain trust state channels, execution of verification strategies, and generation of zero-knowledge proofs.

[0030] S200. The verifier and the verifier in the blockchain network establish an off-chain trust state channel and exchange initial trust state snapshots. The initial trust state snapshots include identity information, association information, and trusted execution environment authentication digest information, including the following steps: Verify that both parties exchange their respective decentralized identity identifiers (DIDs), and verify the validity of the binding relationship between the on-chain identity credential and the decentralized identity based on the blockchain ledger, as well as the validity of the association relationship between the trusted execution environment authentication information used to generate the on-chain identity credential and the decentralized identity, and obtain the binding block height and trusted execution environment authentication digest recorded when establishing the binding relationship; Verify the exchange of Trusted Execution Environment (TEE) certification summaries between the two parties, and verify the authenticity and completeness of the device certification report corresponding to the certification summaries; An initial trust state snapshot is generated based on the decentralized identity identifier, the bound block height, the trusted execution environment authentication digest, the state version number, and the timestamp. Verify that both parties sign and confirm the initial trust state snapshot, generate a state commitment value, and establish an off-chain two-way communication channel.

[0031] The trust state snapshot is generated in the following manner:

[0032] Where H(\cdot) represents the hash function, DID represents the decentralized identity identifier, Height represents the block height to which the identity credential is bound, AttHash represents the trusted execution environment authentication digest, Version represents the state version number, and Timestamp represents the timestamp.

[0033] Furthermore, the state commitment values ​​generated by both parties based on their respective state snapshots are verified:

[0034] Here, SnapshotA represents the verifier's state snapshot, and SnapshotB represents the verified party's state snapshot. The state commitment value is used for state synchronization and dispute resolution during subsequent identity verification. By establishing an off-chain trust state channel and generating state snapshots, the number of on-chain interactions can be reduced while ensuring the credibility of the identity state, thereby improving identity verification efficiency and reducing on-chain computational overhead.

[0035] S300. The verified party generates a zero-knowledge proof within the Trusted Execution Environment (TEE) based on the verification policy and the signature statement from the authoritative institution, and signs the zero-knowledge proof using the TEE's intrinsic key to obtain a signature result, including the following steps: The system receives the verification strategy sent by the verification party and parses the attribute requirements and constraints in the verification strategy, wherein the verification strategy includes at least one of the attribute type to be verified, attribute threshold conditions, attribute range conditions, and logical constraint relationships; and determines the set of attributes to be verified based on the parsing results. Extract attribute data corresponding to the set of attributes to be verified from the authoritative authority signature declaration stored within the Trusted Execution Environment, and construct the corresponding verification constraint relationship and verification circuit according to the verification strategy; A zero-knowledge proof algorithm is executed within a trusted execution environment to generate a zero-knowledge proof. The zero-knowledge proof is then digitally signed using the private key of the device within the trusted execution environment, generating a corresponding signature result. The zero-knowledge proof and the signature result are encapsulated into a verification message and sent to the verifier via an off-chain trusted state channel.

[0036] The zero-knowledge proof is generated using the ZK-SNARK algorithm, and its generation process includes a trust setting stage, a proof generation stage, and a proof verification stage.

[0037] Furthermore, the trusted execution environment generates corresponding verification constraints based on the attribute requirements in the verification strategy, and constructs a verification circuit C based on the verification constraints. The verification constraints are used to describe the satisfaction relationship between user attributes and verification conditions.

[0038] For example, when the verification policy requires users to be at least 18 years old and have a reputation score of at least 80, the following verification constraints can be generated:

[0039]

[0040] Furthermore, the above conditions are combined using logical AND operations to form a holistic verification constraint relationship:

[0041] Among them, Age represents the user's age attribute; Credit represents the user's credit attribute; Representing the logical AND operator During the trusted setup phase, the verification circuit C is constructed according to the verification strategy, and a common reference string CRS is generated:

[0042] Where PK is the proof key, used to generate zero-knowledge proofs; and VK is the verification key, used to verify the validity of the proofs.

[0043] Furthermore, the verification strategy is transformed into corresponding constraint relationships:

[0044] Here, PI represents user privacy input information; AI represents auxiliary input information. When the constraint relationship is valid, it means that the user attributes meet the verification policy requirements.

[0045] During the proof generation phase, the trusted execution environment extracts user attribute information from the authoritative authority's signed statement and combines it with the proof key PK and the verification circuit C to generate a zero-knowledge proof:

[0046] Where π represents zero-knowledge proof; PI represents user privacy input information; and AI represents auxiliary input information.

[0047] The zero-knowledge proof is used to prove that user attributes meet the requirements of the verification strategy without disclosing the user's original identity information.

[0048] To improve the efficiency of proof transmission, the trusted execution environment performs a hash operation on the generated zero-knowledge proof to obtain a proof digest:

[0049] Where H represents the hash function; Hashπ represents the zero-knowledge proof digest.

[0050] During the Trusted Execution Environment (TEE) signing phase, the TEE uses an internally generated and non-exportable device private key to sign the proof digest:

[0051] Among them, (SK) TEE This represents the private key of the trusted execution environment device; Sig TEE This indicates the corresponding digital signature result.

[0052] During the verification phase, the verifier first uses the public key of the trusted execution environment device to verify the signature result:

[0053] Among them, PK TEE This represents the public key of the trusted execution environment device. When the verification result is True, it indicates that the zero-knowledge proof originated from the trusted execution environment.

[0054] The zero-knowledge proof is then verified using the verification key VK:

[0055] When the verification result is True, it indicates that the verified party meets the verification policy requirements, and the verifier cannot obtain the original identity attribute information of the verified party.

[0056] In this embodiment, both the zero-knowledge proof generation and signing processes are completed within a trusted execution environment (TEE), leveraging the hardware isolation capabilities provided by the TEE to protect user attribute data and device private key security. By combining ZK-SNARK zero-knowledge proofs with a TEE, a synergistic effect is achieved, enhancing identity privacy, ensuring reliable proof generation, and improving verification efficiency.

[0057] S400. The verified party sends a zero-knowledge proof and signature result to the verifier through the off-chain trust state channel. The verifier verifies the zero-knowledge proof and signature result and updates the trust state snapshot after successful verification. When the off-chain trust state channel is closed or a dispute occurs, the final trust state snapshot is submitted to the on-chain smart contract for verification and notarization, including the following steps: The verifier receives the zero-knowledge proof, proof digest, and trusted execution environment signature result sent by the verifier through the established trusted state channel, and obtains the corresponding trusted execution environment device public key; The verifier first verifies the signature result using the public key of the trusted execution environment device:

[0058] Among them, PK TEE Represents the public key of a trusted execution environment device; π represents a zero-knowledge proof; , Sig TEE This indicates the signature result from the trusted execution environment. When the verification result is True, it means that the zero-knowledge proof originated from the trusted execution environment and has not been tampered with.

[0059] After the signature verification is successful, the verifier uses the verification key VK to verify the zero-knowledge proof:

[0060] Here, VK represents the zero-knowledge proof verification key. When the verification result is True, it indicates that the verified party meets the verification policy requirements, and the verifier cannot obtain the original identity attribute information of the verified party.

[0061] After successful verification, the local trust state snapshot is updated based on the current verification result, and a new state version number and timestamp are generated. The updated trust state snapshot can be represented as follows:

[0062] Wherein, DID represents decentralized identity identifier; Height represents the block height to which the identity credential is bound; AttHash represents the trusted execution environment authentication digest; Version new Indicates the updated status version number; Timestamp new This indicates that the timestamp has been updated.

[0063] Furthermore, a state commitment value is generated based on the updated trust state snapshot:

[0064] StateCommit represents the state commitment value corresponding to the current trust state, which is used to characterize the latest trust state agreed upon by both parties.

[0065] When the trust state channel is closed or a dispute occurs, the final trust state snapshot is submitted to the on-chain smart contract for verification. If the verification is successful, the submitted trust state snapshot is determined to be the final valid trust state and recorded on the blockchain for notarization. If the verification fails, the submitted trust state snapshot is rejected, and a dispute resolution process is triggered to resubmit the trust state snapshot for verification.

[0066] In this embodiment, zero-knowledge proof verification and state updates are completed off-chain, and on-chain interaction is only performed when the channel is closed or a dispute occurs. This ensures the credibility and traceability of the verification results while reducing on-chain computational overhead and transaction confirmation delays, thereby improving identity verification efficiency and system throughput.

[0067] Example 2: An on-chain and off-chain authentication system based on a trusted execution environment, such as Figure 2 As shown, it includes an identity binding module 100, a trust state channel module 200, an proof generation module 300, a state verification module 400, and a state storage module 500. The identity binding module 100 obtains the user's decentralized identity and on-chain identity certificate, establishes a binding relationship between the on-chain identity certificate and the decentralized identity through a smart contract, and records the trusted execution environment authentication information used to generate the on-chain identity certificate with the decentralized identity to the blockchain. The trust state channel module 200 establishes an off-chain trust state channel between the verifier and the verifiable party in the blockchain network and exchanges an initial trust state snapshot, which includes identity information, association information and trusted execution environment authentication digest information. The proof generation module 300 allows the verified party to generate a zero-knowledge proof within a trusted execution environment based on the verification strategy and the signature statement of an authoritative institution, and to sign the zero-knowledge proof using the native key of the trusted execution environment to obtain a signature result. The state verification module 400 allows the verified party to send zero-knowledge proofs and signature results to the verifier through the off-chain trust state channel. The verifier verifies the zero-knowledge proofs and signature results and updates the trust state snapshot after the verification is successful. When the trust state channel is closed or a dispute occurs, the state storage module 500 submits the final trust state snapshot to the smart contract for verification. If the verification is successful, the submitted trust state snapshot is determined to be the final valid trust state and recorded on the blockchain to complete the storage. Otherwise, the submitted trust state snapshot is rejected, and a dispute handling process is triggered to resubmit the trust state snapshot for verification.

[0068] Various changes and modifications made without departing from the spirit and scope of this invention, and all equivalent technical solutions, also fall within the scope of this invention.

[0069] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0070] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0071] This invention is described with reference to the relevant content of the method, terminal device (system), and computer program product according to the invention. It should be understood that the relevant processes and / or combinations of blocks can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, create means for performing a specified function.

[0072] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal equipment to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that perform the specified function. These computer program instructions may also be loaded onto a computer or other programmable data processing terminal equipment to cause a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing steps for performing the specified function from the instructions that execute on the computer or other programmable terminal equipment.

[0073] It should be noted that: The phrase "an embodiment" or "an embodiment" used in this specification means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. Therefore, the phrase "an embodiment" or "an embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment.

[0074] The above description of the embodiments is provided to enable those skilled in the art to understand and apply the present invention. It will be apparent to those skilled in the art that various modifications can be made to the above embodiments, and the general principles described herein can be applied to other embodiments without inventive effort. Therefore, the present invention is not limited to the above embodiments, and any improvements and modifications made to the present invention by those skilled in the art based on the disclosure thereof should be within the scope of protection of the present invention.

Claims

1. An on-chain and off-chain authentication method based on a trusted execution environment, characterized in that, Includes the following steps: Obtain the user's decentralized identity and on-chain identity certificate, establish a binding relationship between the on-chain identity certificate and the decentralized identity through a smart contract, and record the trusted execution environment authentication information used to generate the on-chain identity certificate and the decentralized identity in the blockchain. In a blockchain network, the verifier and the verifier establish an off-chain trust state channel and exchange initial trust state snapshots, which include identity information, association information, and trusted execution environment authentication digest information. The party being verified generates a zero-knowledge proof within the Trusted Execution Environment (TEE) based on the verification strategy and the signature statement from an authoritative institution, and then signs the zero-knowledge proof using the TEE's intrinsic key to obtain the signature result. The verified party sends zero-knowledge proof and signature results to the verifier through the off-chain trust state channel. The verifier verifies the zero-knowledge proof and signature results and updates the trust state snapshot after the verification is successful. When the trust state channel is closed or a dispute occurs, the final trust state snapshot is submitted to the smart contract for verification. If the verification is successful, the submitted trust state snapshot is determined to be the final valid trust state and recorded on the blockchain for notarization. Otherwise, the submitted trust state snapshot is rejected, and a dispute resolution process is triggered to resubmit the trust state snapshot for verification.

2. The on-chain and off-chain authentication method based on a trusted execution environment according to claim 1, characterized in that, The process of establishing the binding relationship between the on-chain identity credential and the decentralized identity through a smart contract includes the following steps: Obtain the user's decentralized identity and the corresponding decentralized identity identifier; parse the public key information, server endpoint information, and identity declaration information in the corresponding identity document based on the decentralized identity identifier; obtain the on-chain identity credential held by the user and the corresponding identity credential identifier. A binding relationship is established between the on-chain identity credential identifier and the decentralized identity identifier through a smart contract, and the binding relationship is recorded in the blockchain ledger.

3. The on-chain and off-chain authentication method based on a trusted execution environment according to claim 2, characterized in that, After establishing a binding relationship between the on-chain identity credential and the decentralized identity, and associating the trusted execution environment authentication information used to generate the on-chain identity credential with the decentralized identity, the smart contract records the binding transaction hash, binding timestamp, and binding block height generated when establishing the binding relationship. Generate a binding digest value based on the decentralized identity identifier, identity credential identifier, trusted execution environment authentication digest, binding transaction hash, and binding block height: Wherein, BindHash represents the binding digest value; DID represents the decentralized identity identifier; CID represents the identity credential identifier; AttHash represents the trusted execution environment authentication digest; TxHash represents the binding transaction hash; and Height represents the binding block height.

4. The on-chain and off-chain authentication method based on a trusted execution environment according to claim 1, characterized in that, The process of associating the trusted execution environment authentication information used to generate the on-chain identity credential with the decentralized identity and recording it on the blockchain includes the following steps: Obtain the Trusted Execution Environment (TEE) authentication report used to generate the on-chain identity credential; parse the device public key, device measurement value, and device identity identifier in the authentication report; verify the validity of the authentication report signature; and verify the TEE operating status based on the device measurement value. Once the authentication report is verified, the trusted execution environment authentication information is associated with the decentralized identity via a smart contract, and the association is recorded in the blockchain ledger to form a trusted association between the decentralized identity and the trusted execution environment used to generate the on-chain identity credential.

5. The on-chain and off-chain authentication method based on a trusted execution environment according to claim 1, characterized in that, The verifier and the verifier in the blockchain network establish an off-chain trust state channel and exchange initial trust state snapshots, including the following steps: The verifier and the verifier exchange their respective decentralized identity identifiers and verify the corresponding on-chain identity credentials, decentralized identity association records, and trusted execution environment authentication digest information. After successful verification, an initial trust state snapshot is generated and exchanged. The initial trust state snapshot includes at least the identity identifier, the block height corresponding to the identity credential and the decentralized identity association record, the trusted execution environment authentication digest value, the state version number, and the timestamp, in order to establish an off-chain trust state channel between the two parties.

6. The on-chain and off-chain authentication method based on a trusted execution environment according to claim 1, characterized in that, The verified party generates a zero-knowledge proof within the Trusted Execution Environment (TEE) based on the verification strategy and the signature statement from an authoritative institution, and signs the zero-knowledge proof using the TEE's intrinsic key to obtain a signature result, including the following steps: The system receives a verification strategy sent by the verification party and parses the attribute requirements and constraints in the verification strategy. The verification strategy includes at least one of the following: attribute type to be verified, attribute threshold condition, attribute range condition, and logical constraint relationship. Based on the verification strategy, corresponding verification constraints and verification circuits are constructed, and attribute data corresponding to the verification strategy is extracted from the authoritative institution signature declaration stored within the trusted execution environment. A zero-knowledge proof algorithm is then executed using the attribute data to generate a zero-knowledge proof that proves its attributes meet the verification strategy requirements. The authoritative institution signature declaration includes at least one of identity attribute declaration, qualification attribute declaration, reputation attribute declaration, and authority attribute declaration. The zero-knowledge proof is expressed as follows: The zero-knowledge proof is digitally signed using a device private key generated internally within the trusted execution environment and not exportable, generating a corresponding signature result, which is expressed as follows: in, This represents the private key of the trusted execution environment device. π represents the signature result, C represents the verification circuit, PK represents the proof key, PI represents the privacy input information, and AI represents the auxiliary input information.

7. The on-chain and off-chain authentication method based on a trusted execution environment according to claim 1, characterized in that, The verifier verifies the zero-knowledge proof and signature results, and updates the trust state snapshot after successful verification, including the following steps: The verifier uses the device public key corresponding to the trusted execution environment to verify the validity of the signature result: After the signature verification is successful, the zero-knowledge proof is verified: When all the above verification results are True, it is confirmed that the verified party meets the verification policy requirements, and the local trust state snapshot is updated; a state commitment value is generated based on the updated trust state: Among them, PK TEE This represents the public key of the trusted execution environment device. The signature result is represented by π, the zero-knowledge proof by π, and the verification key for the zero-knowledge proof by VK. Snapshot new This represents the updated trust state snapshot.

8. The on-chain and off-chain authentication method based on a trusted execution environment according to claim 1, characterized in that, When the trust state channel is closed or a dispute occurs, the final trust state snapshot is submitted to the smart contract for verification; if the verification is successful, the submitted trust state snapshot is determined to be the final valid trust state and recorded on the blockchain for evidence storage. Otherwise, the submitted trust state snapshot is rejected, and a dispute resolution process is triggered to resubmit the trust state snapshot for verification, including the following steps: When the trust state channel is closed or a dispute occurs, either the verifier or the verifier shall submit the final trust state snapshot, the state commitment value and the corresponding signature information to the smart contract. The smart contract verifies the state commitment value, state version number, timestamp, and signature information. If the verification result is successful, the submitted trust state snapshot is determined to be the final valid trust state, and the final valid trust state is recorded in the blockchain ledger to complete on-chain notarization. Otherwise, the submitted trust state snapshot is rejected, and a dispute resolution process is triggered. In the dispute resolution process, the verifier and the verifier resubmit the trust state snapshot and corresponding signature information, and the smart contract re-executes the verification. When the verification is successful, the resubmitted trust state snapshot is determined as the final valid trust state and recorded in the blockchain ledger to complete the evidence storage.

9. An on-chain and off-chain authentication system based on a trusted execution environment, characterized in that, It includes an identity binding module, a trust state channel module, a proof generation module, a state verification module, and a state storage module; The identity binding module obtains the user's decentralized identity and on-chain identity certificate, establishes a binding relationship between the on-chain identity certificate and the decentralized identity through a smart contract, and records the trusted execution environment authentication information used to generate the on-chain identity certificate with the decentralized identity and then records it to the blockchain. The trust state channel module establishes an off-chain trust state channel between the verifier and the verifier in the blockchain network and exchanges an initial trust state snapshot, which includes identity information, association information and trusted execution environment authentication digest information. The proof generation module allows the verified party to generate a zero-knowledge proof within a trusted execution environment based on the verification strategy and the signature statement of an authoritative institution, and then sign the zero-knowledge proof using the native key of the trusted execution environment to obtain a signature result. In the state verification module, the verified party sends zero-knowledge proof and signature results to the verifier through the off-chain trust state channel. The verifier verifies the zero-knowledge proof and signature results and updates the trust state snapshot after the verification is successful. When the trust state channel is closed or a dispute occurs, the state storage module submits the final trust state snapshot to the smart contract for verification. If the verification passes, the submitted trust state snapshot is determined to be the final valid trust state and recorded on the blockchain for notarization; otherwise, the submitted trust state snapshot is rejected and a dispute resolution process is triggered to resubmit the trust state snapshot for verification.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 8.

Images