Method and user device for issuing verifiable claims

Abstract

A method and a user equipment for issuing a verifiable claim, the method comprising: a first user equipment sending a VC issuance request to an identity system, the first user equipment comprising a TEE, the TEE storing a first account and a first private key thereof; the identity system sending a verification request to the first user equipment; the first user equipment performing real-name authentication on a first user, and sending VC issuance information to the identity system after the real-name authentication is passed; the identity system obtaining a result of the real-name authentication in response to the VC issuance information, and generating a VC content in a case where the authentication is passed, and sending the VC content to the first user equipment; the first user equipment providing the VC content to the TEE, the TEE signing the VC content using the first private key to obtain a first signature, and providing the first signature outside the TEE; sending the first signature to the identity system; and the identity system storing the VC in association with a second account.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of distributed digital identity technology, and in particular relate to a method and user equipment for issuing verifiable claims. 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 a distributed identity identifier (DID) and a DID document (DID DOC). 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 a method for issuing VCs to improve the security and reliability of issuing VCs to user equipment.

[0005] This specification provides a method for issuing a verifiable declaration, comprising: a first user equipment sending a verifiable declaration (VC) issuance request to an identity system; the first user equipment including a Trusted Execution Environment (TEE) storing a first user's first account and a first private key corresponding to the first account; the identity system responding to the VC issuance request sending an identity verification request to the first user equipment; the first user equipment responding to the identity verification request performing real-name authentication on the first user, and after successful real-name authentication sending VC issuance information to the identity system, the VC issuance information including a second user's second account to be issued a VC; the identity system responding to the VC issuance information obtaining the result of the real-name authentication, and if authentication is successful, generating VC content based on the VC issuance information and sending the VC content to the first user equipment; the first user equipment providing the VC content to the TEE, the TEE signing the VC content using the first private key to obtain a first signature, and providing the first signature outside the TEE; sending the first signature to the identity system; and the identity system combining the VC content and the first signature to obtain a VC, and storing the VC associated with the second account.

[0006] In one implementation, the first user equipment sending VC issuance information to the identity system includes:

[0007] The first user equipment provides the VC issuance information to the TEE, the TEE generates a first message including the VC issuance information, signs the first message using the first private key to obtain a second signature, and provides the second signature and the first message to the outside of the TEE;

[0008] The first user equipment sends the second signature and the first message to the identity system;

[0009] The identity system generates VC content based on the VC issuance information, including:

[0010] The identity system obtains the first public key of the first account, uses the first public key to verify the second signature, and generates VC content based on the VC issuance information if the verification is successful.

[0011] In one implementation, the TEE stores a first symmetric key pre-obtained from a Certificate Authority (CA), and providing the first message to the outside of the TEE includes:

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

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

[0014] 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 first ciphertext key;

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

[0016] In one implementation, the first user equipment sending VC issuance information to the identity system further includes:

[0017] The first user equipment sends the first ciphertext message, the first ciphertext key, and the key identifier of the first symmetric key to the identity system;

[0018] The method further includes:

[0019] The identity system sends the key identifiers of the first ciphertext key and the first symmetric key to the CA; receives the second symmetric key from the CA, and uses the second symmetric key to decrypt the first ciphertext message to obtain the first message.

[0020] In one implementation, the identity system sending the VC content to the first user equipment further includes:

[0021] The identity system generates a second message including the VC content, signs the second message to obtain a third signature, and sends the VC content and the third signature to the first user equipment.

[0022] In one implementation, the identity system sends the VC content to the first user equipment, including:

[0023] The identity system generates a third symmetric key, uses the third symmetric key to encrypt the second message to obtain a second ciphertext message, sends the key identifier of the first symmetric key and the third symmetric key to the CA, receives a second ciphertext key from the CA, the second ciphertext key is generated by encrypting with the first symmetric key, and sends the second ciphertext message and the second ciphertext key to the first user equipment.

[0024] In one implementation, the identity system generating VC content based on the VC issuance information further includes:

[0025] The identity system verifies whether the VC issuance information is compliant, and if compliant, generates VC content based on the VC issuance information.

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

[0027] The first user equipment receives VC issuance information input by the first user; and sends a random string to the second user's second user equipment;

[0028] The second user equipment uses the second private key of the second account to sign the random string to obtain a fourth signature, and then sends the fourth signature to the first user equipment;

[0029] The first user equipment sends the second account, the random string, and the fourth signature to the identity system;

[0030] The identity system obtains the second public key of the second account, uses the second public key of the second account to verify the fourth signature, and sends the verification result to the first user equipment.

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

[0032] The identity system uses the second public key to encrypt the VC to obtain the ciphertext VC; and sends the ciphertext VC to the second user equipment.

[0033] The second user equipment uses the second private key to decrypt the ciphertext VC to obtain the VC.

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

[0035] The first user equipment obtains a first account corresponding to the first user from the identity system and provides the first account to the TEE. The identity system stores the identity information of the first user, and the first account corresponds to the identity information. The TEE generates a first public key and a first private key corresponding to the first 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 information of the first account and the first public key in association in the storage system.

[0036] In one implementation, the VC issuance information further includes at least one of the following: the first account, the validity period of the VC, and the description information of the VC.

[0037] A second aspect of this specification provides a method for issuing a verifiable claim, executed by a first user equipment, the first user equipment including a Trusted Execution Environment (TEE), the TEE storing a first account of the first user and a first private key corresponding to the first account, the method comprising:

[0038] Send a Verifiable Claim (VC) Issuance Request to the Identity System;

[0039] Receive an identity verification request from the identity system;

[0040] In response to the identity verification request, the first user is authenticated with his or her real name, and after the real name authentication is successful, VC issuance information is sent to the identity system.

[0041] Receive VC content from the identity system, the VC content being generated based on the VC issuance information;

[0042] The VC content is provided to the TEE, and the TEE uses the first private key to sign the VC content to obtain a first signature, which is then provided to the outside of the TEE.

[0043] The first signature is sent to the identity system for issuing the VC, the VC including the VC content and the first signature.

[0044] In one implementation, the first account includes a distributed identity identifier, and the identity system includes a distributed identity system.

[0045] A third aspect of this specification provides a first user equipment, the first user equipment including a Trusted Execution Environment (TEE), the TEE storing a first account of the first user and a first private key corresponding to the first account, the first user equipment comprising:

[0046] The sending unit is used to send a Verifiable Claim (VC) issuance request to the identity system.

[0047] A receiving unit is configured to receive an identity verification request from the identity system;

[0048] The authentication unit is used to perform real-name authentication on the first user in response to the identity verification request, and send VC issuance information to the identity system after the real-name authentication is successful.

[0049] The receiving unit is further configured to receive VC content from the identity system, the VC content being generated based on the VC issuance information;

[0050] A providing unit is configured to provide the VC content to the TEE, wherein the TEE uses the first private key to sign the VC content to obtain a first signature, and provides the first signature to the outside of the TEE;

[0051] The sending unit is further configured to send the first signature to the identity system for issuing the VC, the VC including the VC content and the first signature.

[0052] 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 third aspect.

[0053] 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 third aspect.

[0054] In the scheme provided in the embodiments of this specification, key management is performed based on the TEE 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 in the TEE. After the DIS 300 ensures that the user's real-name authentication is successful, it generates VC content and sends it to the TEE. The TEE then generates a VC signature, which ensures the security and authority of the generated VC. Attached Figure Description

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

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

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

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

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

[0060] Figure 5 This is a flowchart of a method for a user equipment to verify the DID2 of a VC to be issued, as described in an embodiment of this specification.

[0061] Figure 6 This is a flowchart of the VC issuance method in the embodiments of this specification;

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

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

[0064] 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 the DID can be stored in the blockchain, and the DID can serve as an index or URI for addressing the DID DOC. The DID document includes, for example, the DID, the DID's public key, and the storage address of the Verifiable Credential (VC). The user holds the private key of the DID, thereby gaining access to the DID and the resources associated with it through that private key.

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

