Account key setting method, user device and system

Abstract

An account key setting method, a user equipment and a system, the method is executed by a user equipment, the user equipment comprises a trusted execution environment (TEE), the method comprises: obtaining an account corresponding to a user from an identity system, providing the account to the TEE, the identity system stores identity information of the user, and the account corresponds to the identity information; the TEE generates a first public key and a first private key corresponding to the account, stores the first private key, and provides the first public key outside the TEE; send the information of the first public key to the identity system, for storing the account and the information of the first public key in the storage system by the identity system.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of distributed digital identity technology, and in particular relate to an account key setting method, user equipment, and system. Background Technology

[0002] Compared to traditional digital identities, distributed digital identities can control the privacy and security of information through private keys and do not rely on centralized systems for verification. Therefore, they can achieve "zero-trust" mutual trust and login verification, which improves the security of the overall network while facilitating service providers to authenticate users and obtain user information.

[0003] Distributed digital identity includes, for example, a distributed identity identifier (DID) and a DID document. The DID document can be stored in a blockchain. The DID document includes, for example, the DID, the DID's public key, and the storage address of the verifiable credential (VC). Users hold the private key of the DID, thereby gaining access to the DID and the resources associated with it. Summary of the Invention

[0004] The purpose of this invention is to provide an account key setting method to improve the security of account key management.

[0005] This specification provides a method for setting an account key, executed by a user device, wherein the user device includes a Trusted Execution Environment (TEE), the method comprising:

[0006] The system retrieves the user's account from the identity system and provides the account to the TEE. The identity system stores the user's identity information, and the account corresponds to the identity information.

[0007] The TEE generates a first public key and a first private key corresponding to the account, stores the first private key, and provides the first public key to the outside of the TEE;

[0008] The information of the first public key is sent to the identity system so that the identity system can store the account and the information of the first public key in association in the storage system.

[0009] In one implementation, the account includes a distributed digital identity (DID), and the storage system includes a blockchain system.

[0010] In one implementation, sending the information of the first public key to the identity system includes: sending the information of the first public key and the device information of the user device to the identity system, so that the identity system can store the association between the information of the user device and the first public key.

[0011] In one implementation, obtaining the user's account from the identity system includes:

[0012] Send an account retrieval request to the identity system;

[0013] In response to the identity verification request from the identity system, the user is instructed to perform real-name authentication and obtain real-name authentication information;

[0014] The identity system sends the real-name authentication information to the identity verification server so that the identity verification server can perform real-name authentication on the user.

[0015] If the real-name authentication is successful, the account corresponding to the user is received from the identity system.

[0016] In one implementation, the user equipment stores a device certificate pre-received from a certification authority (CA), the TEE stores a device private key, and the device certificate includes a device public key corresponding to the device private key and a signature of the device public key by the CA. Sending the information of the first public key to the identity system includes sending a first message to the identity system, the first message including the first public key.

[0017] The method further includes:

[0018] The TEE uses the device private key to sign the first message, generates a first signature, and provides the first signature to the outside of the TEE;

[0019] The device certificate and the first signature are sent to the identity system.

[0020] In one implementation, the TEE stores a first symmetric key pre-obtained from the CA, and sending the information of the first public key to the identity system includes:

[0021] The TEE encrypts the first message based on the first symmetric key to obtain a first ciphertext message, and provides the first ciphertext message and the key identifier of the first symmetric key to the outside of the TEE for transmission to the DIS.

[0022] In one implementation, the TEE encrypts the first message based on the first symmetric key, including:

[0023] The TEE generates a second symmetric key, uses the second symmetric key to encrypt the first message to obtain the first ciphertext message, and uses the first symmetric key to encrypt the second symmetric key to obtain the ciphertext key.

[0024] Providing the key identifier of the first ciphertext message and the first symmetric key to the outside of the TEE includes: providing the key identifier of the first ciphertext message, the ciphertext key, and the first symmetric key to the outside of the TEE.

[0025] In one embodiment, the method further includes:

[0026] Receive a second message from the identity system, the second message being used to indicate that the identity system has received the first message and to provide the second message to the TEE;

[0027] The TEE sets the account status to active based on the second message, generates a third message, and the third message is used to indicate that the DID has been activated. The third message is provided to the outside of the TEE.

[0028] The third message is sent to the identity system to trigger the identity system to store the information of the first public key in association with the account in the blockchain.

[0029] In one embodiment, the method further includes:

[0030] The generated transaction is sent to the TEE, and the sending account of the transaction is the DID;

[0031] The TEE uses the first private key to sign the transaction and provides the signature of the transaction to the outside of the TEE;

[0032] The transaction and its signature are sent to the blockchain.

[0033] A second aspect of this specification provides an account key setting system, including a first user device and an identity system, wherein the first user device includes a TEE (Technical Equipment Exchange).

[0034] The identity system is used to send the user's account to the first user device, and the identity system stores the account and the user's identity information in association.

[0035] The first user equipment is configured to: provide the account to the TEE; generate a first public key and a first private key corresponding to the account in the TEE, store the first private key, provide the first public key to the outside of the TEE; and send the information of the first public key to the identity system.

[0036] The identity system is also used to associate and store the information of the account and the first public key in a storage system.

[0037] In one implementation, the storage system includes a blockchain.

[0038] The identity system is also configured to receive a call to the first interface from the user's second user device; instruct the second user device to perform real-name authentication of the user; obtain the user's account if the real-name authentication is successful; and record information in the blockchain to indicate that the information of the first public key corresponding to the first user device is disabled.

[0039] In one implementation, the blockchain also stores information about a second public key of the account, which is generated by the identity system. The identity system also stores a second private key corresponding to the second public key.

[0040] Recording information in the blockchain to indicate that the information corresponding to the first public key of the first user device is disabled includes:

