Decentralized identity management method based on trusted execution environment

Abstract

The invention discloses a decentralized identity management method based on a trusted execution environment, and the method comprises the steps: generating, isolating and storing a user decentralized identity in the trusted execution environment of equipment, carrying out the Hash signature of a decentralized identity document, and recording an uplink; the block chain consensus node verifies the decentralized document uplink transaction through a Byzantine fault-tolerant consensus mechanism and achieves consistency, and writes the metadata of the decentralized identity into the block; encrypting and storing the voucher in a trusted execution environment of the equipment by adopting a Pearson commitment, and supporting voucher Hash uplink and commitment uplink; and introducing a multilevel access structure based on a binary tree, and verifying the and / or logic combination voucher by adopting a depth-first search algorithm. According to the method, decentralized autonomy of the user identity and hardware security isolation are supported, and the reliability and privacy protection capability of user identity management are improved.

Description

Technical Field

[0001] This invention relates to a decentralized identity management method based on a trusted execution environment, belonging to the field of blockchain technology. Background Technology

[0002] In recent years, with the deepening of digital transformation, identity management, as the cornerstone of information system security, has become increasingly important. Traditional centralized identity management relies on a central institution to uniformly allocate and verify identities, which not only poses a single point of failure risk but also faces challenges such as identity forgery, privacy leaks, and complex cross-domain authentication. It is no longer able to meet the needs of emerging scenarios such as multi-device access, trusted data interaction, and user privacy protection.

[0003] Self-Sovereign Identity (SSI) technology has emerged, emphasizing that identity is controlled by the user and does not rely on centralized institutions. The DID and VC standards proposed by the W3C provide unified data structure specifications and operational frameworks for the generation, issuance, and verification of identities. Blockchain, as a decentralized trust infrastructure, possesses characteristics such as immutability, traceability, and high availability, providing a feasible path for building decentralized identity systems and effectively alleviating the trust bottlenecks and data silo problems in traditional identity architectures.

[0004] However, relying solely on blockchain is insufficient to solve core security issues throughout the entire identity management lifecycle. Especially in critical stages such as DID private key protection and VC generation and disclosure, if these processes are still performed by user devices in ordinary environments, they will face threats such as private key leakage and credential abuse. Therefore, hardware-level trusted computing technology is needed to provide robust security support for identity operations. Trusted Execution Environments (TEEs), as an isolated computing technology based on processor architecture, provide trusted protection for identity-sensitive data and operations. For example, TrustZone technology, widely deployed on the ARM architecture, divides the same physical device into a "secure world" and a "normal world," enabling critical identity information (such as DID private keys) to be generated, stored, and used in the secure world, preventing its exposure to vulnerable ordinary environments. Compared to other TEE solutions such as SGX, TrustZone requires no additional hardware costs and is highly suitable for resource-constrained IoT terminal devices.

[0005] After preliminary search, the following solutions are disclosed in the prior art:

[0006] Publication No. CN119766419 A discloses a cross-chain-based adaptive identity revocation method and system. The system includes an application chain, a super chain, trusted hardware, and automatic proxy nodes. The application chain provides initiators and receivers for cross-chain transactions, identifies user cross-chain operations through smart contracts, and transmits these operations to the automatic proxy nodes. The super chain periodically publishes revocation list information to the automatic proxy nodes via a heartbeat mechanism. Each automatic proxy node is equipped with the trusted hardware, providing a trusted execution environment for the identity revocation mechanism to verify heartbeat information, synchronize time, and execute identity revocation operations. This system is applicable to multi-chain environments for financial transactions, supply chain management, and IoT identity authentication scenarios, effectively improving the security, transparency, and revocation efficiency of cross-chain systems.

[0007] However, this patent only focuses on the heartbeat synchronization and verification of the revocation list, lacking complete process support for user identity generation, registration, credential issuance and storage, and also failing to provide hardware isolation protection and privacy security measures for user private keys and sensitive data. These shortcomings correspond to the purpose of this invention.