[0066] 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 circulate and be used on the network through verifiable claims. Currently, most verifiable claims are issued by B-end and G-end entities, who endorse a specific attribute of the recipient through their authority. These entities have the capability to manage their keys securely and autonomously. Conversely, C-end users also have a need to issue verifiable claims, such as authorizing recipients or endorsing recipients through their authority in a specific field. However, C-end users currently lack the ability to securely and autonomously manage their keys.

[0067] In related technologies, C-end users mainly manage their account private keys in two ways: by having them hosted on a centralized service or by managing them themselves. Hosting them on a centralized service carries the risk of third-party leakage and unauthorized use of the private key by the service, while managing the private key by the user 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 Identity System (DIS). The TEE generates a public-private key pair for the user account and stores the private key within the TEE to ensure its security. This allows the user equipment to issue VCs to other DIDs using the TEE. Simultaneously, the DIS ensures that when the user equipment uses the private key stored in the TEE, it is indeed the user performing the operation, thus guaranteeing the security of the user account.

[0069] The aforementioned DIS is used to provide distributed identity services (hereinafter referred to as DIS service) based on blockchain. 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 such as identifiers 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. Each user equipment may have an application or mini-program 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 in business operations.

[0078] The following will refer to Figures 2-6 The scheme for issuing VC in the embodiments of this specification is described in detail.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0109] 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 includes 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0124] After confirming the user's real-name authentication, DIS verifies that the DID retrieval request was initiated by user U1, thus ensuring the security of DID-related operations. Next, DIS can first check if it has recorded the user DID corresponding to user identifier U1. 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.

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

[0126] In S419, DIS sends the user's DID to the application in user equipment 100.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0146] In S315, TEE activates DID.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0160] After the above settings are made, the user equipment 100 can sign the declaration content using the private key sk1 in the TEE for issuing VC.

[0161] Figure 5 This is a flowchart illustrating the method by which a user equipment verifies the DID2 of a VC to be issued, as described in the embodiments of this specification.

[0162] like Figure 5 As shown, in S501, user equipment 100 sends a random string to user equipment 200.

[0163] After user U1 determines that the account to be awarded VC is DID2, user U1 needs to verify that DID2 is the account of the target user (e.g., user U2). To do this, user U1 can send a random string from its user device 100 to user U2's user device 200 to verify that user U2 owns DID2.

[0164] In S503, after receiving a random string, user equipment 200 uses the private key of DID2 to sign the random string to obtain a string signature.

[0165] Specifically, the user equipment 200 can provide the random string to the TEE 20, which stores the private key of DID2. The TEE 20 uses the private key to sign the random string, obtains the string signature, and provides the string signature to the outside of the TEE.

[0166] In S505, user equipment 200 returns the string signature to user equipment 100.

[0167] In S507, user equipment 100 sends DID2, a random string, and a string signature to DIS 300.

[0168] In S509, DIS 300 uses the public key of DID2 to verify the string signature.

[0169] The DIS 300 can locally store the public key information of each DID, allowing it to retrieve the public key of DID2. Alternatively, the DIS 300 can read the DID DOC of DID2 from the blockchain and then retrieve the public key of DID2 from that DID DOC. The DIS 300 can use the public key of DID2 to verify the signature of a string. If the verification is successful, it means that the signature was indeed generated by the private key of DID2, thus verifying that user U2 owns DID2; otherwise, it verifies that user U2 does not own DID2.

[0170] In S511, DIS 300 sends the signature verification result to user equipment 100.

[0171] If the above verification is successful, the user equipment 100 can determine that the user U2 owns DID2, and thus can proceed with the subsequent process of issuing VC to DID2.

[0172] It is understood that the embodiments in this specification are not limited to those described in the way shown in the example. Figure 5 The method shown verifies whether user U2 possesses DID2. For example, user device 100 can directly obtain the public key corresponding to DID2 from the blockchain and use this public key to verify string signatures, etc.