[0041] The identity system is used to generate transactions and sign the transactions, the sending account of the transaction is the account, and the transaction includes information indicating that the information of the first public key corresponding to the first user device is disabled, the signature is generated using the second private key; the transaction and its signature are sent to the blockchain to store the information indicating that the information of the first public key corresponding to the first user device is disabled in the blockchain.

[0042] In one implementation, the call to the first interface includes the identifier of the first user equipment, and the identity system is further configured to determine information about the first public key that will be disabled based on the identifier of the first user equipment.

[0043] A third aspect of this specification provides a user equipment including a Trusted Execution Environment (TEE), the user equipment comprising:

[0044] An acquisition unit is used to acquire an account corresponding to a user from an identity system and provide the account to the TEE. The identity system stores the user's identity information, and the account corresponds to the identity information.

[0045] A generation unit is configured to generate a first public key and a first private key corresponding to the account in the TEE, store the first private key, and provide the first public key to the outside of the TEE.

[0046] A sending unit is configured to send the information of the first public key to the identity system, so that the identity system can store the information of the account and the first public key in association in the storage system.

[0047] A fourth aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0048] A fifth aspect of this specification provides a user equipment including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method described in the first aspect.

[0049] In the solutions provided in the embodiments of this specification, key management is performed based on the TEE (Technical Equipment Environment) of the user equipment and the distributed digital identity system. The TEE generates a public-private key pair for the user account and stores the private key within the TEE, thereby ensuring the security of the private key and preventing third-party use or loss of the private key. Simultaneously, the DIS (Distributed Digital Identity System) ensures that when the user equipment uses the private key, it is the user themselves performing the operation, thus guaranteeing the security of the user account. Attached Figure Description

[0050] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1 This is a system architecture diagram of the embodiments in this specification;

[0052] Figure 2 This is a flowchart illustrating the method for initializing the TEE in the user equipment as described in the embodiments of this specification.

[0053] Figure 3 This is a flowchart illustrating the method for setting the private key of a user's DID within a TEE, as described in the embodiments of this specification.

[0054] Figure 4 This is a flowchart illustrating the method by which a user device obtains a user's DID from a DIS in an embodiment of this specification.

[0055] Figure 5 This is a flowchart illustrating the method by which a user device sends a transaction to the blockchain in the embodiments of this specification.

[0056] Figure 6 This is a flowchart illustrating the method for disabling the control public key in the embodiments of this specification;

[0057] Figure 7 This is an architecture diagram of a user equipment in one of the embodiments of this specification. Detailed Implementation

[0058] 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.

[0059] The accounts used in the embodiments of this specification can be, for example, blockchain accounts that have been verified with real names, or DIDs. A DID is a distributed digital identity ID conforming to W3C specifications; one DID uniquely corresponds to one entity, and an entity can have multiple DIDs. The aforementioned entity refers to the described information subject, including individuals, organizations, or any objective thing. The DID document corresponding to a DID can be stored in the blockchain. The DID document includes, for example, the DID, the DID's public key, and the storage address of the Verifiable Credential (VC). Users hold the private key of the DID, thereby gaining access to the DID and the resources associated with it through that private key.

[0060] A VC, short for "credential," is a digital credential conforming to W3C specifications. This specification provides a standard way to express various types of claims on the web in a cryptographically secure, privacy-respecting, and automatically verifiable manner. These claims refer to a statement or assertion about an objective entity. Specifically, a VC is a descriptive statement endorsing certain attributes issued by the issuer using their own DID to the recipient's DID, and is accompanied by a digital signature. A VC mainly consists of two parts: content and proof. The content includes the issuer's DID, the recipient's DID, and a description of the claim. The proof mainly includes the issuer's signature information and the public key information used for signing.

[0061] Verifiable Claims (VCs), as the application layer of a distributed digital identity system, provide a cryptographically secure, privacy-respecting, and machine-verifiable way to identify certain characteristics of individuals, organizations, or even items on the network. Physical world credentials such as electronic driver's licenses can be circulated and used on the network in the form of verifiable claims.

[0062] The account key setting scheme in the embodiments of this specification can be used in the field of blockchain technology. A blockchain typically includes multiple nodes that can establish P2P (Peer-to-Peer) connections, such as TCP connections, for transmitting data between nodes. These nodes can store the entire ledger, that is, the state of all blocks and all accounts. Each node in the blockchain can generate the same state in the blockchain by executing the same transaction, and each node in the blockchain can store the same state database.

[0063] In the blockchain field, a transaction refers to a unit of task executed and recorded within the blockchain. A transaction typically includes a From field, a To field, and a Data field. Specifically, in the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0064] Blockchain provides the functionality of smart contracts. A smart contract on the blockchain is a contract that can be triggered and executed through transactions within the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract on the blockchain involves initiating a transaction pointing to the smart contract's address, causing each node in the blockchain to run the smart contract code in a distributed manner.

[0065] In a contract deployment scenario, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to the blockchain. The transaction's `data` field includes the code of the contract to be created (such as bytecode or machine code), and the `to` field is empty to indicate that the transaction is used for contract deployment. After the nodes reach a consensus through the consensus mechanism, they determine the contract address "0x6f8ae93…". Each node adds a contract account corresponding to the smart contract's contract address to its state database, allocates state storage corresponding to that contract account, stores the contract code, and saves the hash value of the contract code in the contract's state storage, thus successfully creating the contract.

[0066] In a scenario where a contract is invoked, for example, Bob sends a transaction to the blockchain to invoke a smart contract. The "from" field of this transaction is the address of the account of the transaction initiator (i.e., Bob), the "to" field is "0x6f8ae93…" (as mentioned above), which is the address of the smart contract to be invoked, and the "data" field of the transaction includes the method and parameters for invoking the smart contract. After consensus is reached on this transaction in the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract separately, and updating the state database based on the execution of the contract.

[0067] In related technologies, users primarily manage their account private keys in two ways: by having them hosted on a centralized service or by managing them themselves. Hosting private keys on a centralized service carries the risk of third-party leakage and unauthorized use of the private key by the service, while managing private keys themselves carries the risk of loss.

