DID generation method, device, readable storage medium and electronic device

Abstract

The present invention relates to a method, device, readable storage medium and electronic device for generating a DID. The method comprises: sending a request for creating a DID to a server, so that the server generates a DID identifier after receiving the request and sends the DID identifier to a user; receiving the DID identifier and generating a user public key and a user private key in a trusted execution environment; signing the user public key in the trusted execution environment; sending the signed user public key to the server, so that the server verifies the signature of the user public key, and after the verification is passed, generating a DID document based on the DID identifier and the user public key, and uploading the DID document to the blockchain. The DID generation method and device of the present invention generate a user private key and a user public key in a TEE, sign the user public key in the TEE, and send the signed user public key to the server for signature verification to ensure that the user public key is generated in the TEE and its security.

Description

Technical Field

[0001] The present invention relates to the field of decentralized identity, and more specifically to a method, device, readable storage medium, and electronic device for generating a DID. Background Art

[0002] Decentralized Identity (DID) is a type of digital identity that is derived from traditional centralized identity. In the DID system, each entity (including individuals, organizations, devices, etc.) is identified by a DID, which is a string in a specific format that represents the digital identity of the entity. Each DID corresponds to a DID document. The DID can be used as a Uniform Resource Identifier (URI) for locating DID documents. A DID document is a descriptive text in a preset format (e.g., JSON-LD) about the DID and the owner of the DID. A DID document can include various attributes, such as context, DID subject, public key, authentication, authorization and delegation, service endpoints, and so on.

[0003] In a DID system, requests, data signatures, and transmissions between entities are all based on each entity's public-private key pair (the public key is contained in the DID document, and the private key is stored on the entity or server). Therefore, the security of the entity's public-private key pair is central to the proper functioning of the DID system. Loss or forgery of the public-private key pair can result in data loss.

[0004] Therefore, how to ensure the security of the public-private key pairs generated when creating DID identifiers and DID documents is a technical problem that needs to be urgently solved by those skilled in the art. Summary of the Invention

[0005] One of the purposes of the present invention is to provide a method for generating a DID, generating a user private key and a user public key in a trusted execution environment (TEE), signing the user public key in the TEE, and sending the signed user public key to a server for signature verification to ensure that the user public key is generated in the TEE and its security.

[0006] Based on the above purpose, the present invention provides a method for generating a DID, which is applied to a user terminal and includes the following steps:

[0007] Sending a request for creating a DID to the server, so that the server generates a DID identifier after receiving the request and sends the DID identifier to the user;

[0008] Receive the DID identifier and generate a user public key and a user private key in a trusted execution environment;

[0009] Signing the user public key in the trusted execution environment;

[0010] The signed user public key is sent to the server so that the server can verify the signature of the user public key. After the verification is passed, a DID document is generated according to the DID identifier and the user public key, and the DID document is uploaded to the blockchain.

[0011] Furthermore, in some implementations, signing the user public key in the trusted execution environment specifically includes:

[0012] In the trusted execution environment, the user public key is signed using a pre-configured signature method, wherein the signature method is configured to prohibit signing a user public key that is not generated in the trusted execution environment.

[0013] Furthermore, in some embodiments, the user public key is signed using a pre-configured signature method, specifically including:

[0014] The user public key is signed by a trusted program running in the trusted execution environment, wherein a designated interface in the trusted program for receiving the user public key sent by an application in a non-trusted execution environment is in a closed state.

[0015] Furthermore, in some implementations, sending the signed user public key to the server specifically includes:

[0016] Encapsulating the signed user public key into information of a specified type through the trusted program;

[0017] Sending the specified type of information to the server, so that the server verifies the signature of the user public key after determining that the received information is of the specified type, and generates a DID document based on the DID identifier and the user public key after the verification is successful;

[0018] The trusted program is configured to: after signing data received through interfaces other than the designated interface, encapsulate the signed data into information of a non-designated type.

[0019] Another object of the present invention is to provide a method for generating a DID, generating a user private key and a user public key in the TEE, signing the user public key in the TEE, and sending the signed user public key to the server for signature verification to ensure that the user public key is generated in the TEE and its security.

[0020] Based on the above purpose, the present invention provides a method for generating a DID, which is applied to a server and includes the following steps:

[0021] Receive a request from the user to create a DID;

[0022] Generate a DID identifier for the user terminal according to the request;

[0023] Send the DID identifier to the user terminal, so that the user terminal generates a user public key and a user private key in the trusted execution environment, signs the user public key in the trusted execution environment, and then sends the signed user public key to the server;

[0024] Receive the signed user public key;

[0025] Verify the signature of the user's public key;

[0026] After verification, a DID document is generated based on the DID identifier and the user public key;

[0027] Upload the DID document to the blockchain.

[0028] Furthermore, in some embodiments, receiving the signed user public key specifically includes:

[0029] Receive information of a specified type sent by a user terminal, where the information of the specified type is formed by the user terminal encapsulating a signed user public key through a trusted program running in a scalable execution environment.