[0008] Publication No. CN119519927 A discloses a controllable update method for blockchain smart contracts, including: a system initialization phase, where the blockchain stores hash values ​​of participant identities for authentication, and participants and authentication nodes generate public and private keys for secure transmission; a contract deployment phase, where the deployer and the trusted execution environment authenticate each other, and the trusted execution environment generates relevant parameters and shares them with all users and the deployer as needed, and the deployer executes the contract deployment operation and shares relevant data; an attribute key generation phase, where the updater and the trusted execution environment authenticate each other, and the deployer and updater send encrypted relevant attributes to the trusted execution environment, which generates attribute keys and sends them to the updater in encryption; and a contract update phase, where the updater obtains a controllable chameleon hash ciphertext set, generates relevant parameters, verifies them, executes the contract update operation, and shares relevant data.

[0009] While this invention achieves identity authentication and attribute key management during smart contract updates using a trusted execution environment, its focus is on controllable hashing and the contract update process, rather than supporting a complete decentralized identity management process. This drawback corresponds to the purpose of this invention.

[0010] Therefore, there is an urgent need to address how to combine the decentralized trust capabilities of blockchain with the hardware-level security isolation advantages of TEE to build an identity management system with strong security, autonomous control, and good privacy protection capabilities. Summary of the Invention

[0011] This invention addresses the problem of insecure off-chain operations of identifiers and verifiable credentials in decentralized identity management, leading to easy tampering of user identities and misuse of verifiable credentials. While existing technologies offer solutions for decentralized identity management, such as authorization binding between multiple decentralized identities on-chain, they still lack hardware isolation protection for identity keys and privacy security measures. This invention aims to place the critical execution process of user decentralized identity management within a secure world of a trusted execution environment (TEE), combining primary and secondary ID dual identity identification to achieve end-to-end isolation protection for key operations such as key generation, credential issuance, and storage within a TEE. Sensitive attributes are effectively hidden through Pedersen commitment encryption claims. A multi-level credential access structure based on a binary tree is utilized, and the Depth-First Search (DFS) algorithm is employed to verify AND / OR logically combined credentials to meet the multi-credential logical verification needs in complex business scenarios.

[0012] To address the aforementioned technical problems, this invention provides a decentralized identity management method based on a trusted execution environment, comprising the following steps:

[0013] Step 1: User registration identity,

[0014] Each user initializes the trusted execution environment of their device, generating a public-private key pair, a decentralized identity (DID), and a decentralized identity document. The user's DID consists of a primary ID and multiple secondary IDs, each corresponding to a public-private key pair. The DID document is a parsable data structure carrying the DID (such as public key, server endpoint, and verification method). The user first generates and signs the complete DID document locally, then submits it to the blockchain network. Consensus nodes verify the transaction and reach agreement through a Byzantine fault-tolerant consensus mechanism. Finally, the DID's metadata is written to the block, ensuring that this identity record cannot be tampered with.

[0015] The service endpoint is the network entry address in the DID document used to describe the interaction with the DID subject, and it usually appears in the form of a URI or URL. For example, it can point to a message broker, allowing external applications to send encrypted messages to the DID subject through this address; or it can be a callback address of a decentralized application used to receive responses to authentication requests, that is, to tell other parties "which network address can be used to access or invoke the services provided by this identity".

[0016] The verification method specifies the mechanism used to verify the authenticity of the public key or other credentials associated with the DID.

[0017] The primary ID represents a user's unique real identity in the blockchain network. It is used to prove the user's legitimacy to the blockchain network during registration and serves as the basic identity source or "mother identity" for all secondary IDs. Each primary ID corresponds to a pair of public and private keys, where the private key is always stored in isolation in a Trusted Execution Environment (TEE) and is used for signing and proving the user's control over the primary ID.

[0018] The secondary ID is a pseudonym or scenario-specific ID derived from the primary ID. It is also a public-private key pair. When using the secondary ID for operations such as signing, the primary ID is not directly exposed. Users can use different secondary IDs to interact with the outside world in different applications or scenarios to avoid linking to the real identity through on-chain activities.