[0068] In the embodiments described in this specification, key management is based on the user equipment's TEE and the Decentralized Digital Identity System (DIS). The TEE generates a public-private key pair for the user account and stores the private key within the TEE, thereby ensuring the security of the private key and preventing third-party use or loss of the private key. Simultaneously, the DIS ensures that when the user equipment uses the private key, it is the user themselves performing the operation, thus guaranteeing the security of the user account.

[0069] The DIS (Distributed Identity System) includes, for example, a master server, an identity information storage server, and a DIS storage server. The master server provides distributed identity services (hereinafter referred to as DIS service) based on blockchain. The identity information storage server stores the identity information of users corresponding to user IDs. The DIS storage server stores DID-related data, such as DIDs and DID public keys, and provides on-chain services. DIS service is an efficient, compliant, secure, and reliable digital identity management solution. The distributed and secure capabilities of blockchain technology facilitate collaborative work across institutions and organizations, enabling identity data to be shared and replicated across multiple nodes, resisting failures and tampering. The cryptographic methods of blockchain technology allow for effective user participation, establishing a link between user entities and digital identities, and protecting the reasonable use of personal information through user authorization, making data flow more trustworthy and compliant.

[0070] The following parties are included in DIS:

[0071] Holder: The owner and user of the DID identity. Users create and manage their own DIDs through a DID client proxy (such as a mini-program).

[0072] Issuer: Also known as the certificate issuer, this is the party involved in certifying data. This refers to the organization or individual that issues or issues a Certificate of Value (VC) to the user.

[0073] Verifier: Also known as the application party, this is a participant in using the data. This participant is a service provider that provides services to users using the DID, and is generally an organization or individual authorized by the user to verify the user's identity, the issuer's identity, and the content of verifiable claims.

[0074] Figure 1 This is a system architecture diagram of an embodiment in this specification. The system includes user equipment 100, user equipment 200, DIS 300, and blockchain 400. User equipment 100 includes a Trusted Execution Environment (TEE) TEE10, and user equipment 200 includes TEE20.

[0075] TEE (Trusted Execution Environment) is a secure extension of CPU hardware, completely isolated from the external environment. Currently, the industry is paying close attention to TEE solutions, with almost all mainstream chip and software alliances having their own TEE solutions. Examples include software-based TPM (Trusted Platform Module) and hardware-based SGX (Software Guard Extensions), ARM Trustzone, and AMD PSP (Platform Security Processor). TEE acts as a black box; the code and data executed within it cannot be viewed even at the operating system level. Operations can only be performed through predefined interfaces in the code. In terms of efficiency, due to the black-box nature of TEE, computations are performed on plaintext data, rather than the complex cryptographic operations of homomorphic encryption, resulting in almost no loss of efficiency. Therefore, adopting TEE technology can largely meet the trusted computing requirements of blockchain scenarios with relatively small performance losses.

[0076] In TEE technology, SGX (Software Guard Extension) technology will be used as an example for explanation. Blockchain nodes can create enclaves (enclaves or enclaves) based on SGX technology to serve as TEEs for executing blockchain transactions. Specifically, blockchain nodes utilize newly added processor instructions in the CPU to allocate a portion of memory as an EPC (Enclave Page Cache) to house the aforementioned enclaves. The memory area corresponding to the EPC is encrypted by the CPU's internal Memory Encryption Engine (MEE). The contents of this memory area (code and data within the enclave) can only be decrypted within the CPU core, and the encryption / decryption keys are only generated and stored in the CPU when the EPC starts. Therefore, the security boundary of the enclave only includes itself and the CPU. Neither privileged nor non-privileged software can access the enclave. Even operating system administrators and VMMs (Virtual Machine Monitors; or Hypervisors) cannot affect the code and data within the enclave, thus providing extremely high security. With the aforementioned security safeguards in place, the CPU can process data within the Enclave with extremely high computational efficiency, thus balancing data security and computational efficiency. Furthermore, data entering and leaving the TEE can be encrypted, thereby protecting data privacy.

[0077] Figure 1 User equipment 100 and user equipment 200 can be user equipment belonging to different users, or they can be two user equipment belonging to the same user. Each user equipment can have an application or app installed for business operations. This application may include a TEE (Transaction Execution Environment) interface, which the user equipment can call to initialize the TEE, install a Trusted Application (TA), and set device keys, session keys, etc. After TEE initialization, the user can generate a public-private key pair for their user DID through the TEE on their user equipment and store the private key in the TEE, thus ensuring the security of the private key. After generating the public-private key pair, the TEE provides the public key to DIS 300, enabling DIS 300 to store the user DID's public key in blockchain 400 after successful user authentication. This public-private key pair, referred to as the control private key and control public key, is used to process user transactions.

[0078] In cases where user equipment 100 and user equipment 200 belong to the same user, and in situations such as when user equipment 100 is lost, the user can request DIS 300 to disable the public key of the DID corresponding to user equipment 100 through user equipment 200, thereby ensuring the security of the user's DID.

[0079] The following will refer to Figures 2-6 This specification describes in detail the scheme for setting account keys in the embodiments.

[0080] Figure 2 This is a flowchart illustrating the method for initializing the TEE in a user equipment according to embodiments of this specification. The following description uses user equipment 100 as an example.

[0081] like Figure 2 As shown, in S201, the application in user equipment 100 sends a TEE status check request to TEE 10.

[0082] In S203, the TEE returns the status check results to the application.

[0083] Upon receiving a status check request, TEE10 can, for example, check whether a TA is installed on TEE10. If a TA is installed, it can obtain the TA version, determine whether the TA version is suitable for the user's device, and check whether the device key, session key, etc., are set in the TEE. After completing the above checks, TEE10 returns the check results to the application.

[0084] In S205, the application sends a TEE initialization request to the DIS.

[0085] If the inspection results indicate that the TA is not installed in the TEE or the TA version is not compatible with the user's equipment, the application sends a TEE initialization request to the DIS 300 to obtain the latest version of the TA.