[0030] Furthermore, in some implementations, verifying the signature of the user's public key specifically includes:

[0031] After determining that the received information is of a specified type, verifying the signature of the user public key.

[0032] Another object of the present invention is to provide a DID generation device, which generates a user private key and a user public key in TEE, signs the user public key in TEE, and sends the signed user public key to the server for signature verification to ensure that the user public key is generated in TEE and its security.

[0033] Based on the above objectives, the present invention provides a device for generating a DID, which is applied to a user terminal and includes:

[0034] A first sending module is configured to send a request for creating a DID to a server, so that the server generates a DID identifier after receiving the request and sends the DID identifier to the user terminal;

[0035] A first receiving module is configured to receive the DID identifier and generate a user public key and a user private key in a trusted execution environment;

[0036] A signing module, configured to sign the user public key in the trusted execution environment;

[0037] The second sending module is configured to send the signed user public key to the server so that the server verifies the signature of the user public key, and after the verification is passed, generates a DID document according to the DID identifier and the user public key, and uploads the DID document to the blockchain.

[0038] Furthermore, in some implementations, signing the user public key in the trusted execution environment specifically includes:

[0039] In the trusted execution environment, the user public key is signed using a pre-configured signature method, wherein the signature method is configured to prohibit signing a user public key that is not generated in the trusted execution environment.

[0040] Furthermore, in some embodiments, the user public key is signed using a pre-configured signature method, specifically including:

[0041] The user public key is signed by a trusted program running in the trusted execution environment, wherein a designated interface in the trusted program for receiving the user public key sent by an application in a non-trusted execution environment is in a closed state.

[0042] Furthermore, in some implementations, sending the signed user public key to the server specifically includes:

[0043] Encapsulating the signed user public key into information of a specified type through the trusted program;

[0044] Sending the specified type of information to the server, so that the server verifies the signature of the user public key after determining that the received information is of the specified type, and generates a DID document based on the DID identifier and the user public key after the verification is successful;

[0045] The trusted program is configured to: after signing data received through interfaces other than the designated interface, encapsulate the signed data into information of a non-designated type.

[0046] Another object of the present invention is to provide a DID generation device, which generates a user private key and a user public key in TEE, signs the user public key in TEE, and sends the signed user public key to the server for signature verification to ensure that the user public key is generated in TEE and its security.

[0047] Based on the above objectives, the present invention provides a DID generation device, which is applied to a server and includes:

[0048] A second receiving module is configured to receive a request for creating a DID sent by a user terminal;

[0049] A first generating module is configured to generate a DID identifier of the user terminal according to the request;

[0050] A third sending module is configured to send the DID identifier to the user terminal, so that the user terminal generates a user public key and a user private key in the trusted execution environment, signs the user public key in the trusted execution environment, and then sends the signed user public key to the server;

[0051] A third receiving module is configured to receive the signed user public key;

[0052] Verification module, set to verify the signature of the user's public key;

[0053] A second generation module is configured to generate a DID document based on the DID identifier and the user public key after the verification is passed;

[0054] The upload module is configured to upload the DID document to the blockchain.

[0055] Furthermore, in some embodiments, receiving the signed user public key specifically includes:

[0056] Receive information of a specified type sent by a user terminal, where the information of the specified type is formed by the user terminal encapsulating a signed user public key through a trusted program running in a scalable execution environment.

[0057] Furthermore, in some implementations, verifying the signature of the user's public key specifically includes:

[0058] After determining that the received information is of a specified type, verifying the signature of the user public key.

[0059] Another object of the present invention is to provide a readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the steps of the DID generation method as described above.

[0060] Another object of the present invention is to provide an electronic device, which includes a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it performs the steps of the DID generation method as described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Figure 1is a structural diagram of a DID system according to an exemplary embodiment of the present invention;

[0062] Figure 2 Flowchart of a method for generating a DID according to an embodiment of the present invention;

[0063] Figure 3 is a flowchart of a method for generating a DID according to another embodiment of the present invention;

[0064] Figure 4 This is a structural block diagram of a device for generating a DID according to an embodiment of the present invention;

[0065] Figure 5 FIG. 4 is a structural block diagram of a DID generation device according to another embodiment of the present invention. DETAILED DESCRIPTION

[0066] The preferred embodiments of the present invention are given below in conjunction with the accompanying drawings and described in detail.

[0067] In the DID system, each entity (including individuals, organizations, devices, etc.) is assigned a DID identifier, a string in a specific format that represents the entity's digital identity. Each DID identifier corresponds to a DID document. A DID identifier can serve as a Uniform Resource Identifier (URI) for locating DID documents. A DID identifier consists of a scheme, a DID method, and a DID method-specific string. The scheme is fixed and indicates that the string is a DID identifier string. The DID method indicates the set of methods used to define and operate the DID identifier. The DID method-specific string represents the unique identifier string under the DID method. Each DID identifier corresponds to a DID document. A DID identifier can serve as a Uniform Resource Identifier (URI) for locating DID documents. A DID document is a descriptive text in a pre-defined format (e.g., JSON-LD) that includes information about the DID identifier and its owner. A DID document may include various properties, such as context, DID subject, public key, authentication, authorization and delegation, service endpoint, creation, update, proof, extensibility, and other suitable properties, or any combination thereof. A DID document may define or point to a resource that defines a number of operations that may be performed relative to the DID.