[0019] The primary ID is not used directly in most business scenarios. When it is necessary to confirm whether a secondary ID belongs to a user, the service provider can access the on-chain mapping relationship between the primary ID and secondary IDs and request the user to complete a random number challenge in the TEE using the primary ID's private key to complete the identity verification. In this way, all user secondary IDs are generated and operated by the legitimate holder of the same primary ID, thereby preventing Sybil attacks; and using multiple secondary IDs reduces the privacy leakage risk of Verifiable Credential (VC) attribute links.

[0020] Step 2: The institution issues a certificate.

[0021] When a user applies for credentials, the institution first sends a random number challenge to the user. The user transmits the challenge request to the TEE, which signs the challenge using its private key and immediately erases the temporary data after signing. Subsequently, the user returns the challenge response and credential declaration data (such as department, degree, age, access permissions, etc. in a student identity credential) to the institution. The institution queries and compares the public key and signature of the user's DID document on the blockchain node to confirm the user's identity. After confirming the validity of the user's identity, the institution performs a hash operation on the credential declaration data submitted by the user, then signs the hash value using its own private key to generate a VC that conforms to the W3C standard. The institution then integrates the signature result with the VC and returns it to the user. Finally, the user receives and stores the VC in the TEE.

[0022] Step 3: The institution records the status of the voucher on the blockchain.

[0023] After the VC is issued, the institution performs digest processing on the credential according to its type: for plaintext credentials, its hash value is calculated as the credential digest; for credentials containing sensitive information, a Pedersen commitment is used to generate a commitment value as the credential digest, where the Pedersen commitment is a large prime number. Implemented on the cyclic group, It is a generator of the cyclic group, for sensitive attribute values Randomly select blinding factors Through homomorphic operations The commitment value was calculated. The verification party is unaware of this. Verify its authenticity when the value is true;

[0024] Subsequently, the institution uses its own private key to jointly sign the credential digest and related metadata, generates a signature certificate, and calls a smart contract to write the signature certificate and credential digest to the blockchain, realizing the immutable on-chain storage of the credential status; when the credential needs to be revoked, the institution or its authorized nodes call the smart contract again to update the on-chain credential status to "revoked", and notify each service provider to update the credential status synchronously through the on-chain event mechanism.

[0025] Step 4: The user sends credentials to the service provider and requests verification.

[0026] When a user needs to verify their identity, the TEE will first selectively disclose or commit to encrypt the VC they hold, and may attach a one-time generated timestamp and random number to prevent replay attacks; then, the user will send the processed VC along with the digital signature to the service provider.

[0027] Step 5: The service provider verifies the credentials.

[0028] Step 5 introduces a multi-level access structure for credentials based on a binary tree. A depth-first search (DFS) algorithm is used to verify credentials that are logically combined. Efficient, fine-grained verification of the overall credential combination is achieved by merging the Boolean values ​​of tree child nodes. Specifically, this includes:

[0029] Starting from the root node of the access structure, recursively traverse its branches in a depth-first search order; for leaf nodes, execute the verification process of their corresponding single credential; for non-leaf nodes, merge the Boolean verification results of child nodes according to their logic gate type.

[0030] During the traversal, a short-circuit optimization mechanism is introduced. When traversing to an AND gate node, if the verification result of any of its child nodes is false, the verification of subsequent child nodes of the AND gate node is immediately terminated and the node is determined to be false. When traversing to an OR gate node, if the verification result of any of its child nodes is true, the verification of subsequent child nodes of the OR gate node is immediately terminated and the node is determined to be true.

[0031] To improve the efficiency of the short-circuit optimization mechanism, a weight optimization strategy is adopted, which assigns weight attributes to leaf node credentials and performs structural optimization based on weights when constructing the access tree, placing nodes with higher weights on the priority traversal path of depth-first search.

[0032] Furthermore, in step 1, when the device is initialized in the TEE, it generates and stores the user's primary ID and multiple secondary ID public and private key pairs in isolation, and constructs a resolvable DID document containing metadata such as public key, server endpoint, and verification method. The primary ID is unique to the outside world to resist Sybil attacks, while multiple secondary IDs are mapped to the primary ID to protect attribute association privacy.

[0033] Users sign the DID document and submit it to the blockchain network. Consensus nodes verify the transaction and reach an agreement through the Byzantine fault-tolerant consensus mechanism, and finally write the DID's metadata into the block.