[0086] In S207, DIS sends a TA download request to the TA management server.

[0087] The TA download request includes, for example, connection information such as the connection address and port number of user device 100.

[0088] In S209, the TA management server sends TAs to the application.

[0089] The TA management server can connect to user device 100 based on the aforementioned TA download request and send the latest version of the TA to the application. Specifically, the TA management server can push the TA download command to the application, and the TEE interaction interface in the application can download the latest version of the TA according to the download command.

[0090] In S211, the application provides the latest version of the TA to the TEE.

[0091] After downloading the latest version of the TA, the TEE interaction interface in the application provides the latest version of the TA to TEE10 based on the communication mechanism between the TEE and the external TEE in user equipment 100. This allows TEE10 to install the latest version of the TA. After the TA is installed in TEE10, a wallet containing the user's DID is generated. TEE10 can then perform a series of operations by running the TA, including storing the user's DID information and performing signing, encryption, and other operations.

[0092] In S213, the application requests the envelope key, device private key, and device certificate from the Certificate Authority (CA).

[0093] The envelope key is used for subsequent encryption of the channel with the DIS 300. This envelope key can be a symmetric key or an asymmetric key. This specification describes the example using a symmetric key. The device certificate includes the user equipment 100's public key and the CA's signature of the public key. The public key corresponds to the device private key.

[0094] In S215, the CA sends the envelope key, device private key, and device certificate to the application.

[0095] In response to an application's request, the CA can generate a device private key and a device public key for user equipment 100, and generate a device certificate based on the device public key. Simultaneously, it generates a symmetric key as the envelope key for user equipment 100. After generating the symmetric key, the CA assigns a unique identifier, keyID, to it and records the correspondence between keyID and the symmetric key locally.

[0096] The CA then sends the device private key, device certificate, envelope key, and its keyID to the application.

[0097] In S217, the interface used for initialization in the application provides the envelope key, device private key, and device certificate to the TEE.

[0098] Specifically, the interface used for initialization in the application can provide the envelope key and its keyID, device private key and device certificate to the TEE10.

[0099] In S219, the TEE provides the application with the TA version number and initialization success information.

[0100] After the TEE10 installs the TA as described above and obtains the device private key, device certificate, and envelope key, it can return an initialization success message to the application and return the version number of the TA it installed.

[0101] In S221, the application sends the TA version number and initialization success message received from the TEE to the DIS 300.

[0102] After receiving the TA version number and initialization success message, DIS 300 first checks if the TA version in TEE10 is the latest version. If it is not the latest version, it can trigger TEE10 to download the latest TA again. If the TA version number in TEE10 is the latest version, it can then configure the DID key with user equipment 100.

[0103] User equipment 100 is passing through Figure 2 After initializing TEE 10 using the method shown, it can be accessed via... Figure 3 The method shown sets the private key for the user's DID within TEE10.

[0104] like Figure 3 As shown, in S301, user equipment 100 receives user DID from DIS.

[0105] User U1, to which user equipment 100 belongs, may have already created a DID through his other user equipment. In this case, the correspondence between the user's identity information and the created DID is recorded in DIS 300. Therefore, user equipment 100 can receive user U1's DID from DIS 300.

[0106] Alternatively, if user U1 has not yet created a DID, in this case, user equipment 100 may request DIS to create a DID for user U1 and receive the DID from DIS.

[0107] Figure 4 This is a flowchart illustrating the method by which a user device obtains a user's DID from a DIS in an embodiment of this specification.

[0108] refer to Figure 4 In S401, the application in user equipment 100 sends a user DID retrieval request to DIS.

[0109] After user U1 starts using user equipment 100, it can perform an operation in the application to instruct user equipment 100 to activate the use of user DID, thereby user equipment 100 sending a user DID retrieval request to DIS according to the instruction.

[0110] The request may include, for example, a user identifier U1 registered in the DIS. The DIS records the correspondence between user identifier U1 and user identity information. For example, the DIS may include an identity information storage device for storing and managing the correspondence between user identifiers and user identity information. User identity information may include, for example, the user's two-factor information, namely, name and identification number.

[0111] In S403, DIS sends an identity verification request to the identity verification server.

[0112] In response to a user's DID retrieval request, the DIS300 can generate an identity verification request to be sent to the identity verification server. The DIS300 can obtain the identity information of the user corresponding to user identifier U1 based on user identifier U1, and include the user's identity information in the identity verification request for real-name authentication of user U1 using the user's identity information.

[0113] Identity verification servers, such as those of authoritative institutions, store the identity information and detailed characteristics of various entities, such as users' facial features and fingerprints. These characteristics can be used to verify the identity of entities, i.e., real-name authentication.

[0114] In S405, the identity verification server sends the identity verification ID to the DIS.

[0115] After receiving a verification request, the verification server generates a verification ID corresponding to the request and stores the verification request associated with that ID. It then sends the verification ID to DIS 300.

[0116] In S407, DIS sends the identity ID to the application in user equipment 100.

[0117] In S409, the application instructs the user to perform real-name authentication and obtains the user's real-name authentication data.

[0118] Applications can authenticate users' identities by calling the real-name authentication interface provided by the identity verification server. This real-name authentication may involve facial recognition, capturing the user's facial features, and obtaining real-name authentication data, such as video data including the user's facial features.

[0119] In S411, the application sends the real-name authentication data and identity verification ID to the identity verification server.

[0120] In S413, the identity verification server performs real-name authentication on users based on real-name authentication data and identity verification ID.

[0121] Specifically, the identity verification server obtains the corresponding identity verification request based on the identity verification ID, retrieves the user's identity information from the identity verification request, finds the user's detailed features (such as facial features) locally based on the user's identity information, compares the facial features in the real-name authentication data with the facial features read locally, if the comparison result is consistent, it can be determined that the user currently performing the operation is the user corresponding to the pre-recorded UID, and the real-name authentication is successful; otherwise, the real-name authentication fails.