[0068] An entity's DID allows that entity to gain full control over its identity and the information associated with it. Verifiable Claims (VCs) allow for authorization, endorsement, and verification between different entities. In a commercial environment, a service provider can use its customer's DID and VC to identify and authenticate the customer and provide the appropriate service or product.

[0069] A VC can provide verifiable online information about an entity's qualities, characteristics, relationships, and other relevant information. A VC can contain descriptive text in a pre-defined format (e.g., JSON-LD) that describes one or more claims about the DID (e.g., the DID owner's age, the DID owner's educational background) and the entity's endorsement of the claim. A VC can include various attributes, such as context, identity, type, credential subject, issuer, issuance date, proof, expiration date, status, representation, other suitable attributes, or any combination thereof. A VC can specify the type of its claim, which can indicate the structure of the claim. This can facilitate automated processing by VC issuers and VC verifiers.

[0070] Each entity in the DID system can participate in and implement DID services in different roles. For example, an entity (individual) wishes to use a service provided by a commercial entity (such as an Internet cafe), which requires proof that the individual is over 18 years old. The individual can request a VC issued by another entity (a government agency that provides citizen age verification). In this case, the government agency is the VC issuer, the individual is the VC holder, and the commercial entity is the VC verifier. The commercial entity can verify the VC to ensure that the individual meets the age requirement. In another example, an entity (user) can issue a VC to another entity (a first enterprise) to allow it to use data stored by another entity (a second enterprise). In this case, the user is the VC issuer, the first enterprise is the VC holder, and the second enterprise is the VC verifier.

[0071] like Figure 1As shown, in an exemplary embodiment, the DID system 100 includes a server 110 and multiple entities 120. The server 110 runs a server 111 for creating and managing DIDs, and each entity 120 runs a client 121 for performing DID services. For example, when an entity 120 wants to join the DID system, the client 121 on the entity 120 will send a request to the server 111. After receiving the request, the server 111 will generate a DID identifier and a DID document. The DID document includes a public key, and the private key is stored on the client 121 or the server 111. The DID document is then uploaded to the blockchain 130. After the upload is completed, all entities 120 on the blockchain 130 can query the DID document. Alternatively, when an entity 120 (first entity) requires another entity 120 (second entity) to issue a verifiable claim (VC) for it, the user terminal 121 on the first entity will send a VC request to the server 111. After receiving the VC request, the server 111 will send the VC request to the user terminal 121 on the second entity. The user terminal 121 on the second entity generates a VC based on the VC request and sends the VC to the server 111. The server 111 then sends the VC to the user terminal 121 on the first entity.

[0072] When each entity in the DID system performs DID services, it must use its own private key to sign the DID service data. The user end of another entity then verifies the signature by querying the public key in the DID document to ensure that the DID service data was generated by the user end of that entity. For example, in the age certificate issued by a government agency for an individual, the government agency uses its private key to sign the age attribute. When a commercial entity verifies this certificate, it obtains the government agency's DID document on the blockchain through a server and verifies the signature against the government agency's public key in the DID document. If the signature passes, it confirms that the certificate was issued by the government agency. Therefore, the security of the entity's public-private key pair is the core security guarantee for the normal operation of the DID system. If the public-private key pair is lost or forged, data loss will occur.

[0073] In the prior art, when an entity wants to join the DID system, it needs to send a request to the server used to create and manage DIDs. After receiving the request, the server will generate a DID identifier and a corresponding DID document. The public key and private key generated by the server and associated with the user are hosted on the server. When the user needs to use the private key for authorization to perform DID business, it needs to log in with the account and then authorize the server to sign. However, the essence of this method still requires a centralized server to manage identity and public-private key pairs, which conflicts with the decentralization of the DID system. In another solution of the prior art, the private key is stored in the virtual machine of the user, but the security level of the virtual machine is not high, and there is a risk of private key leakage due to hacker attacks.

[0074] To solve the problems existing in the prior art, the present invention provides a DID generation method, which generates a user private key and a user public key in a trusted execution environment (TEE), signs the user public key in the TEE, and sends the signed user public key to the server for signature verification to ensure that the user public key is generated in the TEE and its security.

[0075] like Figure 2 As shown, an embodiment of the present invention provides a method for generating a DID, which is applied to a user terminal 121 and includes the following steps:

[0076] S210 : Sending a request for creating a DID to the server 111 , so that the server 111 generates a DID identifier after receiving the request and sends the DID identifier to the user 121 .