[0034] In step 2, the service provider first sends a random number challenge to the user. The user then passes the challenge to the device TEE, which uses the corresponding private key to sign the challenge and immediately destroys the temporary data after signing.

[0035] Service providers verify user identity by comparing the public key and signature in the on-chain DID document through blockchain query. The organization then hashes the user's submitted claim data and signs it with its own private key to generate a VC that conforms to W3C specifications. The signature result is then integrated with the claim data and returned to the user. The user receives and securely stores the credential in the TEE for subsequent selective disclosure or generation of a Verifiable Presentation (VP).

[0036] The hash operation functions include: SHA-256 function, MD5 function, SHA-1 function, etc.

[0037] In step 3, the institution performs digest processing on the voucher according to the voucher type—calculating the hash value for plaintext vouchers and generating a commitment value for encrypted vouchers using Pedersen commitment encryption;

[0038] Then, the institution uses its own private key to jointly sign the credential digest and related metadata (user public key, institution public key, institution DID, etc.) to generate a signature certificate. Next, the institution calls a smart contract to write the signature certificate and credential digest into the blockchain, realizing the immutable on-chain storage of the credential status. When the credential needs to be revoked, the institution or its authorized nodes call the smart contract again to update the on-chain credential status to "revoked" and notify all service providers to update the credential status synchronously through the on-chain event mechanism.

[0039] In step 4, when a user needs to verify, the credentials held are first selectively disclosed or committed to encryption in the device's TEE, and combined with a one-time generated timestamp and random number to prevent replay attacks.

[0040] Step 5 introduces a multi-level access structure for credentials based on a binary tree, and uses the DFS algorithm to verify the combined credentials with / or logical combinations. The efficient and fine-grained verification of the overall credential combination is achieved by merging the Boolean values ​​of the tree child nodes.

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

[0042] This application provides a decentralized identity management method based on a Trusted Execution Environment (TEE). By utilizing TEE hardware isolation technology, a tamper-proof key operation enclave is formed locally on IoT devices, achieving physical isolation of key processes such as private key generation, storage, and signature verification. Blockchain provides globally consistent and immutable records for decentralized identities and institution-issued credentials, ensuring identity ownership and credential trustworthiness, and avoiding risks such as single points of failure in traditional centralized identity management systems. A dual identity mechanism of primary ID and secondary ID is designed. The primary ID serves as the main identity resistant to Sybil attacks, while the secondary ID serves as a scenario-specific pseudonym for privacy protection. Identity linking is achieved through on-chain mapping and random number challenge verification, enhancing identity privacy protection and attack resistance. Verifiable credentials are combined with plaintext claims and Pedersen commitment cryptographic claims, satisfying the verification efficiency requirements of conventional business scenarios while using homomorphic commitment algorithms to prove sensitive attributes, effectively resisting link attacks and privacy inferences. To address the challenge of multi-credential logical verification in complex business scenarios, a multi-level credential proof method based on a binary tree structure is proposed. This method organizes fragmented credentials into a hierarchical access structure through logical operators, thereby optimizing the verification time complexity from traditional linear search to logarithmic level, significantly improving the efficiency of multi-condition credential verification scenarios. Attached Figure Description

[0043] Figure 1 This is an example of an overall structural diagram of a decentralized identity management method based on a trusted execution environment;

[0044] Figure 2 This is a schematic diagram of an exemplary user DID identity registration process;

[0045] Figure 3 This is an exemplary schematic diagram of the entire identity management workflow;

[0046] Figure 4 This is a schematic diagram of an exemplary tree-based multi-level access structure for credentials;

[0047] Figure 5 This is a schematic diagram of an exemplary leaf node credential verification process. Detailed Implementation

[0048] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0049] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0050] Figure 1 This paper demonstrates the overall architecture of a decentralized identity management approach based on a trusted execution environment. The approach model includes users, institutions, service providers, and a blockchain network. A blockchain council can act as an institution, and any IoT application can act as a service provider. Institutions are configured as full nodes on the blockchain, while resource-constrained IoT devices are deployed as light nodes. Institutions sign and issue credentials, while service providers publish access policies and verify credentials. Users are the credential holders who wish to access the application.