[0122] S415, the identity verification server sends the identity verification result corresponding to the identity verification ID to the DIS.

[0123] For example, if the identity verification server determines that the user's real-name authentication has passed, it can send the identity verification ID along with the identity verification success information to the DIS. In one implementation, after the user equipment 100 successfully completes real-name authentication, it sends the authentication success information to the DIS. In response to this information, the DIS requests the identity verification server to obtain the identity verification result corresponding to the identity verification ID. In response to the request from the DIS, the identity verification server sends the identity verification result corresponding to the identity verification ID to the DIS.

[0124] In S417, DIS obtains the user's DID.

[0125] After confirming the user's real-name authentication, DIS verifies that the DID retrieval request was initiated by the user, thus ensuring the security of DID-related operations. Next, DIS can first check if the user ID corresponding to user identifier U1 is recorded in DIS. For example, DIS can store the mapping between user identifiers and user DIDs in the storage server through DIS cloud services. If the storage server records user identifier U1 corresponding to, for example, DID1, it means that user U1 has previously registered a DID through another user device. DIS can then obtain DID1 to return to user device 100.

[0126] If the DIS does not record the user DID corresponding to user identifier U1, the DIS can generate a unique DID (e.g., DID1) for each user. Specifically, the DIS can obtain the user's two-factor information corresponding to user identifier U1, hash the user's two-factor information, and use the resulting hash value as the user's DID1. After generating DID1, the DIS can store the correspondence between user identifier U1 and DID1 in the storage server.

[0127] In S419, DIS sends the user's DID to the application in the user's device.

[0128] Return to Figure 3 In S303, the application provides the user's DID to the TEE.

[0129] Specifically, the application can send the DID to the aforementioned TEE interaction interface, through which the DID is provided to the TEE. Additionally, the application can also provide the user's user identifier U1 in the DIS, along with the aforementioned authentication ID, to the TEE together with the DID.

[0130] In S305, the TEE generates a public-private key pair (public key pk1 and private key sk1) corresponding to the DID and stores the private key sk1.

[0131] The trusted program TA in the TEE may include a key generator that generates a public-private key pair as the public-private key pair for DID1. After generating the new public-private key pair, the TEE may store the private key sk1 associated with DID1. In another implementation, the TEE may store the private key sk1, the public key pk1, and DID1 in association.

[0132] In S307, the TEE provides the public key pk1 to the application.

[0133] Specifically, the TEE can generate a service message for activating the public key pk1, which may include the public key pk1. Additionally, the service message may also include other information such as the user identifier U1 and DID1.

[0134] After generating the service message, the TEE can sign the service message using its private key to obtain a message signature, which is used to ensure that the service message cannot be tampered with. Furthermore, the TEE can encrypt the service message based on an envelope key to obtain a ciphertext message. Specifically, the TEE can generate a symmetric key, use the symmetric key to encrypt the service message to obtain a ciphertext message, and then use the envelope key to encrypt the symmetric key to obtain a ciphertext key. Afterwards, the TEE can provide the ciphertext message, ciphertext key, keyID of the envelope key, and message signature to an external entity for use by the application. For example, the TEE can provide this data to the application by calling the aforementioned TEE interaction interface. It is understood that the above-mentioned signing and encryption of the service message can further enhance the security of information sent by the TEE. Other methods to increase security can also be used in the embodiments of this specification to improve the security of information sent by the TEE, and are not limited thereto.

[0135] In S309, the application sends the public key pk1 to the DIS.

[0136] Specifically, the application can send the encrypted message, encrypted key, envelope key keyID, message signature, the aforementioned identity verification ID, and device certificate to DIS.

[0137] In S311, DIS sends the verification result information of the encrypted message to the application in the user equipment 100.

[0138] After receiving the encrypted message, encrypted key, envelope key keyID, identity verification ID, and device certificate, DIS verifies the encrypted message to determine whether to allow the user device to activate the use of DID.

[0139] Specifically, the DIS first sends the ciphertext key and the envelope key keyID to the CA. The CA can then obtain the envelope key corresponding to the keyID, use the envelope key to decrypt the ciphertext key, obtain the symmetric key used as the session key, and send the session key to the DIS.

[0140] After receiving the session key from the CA, the DIS uses the session key to decrypt the ciphertext message to obtain the plaintext service message. Then, the DIS can obtain the CA's public key and use it to verify the CA's signature of the device's public key in the device certificate. If the signature verification is successful, the DIS can use the device's public key to verify the message signature.

[0141] After the message signature verification is successful, DIS can send the identity verification ID to the identity verification server to determine whether the real-name authentication corresponding to the identity verification ID has been successfully verified.

[0142] DIS can also verify whether the current activation meets the preset activation rules, such as whether DID1 has been authorized to activate other devices.

[0143] If all the above verifications pass, DIS retrieves the public key pk1 from the business message, associates and stores the public key pk1 with DID1, and generates a verification result message. This verification result message may include information indicating that the verification of the public key pk1 has passed and that DID1 is activated. The verification result message may also include information such as DID1 and the public key pk1. Simultaneously, DIS can generate a symmetric key as the current session key, and use the session key to encrypt the verification result message, obtaining a ciphertext verification result message. DIS can also use its own private key to generate a signature for the verification result message.

[0144] Afterwards, DIS can send the keyID of the session key and envelope key to CA. CA obtains the envelope key based on the keyID, uses the envelope key to encrypt the session key to obtain the ciphertext key, and returns the ciphertext key to DIS.

[0145] Then, the DIS can send the encrypted verification result message, message signature, and encrypted key to the application in the user equipment 100.

[0146] In S313, after receiving the above data, the application provides the data to the TEE to provide the verification result information to the TEE.

[0147] In S315, TEE activates DID.