[0173] Figure 6 This is a flowchart of the VC issuance method in the embodiments of this specification.

[0174] like Figure 6 As shown, in S601, the application in user equipment 100 sends a VC grant request to DIS.

[0175] The VC issuance request may include the user identifier of user U1 (such as "U1") to request DIS to allow user U1 to issue VCs to other DIDs through user equipment 100.

[0176] In S603, DIS 300 sends an identity verification request to the application in user equipment 100.

[0177] Specifically, after receiving the VC issuance request, the DIS 300 obtains the identity information corresponding to user U1, generates verification information including this identity information, and sends this verification information to the verification server to request the verification server to verify whether the currently operating user is the user corresponding to the identity information. After receiving the verification information, the verification server generates a verification ID and returns the verification ID to the DIS 300. The DIS 300 generates a verification request and sends this verification request to the application to request the application to perform real-name authentication on the user. This verification request includes the aforementioned verification ID.

[0178] In S605, the application in user equipment 100 obtains the user's real-name authentication data.

[0179] Specifically, applications can call the interface provided by the identity verification server to perform real-name authentication on users. This real-name authentication, for example, involves capturing a video of the user's face as the user's real-name authentication data.

[0180] In S607, after obtaining the user's real-name authentication data, the application in user equipment 100 sends the user's real-name authentication data to the identity verification server.

[0181] Specifically, the application can send the real-name authentication data and the identity verification ID together to the identity verification server. Referring to the description of step S413 above, the identity verification server can verify whether the user currently operating is user U1 based on the real-name authentication data and the identity verification ID. After performing the real-name authentication, the identity verification server can store the real-name authentication result in association with the identity verification ID.

[0182] In S609, after the real-name authentication is successful, the application of user equipment 100 sends the VC issuance information to DIS 300.

[0183] The application can also send the real-name authentication information and VC issuance information to the DIS 300 together. The VC issuance information includes, for example, user U1's DID1, user U2's DID2 (to be issued a VC), VC description information, VC validity period, and verification ID. At least some of this information can be used to generate the VC content.