[0051] Figure 2 This diagram illustrates the user DID registration process. Each user holds a pair of DIDs, consisting of a primary ID and multiple secondary IDs. The primary ID is unique for regulatory purposes, while multiple secondary IDs can be used in various everyday applications. Blockchain consensus is central to the registration and issuance of DIDs for IoT devices and users. In the Practical Byzantine Fault Tolerance (PBFT) consensus model, there are client nodes (users), primary nodes, and secondary nodes. Client nodes are responsible for sending transaction requests. Primary nodes are used to package transactions into blocks and perform block consensus; only one primary node exists per consensus round. Secondary nodes are used for block consensus; multiple secondary nodes exist per round, and each secondary node performs similar tasks. Both primary and secondary nodes are consensus nodes. PBFT consensus mainly includes three phases: the pre-preparation phase, the preparation phase, and the commit phase. In the diagram, node 0 is the primary node, and node 3 is the faulty node, as detailed below:

[0052] (1) The user first sends a main ID registration request to the blockchain node, providing verifiable proof of identity, such as an electronic ID card, device MAC address, or other guarantees. The blockchain node then verifies the identity and publishes the authentication result. If successful, the user will generate a DID identifier corresponding to the main ID and send a registration request to the blockchain node.

[0053] (2) Next, the blockchain nodes perform PBFT consensus. In the pre-preparation phase, the master node receives the request for verification and broadcasts the pre-preparation message to all slave nodes. Each slave node receives the pre-preparation message and verifies it. Then, in the preparation phase, each slave node verifies the validity of the pre-preparation message and broadcasts the preparation message to the entire network. When a node collects at least 2t+1 (t is the number of faulty and attacking nodes) valid preparation messages from different nodes, it reaches the state of broadcasting the commit message. Finally, in the commit phase, if a node collects at least 2t+1 commit messages, it will write the request into its local state machine in sequence and return the execution result to the client.

[0054] (3) When a user receives a submission message, it can confirm whether the blockchain nodes have reached a consensus on the request. If so, the blockchain nodes will reply to the user using the master ID.

[0055] (4) The user receives a reply and confirms that the consensus has been completed, and then stores the master ID in the device's TrustZone security world.

[0056] (5) Users continue to apply for a secondary ID and submit the primary ID to start a new round of consensus. At this time, the secondary ID is public.

[0057] Figure 3 The entire identity management workflow is demonstrated. When a user device is activated, TrustZone verifies the integrity of the secure world firmware OP-TEE via Secure Boot, loads and initializes the device. A DID public-private key pair is generated within TrustZone's secure world. The private key never leaves the TEE's secure memory, while the public key is transmitted to the ordinary world via a secure API for DID registration. The DID document is hashed within the secure world and signed using the private key to ensure document integrity. The processed DID identity information is then transmitted to the ordinary world, which only receives the signature result and cannot tamper with the data. Next, the user submits an identity registration request to the organization, including metadata such as the public key and device type. The DID document is stored on the blockchain for evidence, ensuring immutability and global traceability. Finally, the blockchain node returns a registration success message to the user.

[0058] When a user applies for a VC from an institution, they must first prove the validity of their DID. The institution sends a random number challenge to the user, requiring them to prove they possess the DID's private key. Upon receiving the challenge, the user forwards it to the TEE (TrustEngineer), which signs the challenge using its private key. After signing, TrustZone immediately erases temporary data in memory, such as the random number and intermediate signature state. Next, the institution queries the blockchain node for the DID document, checks the DID's validity, verifies the consistency between the public key and the on-chain record, and verifies the signature's validity, thereby confirming the user's identity. Finally, if the verification passes, the institution hashes the declared data, signs the hash value using its private key, generates a digital signature for the VC, encapsulates the signature result and the declared data into a W3C-compliant VC, and returns the integrated signature result and VC to the user; otherwise, an error message is returned.