[0148] After receiving the encrypted verification result message, signature, and encrypted key, the TEE verifies the signature using the pre-obtained public key of the DIS. If the verification passes, it decrypts the encrypted key using the envelope key to obtain the session key. The session key is then used to decrypt the encrypted verification result message to obtain the verification result message. If the verification result message indicates that activation is allowed (DID1), the TEE sets the state of DID1 to active. With DID1 active, the TEE can perform operations such as sending transactions using DID1 and the private key sk1.

[0149] In S317, the TEE returns activation confirmation information to the application.

[0150] Specifically, after setting DID1 to an active state, the TEE generates an activation confirmation message to confirm the activation of DID1. This activation confirmation message includes, for example, DID1 and the public key pk1. Similarly, the TEE can generate a new symmetric key as the current session key, use this session key to encrypt the activation confirmation message to obtain a ciphertext message, and then use the envelope key to encrypt the session key to obtain a ciphertext key. The TEE can then return the ciphertext message, the ciphertext key, and the keyID of the envelope key to the application, which can then be used to return activation confirmation information to the application. Additionally, the TEE can also use the device's private key to generate a signature for the activation confirmation message.

[0151] In S319, the application sends activation confirmation information to DIS.

[0152] Specifically, the application sends the encrypted message, encrypted key, envelope key keyID, signature, and device certificate to DIS.

[0153] In S321, DIS determines the public key pk2 for DID recovery and generates DID DOC, which includes information about public key pk1 and public key pk2.

[0154] After receiving the aforementioned data, DIS performs signature verification and decryption in a similar manner to the above, and then obtains an activation confirmation message. After confirming that DID1 and public key pk1 have been activated based on the activation confirmation message, DIS determines the recovery public key pk2 for DID1. This recovery public key pk2 can be used to deactivate public key pk1 when it needs to be deactivated.

[0155] Specifically, when DID1 is a newly created DID, DIS can generate a public-private key pair (sk2 and pk2), store the private key sk2 as the recovery private key, and use pk2 as the recovery public key pk2. The recovery private key can only be used to send transactions to the blockchain to discard the control public key (e.g., public key pk1) of the DID, and cannot be used to send other types of transactions.

[0156] If DID1 is an already created DID, DIS can retrieve the current DID DOC from the blockchain and determine if a recovery public key is set in the DID DOC. If a recovery public key is set, it means that DIS has already stored the corresponding recovery private key, and DIS can continue to use the recovery public key and recovery private key. If no recovery public key is set in the DID DOC, but DIS stores the corresponding escrow private key and escrow public key for the DID, DIS can use the escrow private key to perform operations on DID1. DIS can then use the escrow private key and escrow public key as the recovery private key and recovery public key.

[0157] After determining the recovery public key pk2 and recovery private key sk2, DIS can generate a DID DOC, which includes DID1, control public key pk1, and recovery public key pk2.

[0158] When a user generates multiple control public keys for DID1 through multiple user devices, DIS can distinguish these multiple control public keys by the identifier of the user device. Specifically, DIS can record the correspondence between the user device identifier and the keyID of each control public key, and record the keyID of each control public key pk1 in the DID DOC.

[0159] In S323, DIS sends a transaction to the blockchain for storing the DID DOC in the blockchain.

[0160] DIS can generate transactions that include the DID DOC in their data fields for storing the DID DOC in the blockchain. Specifically, for example, a contract C1 for managing DIDs is deployed in the blockchain. This transaction can call contract C1, passing the DID DOC as an input parameter. When each node in the blockchain executes this transaction, it stores the DID DOC in association with DID1 in the contract state of contract C1. If a DID document is already stored in the contract state, the DID DOC replaces the existing document.

[0161] After the above settings are made, user device 100 can sign the transaction using the private key sk1 in the TEE and send the transaction to the blockchain. Figure 5This is a flowchart illustrating the method by which a user device sends a transaction to the blockchain in an embodiment of this specification.

[0162] like Figure 5 As shown, in S501, the application sends a transaction to the TEE, and the sending account of the transaction is DID.

[0163] When a user needs to send a transaction to the blockchain, they can instruct user device 100 to generate a transaction, the account of which is, for example, a DID.

[0164] In S503, the TEE uses the private key sk1 to sign the transaction and obtain the transaction signature.

[0165] In S505, the TEE returns the transaction signature to the application.

[0166] In S507, the application sends the transaction and its signature to the blockchain.

[0167] In S509, the public key pk1 of the DID is obtained in the blockchain, and the public key pk1 is used to verify the transaction signature.

[0168] After receiving the transaction and its signature, any node in the blockchain can read DID1's control public key pk1 in the blockchain and use the public key pk1 to verify the transaction signature if it is determined that the sending account of the transaction is DID1.

[0169] In the case where DID1 includes multiple control public keys corresponding to multiple user devices, and DID DOC includes each control public key and its corresponding keyID, the application of user device 100 can send the transaction, signature, and device identifier of user device 100 to DIS. As mentioned above, DIS records the correspondence between user device identifiers and keyIDs of each control public key. DIS determines the keyID corresponding to user device 100 based on this correspondence and sends the transaction, signature, and keyID to the blockchain. Thus, the blockchain node can obtain the control public key pk1 corresponding to user device 100 in DID DOC based on the keyID, and use the control public key pk1 to verify the signature of the transaction.

[0170] In another implementation, each control public key and the corresponding user device identifier can be recorded in the DID DOC, so that the application of user device 100 can directly send transactions, signatures and the device identifier of user device 100 to the blockchain. The blockchain node can obtain the control public key corresponding to user device 100 from the DID DOC based on the device identifier.

[0171] During the transaction sending process described above, users do not need to keep their account private keys themselves or entrust them to a third party. They only need to send the transaction to the TEE to obtain the transaction signature, which ensures the security of the private key.

[0172] In this scheme, if a user's device is lost, or if the user is about to transfer the device to someone else, the user needs to disable the control public key corresponding to the user device in the DID DOC to prevent others from using the device to perform DID operations on the user. The following describes the public key disabling method in this embodiment using the example of a user losing user device 100.