[0184] Specifically, the application can provide the VC issuance information to the TEE ( Figure 6 (Not shown in the image), the TEE can generate a message based on the VC issuance information, sign the message using the private key sk1 of DID1 to obtain the message signature, and provide the message signature and message to the application. Thus, the application can send the message and message signature together to DIS 300.

[0185] Furthermore, a symmetric key can be generated within the TEE10. This symmetric key is used to encrypt the aforementioned message to obtain the ciphertext message. Then, the envelope key is used to encrypt the symmetric key again to obtain the ciphertext key. Afterward, the TEE can provide the ciphertext message, ciphertext key, the keyID of the envelope key, and the message signature to an external source for use by the application. Thus, the application can send the ciphertext message, ciphertext key, keyID of the envelope key, and the message signature to the DIS 300.

[0186] In S611, DIS 300 obtains the identity verification result from the identity verification server.

[0187] The DIS 300 can send a result retrieval request to the identity verification server based on the VC issuance information or the real-name authentication pass information. This result retrieval request may include, for example, the aforementioned identity verification ID. After receiving the result retrieval request, the identity verification server finds the corresponding real-name authentication result (i.e., the identity verification result) based on the identity verification ID and sends the identity verification result to the DIS 300.

[0188] When the DIS 300 receives the ciphertext message, ciphertext key, envelope key's keyID, and message signature, the DIS 300 can send the ciphertext key and envelope key's keyID to the CA. The CA can find the envelope key based on the envelope key's keyID, use the envelope key to decrypt the ciphertext key, obtain the symmetric key, and return the symmetric key to the DIS 300. The DIS 300 can then use the symmetric key to decrypt the ciphertext message, obtain the plaintext message, read the authentication ID from the plaintext message, and retrieve the authentication result from the authentication server based on this authentication ID.

[0189] In S613, DIS 300 generates VC content based on VC issuance information.

[0190] When the DIS 300 determines that the user's real-name authentication has passed based on the identity verification result, the DIS 300 can generate VC content based on the VC issuance information.

[0191] Specifically, after confirming that the real-name authentication is successful, the DIS 300 can obtain the public key of DID1, use the public key of DID1 to verify the signature of the above message, and generate VC content based on the VC issuance information if the signature verification is successful.

[0192] Furthermore, after confirming that real-name authentication and signature verification have passed, DIS 300 also verifies the VC issuance information according to preset business logic, such as verifying whether the VC issuance information is compliant. If the VC issuance information is confirmed to be compliant, DIS 300 generates VC content based on the VC issuance information.

[0193] DIS 300 can assemble information such as DID1 of user U1, DID2 of user U2 to be issued VC, VC description information, and VC validity period in the VC issuance information according to a preset format, thereby generating VC content.

[0194] In S615, DIS 300 sends VC content to the application in user equipment 100.

[0195] Specifically, the DIS 300 can generate a message including VC content. Similar to S609, the message is signed using the DIS 300's private key to generate a message signature. The DIS 300 can also generate a symmetric key, use this symmetric key to encrypt the message, obtaining a ciphertext message. The key identifier of the aforementioned envelope key and the symmetric key are sent to the CA. The CA obtains the envelope key based on the key identifier, uses the envelope key to encrypt the symmetric key, obtaining a ciphertext key, and sends the ciphertext key to the DIS 300. Afterwards, the DIS 300 can send the ciphertext message, ciphertext key, and message signature together to the user equipment 100.

[0196] In S617, the application of user equipment 100 provides VC content to TEE10.

[0197] Specifically, the application can provide the encrypted message, message signature, and encrypted key to the TEE10.

[0198] In S619, TEE10 uses the DID1 private key to sign the VC content, thus obtaining the VC signature.

[0199] Specifically, when TEE10 receives the ciphertext message, message signature, and ciphertext key, referring to the description of S611 above, TEE10 can decrypt the ciphertext message based on the envelope key to obtain the plaintext message, extract the VC content from the message, and obtain the public key of DIS 300 to verify the message signature to confirm that the message has not been tampered with.

[0200] After the signature verification is successful, TEE 10 uses the private key of DID1 to sign the VC content, thus obtaining the VC signature.

[0201] By having DIS 300 generate VC content and send it to TEE after ensuring user real-name authentication, and then having TEE generate a VC signature, the security and authority of the generated VC are ensured. This solution also ensures the compliance of VCs when DIS 300 performs compliance checks on VC issuance information.

[0202] In S621, TEE10 provides VC signatures to applications.

[0203] In S623, the application in user equipment 100 sends the VC signature to DIS 300.

[0204] In S625, DIS 300 combines the VC content and VC signature to obtain the VC, and stores the VC associated with DID2.

[0205] After storing the VC associated with DID2, DIS 300 can send a transaction to the blockchain invoking contract C1 to update the DID DOC of DID2 stored in the blockchain, ensuring that the DID DOC includes the storage address of the VC. In this way, users (e.g., VC validators) can read the DID DOC from the blockchain, retrieve the storage address of the VC from the DID DOC, and thus obtain the VC. The validator can obtain the public key pk1 of DID1 from the blockchain and use pk1 to verify the VC signature in the VC. If the verification is successful, the authenticity and trustworthiness of the VC content in the VC can be confirmed.

[0206] In another implementation, after storing the VC associated with DID2, DIS 300 can send a VC issuance completion message to User Equipment 100. User Equipment 100 can then send this message to User Equipment 200. User Equipment 200 can then query DIS 300 for the VC corresponding to DID2 based on DID2. DIS 300 can read the VC stored associated with DID2, encrypt it using the public key of DID2 to obtain the ciphertext VC, and send the ciphertext VC to User Equipment 200. Upon receiving the ciphertext VC, User Equipment 200 can decrypt it using the private key of DID2 to obtain the VC. After obtaining the VC, User Equipment 200 can provide it to a verifier to prove that it possesses the attributes included in the VC content.

[0207] Figure 7 This is an architectural diagram of a first user equipment according to an embodiment of this specification. The first user equipment includes a Trusted Execution Environment (TEE), which stores a first account of the first user and a first private key corresponding to the first account. The first user equipment includes:

[0208] Sending unit 71 is used to send a Verifiable Declaration (VC) issuance request to the identity system;

[0209] Receiving unit 72 is used to receive an identity verification request from the identity system;

[0210] Authentication unit 73 is used to perform real-name authentication on the first user in response to the identity verification request, and send VC issuance information to the identity system after the real-name authentication is successful.

[0211] The receiving unit 72 is further configured to receive VC content from the identity system, the VC content being generated based on the VC issuance information;

[0212] The providing unit 74 is used to provide the VC content to the TEE, the TEE uses the first private key to sign the VC content to obtain a first signature, and provides the first signature to the outside of the TEE;

[0213] The sending unit 71 is further configured to send the first signature to the identity system for issuing the VC, the VC including the VC content and the first signature.

[0214] 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-6 The method shown.

[0215] 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-6 The method shown.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0230] 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. A method for issuing a verifiable claim, comprising: The first user equipment sends a Verifiable Claim (VC) Issuance Request to the Identity System. The first user equipment includes a Trusted Execution Environment (TEE). The TEE generates a first public key and a first private key corresponding to the first account, stores the first private key, and provides the first public key to the outside of the TEE. The TEE stores the first user's first account and the first private key corresponding to the first account; The first public key and the first private key are used to process the first user's business transactions; The identity system responds to the VC issuance request by sending an identity verification request to the first user equipment. The first user equipment responds to the identity verification request to perform real-name authentication on the first user, and after the real-name authentication is successful, sends VC issuance information to the identity system. The VC issuance information includes the second account of the second user to be issued a VC. The identity system responds to the VC issuance information to obtain the result of the real-name authentication. If the authentication is successful, it generates VC content based on the VC issuance information and sends the VC content to the first user device. The first user equipment provides VC content to the TEE, and the TEE uses the first private key to sign the VC content to obtain a first signature, and provides the first signature to the outside of the TEE; Send the first signature to the identity system; The identity system combines the VC content and the first signature to obtain the VC, and stores the VC in association with the second account.