[0059] After receiving a VC issued by an organization, the user stores it in the TrustZone secure world and performs credential commitment encryption as needed, or generates a VP (Verification Token) using a selective disclosure mechanism. Alternatively, one-time verification parameters, such as timestamps and random numbers, can be dynamically generated in the secure world to prevent replay attacks. The processed VC is then sent to the service provider. Upon receiving the VC, the service provider parses it, extracting the claim data, signature, and organization DID. Next, the service provider checks the VC signature validity, organization identity, and credential status through blockchain nodes. Finally, if verification passes, the service provider returns a verification success message to the user; otherwise, it returns an error message.

[0060] Figure 4 This demonstrates a multi-level access tree structure for credentials, consisting of a series of nodes. Each non-leaf node is composed of its child nodes, and each node represents a logical condition. Leaf nodes typically represent individual credential conditions, while non-leaf nodes are used to combine multiple child conditions to form more complex verification logic. Non-leaf nodes can be divided into two categories: AND gates and OR gates. An AND gate indicates that the conditions of both its left and right child nodes must be satisfied simultaneously, while an OR gate indicates that only one child node needs to be satisfied. The verification process uses bottom-up Boolean operations, and the verification result of a non-leaf node is logically calculated from the verification results of its child nodes.

[0061] To improve verification efficiency and prevent performance issues caused by deep recursive insertion, weight values ​​are assigned to credential nodes, and the tree structure is optimized based on these weights. Specifically, credentials with higher weights are placed in the left subtree, ensuring that the maximum weight in the left subtree is greater than that in the right subtree. This helps prioritize the processing of more important credentials during traversal and verification, improving the overall efficiency and security of access control.

[0062] Figure 5This demonstrates the credential verification process at the leaf nodes of the credential access tree, employing the Depth-First Search (DFS) algorithm during the verification process. (For operators...) If either the left or right child node returns TRUE, then the tree returns TRUE, and the verification is complete; for operators... If either the left or right child node returns FALSE, the tree returns FALSE, and verification is complete. If the entire tree's boolean value is TRUE, then TRUE is returned; otherwise, FALSE is returned. Each credential in a leaf node needs to perform the following steps to verify the identity of the user:

[0063] (1) The service provider authenticates the user to confirm whether the private key is in the user's possession. First, the user initiates a challenge, generates a challenge hash, and signs the hash value with their private key. Both the challenge and the signature are sent to the service provider. Then, the service provider decrypts the signature using the user's public key to obtain the hash value and generates a new hash value using the same hashing algorithm as the original challenge. Finally, the service provider compares the new hash value with the hash value provided by the user. Verification is successful only if the two hash values ​​match, indicating that the public key used to decrypt the signature corresponds to the private key used to create the signature.

[0064] (2) Next, the user sends a credential authentication request to the service provider. The service provider extracts the organization's DID from the credential, invokes the smart contract, and checks whether it is in the list of compliant organizations. Then, the service provider verifies the validity of the credential content, such as the expiration date, credential format, and the organization's signature. The digital signature is actually encrypted using the organization's private key, and the service provider can decrypt the signature using the organization's public key to obtain the credential hash or commitment.

[0065] (3) After receiving the user's credentials, the service provider calculates the hash value or commitment value of the user's credential subject to generate a new digest. Then, it decrypts the credential signature using the institution's public key, extracts the institution's credential digest, and compares it. Verification is successful only if the new digest calculated by the service provider matches the institution's credential digest, which means that the user's attributes have been authenticated by the institution.

[0066] (4) Finally, the service provider will call the smart contract to compare the two digests calculated by the service provider and the institution’s credential digest with the credential digest stored on the blockchain. The verification will only pass if the three digests match.

[0067] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0068] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0069] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0070] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0071] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."

[0072] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A decentralized identity management method based on a trusted execution environment, characterized in that, The method includes the following steps: Step 1: User registration identity, Step 2: The institution issues a certificate. Step 3: The institution records the status of the voucher on the blockchain. Step 4: The user sends credentials to the service provider and requests verification. Step 5: The service provider verifies the credentials.