[0173] Figure 6 This is a flowchart illustrating the method for disabling the control public key in the embodiments of this specification.

[0174] like Figure 6 As shown, in S601, user equipment 200 sends a public key disable request to DIS.

[0175] Assuming that user equipment 100 and user equipment 200 are both user equipment of user U1, after user U1 loses user equipment 100, user U1 can disable the public key pk1 (i.e., control public key pk1) corresponding to user equipment 100 through user equipment 200. Specifically, user equipment 200 can send a public key disabling request to DIS by calling the public key disabling interface through the application. The device identifier of user equipment 100 can be passed to this interface to disable the control public key corresponding to user equipment 100.

[0176] It is understood that although the description uses user equipment 200 as an example, in the embodiments of this specification, the user is not limited to executing the method process through a device including TEE. For example, the user may also execute the method through a device that does not include TEE and has not activated the user DID.

[0177] In S603, DIS sends an identity verification request to the identity verification server.

[0178] After receiving a user's public key disabling request, and determining that the user equipment 200's login DIS UID is U1, the DIS needs to verify whether the requesting user is indeed user U1. Therefore, it sends an identity verification request for user U1 to the identity verification server. This verification request includes user U1's identity information, such as the user's two-factor authentication information. The DIS can obtain the identity information corresponding to user U1's UID from the identity data server.

[0179] In S605, the identity verification server generates an identity verification ID in response to the identity verification request and sends the identity verification ID to the DIS.

[0180] In S607, DIS sends the identity verification ID to user equipment 200.

[0181] In S609, user equipment 200 performs real-name authentication on users and obtains the users' real-name authentication data.

[0182] This step can be referred to the above. Figure 4 The description of step S409 in the previous section will not be repeated here.

[0183] In S611, user equipment 200 sends real-name authentication data and identity verification ID to the identity verification server.

[0184] In S613, the identity verification server performs real-name authentication on users based on real-name authentication data and identity verification ID.

[0185] This step can be referred to in the description of S413 above, and will not be repeated here.

[0186] In S615, the identity verification server sends the identity verification result corresponding to the identity verification ID to the DIS.

[0187] This step can be referred to the above. Figure 4 The description of step S415 in the previous section will not be repeated here.

[0188] In S617, DIS obtains the user's DID based on the user's identity information.

[0189] It is understood that in the embodiments of this specification, the DIS can obtain the user's DID based on the user's identity information. For example, as described above, the DID is calculated based on the hash value of the user's identity information. Therefore, the DIS can perform hash calculation based on the identity information of user U1 to obtain the DID corresponding to user U1. It is understood that the embodiments of this specification are not limited to obtaining the DID based on the user's identity information as described above. For example, the DIS can record the correspondence between user identity information and DID, so that the DID of user U1 can be obtained based on the correspondence.

[0190] In one implementation, the DIS can store the correspondence between user identity information and DID in the storage server. The DIS can send an instruction to disable the public key to the storage server, so that the storage server executes S617-S623, wherein the instruction includes the identity information of user U1 and the device information of user equipment 100.

[0191] In S619, DIS obtains the DID DOC of user U1's DID from the blockchain.

[0192] DIS can query the DID DOC of user U1's DID by sending a transaction to the blockchain. This transaction can, for example, invoke the aforementioned contract C1.

[0193] In S621, DIS updates the DID DOC to include public key disabled information in the DID DOC.

[0194] In one implementation, if the DID DOC only records the public key information corresponding to the user equipment 100, then the DIS can directly record the disabling information for that public key in the DID DOC.

[0195] In another implementation, the DID DOC records the public key information of multiple user devices of user U1, where each public key includes a public key and its corresponding keyID. The DIS records the correspondence between each user device and its public key keyID. Therefore, the DIS can read the keyID corresponding to user device 100 from the correspondence between user device and public key keyID based on the device information of user device 100, find the public key information of user device 100 in the DID DOC based on the keyID of user device 100, and record public key disabling information. This public key disabling information is used to indicate that the public key information of user device 100 is disabled. After recording this public key disabling information, if user device 100 sends a transaction to the blockchain (the transaction signature of which is generated based on the private key in TEE10 of user device 100), the blockchain nodes, based on the public key disabling information in the DID DOC, will not be able to verify the transaction successfully, and therefore the transaction cannot be executed successfully. Transactions sent by user equipment 100 before its public key was disabled remain valid and can still be verified using the public key of the disabled user equipment 100 in the DID DOC.

[0196] In S623, DIS sends transactions to the blockchain for storing updated DID DOCs.

[0197] DIS can generate a transaction whose sending account is DID. This transaction calls the function in contract C1 used to update the DID DOC. The input parameters to contract C1 include the updated DID DOC. Simultaneously, the transaction is signed using the aforementioned private key sk2 (refer to the above). Figure 3 The transaction is generated by signing the transaction as described in S321. The DIS sends the transaction to the blockchain. After receiving the transaction, the blockchain node obtains the public key pk2 from the DID DOC based on the function call to contract C1 in the transaction, verifies the transaction signature using the public key pk2, and executes the transaction if the verification is successful, storing the updated DIDDOC in the blockchain instead of the original DID DOC.

[0198] pass Figure 6The method shown allows users to easily disable the key of the user DID corresponding to user device 100 through another user device when they lose their user device 100 or decide that they no longer need to use their user device 100, thereby further ensuring the security of the user DID.

[0199] Figure 7 This is an architecture diagram of a user equipment according to an embodiment of this specification. The user equipment includes a Trusted Execution Environment (TEE). The user equipment includes:

[0200] The acquisition unit 71 is used to acquire an account corresponding to the user from the identity system and provide the account to the TEE. The identity system stores the user's identity information, and the account corresponds to the identity information.

[0201] Generation unit 72 is used to generate a first public key and a first private key corresponding to the account in the TEE, store the first private key, and provide the first public key to the outside of the TEE;

[0202] The sending unit 73 is used to send the information of the first public key to the identity system so that the identity system can store the information of the account and the first public key in association in the storage system.