[0077] When an entity 120 wants to join the DID system 100, the user terminal 121 sends a request to the server terminal 111 to create a DID. After receiving the request, the server terminal 111 generates a DID identifier and sends the DID identifier to the user terminal 121. The DID identifier is the unique identifier of the entity 120 in the DID system.

[0078] S220: Receive the DID identifier and generate the user public key and user private key in the TEE.

[0079] After receiving the DID, client 121 generates a public and private key in the TEE. The TEE, based on the ARM TrustZone architecture, is a secure environment independent of the operating system. This protects data in the TEE even if the operating system is compromised. Generating public and private keys in the TEE ensures their security, preventing data leaks from hacker attacks.

[0080] In some embodiments, user public and private keys can also be generated in a secure element (SE). The SE is typically provided in chip form and contains encryption / decryption logic to prevent external malicious parsing attacks and protect data security. This protects data in the SE from malicious attacks and serves the same purpose as the TEE: to ensure the security of user public and private keys.

[0081] S230: Sign the user public key in TEE.

[0082] To ensure that the user public key received by the server is sent from the TEE, the user public key is first signed so that the server can verify the signature after receiving the signed user public key to ensure that the received user public key is sent from the TEE.

[0083] In some embodiments, signing the user's public key in the TEE specifically includes:

[0084] In the TEE, a pre-configured signature method is used to sign the user public key, wherein the signature method is configured to prohibit signing the user public key that is not generated in the TEE.

[0085] Since attackers can hijack the operating system, generate user public and private keys on the REE (Rich Execution Environment, usually referring to the operating system), and then transfer them to the TEE, if the TEE signs the user public key generated on the REE and uses it as the user public key in the DID document, the security of the DID cannot be guaranteed. Therefore, by configuring the signing method to prohibit signing user public keys that are not generated in the TEE, it can be guaranteed that the user public key is always generated in the TEE, thereby ensuring its security.

[0086] In some embodiments, a trusted program (TA) runs in the TEE. The TA refers to a fixed code running in the TEE. The code logic is strictly written in accordance with the logic agreed upon in the early stage of the business, and it will not be invaded by the outside during operation, so it can run safely. The TA has an interface for communicating with the REE, which is used to receive data generated by the application of the REE. Different types of data can be transmitted through different interfaces. In some embodiments, the user public key is signed by the TA, and the designated interface in the TA for receiving the user public key sent by the application in the non-trusted execution environment (i.e., the REE) can be set to be in a closed state. In this way, the user public key generated outside the TEE will not be able to be transmitted to the TA as a public key. Even if the user public key generated on the REE side is transmitted to the TA through other interfaces (such as the business data interface), the TA will only process it as business data, and will not sign it as a user public key, thereby ensuring that the TA will only sign the user public key generated in the TEE and use it as the public key of the DID document to ensure the security of the user public key and the user private key.

[0087] In some embodiments, the user's public key can be signed with a manufacturer's preset private key or a certificate chain can be issued for the user's public key through the Certificate Authority (CA) center in the TEE. After the signed user's public key is sent to the server 111, the server 111 uses the manufacturer's preset public key or the certificate public key to verify the signature of the user's public key.

[0088] S240: Send the signed user public key to the server 111 so that the server 111 verifies the signature of the user public key. After the verification is passed, a DID document is generated according to the DID identifier and the user public key, and the DID document is uploaded to the blockchain 130.

[0089] After the signed user public key is sent to the server 111, the server 111 will verify the signature of the user public key. After the verification is passed, the server 111 will generate a DID document based on the DID identifier and the user public key, and upload the DID document to the blockchain 130. If the upload is successful, the user terminal 121 will receive the upload success message sent by the server 111, and the entire DID creation process is completed.

[0090] In some embodiments, sending the signed user public key to the server 111 specifically includes:

[0091] Encapsulate the signed user public key into a specified type of information through TA;

[0092] Sending information of a specified type to the server 111, so that the server 111 verifies the signature of the user's public key after determining that the received information is of the specified type, and generates a DID document based on the DID identifier and the user's public key after the verification is successful;

[0093] The TA is configured to: after signing data received through interfaces other than the designated interface, encapsulate the signed data into information of a non-designated type.

[0094] Information of a specified type means that the information is the signed user public key. When the server 111 determines that the received information is a message of a specified type, the server 111 verifies its signature and generates a DID document based on the user public key. Information of an unspecified type means that the data in the information is business data, not the user public key. After determining that it is unspecified information, the server 111 will not use it as the user public key and generate a DID document based on it. Instead, it will only consider it as business data and perform corresponding business operations.

[0095] Since the designated interface in TA for receiving user public keys sent by applications outside TEE is in a closed state, the user public key generated on the REE side can only be transmitted to TA from the non-designated interface. After receiving it, TA will only encapsulate it as non-designated type of information, thereby avoiding using the user public key and user private key generated on the REE side as the public-private key pair of DID, thereby ensuring the security of the user public key and user private key.

[0096] like Figure 3 As shown, another embodiment of the present invention provides a method for generating a DID, which is applied to the server 111 and includes the following steps:

[0097] S310: Receive a request for creating a DID sent by the user terminal 121.

[0098] S320: Generate a DID identifier according to the request.

[0099] S330: Send the DID identifier to the user terminal 121, so that the user terminal 121 generates a user public key and a user private key in the TEE, signs the user public key in the TEE, and then sends the signed user public key to the server 111.

[0100] When an entity 120 wants to join the DID system 100, the user terminal 121 sends a request to the server terminal 111 to create a DID. After receiving the request, the server terminal 111 generates a DID identifier and sends the DID identifier to the user terminal 121. The DID identifier is the unique identifier of the entity 120 in the DID system.

[0101] After receiving the DID, the user terminal 121 generates a public key and a private key in the TEE. By generating the public key and the private key in the TEE, their security can be guaranteed to avoid being leaked by hackers. In some embodiments, the public key and the private key can also be generated in a secure element (SE).

[0102] In some embodiments, the user terminal 121 signs the user public key in the TEE using a pre-configured signature method, where the signature method is configured to prohibit signing user public keys that are not generated in the TEE. This ensures that the user public key is always generated in the TEE, thereby ensuring its security.

[0103] In some embodiments, a trusted program (TA) runs in the TEE, and the user public key is signed by the TA, and the designated interface in the TA for receiving the user public key sent by the application in the non-trusted execution environment (i.e., in the REE) can be set to be in a closed state. In this way, the user public key generated outside the TEE will not be able to be transmitted to the TA as a public key. Even if the user public key generated on the REE side is transmitted to the TA through other interfaces (such as the business data interface), the TA will only process it as business data, and will not sign it as a user public key, thereby ensuring that the TA will only sign the user public key generated in the TEE and use it as the public key of the DID document to ensure the security of the user public key and the user private key.

[0104] In some embodiments, the user terminal 121 can use the manufacturer's preset private key to sign the user's public key or issue a certificate chain for the user's public key through the Certificate Authority (CA) center in the TEE. After the signed user public key is sent to the server 111, the server 111 uses the manufacturer's preset public key or the certificate public key to verify the signature of the user's public key.

[0105] S340: Receive the signed user public key.

[0106] S350: Verify the signature of the user's public key.

[0107] S360: After verification, a DID document is generated based on the DID identifier and user public key.

[0108] S370: Upload the DID document to the blockchain.

[0109] After the signed user public key is sent to the server 111, the server 111 will verify the signature of the user public key. After the verification is passed, the server 111 will generate a DID document based on the DID identifier and the user public key, and upload the DID document to the blockchain 130. If the upload is successful, the user terminal 121 will receive the upload success message sent by the server 111, and the entire DID creation process is completed.

[0110] In some embodiments, receiving the signed user public key specifically includes:

[0111] Receive information of a specified type sent by a user terminal, where the information of the specified type is formed by the user terminal encapsulating a signed user public key through a trusted program running in a scalable execution environment.

[0112] Verify the signature of the user's public key, including:

[0113] After determining that the received information is of a specified type, verifying the signature of the user public key.

[0114] Information of a specified type means that the information is the signed user public key. When the server 111 determines that the received information is a message of a specified type, the server 111 verifies its signature and generates a DID document based on the user public key. Information of an unspecified type means that the data in the information is business data, not the user public key. After determining that it is unspecified information, the server 111 will not use it as the user public key and generate a DID document based on it. Instead, it will only consider it as business data and perform corresponding business operations.

[0115] Since the designated interface in TA for receiving user public keys sent by applications outside TEE is in a closed state, the user public key generated on the REE side can only be transmitted to TA from the non-designated interface. After receiving it, TA will only encapsulate it as non-designated type of information, thereby avoiding using the user public key and user private key generated on the REE side as the public-private key pair of DID, thereby ensuring the security of the user public key and user private key.

[0116] The DID generation method of the embodiment of the present invention generates a user private key and a user public key in the TEE, signs the user public key in the TEE, and sends the signed user public key to the server for signature verification to ensure that the user public key is sent from the TEE and its security; by prohibiting the signing of the user public key generated outside the TEE, it is ensured that the user public key is generated in the TEE, further ensuring the security of the key.

[0117] like Figure 4As shown, an embodiment of the present invention provides a DID generation device, which is applied to a user terminal 121 and includes: a first sending module 11, a first receiving module 12, a signature module 13 and a second sending module 14.

[0118] The first sending module 11 is configured to send a request for creating a DID to the server, so that the server generates a DID identifier after receiving the request and sends the DID identifier to the user.

[0119] When an entity 120 wants to join the DID system 100, the user terminal 121 sends a request to the server terminal 111 to create a DID. After receiving the request, the server terminal 111 generates a DID identifier and sends the DID identifier to the user terminal 121. The DID identifier is the unique identifier of the entity 120 in the DID system.

[0120] The first receiving module 12 is configured to receive the DID identifier and generate a user public key and a user private key in a trusted execution environment.