2. The decentralized identity management method based on a trusted execution environment according to claim 1, characterized in that, Step 1: User registration, details are as follows: Each user initializes the trusted execution environment of the device, generating a public-private key pair, a decentralized identity (DID), and a decentralized identity document. The user's DID consists of a primary ID and multiple secondary IDs, with each ID corresponding to a public-private key pair. The DID document is a parsable data structure that carries the DID (public key), server endpoint, and verification method. The user first generates and signs the complete DID document locally, and then submits it to the blockchain network. Each consensus node verifies the transaction and reaches an agreement through the Byzantine fault-tolerant consensus mechanism. Finally, the metadata of the DID is written into the block to ensure that this identity record cannot be tampered with. The service endpoint is the network entry address in the DID document used to describe the interaction with the DID subject. It appears in the form of a URI or URL, allowing external applications to send encrypted messages to the DID subject through this address; or it is a callback address of a decentralized application used to receive the response to the authentication request, that is, to tell other parties "which network address can be used to access or call the services provided by this identity". The verification method specifies the mechanism used to verify the authenticity of the public key or other credentials associated with the DID; The primary ID represents a user's unique real identity in the blockchain network. It is used to prove the user's legitimacy to the blockchain network during registration and serves as the basic identity source or "mother identity" for all secondary IDs. Each primary ID corresponds to a pair of public and private keys, where the private key is always stored in isolation in a Trusted Execution Environment (TEE) and is used for signing and proving the user's control over the primary ID. The secondary ID is a "pseudonym" or "scenario-specific ID" derived from the primary ID. It is also a public-private key pair. When using the secondary ID for operations such as signing, the primary ID is not directly exposed. Users use different secondary IDs to interact with the outside world in different applications or scenarios to avoid linking to the real identity through on-chain activities. The primary ID is not used directly in most business scenarios. When it is necessary to confirm whether a secondary ID belongs to a user, the service provider can access the mapping relationship between the primary ID and the secondary ID on the chain and request the user to complete a random number challenge in the TEE using the primary ID's private key to complete the identity verification. In this way, the user's secondary IDs are all generated and operated by the legitimate holder of the same primary ID, thereby preventing Sybil attacks. Furthermore, using multiple secondary IDs reduces the privacy leakage risk of Verifiable Credential (VC) attribute links.

3. The decentralized identity management method based on a trusted execution environment according to claim 1, characterized in that, Step 2: The institution issues a certificate, as detailed below. When a user applies for credentials, the institution first sends a random number challenge to the user. The user transmits the challenge request to the TEE, which signs the challenge using its private key and immediately erases the temporary data after signing. Subsequently, the user returns the challenge response and credential declaration data to the institution. The institution queries and compares the public key and signature of the user's DID document on the blockchain node to confirm the user's identity. After confirming the validity of the user's identity, the institution performs a hash operation on the credential declaration data submitted by the user, then signs the hash value using its own private key to generate a VC that conforms to the W3C standard. The institution then integrates the signature result with the VC and returns it to the user. Finally, the user receives and stores the VC in the TEE.

4. The decentralized identity management method based on a trusted execution environment according to claim 1, characterized in that, Step 3: The institution records the status of the voucher on the blockchain, as detailed below. After the VC is issued, the institution first performs a digest processing on the VC according to the selected strategy: if it is a plaintext certificate, the certificate hash value is calculated; if an encrypted certificate is required, Pedersen is used to commit encryption on the certificate; then, the institution uses its own private key to digitally sign the VC and generate a signature certificate; then, the institution calls the smart contract to upload the signature certificate and digest (hash value or commitment value) to the blockchain network; finally, if the certificate needs to be revoked, the institution or authorized node calls the smart contract again to update the on-chain status of the corresponding certificate to "revoked" and reminds all service providers to update the certificate status synchronously through the event notification mechanism.