[0203] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform actions such as... Figures 2-5 The method shown.

[0204] This specification also provides a user equipment, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements, as described above. Figures 2-5 The method shown.

[0205] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0206] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0207] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0208] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, 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, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0209] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0210] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, 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 apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0211] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device 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, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0212] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0213] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0214] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0215] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0216] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented 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.

[0217] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0218] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0219] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. An account key setting system, comprising a first user equipment and an identity system, wherein the first user equipment includes a TEE. The identity system is used to send the user's account to the first user device. The identity system stores the account and the user's identity information in association. The user has passed real-name authentication performed based on the identity information. The first user equipment is configured to: provide the account to the TEE; generate a first public key and a first private key corresponding to the account in the TEE, store the first private key, provide the first public key to the outside of the TEE; and send the information of the first public key to the identity system. The identity system is also used to, after the user's real-name authentication is passed, store the information of the account and the first public key in association in the blockchain; The identity system is also used to receive calls to the first interface from the user's second user device; Instruct the second user equipment to perform real-name authentication of the user; If the real-name authentication is successful, obtain the user's account; Information is recorded in the blockchain to indicate that the information for the first public key corresponding to the first user equipment is disabled.

2. The system according to claim 1, wherein the blockchain further stores information of a second public key of the account, the second public key being generated by the identity system, and the identity system further stores a second private key corresponding to the second public key. Recording information in the blockchain to indicate that the information corresponding to the first public key of the first user device is disabled includes: The identity system is used to generate transactions and sign the transactions, the sending account of the transaction is the account, and the transaction includes information indicating that the information of the first public key corresponding to the first user device is disabled, the signature is generated using the second private key; the transaction and its signature are sent to the blockchain to store the information indicating that the information of the first public key corresponding to the first user device is disabled in the blockchain.

3. The system according to claim 2, wherein, The call to the first interface includes the identifier of the first user device, and the identity system is further used to determine the information of the first public key that will be disabled based on the identifier of the first user device.

4. An account key setting method, executed by a user equipment, wherein the user equipment includes a Trusted Execution Environment (TEE), the method comprising: The system obtains the account corresponding to the user from the identity system and provides the account to the TEE. The identity system stores the user's identity information, the account corresponds to the identity information, and the user has passed real-name authentication based on the identity information. The TEE generates a first public key and a first private key corresponding to the account, stores the first private key, and provides the first public key to the outside of the TEE; The information of the first public key is sent to the identity system so that the identity system can store the account and the information of the first public key in association in the storage system after the user's real-name authentication is successful.

5. The method according to claim 4, wherein the account includes a distributed digital identity (DID), and the storage system includes a blockchain system.

6. The method according to claim 4 or 5, wherein sending the information of the first public key to the identity system comprises: The information of the first public key and the device information of the user device are sent to the identity system so that the identity system can store the association between the user device and the information of the first public key in the storage system.

7. The method according to claim 4 or 5, wherein obtaining the account corresponding to the user from the identity system includes: Send an account retrieval request to the identity system; In response to the identity verification request from the identity system, the user is instructed to perform real-name authentication and obtain real-name authentication information; The real-name authentication information is sent to the identity verification server so that the identity verification server can perform real-name authentication on the user. If the real-name authentication is successful, the account corresponding to the user is received from the identity system.

8. The method according to claim 5, wherein the user equipment stores a device certificate pre-received from a certification authority (CA), the TEE stores a device private key, the device certificate includes a device public key corresponding to the device private key, and the CA's signature of the device public key, and the step of sending the information of the first public key to the identity system includes sending a first message to the identity system, the first message including the first public key. The method further includes: The TEE uses the device private key to sign the first message, generates a first signature, and provides the first signature to the outside of the TEE; The device certificate and the first signature are sent to the identity system.

9. The method according to claim 8, wherein the TEE stores a first symmetric key pre-obtained from the CA, and the step of sending the information of the first public key to the identity system comprises: The TEE encrypts the first message based on the first symmetric key to obtain a first ciphertext message, and provides the first ciphertext message and the key identifier of the first symmetric key to the outside of the TEE for transmission to the DIS.

10. The method according to claim 9, wherein the TEE encrypts the first message based on the first symmetric key, comprising: The TEE generates a second symmetric key, uses the second symmetric key to encrypt the first message to obtain the first ciphertext message, and uses the first symmetric key to encrypt the second symmetric key to obtain the ciphertext key. Providing the key identifier of the first ciphertext message and the first symmetric key to the outside of the TEE includes: providing the key identifier of the first ciphertext message, the ciphertext key, and the first symmetric key to the outside of the TEE.

11. The method of claim 9, further comprising: Receive a second message from the identity system, the second message being used to indicate that the identity system has received the first message and to provide the second message to the TEE; The TEE sets the account status to active based on the second message, generates a third message, and the third message is used to indicate that the DID has been activated. The third message is provided to the outside of the TEE. The third message is sent to the identity system to trigger the identity system to store the information of the first public key in association with the account in the blockchain.

12. The method of claim 11, further comprising: The generated transaction is sent to the TEE, and the sending account of the transaction is the DID; The TEE uses the first private key to sign the transaction and provides the signature of the transaction to the outside of the TEE; The transaction and its signature are sent to the blockchain.

13. A user equipment, the user equipment including a Trusted Execution Environment (TEE), the user equipment comprising: The acquisition unit is used to acquire an account corresponding to a user from the identity system and provide the account to the TEE. The identity system stores the user's identity information, the account corresponds to the identity information, and the user has passed real-name authentication based on the identity information. A generation unit is configured to generate a first public key and a first private key corresponding to the account in the TEE, store the first private key, and provide the first public key to the outside of the TEE. The sending unit is configured to send the information of the first public key to the identity system, so that the identity system can store the account and the information of the first public key in association in the storage system after the user's real-name authentication is successful.

14. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 4-12.

15. A user equipment comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 4-12.

Images