[0121] After receiving the DID, the user terminal 121 generates a user public key and a user private key in the TEE. By generating the user public key and the user private key in the TEE, their security can be guaranteed to avoid being leaked by hackers.

[0122] In some embodiments, the user public key and the user private key may also be generated in a secure element (SE).

[0123] The signature module 13 is configured to sign the user public key in the trusted execution environment.

[0124] To ensure that the user public key received by the server is sent from the TEE, the user public key is first signed so that the server can verify the signature after receiving the signed user public key to ensure that the received user public key is sent from the TEE.

[0125] In some embodiments, signing the user's public key in the TEE specifically includes:

[0126] In the TEE, a pre-configured signature method is used to sign the user public key, wherein the signature method is configured to prohibit signing the user public key that is not generated in the TEE.

[0127] By configuring the signature method to prohibit signing user public keys that are not generated in the TEE, you can ensure that the user public key is always generated in the TEE, thereby ensuring its security.

[0128] In some embodiments, a trusted program (TA) runs in the TEE, and the user public key is signed by the TA, and the designated interface in the TA for receiving the user public key sent by the application in the non-trusted execution environment (i.e., in the REE) can be set to be in a closed state. In this way, the user public key generated outside the TEE will not be able to be transmitted to the TA as a public key. Even if the user public key generated on the REE side is transmitted to the TA through other interfaces (such as the business data interface), the TA will only process it as business data, and will not sign it as a user public key, thereby ensuring that the TA will only sign the user public key generated in the TEE and use it as the public key of the DID document to ensure the security of the user public key and the user private key.

[0129] In some embodiments, the user's public key can be signed with a manufacturer's preset private key or a certificate chain can be issued for the user's public key through the Certificate Authority (CA) center in the TEE. After the signed user's public key is sent to the server 111, the server 111 uses the manufacturer's preset public key or the certificate public key to verify the signature of the user's public key.

[0130] The second sending module 14 is configured to send the signed user public key to the server so that the server verifies the signature of the user public key, and after the verification is passed, generates a DID document according to the DID identifier and the user public key, and uploads the DID document to the blockchain.

[0131] After the signed user public key is sent to the server 111, the server 111 will verify the signature of the user public key. After the verification is passed, the server 111 will generate a DID document based on the DID identifier and the user public key, and upload the DID document to the blockchain 130. If the upload is successful, the user terminal 121 will receive the upload success message sent by the server 111, and the entire DID creation process is completed.

[0132] In some embodiments, sending the signed user public key to the server 111 specifically includes:

[0133] Encapsulate the signed user public key into a specified type of information through TA;

[0134] Sending information of a specified type to the server 111, so that the server 111 verifies the signature of the user's public key after determining that the received information is of the specified type, and generates a DID document based on the DID identifier and the user's public key after the verification is successful;

[0135] The TA is configured to: after signing data received through interfaces other than the designated interface, encapsulate the signed data into information of a non-designated type.

[0136] Information of a specified type means that the information is the signed user public key. When the server 111 determines that the received information is a message of a specified type, the server 111 verifies its signature and generates a DID document based on the user public key. Information of an unspecified type means that the data in the information is business data, not the user public key. After determining that it is unspecified information, the server 111 will not use it as the user public key and generate a DID document based on it. Instead, it will only consider it as business data and perform corresponding business operations.

[0137] Since the designated interface in TA for receiving user public keys sent by applications outside TEE is in a closed state, the user public key generated on the REE side can only be transmitted to TA from the non-designated interface. After receiving it, TA will only encapsulate it as non-designated type of information, thereby avoiding using the user public key and user private key generated on the REE side as the public-private key pair of DID, thereby ensuring the security of the user public key and user private key.

[0138] like Figure 5 As shown, another embodiment of the present invention provides a DID generation device, which is applied to the server and includes a second receiving module 21, a first generating module 22, a third sending module 23, a third receiving module 24, a verification module 25, a second generating module 26 and an uploading module 27.

[0139] The second receiving module 21 is configured to receive a request for creating a DID sent by a user terminal.

[0140] The first generating module 22 is configured to generate a DID identifier of the user terminal according to the request.

[0141] The third sending module 23 is configured to send the DID identifier to the user terminal so that the user terminal generates a user public key and a user private key in a trusted execution environment, signs the user public key in the trusted execution environment, and then sends the signed user public key to the server.

[0142] When an entity 120 wants to join the DID system 100, the user terminal 121 sends a request to the server terminal 111 to create a DID. After receiving the request, the server terminal 111 generates a DID identifier and sends the DID identifier to the user terminal 121. The DID identifier is the unique identifier of the entity 120 in the DID system.

[0143] After receiving the DID, the user terminal 121 generates a public key and a private key in the TEE. By generating the public key and the private key in the TEE, their security can be guaranteed to avoid being leaked by hackers. In some embodiments, the public key and the private key can also be generated in a secure element (SE).