5. The decentralized identity management method based on a trusted execution environment according to claim 1, characterized in that, Step 4: The user sends credentials to the service provider and requests verification, as detailed below. When a user needs to verify their identity, the TEE will first selectively disclose or commit to encrypt the VC they hold, and may attach a one-time generated timestamp and random number to prevent replay attacks; then, the user sends the processed VC along with the digital signature to the service provider. Step 5: The service provider verifies the credentials. Upon receiving the certificate, the service provider extracts the organization's DID and signature from it, and calls the blockchain smart contract to query the organization's public key, the on-chain stored certificate digest (hash value or commitment value), and the certificate status. The service provider calculates a new hash value or commitment value for the received certificate body (plaintext or encrypted attribute), and uses the organization's public key to decrypt the certificate signature to obtain the organization's original digest. Finally, the service provider compares the two with the on-chain digest. If they match and the certificate has not been revoked, the verification is successful, and the service provider returns the verification result to the user, completing the certificate verification process.

6. The decentralized identity management method based on a trusted execution environment according to claim 1, characterized in that, In step 1, when the device is initialized in the TEE, it generates and stores the user's primary ID and multiple secondary ID public and private key pairs in isolation. It constructs a resolvable DID document containing public key, server endpoint, and authentication method metadata. The primary ID is unique to the outside world to resist Sybil attacks, while multiple secondary IDs are mapped to the primary ID to protect attribute association privacy. Users sign the DID document and submit it to the blockchain network. Consensus nodes verify the transaction and reach an agreement through the Byzantine fault-tolerant consensus mechanism, and finally write the DID's metadata into the block.

7. The decentralized identity management method based on a trusted execution environment according to claim 1, characterized in that, In step 2, the service provider first sends a random number challenge to the user. The user then passes the challenge to the device TEE, which uses the corresponding private key to sign the challenge and immediately destroys the temporary data after signing. Service providers verify user identity by comparing the public key and signature in the on-chain DID document through blockchain query. After that, the organization hashes the user's submitted claim data and signs it with its own private key to generate a VC that conforms to W3C specifications. The signature result is then integrated with the claim data and returned to the user. The user receives and securely stores the credential in the TEE for subsequent selective disclosure or generation of a Verifiable Presentation (VP). The hash functions include: SHA-256 function, MD5 function, and SHA-1 function.

8. The decentralized identity management method based on a trusted execution environment according to claim 1, characterized in that, In step 3, the institution performs digest processing on the vouchers according to their type: for plaintext vouchers, their hash value is calculated as the voucher digest; for vouchers containing sensitive information, a Pedersen commitment is used to generate a commitment value as the voucher digest, where the Pedersen commitment is a large prime number. Implemented on the cyclic group, It is a generator of the cyclic group, for sensitive attribute values Randomly select blinding factors Through homomorphic operations The commitment value was calculated. The verification party is unaware of this. Verify its authenticity when the value is true; Subsequently, the institution uses its own private key to jointly sign the credential digest and related metadata, generates a signature certificate, and calls a smart contract to write the signature certificate and credential digest into the blockchain, realizing the immutable on-chain storage of the credential status; when the credential needs to be revoked, the institution or its authorized nodes call the smart contract again to update the on-chain credential status to "revoked", and notify each service provider to update the credential status synchronously through the on-chain event mechanism.

9. The decentralized identity management method based on a trusted execution environment according to claim 1, characterized in that, Step 5 introduces a multi-level access structure for credentials based on a binary tree. A depth-first search (DFS) algorithm is used to verify credentials that are logically combined. Efficient, fine-grained verification of the overall credential combination is achieved by merging the Boolean values ​​of tree child nodes. Specifically, this includes: Starting from the root node of the access structure, recursively traverse its branches in a depth-first search order; for leaf nodes, execute the verification process of their corresponding single credential; for non-leaf nodes, merge the Boolean verification results of child nodes according to their logic gate type. During the traversal, a short-circuit optimization mechanism is introduced. When traversing to an AND gate node, if the verification result of any of its child nodes is false, the verification of subsequent child nodes of the AND gate node is immediately terminated and the node is determined to be false. When traversing to an OR gate node, if the verification result of any of its child nodes is true, the verification of subsequent child nodes of the OR gate node is immediately terminated and the node is determined to be true. To improve the efficiency of the short-circuit optimization mechanism, a weight optimization strategy is adopted, which assigns weight attributes to leaf node credentials and performs structural optimization based on weights when constructing the access tree, placing nodes with higher weights on the priority traversal path of depth-first search.

Images