2. The method according to claim 1, wherein the first user equipment sending VC issuance information to the identity system includes: The first user equipment provides the VC issuance information to the TEE, the TEE generates a first message including the VC issuance information, signs the first message using the first private key to obtain a second signature, and provides the second signature and the first message to the outside of the TEE; The first user equipment sends the second signature and the first message to the identity system; The identity system generates VC content based on the VC issuance information, including: The identity system obtains the first public key of the first account, uses the first public key to verify the second signature, and generates VC content based on the VC issuance information if the verification is successful.

3. The method according to claim 2, wherein the TEE stores a first symmetric key pre-obtained from a Certificate Authority (CA), and providing the first message to the outside of the TEE 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.

4. The method according to claim 3, 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 first ciphertext key; Providing the key identifiers of the first ciphertext message and the first symmetric key to the outside of the TEE includes: providing the key identifiers of the first ciphertext message, the first ciphertext key, and the first symmetric key to the outside of the TEE.

5. The method according to claim 4, wherein the first user equipment sending VC issuance information to the identity system further includes: The first user equipment sends the first ciphertext message, the first ciphertext key, and the key identifier of the first symmetric key to the identity system; The method further includes: The identity system sends the key identifiers of the first ciphertext key and the first symmetric key to the CA; The second symmetric key is received from the CA, and the second symmetric key is used to decrypt the first ciphertext message to obtain the first message.

6. The method according to claim 2, wherein the identity system sends the VC content to the first user equipment, further comprising: The identity system generates a second message including the VC content, signs the second message to obtain a third signature; The VC content and the third signature are sent to the first user device.