[0144] In some embodiments, the user terminal 121 signs the user public key in the TEE using a pre-configured signature method, where the signature method is configured to prohibit signing user public keys that are not generated in the TEE. This ensures that the user public key is always generated in the TEE, thereby ensuring its security.

[0145] In some embodiments, a trusted program (TA) runs in the TEE, and the user public key is signed by the TA, and the designated interface in the TA for receiving the user public key sent by the application in the non-trusted execution environment (i.e., in the REE) can be set to be in a closed state. In this way, the user public key generated outside the TEE will not be able to be transmitted to the TA as a public key. Even if the user public key generated on the REE side is transmitted to the TA through other interfaces (such as the business data interface), the TA will only process it as business data, and will not sign it as a user public key, thereby ensuring that the TA will only sign the user public key generated in the TEE and use it as the public key of the DID document to ensure the security of the user public key and the user private key.

[0146] In some embodiments, the user terminal 121 can use the manufacturer's preset private key to sign the user's public key or issue a certificate chain for the user's public key through the Certificate Authority (CA) center in the TEE. After the signed user public key is sent to the server 111, the server 111 uses the manufacturer's preset public key or the certificate public key to verify the signature of the user's public key.

[0147] The third receiving module 24 is configured to receive the signed user public key.

[0148] The verification module 25 is configured to verify the signature of the user's public key.

[0149] The second generating module 26 is configured to generate a DID document according to the DID identifier and the user public key after the verification is passed.

[0150] The upload module 27 is configured to upload the DID document to the blockchain.

[0151] After the signed user public key is sent to the server 111, the server 111 will verify the signature of the user public key. After the verification is passed, the server 111 will generate a DID document based on the DID identifier and the user public key, and upload the DID document to the blockchain 130. If the upload is successful, the user terminal 121 will receive the upload success message sent by the server 111, and the entire DID creation process is completed.

[0152] In some embodiments, receiving the signed user public key specifically includes:

[0153] Receive information of a specified type sent by a user terminal, where the information of the specified type is formed by the user terminal encapsulating a signed user public key through a trusted program running in a scalable execution environment.

[0154] Verify the signature of the user's public key, including:

[0155] After determining that the received information is of a specified type, verifying the signature of the user public key.

[0156] Information of a specified type means that the information is the signed user public key. When the server 111 determines that the received information is a message of a specified type, the server 111 verifies its signature and generates a DID document based on the user public key. Information of an unspecified type means that the data in the information is business data, not the user public key. After determining that it is unspecified information, the server 111 will not use it as the user public key and generate a DID document based on it. Instead, it will only consider it as business data and perform corresponding business operations.

[0157] Since the designated interface in TA for receiving user public keys sent by applications outside TEE is in a closed state, the user public key generated on the REE side can only be transmitted to TA from the non-designated interface. After receiving it, TA will only encapsulate it as non-designated type of information, thereby avoiding using the user public key and user private key generated on the REE side as the public-private key pair of DID, thereby ensuring the security of the user public key and user private key.

[0158] The DID generation device of the embodiment of the present invention generates a user private key and a user public key in the TEE, signs the user public key in the TEE, and sends the signed user public key to the server for signature verification to ensure that the user public key is sent from the TEE and its security; by prohibiting the signing of the user public key generated outside the TEE, it is ensured that the user public key is generated in the TEE, further ensuring the security of the key.

[0159] Yet another embodiment of the present invention provides a readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the steps of the DID generation method in the above embodiment of the present invention.

[0160] Another embodiment of the present invention provides an electronic device, which includes a memory and a processor. The memory stores executable code. When the processor executes the executable code, it performs the steps of the DID generation method in the above embodiment of the present invention.

[0161] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, 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 a combination of any of these devices.

[0162] For the convenience of description, the above device is described as being divided into various units according to their functions. Of course, when implementing the present invention, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0163] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0164] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts 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, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0165] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0166] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

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

[0168] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0169] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The 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 technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0170] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0171] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0172] The present invention may be described in the general context of computer-executable instructions, such as program modules, executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. The present invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media, including storage devices.

[0173] The various embodiments of the present invention are described in a progressive manner. Similar portions between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiment is generally similar to the method embodiment, so its description is relatively simple. For relevant portions, refer to the description of the method embodiment.

[0174] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of the present invention. Various modifications are possible. In other words, any simple, equivalent changes and modifications made in accordance with the claims and description of the present invention are within the scope of protection of the patent claims. Anything not fully described in this invention constitutes conventional technology.

Claims

1. A method for generating a DID, the method being applied to a user terminal, the method comprising the steps of: Sending a request for creating a DID to the server, so that the server generates a DID identifier after receiving the request and sends the DID identifier to the user; Receive the DID identifier and generate a user public key and a user private key in a trusted execution environment; Signing the user public key in the trusted execution environment; Send the signed user public key to the server so that the server can verify the signature of the user public key. After the verification is successful, the server generates a DID document based on the DID identifier and the user public key, and uploads the DID document to the blockchain; Signing the user public key in the trusted execution environment specifically includes: In the trusted execution environment, the user public key is signed using a pre-configured signature method, wherein the signature method is configured to prohibit signing a user public key that is not generated in the trusted execution environment.