7. The method according to claim 6, wherein the identity system sends the VC content to the first user equipment, further comprising: The identity system generates a third symmetric key, uses the third symmetric key to encrypt the second message to obtain a second ciphertext message, sends the key identifier of the first symmetric key and the third symmetric key to the CA, receives a second ciphertext key from the CA, the second ciphertext key is generated by encrypting with the first symmetric key, and sends the second ciphertext message and the second ciphertext key to the first user equipment.

8. The method according to claim 1 or 2, wherein the identity system generates VC content based on the VC issuance information, further comprising: The identity system verifies whether the VC issuance information is compliant, and if compliant, generates VC content based on the VC issuance information.

9. The method according to claim 1 or 2, further comprising: The first user equipment receives VC issuance information input by the first user; Send a random string to the second user's second user device; The second user equipment uses the second private key of the second account to sign the random string to obtain a fourth signature, and then sends the fourth signature to the first user equipment; The first user equipment sends the second account, the random string, and the fourth signature to the identity system; The identity system obtains the second public key of the second account, uses the second public key of the second account to verify the fourth signature, and sends the verification result to the first user equipment.

10. The method of claim 9, further comprising: The identity system uses the second public key to encrypt the VC, obtaining ciphertext VC; The encrypted VC is sent to the second user equipment; The second user equipment uses the second private key to decrypt the ciphertext VC to obtain the VC.

11. The method according to claim 1 or 2, further comprising: The first user equipment obtains a first account corresponding to the first user from the identity system and provides the first account to the TEE. The identity system stores the identity information of the first user, and the first account corresponds to the identity information. The information of the first public key is sent to the identity system so that the identity system can store the information of the first account and the first public key in association in the storage system.

12. The method according to claim 1 or 2, wherein the VC issuance information further includes at least one of the following: the first account, the validity period of the VC, and the description information of the VC.

13. A method of issuing a verifiable claim, performed by a first user device, the first user device comprising a trusted execution environment (TEE) therein, the TEE generating a first public key and a first private key corresponding to the first account, storing the first private key, and providing the first public key outside the TEE. The TEE stores the first user's first account and a first private key corresponding to the first account. The first public key and the first private key are used to process the first user's business transactions. The method includes: Send a Verifiable Claim (VC) Issuance Request to the Identity System; Receive an identity verification request from the identity system; In response to the identity verification request, the first user is authenticated with his or her real name, and after the real name authentication is successful, VC issuance information is sent to the identity system. Receive VC content from the identity system, the VC content being generated based on the VC issuance information; The VC content is provided to the TEE, and the TEE uses the first private key to sign the VC content to obtain a first signature, which is then provided to the outside of the TEE. The first signature is sent to the identity system for issuing the VC, the VC including the VC content and the first signature.

14. The method of claim 13, wherein, The first account includes a distributed identity identifier, and the identity system includes a distributed identity system.

15. A first user device comprising a trusted execution environment (TEE) therein, the TEE generating a first public key and a first private key corresponding to the first account, storing the first private key, and providing the first public key outside the TEE. The TEE stores the first user's first account and the first private key corresponding to the first account. The first public key and the first private key are used to process the first user's business transactions. The first user equipment includes: The sending unit is used to send a Verifiable Claim (VC) issuance request to the identity system. A receiving unit is configured to receive an identity verification request from the identity system; The authentication unit is used to perform real-name authentication on the first user in response to the identity verification request, and send VC issuance information to the identity system after the real-name authentication is successful. The receiving unit is further configured to receive VC content from the identity system, the VC content being generated based on the VC issuance information; A providing unit is configured to provide the VC content to the TEE, wherein the TEE uses the first private key to sign the VC content to obtain a first signature, and provides the first signature to the outside of the TEE; The sending unit is further configured to send the first signature to the identity system for issuing the VC, the VC including the VC content and the first signature. 16.A user equipment comprising a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method in claim 13 or 14.

Images