2. The DID generation method according to claim 1, wherein the user public key is signed using a pre-configured signature method, specifically comprising: The user public key is signed by a trusted program running in the trusted execution environment, wherein a designated interface in the trusted program for receiving the user public key sent by an application in a non-trusted execution environment is in a closed state.

3. The DID generation method according to claim 2, wherein the signed user public key is sent to the server, specifically comprising: Encapsulating the signed user public key into information of a specified type through the trusted program; Sending the specified type of information to the server, so that the server verifies the signature of the user public key after determining that the received information is of the specified type, and generates a DID document based on the DID identifier and the user public key after the verification is successful; The trusted program is configured to: after signing data received through interfaces other than the designated interface, encapsulate the signed data into information of a non-designated type.

4. A method for generating a DID, the method being applied to a server, the method comprising the steps of: Receive a request from the user to create a DID; Generate a DID identifier for the user terminal according to the request; The DID identifier is sent to the user terminal, so that the user terminal generates a user public key and a user private key in a trusted execution environment, signs the user public key in the trusted execution environment, and then sends the signed user public key to the server; wherein, The signature is a signature of the user public key by the user terminal in the trusted execution environment using a pre-configured signature method, wherein the signature method is configured to prohibit signing a user public key that is not generated in the trusted execution environment; Receive the signed user public key; Verify the signature of the user's public key; After verification, a DID document is generated based on the DID identifier and the user public key; Upload the DID document to the blockchain.

5. The DID generation method according to claim 4, wherein receiving the signed user public key comprises: Receive information of a specified type sent by a user terminal, where the information of the specified type is formed by the user terminal encapsulating a signed user public key through a trusted program running in a trusted execution environment.

6. The DID generation method according to claim 5, wherein verifying the signature of the user's public key comprises: After determining that the received information is of a specified type, verifying the signature of the user public key.

7. A device for generating a DID, the device being applied to a user terminal, the device comprising: A first sending module is configured to send a request for creating a DID to a server, so that the server generates a DID identifier after receiving the request and sends the DID identifier to the user terminal; A first receiving module is configured to receive the DID identifier and generate a user public key and a user private key in a trusted execution environment; A signing module, configured to sign the user public key in the trusted execution environment; A second sending module is configured to send the signed user public key to the server, so that the server verifies the signature of the user public key, and after the verification is passed, generates a DID document according to the DID identifier and the user public key, and uploads the DID document to the blockchain; Signing the user public key in the trusted execution environment specifically includes: In the trusted execution environment, the user public key is signed using a pre-configured signature method, wherein the signature method is configured to prohibit signing a user public key that is not generated in the trusted execution environment.

8. The DID generation device according to claim 7, wherein the user public key is signed using a pre-configured signature method, specifically comprising: The user public key is signed by a trusted program running in the trusted execution environment, wherein a designated interface in the trusted program for receiving the user public key sent by an application in a non-trusted execution environment is in a closed state.

9. The DID generation device according to claim 8, wherein the signed user public key is sent to the server, specifically comprising: Encapsulating the signed user public key into information of a specified type through the trusted program; Sending the specified type of information to the server, so that the server verifies the signature of the user public key after determining that the received information is of the specified type, and generates a DID document based on the DID identifier and the user public key after the verification is successful; The trusted program is configured to: after signing data received through interfaces other than the designated interface, encapsulate the signed data into information of a non-designated type.

10. A device for generating a DID, the device being applied to a server, the device comprising: A second receiving module is configured to receive a request for creating a DID sent by a user terminal; A first generating module is configured to generate a DID identifier of the user terminal according to the request; a third sending module, configured to send the DID identifier to the user terminal, so that the user terminal generates a user public key and a user private key in the trusted execution environment, signs the user public key in the trusted execution environment, and then sends the signed user public key to the server; wherein the signature is signed by the user terminal in the trusted execution environment using a pre-configured signing method to sign the user public key, and the signing method is configured to prohibit signing a user public key that is not generated in the trusted execution environment; A third receiving module is configured to receive the signed user public key; Verification module, set to verify the signature of the user's public key; A second generation module is configured to generate a DID document based on the DID identifier and the user public key after the verification is passed; The upload module is configured to upload the DID document to the blockchain.

11. The DID generation device according to claim 10, receiving the signed user public key, specifically comprising: Receive information of a specified type sent by a user terminal, where the information of the specified type is formed by the user terminal encapsulating a signed user public key through a trusted program running in a trusted execution environment.

12. The DID generation device according to claim 11, wherein verifying the signature of the user's public key comprises: After determining that the received information is of a specified type, verifying the signature of the user public key.

13. A readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the steps of the method for generating a DID according to any one of claims 1 to 6.

14. An electronic device comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it performs the steps of the DID generation method according to any one of claims 1 to 6.

Images