Account management method, account management device, and account management system

Abstract

Embodiments of the present specification provide an account management method, an account management device and an account management system. The account management method comprises: a service component of a service end obtaining scenario identity registration data from a user side from a client component of a client end; the service component configuring scenario information associated with the user side according to the scenario identity registration data; and the service component configuring a scenario identity associated with a scenario of the user side on a scenario chain.

Description

TECHNICAL FIELD

[0001] Embodiments of the present specification belong to the technical field of blockchains, and particularly relate to an account management method, an account management device, and an account management system. BACKGROUND

[0002] With the continuous development of digitalization, more and more business scenarios are developed to provide corresponding services for user parties. Generally, a user party needs to establish its identity or account in each business scenario, and the operator of the business scenario can manage the identities or accounts of all users in a centralized manner. This will often cause multiple identities or accounts of the same user party in multiple business scenarios to be fragmented from each other, which is difficult to effectively integrate. In addition, since the specific operations of the user party are generally performed by the upper application of the operator, it also brings certain security risks. Therefore, it is necessary to improve the way of managing the identities or accounts of users in multiple business scenarios. SUMMARY

[0003] An object of one or more embodiments of the present specification is to provide an account management method, an account management device, and an account management system to integrate the identities of a user in different business scenarios and to realize distributed account management to ensure account security.

[0004] According to a first aspect of one or more embodiments of the present specification, an account management method is provided, comprising: a service component of a service end obtaining scenario identity registration data from a user party from a client component of a client, wherein an identity document associated with a decentralized identity of the user party is stored on an identity chain; the service component configuring scenario information associated with the user party according to the scenario identity registration data; and the service component configuring a scenario identity associated with the scenario of the user party on a scenario chain.

[0005] According to a second aspect of one or more embodiments of the present specification, an account management device is provided, comprising a communication module and a scenario identity registration module, the communication module is configured to obtain scenario identity registration data from a user party from a client component of a client, wherein an identity document associated with a decentralized identity of the user party is stored on an identity chain, the scenario identity registration module is configured to configure scenario information associated with the user party according to the scenario identity registration data, and to configure a scenario identity associated with the scenario of the user party on a scenario chain.

[0006] According to a third aspect of one or more embodiments of the present specification, an account management system is provided, comprising an account management device as described above, a client, and a blockchain storing an identity document associated with a decentralized identity of a user party and a scenario identity. BRIEF DESCRIPTION OF DRAWINGS

[0007] In order to more clearly illustrate the technical solutions in the embodiments of the present specification, the drawings needed to be used in the embodiment description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments described in the present specification, and other drawings can also be obtained by those skilled in the art without creative labor.

[0008] Figure 1 is a schematic diagram of registering a decentralized identity of a user party on an identity chain in an account management method of an embodiment of the present specification;

[0009] Figure 2 is a flowchart of registering a scenario chain associated with a scenario of an operator at a service component in an account management method of an embodiment of the present specification;

[0010] Figure 3 is a flowchart of an account management method of an embodiment of the present specification;

[0011] Figure 4 is a schematic diagram of an account management method in a specific example of the present specification;

[0012] Figure 5 is a schematic diagram of generating a recovery public key and a recovery private key of a user party in an account management method of an embodiment of the present specification;

[0013] Figure 6 is a schematic diagram of generating a recovery public key and a recovery private key of a user party in an account management method of another embodiment of the present specification;

[0014] Figure 7 is a schematic diagram of updating a control public key and a control private key of a user party by using a recovery public key and a recovery private key of the user party in an account management method of an embodiment of the present specification;

[0015] Figure 8 is a schematic diagram of updating a control public key and a control private key of a user party by using a recovery public key and a recovery private key of the user party in an account management method of another embodiment of the present specification;

[0016] Figure 9 is a schematic diagram of an account management device in an embodiment of the present specification;

[0017] Figure 10 is a schematic diagram of an account management system in an embodiment of the present specification. DETAILED DESCRIPTION

[0018] In order for those skilled in the art to better understand the technical solutions in the specification, the technical solutions in the specification will be clearly and completely described below in combination with the drawings in the embodiments of the specification. Obviously, the described embodiments are only some of the embodiments of the specification, not all the embodiments. Based on the embodiments in the specification, all other embodiments obtained by those of ordinary skill in the art without creative labor should belong to the scope of protection of the specification.

[0019] The blockchain is a distributed network data storage technology constructed by using encryption algorithms and point-to-point transmission technology, which has the characteristics of decentralization, tamper resistance, traceability, etc. In the blockchain, data can no longer be stored in a centralized hardware or management agency, but is maintained by blockchain nodes with equal rights and obligations; data can be recorded on multiple nodes of the system constructed by the blockchain technology, and the data stored in the local blockchain of any node can be viewed at any time; once the data is verified and added to the blockchain, it can be permanently stored, and the consensus algorithm and hash chain data storage technology can realize the data tamper resistance, thereby guaranteeing the security and authenticity of the data.

[0020] The trusted execution environment (Trusted Execution Environment, TEE) refers to the secure and trusted area (TrustZone) in the server or client to ensure the security, confidentiality and integrity of the code and data put into it. The trusted execution environment provides an isolated execution environment or an independent small operating system, which directly provides a few services in the form of system calls (directly handled by the TrustZone kernel), the code and data of which can run in the trusted execution environment and can be guaranteed not to be disturbed by the regular operating system during the running process, thereby guaranteeing the confidentiality, integrity and security of the code and data.

[0021] A decentralized identifier service (DIS) based on blockchain technology can provide a user with a decentralized identifier (DID) that is controlled by the user and is not limited by a single registration center, identity service provider or authentication center. However, current DIS systems mainly provide services for business scenarios on the enterprise side (B side), and in most business scenarios, a key escrow method is used to help the client side (C side) or user side manage keys. In this way, in different business scenarios, multiple keys of the same user side are often independent of each other, in other words, the identity of the same user side in different business scenarios is fragmented and cannot be effectively integrated. In addition, the on-chain operation of the user side is usually performed by an upper application proxy, which cannot guarantee that the upper application does not simulate the behavior of the user side to commit fraud, and therefore there is a certain security and compliance risk.

[0022] To solve the above problems, one or more embodiments of the present specification propose an account management method that directly provides an account management service for a user side, which can help the user side safely manage keys, can manage on-chain accounts in various business scenarios in combination with a DIS technology escrow mode, decouples the identity of the user side from the business scenario, and can assist the user side in performing on-chain operations that can guarantee privacy security through a smart contract.

[0023] In the account management method of one or more embodiments of the present specification, information interaction between the client side and the server side is usually involved. The client side can include, for example, a mobile terminal such as a smartphone, tablet computer, smart television, etc. of the user side. The client side can run based on an Android operating system, an IOS operating system or other operating systems, which is not limited here. A first trusted execution environment can be set in the client side for secure storage and calculation, etc., and in addition, a client component outside the first trusted execution environment can also be included in the client side for other storage and calculation. The server side can include a service component that provides corresponding services for the user side, and in addition, one or more blockchains for recording identity information of the user side can also be included in the server side. In addition, in some embodiments, a second trusted execution environment can also be set in the server side, and for example, a blockchain can be stored in the second trusted execution environment to ensure the security of the data. In some embodiments, the client component and the service component can be based on a distributed mobile terminal component service implemented based on a blockchain, which can provide a distributed trusted link to realize the interaction between the mobile terminal and the service of the blockchain.

[0024] In one or more embodiments of the present specification, the account management method can comprise registering a decentralized identity of a user party on an identity chain. Wherein the decentralized identity of the user party can be registered or established independently of a specific business scenario, and accordingly, the identity chain can also exist independently of a specific business scenario, and then the user party can further establish a scenario identity corresponding to each business scenario based on the general decentralized identity.

[0025] In some embodiments, the information contained in the identity account associated with the decentralized identity on the identity chain can include an identity (Identity) and an identity document (Doc) of the user party. Specifically, a blockchain account can be opened on the identity chain, and the blockchain account can be used to perform the on-chain operation of the information. One or more smart contracts can be set under the blockchain account to implement corresponding functions. Among them, the identity account can be an account established under a preset smart contract for recording the information of the user party. The decentralized identity and the public key of the user party can be defined in the identity document of the identity account. The identity document can include one or more public keys, such as one or more control public keys and a recovery public key set by the user party, and the like, which will be described in detail later. In some embodiments, the scenario information (Scence) associated with the user party can also be defined in the identity document, which can specifically indicate the content of the scenario, the blockchain where the scenario is located, and the smart contract related to the scenario, and the like. However, it can be understood that in some embodiments, depending on the user party's willingness and other factors, the scenario information associated with the user party can also not be stored on the blockchain, but can be stored in an off-chain database set independently of the blockchain or stored elsewhere, which is not limited herein. As can be seen, the identity document stored on the identity chain at least includes the decentralized identity and the public key of the user party. In addition, in order to establish the connection between the user party and the business scenario, the user's scenario identity can be recorded in the scenario chain. The scenario identity can exist in the form of a scenario account on the scenario chain, or in the form of identity information bound to the smart contract on the scenario chain. Specifically, in some embodiments, the scenario chain can listen to the DID smart contract on the identity chain. Once the user party gives an instruction to open a certain business scenario (for example, the user can open it by selecting a scenario in the scenario list), the scenario chain corresponding to the business scenario can obtain the DID to be opened from the identity chain and establish a corresponding scenario account on the scenario chain. Similar to the identity account, the scenario account can be established under the smart contract of the scenario chain. In addition, the scenario account can synchronize the required information from the identity document corresponding to the DID, such as the control public key, or other information related to the business scenario can also be recorded in the scenario account. In some embodiments, the scenario identity of the user party recorded on the scenario chain can at least include a scenario identifier for indicating the scenario, a decentralized identity of the user, and at least one public key (including a control public key and a recovery public key, and the like). However, it can be understood that the scenario identity of the user party can also include other contents, as long as the business scenario in which the user party is located, the identity of the user party, and the related information of the user party required to complete the corresponding business activities can be determined through the scenario identity.

[0026] Specifically, as Figure 1As shown, the registration of the decentralized identity of the user party on the identity chain can include:

[0027] At step S101, the service component obtains the identity registration data of the user party from the client component.

[0028] The identity registration data can include identity verification information. In some embodiments, the identity registration data can also include username information (nickname) of the user party on the identity chain, etc. The identity verification information can be used for real person (KYC) authentication of the user party. In some embodiments, the identity verification information can include two-element information (ID number and name). Alternatively, the identity verification information can also include other numbers (such as the passport number, driver's license number, tax number, bank card number, mobile phone number of an individual, the unified social credit code of an enterprise or other organization, etc.) and name information that can uniquely indicate the user party. At the same time, the identity verification information can also include the biometric information of the user party, such as at least one of the face information, fingerprint information, and voice information of the user party.

[0029] Then, the registration of the decentralized identity of the user party on the identity chain can include:

[0030] At step S103, the service component verifies the identity verification information.

[0031] Specifically, the service component can verify the identity verification information provided by the user party through an identity verification platform. The identity verification platform can be set on the identity chain or independently of the identity chain (for example, the identity verification platform can be a centralized identity verification platform set by the public security organ). The service component can transmit the identity verification information to the identity verification platform, and the identity verification platform verifies the identity of the user party according to the identity verification information. In the verification process, the identity verification platform can compare whether the identity verification information provided by the user party matches the pre-stored information, and returns the verification result to the service component.

[0032] Returning to Figure 1 The registration of the decentralized identity of the user party on the identity chain can also include:

[0033] At step S105, when the verification is passed, the service component allocates a decentralized identity for the user party; and

[0034] At step S107, the service component transmits the decentralized identity to the first trusted execution environment.

[0035] The service component allocating a decentralized identity for the user party can include establishing a decentralized identity (DID) associated with the username information for the user party.

[0036] Further, to ensure the user party's decentralized identity is securely transferred from the service component into the first trusted execution environment, the service component transferring the decentralized identity into the first trusted execution environment can include the service component signing the decentralized identity with the service private key to produce second signature data, and the service component transferring the decentralized identity and the second signature data into the first trusted execution environment.

[0037] Accordingly, as shown in FIG. 1, registering the user party's decentralized identity on the identity chain can further include: Figure 1

[0038] Step S109, in the first trusted execution environment, verifying the second signature data with the service public key.

[0039] The service public key and the service private key can be based on an asymmetric encryption algorithm, such as a public key cryptography system (RSA). Verifying information signed by the service private key with the service public key can ensure that the information originates from the expected service component, thereby ensuring security.

[0040] Further, as shown in FIG. 1, registering the user party's decentralized identity on the identity chain can further include: Figure 1

[0041] Step S111, when the verification passes, generating a control public key and a control private key of the user party in the first trusted execution environment;

[0042] Step S113, transferring the decentralized identity and the control public key from the first trusted execution environment to the service component; and

[0043] Step S115, storing the control private key in the first trusted execution environment.

[0044] The control public key and the control private key are also based on an asymmetric encryption algorithm, such as a public key cryptography system (RSA). In various business scenarios, the user party can use its control private key to sign relevant information in the first trusted execution environment, while the counterpart receiving the signature data can use the user party's control public key to verify the signature data in the corresponding business scenario, and update the required information to the identity chain and / or the scenario chain after the verification passes. Since the control private key is generated in the first trusted execution environment of the client and stored in the first trusted execution environment without being leaked outside the first trusted execution environment, the control private key can be well ensured to be used only by the user party itself, thereby ensuring the security of data and business. In a specific example, the control public key and the control private key can be generated based on an elliptic curve signature algorithm, such as using Rl curve. However, it can be understood that other digital signature algorithms can also be used to generate the control public key and the control private key, which are not limited here.​​

[0045] In addition, considering that the control public key is transmitted from the first trusted execution environment to the service component for the first time, when the decentralized identity and the control public key are transmitted to the service component here, the information to be transmitted can not be signed by using the generated control private key, but the control public key is directly transmitted to the service component together with the decentralized identity (or the control public key). However, it can be understood that in other specific examples, the decentralized identity and the control public key (or the control public key) can also be signed by using the private key of the first trusted execution environment in the first trusted execution environment to generate corresponding signature data, and the decentralized identity and the control public key (or the control public key) are transmitted to the service component together with the corresponding signature data, and the service component can verify the signature data by using the received public key of the first trusted execution environment, and perform the subsequent steps after the verification is passed.

[0046] Further, as shown in Figure 1 After the service component obtains the control public key of the user side from the first trusted execution environment, the registration of the decentralized identity of the user side on the identity chain can further include:

[0047] Step S117, the service component configures the identity document associated with the decentralized identity of the user side according to the decentralized identity and the control public key.

[0048] Wherein, the identity document of the user side can be configured based on a preset document format as needed, which is not limited here. As described above, the decentralized identity and the control public key of the user side are included in the identity document.

[0049] Further, as shown in Figure 1 The registration of the decentralized identity of the user side on the identity chain can further include:

[0050] Step S119, the service component registers the decentralized identity of the user side on the identity chain based on the identity document.

[0051] Specifically, the registration of the decentralized identity of the user side can be completed by calling the corresponding smart contract on the identity chain. First, a blockchain account can be opened on the identity chain, and the service component can use the blockchain account to transmit the configured identity document to the corresponding smart contract, so as to register the identity account based on the identity document under the smart contract, thereby realizing the registration of the decentralized identity of the user side on the identity chain.

[0052] As shown in Figure 1As shown, after successfully registering or establishing the user party's decentralized identity on the identity chain, the identity chain can also feed back a success message to the service component, and the service component can further feed back the success message to the client component, so that the user party can know the registration status of its decentralized identity on the client.

[0053] After registering the user party's decentralized identity on the identity chain, the user party can establish its corresponding scenario identity in various specific business scenarios based on the decentralized identity. As a prerequisite, the account management method can also include registering, at the service component, the scenario chain associated with the scenario of the operation party. After pre-registering the scenario chain corresponding to various business scenarios, the service component can help the user party to establish the corresponding scenario identity based on its decentralized identity.

[0054] Specifically, as shown in Figure 2 Registering, at the service component, the scenario chain associated with the scenario of the operation party can include:

[0055] In step S201, the service component acquires scenario registration data from the operation party.

[0056] The scenario registration data can include scenario chain configuration data, smart contract configuration data, and scenario description data of the scenario chain associated with the scenario.

[0057] Then, the service component can perform the operation of initializing the scenario chain according to the scenario chain configuration data, i.e., step S203 shown in Figure 2 According to the scenario chain configuration data, the service component finds the corresponding scenario chain, thereby being able to establish a connection with the scenario chain. In this way, the service component can perform information interaction with the scenario chain. When the connection is successfully established, the scenario chain can transmit a success message to the service component, and the service component can further transmit the success message to the operation party to inform the operation party of the current scenario chain initialization status.

[0058] In addition, as shown in Figure 3 Registering, at the service component, the scenario chain associated with the scenario of the operation party can also include: in step S205, the service component deploys the smart contract of the scenario chain according to the smart contract configuration data. In this way, the service component can instruct the scenario chain to complete the desired operation by calling the corresponding smart contract. Similarly, after completing the deployment of the smart contract, the scenario chain can transmit a success message to the service component, and the service component can further transmit the success message to the operation party to inform the operation party of the current smart contract deployment status.

[0059] After the connection between the service component and the scenario chain is completed and the smart contract is deployed in the service component, step S207 can be performed, in which the service component records at least part of the scenario registration data including scenario description data to establish the scenario. The scenario description data is used to describe or explain the basic information about the scenario. In some embodiments, the recorded part of the scenario registration data can also include a scenario chain identifier for indicating the scenario chain, smart contract information for describing the smart contract, and other extended information, etc. The service component can record the at least part of the scenario registration data on the blockchain, or can also record in an off-chain database, which is not limited herein. Similarly, when the establishment of the scenario is completed, the service component can transmit a success message to the operator to inform the operator of the current scenario establishment status.

[0060] When the registration of the scenario chain is completed at the service component, the user party can select a business scenario desired to join from the scenarios provided by the service component based on the decentralized identity, and complete the registration of the scenario identity on the scenario chain associated with the selected scenario. Specifically, as shown in Figure 3 The account management method can include:

[0061] In step S310, the service component of the service end obtains the scenario identity registration data from the user party from the client component of the client end.

[0062] In some embodiments, the scenario identity registration data can include selected scenario list data configured to indicate one or more scenarios selected by the user party. In a specific example, the user party can select one or more scenarios desired to join from the candidate scenario list data provided by the service component to generate the selected scenario list data. In addition, in some embodiments, the user party can also sign the selected scenario list data to ensure security.

[0063] As shown in Figure 4 The service component of the service end obtaining the scenario identity registration data from the user party from the client component of the client end can specifically include:

[0064] In step S301, the service component actively or based on the request of the client component transmits the candidate scenario list data to the client component;

[0065] In step S303, the client component obtains the selected one or more scenarios from the user party, and configures the selected scenario list data according to the one or more scenarios;

[0066] In step S305, the client component transmits the selected scenario list data to the first trusted execution environment;

[0067] Step S307, in the first trusted execution environment, the selected scene list data is signed by the user-side control private key to generate first signature data;

[0068] Step S309, the first signature data is transmitted from the first trusted execution environment to the client component; and

[0069] Step S311, the client component transmits the selected scene list data and the first signature data to the service component together.

[0070] However, it can be understood that in some other embodiments, the user-side control private key can also be stored in a key escrow end of a third party different from the client and the server. In this case, the selected scene list data can be signed by the user-side control private key in the key escrow end to generate the first signature data.

[0071] Return Figure 3 The account management method can further include:

[0072] Step S330, the service component configures scene information associated with the user side according to the scene identity registration data.

[0073] Specifically, as Figure 4 indicated, the service component configuring scene information associated with the user side according to the scene identity registration data can include:

[0074] Step S313, the service component verifies the first signature data by the user-side control public key.

[0075] Wherein, the control public key and the control private key are matched, and as described above, the control public key can be contained in the identity document of the decentralized identity management of the user side, so that the service component can obtain the control public key of the user side from the identity chain.

[0076] Then, when the verification passes, the service component can update the scene information associated with the user side according to the selected scene list data.

[0077] In some embodiments, the scene information associated with the user side can be contained in the identity document on the identity chain of the user side. Accordingly, as Figure 4 indicated, when the verification passes, the service component updating the scene information associated with the user side according to the selected scene list data can include:

[0078] Step S315, when the verification passes, the service component obtains the identity document associated with the decentralized identity of the user side from the identity chain;

[0079] Step S317, the service component updates the scene information contained in the identity document according to the selected scene list data; and

[0080] Step S319, the service component transmits the updated identity document to the identity chain for storage by the identity chain.

[0081] In addition, after completing the on-chain storage of the identity document, the identity chain can transmit a success message to the service component for feedback.

[0082] However, in other embodiments, the scene information can also not be contained in the identity document for on-chain storage, but be stored in an off-chain database set independently of the identity chain and the scene chain, or stored elsewhere, to better protect the privacy of the user side. In this case, the service component can obtain the scene information from the off-chain database or the like, and return the updated scene information to the off-chain database or the like for storage after completing the update of the scene information.

[0083] As shown in Figure 3 and Figure 4 The account management method can further include:

[0084] Step S350, the service component configures the scene identity associated with the scene of the user side on the scene chain.

[0085] Specifically, in some embodiments, the service component configuring the scene identity associated with the scene of the user side on the scene chain can include the service component establishing a scene account of the user side on the scene chain as the scene identity. The scene account on the scene chain can be similar to the identity account on the identity chain, and the scene account can include a scene identity document, which records information such as scene identification, decentralized identity of the user side, and public key.

[0086] Alternatively, in other embodiments, the service component can bind the identity information of the user side as the scene identity to the smart contract on the scene chain to achieve the configuration of the scene identity associated with the scene of the user side on the scene chain. That is, the operation associated with the scene identity of the user side can be completed by calling the smart contract on the scene chain, without directly establishing an account of the user side on the scene chain.

[0087] As shown in Figure 4 After completing the configuration of the scene identity, the scene chain can also transmit a success message to the service component, and the service component can further transmit the success message to the client component to inform the user side of the configuration status of its scene identity.

[0088] As described above, the identity document of the user party's decentralized identity can be stored on the identity chain, and the scenario identity associated with each business scenario can be established on the corresponding scenario chain. In a specific example, each scenario can correspond to a scenario chain. In another specific example, multiple scenarios can correspond to the same scenario chain. Alternatively, in yet another specific example, one scenario can also correspond to multiple scenario chains. In addition, in some cases, at least part of the scenario chain and the identity chain can be the same blockchain to save blockchain resources. However, it can be understood that the identity chain and the scenario chain can also be respectively set as different blockchains.

[0089] In one or more embodiments of the present specification, in order to facilitate the user party to add or modify the control public key and the control private key (for example, in the case that the user party's client is lost or stolen by others, etc.), the account management method can further include generating a recovery public key and a recovery private key of the user party. Wherein the recovery public key and the recovery private key are matched, for example, the recovery public key and the recovery private key can be based on an asymmetric encryption algorithm, for example, based on a public key cryptography (RSA). In the case that the user party needs to add or modify the control public key and the control private key, the control public key and the control private key can be securely reset based on the recovery public key and the recovery private key.

[0090] In an embodiment, generating the recovery public key and the recovery private key of the user party can include: the service component obtaining the recovery key data of the user party from the client component.

[0091] Wherein, the recovery key data can be used to verify the identity of the user party when the user party requests to add or modify the control public key and the control private key, in other words, the recovery key data can be used to confirm that the party requesting to add or modify the control public key and the control private key is indeed the user party corresponding to the relevant decentralized identity. The user party can set the recovery key data in various ways. For example, in a specific example, the recovery key data can include a recovery question set by the user party and a recovery answer matched with the recovery question. When the user party needs to add or modify the control public key and the control private key, the answer information to the recovery question can be provided, and when the provided answer information is consistent with the pre-stored recovery answer, the identity of the user party can be confirmed, so as to continue the operation of adding or modifying the control public key and the control private key, as will be described in detail later. Alternatively, the user party can also configure the recovery key data in other ways, for example, the user party can include a recovery password in the recovery key data, which is not limited herein.

[0092] To ensure the security of the recovery key data, the user party can also sign the recovery key data with the control private key thereof to generate third signature data, and transmit the recovery key data and the third signature data from the client component to the service component to instruct the service component to generate the recovery public key and the recovery private key. Specifically, as shown in Figure 5 The generating of the recovery public key and the recovery private key of the user party can include:

[0093] At step S401, the client component obtains the recovery key data from the user party, and transmits the recovery key data to the first trusted execution environment.

[0094] At step S403, in the first trusted execution environment, the recovery key data is signed with the control private key of the user party to generate third signature data, and the third signature data is transmitted from the first trusted execution environment to the client component; and

[0095] At step S405, the service component obtains the recovery key data and the third signature data from the client component.

[0096] Further, the generating of the recovery public key and the recovery private key of the user party can also include: the service component generates the recovery public key and the recovery private key of the user party according to the recovery key data.

[0097] Specifically, as shown in Figure 5 The service component generates the recovery public key and the recovery private key of the user party according to the recovery key data can include:

[0098] At step S407, the service component verifies the third signature data with the control public key of the user party; and

[0099] At step S409, when the verification is passed, the service component generates the recovery public key and the recovery private key of the user party.

[0100] In a specific example, the recovery public key and the recovery private key can be generated based on an elliptic curve signature algorithm, for example, using R1 curve. However, it can be understood that other digital signature algorithms can also be used to generate the recovery public key and the recovery private key, which are not limited here.

[0101] Further, the generating of the recovery public key and the recovery private key of the user party can also include:

[0102] At step S411, the service component stores the decentralized identity of the user party and the recovery public key on the identity chain in association.

[0103] In this way, when the user party needs to add or modify the control public key and the control private key, the recovery public key and the recovery private key can be used to ensure the security of the reset control key process, as will be described in detail hereinafter.

[0104] In addition, after the recovery public key and the recovery private key of the user side are successfully generated, the service component can transmit a success message to the client component to inform the user side of the establishment state of the recovery public key and the recovery private key.

[0105] However, in the above embodiment, the recovery public key and the recovery private key are generally generated in the service component, which leads to the possibility of leakage of the recovery private key and thus causes certain security risks. To solve the above problem, in another embodiment of the present specification, a second trusted execution environment can be arranged in the service end, and the recovery public key and the recovery private key are generated in the second trusted execution environment, and the recovery private key is stored on a trusted chain in the second trusted execution environment, so as to improve the security of the recovery key. In some embodiments, the information to be transmitted into the second trusted execution environment can be encrypted by using the chain public key of the trusted chain, and the information is decrypted in the trusted chain by using the chain private key matched with the chain public key, and then the corresponding privacy calculation is performed to ensure security.

[0106] Specifically, generating the recovery public key and the recovery private key of the user side can include: the service component obtaining the recovery key data of the user side from the client component, and transmitting the recovery key data to the trusted chain.

[0107] Similarly, the recovery key data can be used to verify the identity of the user side when the user side requests to add or modify the control public key and the control private key. In a specific example, the recovery key data can include a recovery question set by the user side and a recovery answer matched with the recovery question. Alternatively, the user side can also configure the recovery key data in other ways, which is not limited herein.

[0108] To ensure the security of the recovery key data, the recovery key data can be encrypted by using the chain public key of the trusted chain, and the encrypted recovery key data is signed by using the control private key of the user side to generate fourth signature data, and the encrypted recovery key data and the fourth signature data are transmitted to the service component, and the encrypted recovery key data verified by signature is transmitted to the second trusted execution environment by the service component. Specifically, as shown in Figure 6 Generating the recovery public key and the recovery private key of the user side can include:

[0109] Step S421, the client component obtains the recovery key data from the user side;

[0110] Step S423, the client component obtains the chain public key from the trusted chain;

[0111] Step S425, the client component encrypts the recovery key data by using the chain public key to generate encrypted recovery key data;

[0112] Step S427, the client component transmits the encrypted recovery key data to the first trusted execution environment;

[0113] Step S429, in the first trusted execution environment, the encrypted recovery key data is signed with the control private key of the user side to generate fourth signature data, and the fourth signature data is transmitted from the first trusted execution environment to the client component.

[0114] Correspondingly, as shown in Figure 6 the generation of the recovery public key and the recovery private key of the user side can comprise:

[0115] Step S431, the service component acquires the encrypted recovery key data and the fourth signature data from the client component;

[0116] Step S433, the service component verifies the fourth signature data with the control public key of the user side;

[0117] Step S435, when the verification is passed, the service component transmits the encrypted recovery key data to the trusted chain in the second trusted execution environment on the service side.

[0118] It can be understood that in some other embodiments, the service component can also directly transmit the recovery key data to the trusted chain in the second trusted execution environment on the service side without signing the encrypted recovery key data.

[0119] Further, the generation of the recovery public key and the recovery private key of the user side can also comprise generating the matching recovery public key and the recovery private key of the user side according to the recovery key data in the second trusted execution environment.

[0120] Specifically, as shown in Figure 6 the generation of the matching recovery public key and the recovery private key of the user side according to the recovery key data in the second trusted execution environment can comprise:

[0121] Step S437, in the second trusted execution environment, the encrypted recovery key data is decrypted with the chain private key of the trusted chain to generate the recovery key data; and

[0122] Step S439, in the second trusted execution environment, the matching recovery public key and the recovery private key of the user side are generated according to the recovery key data, and the recovery key data is stored.

[0123] As described above, the recovery public key and the recovery private key are matching, and they can be based on an asymmetric encryption algorithm, for example, based on a public key cryptography system (RSA). In a specific example, the recovery public key and the recovery private key can be generated based on an elliptic curve signature algorithm, for example, generated using R1 curve. However, it can be understood that other digital signature algorithms can also be used to generate the recovery public key and the recovery private key, which are not limited here.

[0124] Further, since the recovery key data used for verifying the identity of the user is transmitted in an encrypted manner, and the decrypted recovery key data is stored in the second trusted execution environment, the security of the recovery key data can be well guaranteed, and it can be avoided that other people outside the user side use the leaked recovery key data to illegally add or modify the control public key and the control private key of the user side.

[0125] Further, as shown in Figure 6 the generating the recovery public key and the recovery private key of the user side can further include:

[0126] At step S441, the service component obtains the recovery public key of the user side from the second trusted execution environment; and

[0127] At step S443, the service component stores the decentralized identity of the user side and the recovery public key in association on the identity chain.

[0128] In this way, when the user side needs to add or modify the control public key and the control private key, the recovery public key and the recovery private key can be used to ensure the security of the process of resetting the control key, as will be described in detail hereinafter.

[0129] In addition, after the recovery public key and the recovery private key of the user side are successfully generated, the service component can transmit a success message to the client component to inform the user side of the establishment state of the recovery public key and the recovery private key.

[0130] In some embodiments of the present specification, in order to save blockchain resources, the trusted chain and the identity chain can be the same blockchain, and are arranged in the second trusted execution environment of the service end. For the blockchain arranged in the second trusted execution environment, it usually uses a secure manner suitable for the trusted execution environment to interact with the outside world as necessary. Accordingly, the identity document stored on the identity chain can have better security. However, it can be understood that in some other embodiments, the trusted chain and the identity chain can also be two different blockchains, wherein the trusted chain at least stores the recovery key data and the recovery private key of the user side, and the identity chain stores the decentralized identity of the user side and the identity document thereof.

[0131] As described above, in one or more embodiments of the present specification, when the control public key and the control private key of the user side are lost, the recovery public key and the recovery private key thereof can be used to securely add or modify the control public key and the control private key. That is, the account management method of one or more embodiments of the present specification can further include updating the control public key and the control private key of the user side by using the recovery public key and the recovery private key of the user side.

[0132] In some embodiments, as Figure 7As shown, updating the control public key and the control private key of the user party with the recovery public key and the recovery private key of the user party can include:

[0133] At step S501, the service component obtains identity verification information from the user party from the client component.

[0134] As mentioned above, the identity verification information can be used for real person (KYC) authentication of the user party. In some embodiments, the identity verification information can include two-factor information (an identity card number and a name). Alternatively, the identity verification information can also include other numbers (e.g., a passport number, a driver's license number, a tax number, a bank card number, a mobile phone number, a unified social credit code of an enterprise or other organization, etc.) and names, etc. that can uniquely indicate the user party. Meanwhile, the identity verification information can also include biometric information of the user party, for example, can include at least one of facial information, fingerprint information, and voice information of the user party.

[0135] Then, as shown in FIG. 5B, the service component can verify the identity verification information. Figure 7 As shown, updating the control public key and the control private key of the user party with the recovery public key and the recovery private key of the user party can include:

[0136] At step S503, the service component verifies the identity verification information.

[0137] Specifically, the service component can verify the identity verification information provided by the user party through an identity verification platform. The identity verification platform can be set on the identity chain or independently of the identity chain (for example, the identity verification platform can be a centralized identity verification platform set by a public security organ). The service component can transmit the identity verification information to the identity verification platform, and the identity verification platform verifies the identity of the user party according to the identity verification information. In the verification process, the identity verification platform can compare whether the identity verification information provided by the user party matches the pre-stored information, and returns the verification result to the service component.

[0138] Further, when the verification is passed, the fifth signature data can be generated by signing the updated control public key of the user party based on the recovery private key of the user party.

[0139] The recovery private key of the user party can be stored in a key escrow end of a third party, and the fifth signature data is generated in the key escrow end.

[0140] In addition, in some embodiments, the hash value of the updated control public key can be signed to generate the fifth signature data. Specifically, as shown in FIG. 5B, when the verification is passed, the fifth signature data can be generated by signing the updated control public key of the user party based on the recovery private key of the user party. Figure 7 As shown, updating the control public key and the control private key of the user party with the recovery public key and the recovery private key of the user party can include:

[0141] Step S505: When the verification is successful, the service component obtains the updated control public key from the client component.

[0142] In step S507, the service component performs a hash calculation on the updated control public key to generate a first hash value;

[0143] Step S509: The service component transmits the first hash value to the key escrow terminal;

[0144] Step S511: In the key escrow terminal, the user's recovery private key is used to sign the first hash value to generate the fifth signature data.

[0145] It is understood that in some other embodiments, the updated control public key can also be directly signed to generate the fifth signature data.

[0146] Then, as Figure 7 As shown, proceeding to step S513, the service component verifies the fifth signature data using the user's recovery public key; and

[0147] In step S515, when the signature verification is successful, the service component updates the identity document associated with the user's decentralized identity to configure the updated control public key in the identity document.

[0148] As described above, the service component can retrieve the user's decentralized identity document from the identity chain, configure the updated control public key in the identity document, and then transmit the updated identity document to the identity chain for on-chain storage. Furthermore, upon successful configuration, the identity chain can transmit a success message to the service component.

[0149] Furthermore, such as Figure 7 As shown, updating the user's control public key and control private key using the user's recovery public key and recovery private key may also include:

[0150] In step S517, the service component updates the user's scenario identity to configure the updated control public key in the scenario identity.

[0151] Specifically, the service component can update the scenario account on the scenario chain, or update the identity information in the smart contract of the scenario chain accordingly.

[0152] In other embodiments, such as Figure 8 As shown, updating the user's control public key and control private key using the user's recovery public key and recovery private key can include:

[0153] Step S521: The service component obtains the identity verification information from the user from the client component.

[0154] As described above, the identity verification information can be used for real person (KYC) authentication of the user party. In some embodiments, the identity verification information can include two-factor information (ID number and name). Alternatively, the identity verification information can also include other numbers (e.g., passport number, driver's license number, tax number, bank card number, mobile phone number, unified social credit code of an enterprise or other organization, etc.) and name information that can uniquely indicate the user party. At the same time, the identity verification information can also include the biometric information of the user party, for example, can include at least one of the facial information, fingerprint information and voice information of the user party.

[0155] Then, go to step S523, the service component verifies the identity verification information.

[0156] Specifically, the service component can verify the identity verification information provided by the user party through the identity verification platform. The identity verification platform can be set on the identity chain or independently of the identity chain (for example, the identity verification platform can be a centralized identity verification platform set by the public security organ). The service component can transmit the identity verification information to the identity verification platform, and the identity verification platform verifies the identity of the user party according to the identity verification information. In the verification process, the identity verification platform can compare whether the identity verification information provided by the user party matches the pre-stored information, and return the verification result to the service component.

[0157] Further, updating the control public key and the control private key of the user party by using the recovery public key and the recovery private key of the user party can include:

[0158] Step S525, when the verification is passed, the service component obtains the recovery question in the recovery key data set by the user party from the trusted chain; and

[0159] Step S527, the service component transmits the decentralized identity of the user party and the recovery question to the client component.

[0160] Wherein, the trusted chain is stored and run in the second trusted execution environment of the service end. The client component can present the recovery question to the user party, and obtain the answer information from the user party (step S529).

[0161] Then, continue to step S531, the client component transmits the answer information to the first trusted execution environment;

[0162] Step S533, in the first trusted execution environment, an updated control public key and an updated control private key are generated, and the updated control private key is stored in the first trusted execution environment; and

[0163] Step S535, the user's decentralized identity, the answer information, and the updated control public key are included in the first key update data and transmitted to the service component.

[0164] In some embodiments, the first key update data can also be signed by the updated control private key in the first trusted execution environment, and the signature data is transmitted to the service component together with the first key update data. When the service component receives the first key update data and the corresponding signature data, the signature data can be verified by the updated control public key, and then subsequent operations are performed.

[0165] When the service component obtains the first key update data from the client, the second key update data generated based on the first key update data can be transmitted to the trusted chain so that the trusted chain verifies the identity of the user side. In some embodiments, the second key update data can include the user's decentralized identity, the answer information to the recovery question, and a second hash value generated by hashing the updated control public key.

[0166] Return Figure 8 The updated control public key and control private key of the user side by using the recovery public key and the recovery private key of the user side can include:

[0167] Step S537, the service component calculates the updated control public key to generate a second hash value; and

[0168] Step S539, the service component includes the user's decentralized identity, the answer information, and the second hash value in the second key update data and transmits them to the trusted chain.

[0169] However, it can be understood that in some embodiments, the first key update data can also be directly transmitted to the trusted chain as the second key update data so that the trusted chain verifies the identity of the user side. The specific verification process can include:

[0170] Step S541, in the second trusted execution environment, the answer information is compared with the recovery answer in the recovery key data;

[0171] Step S543, when the answer information is consistent with the recovery answer, the second hash value is signed by the recovery private key of the user side to generate sixth signature data; and

[0172] Step S545, the sixth signature data is transmitted from the second trusted execution environment to the service component.

[0173] When the service component obtains the sixth signature data from the second trusted execution environment, it can continue to step S547, the service component verifies the sixth signature data by using the recovery public key of the user side; and

[0174] Step S549, when the signature verification passes, the service component updates the identity document associated with the user party's decentralized identity to configure the updated control public key in the identity document.

[0175] As described above, the service component can obtain the identity document of the user party's decentralized identity from the identity chain, and configure the updated control public key in the identity document, and then transmit the updated identity document to the identity chain for on-chain storage. In addition, after the configuration succeeds, the identity chain can transmit a success message to the service component.

[0176] Further, as shown in Figure 8 configuring the user party's control public key and control private key using the user party's recovery public key and recovery private key can further include:

[0177] Step S517, the service component updates the user party's scenario identity to configure the updated control public key in the scenario identity.

[0178] Specifically, the service component can update the scenario account on the scenario chain, or make corresponding updates to the identity information in the smart contract of the scenario chain.

[0179] In addition, after the configuration succeeds, the scenario chain can transmit a success message to the service component, and the service component further transmits the success message to the client component.

[0180] The account management method of one or more embodiments of the present specification can assist C-end users in managing scenario identities and corresponding on-chain assets in various scenarios. Specifically, based on the trusted execution environment technology, the security of the private key stored therein can be guaranteed. In addition, a decentralized identity system is constructed based on a blockchain, and the identity information is decoupled from specific business scenarios, which can greatly facilitate users in managing their identity information. For example, in the case of adding a business scenario, the business scenario can be extended by adding a scenario chain, simplifying the scenario adding process.

[0181] One or more embodiments of the present specification also provide an account management device, as shown in Figure 9 The account management device can include a communication module 910 and a scenario identity registration module 920. The communication module 910 can be configured to obtain scenario identity registration data from a user party from a client component of a client, and the scenario identity registration module 920 can be configured to configure scenario information associated with the user party according to the scenario identity registration data, and configure the user party's scenario identity associated with the scenario on the scenario chain.

[0182] Further, the account management device can further comprise one or more of a scenario chain registration module 930 configured to register a scenario chain of the scenario associated with the operator, an identity registration module 940 configured to register the decentralized identity of the user party on the identity chain, a recovery key module 950 configured to generate a recovery public key and a recovery private key of the user party, and a key update module 960 configured to update the control public key and the control private key of the user party with the recovery public key and the recovery private key of the user party, for performing the corresponding steps in the account management method as above.

[0183] One or more embodiments of the present specification also provide an account management system, as shown in Figure 10 The account management system can comprise one or more account management devices 900, the client 800 and a blockchain 700 storing the identity document and the scenario identity associated with the decentralized identity of the user party as described above. The blockchain 700 can provide a decentralized identity service to achieve distributed account management, which can be one or more of the identity chain, the scenario chain and the trust chain as described above.

[0184] In the 1990s, it was relatively easy to distinguish whether an improvement in a technology was a hardware improvement (e.g., an improvement in the circuit structure of a diode, transistor, switch, etc.) or a software improvement (an improvement in a method flow). However, as technology has evolved, many improvements in method flows today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flows into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using hardware entity modules. For example, a programmable logic device (PLD) (e.g., a field programmable gate array (FPGA)) is an integrated circuit whose logic function is determined by the user programming the device. A digital system is "integrated" on a PLD by the designer programming it him or herself, without having to ask a chip manufacturer to design and manufacture a custom integrated circuit chip. Moreover, instead of manually fabricating integrated circuit chips, this programming is now mostly implemented using "logic compiler" software, which is similar to the software compiler used when developing programs, and the original code to be compiled is also written in a specific programming language, which is called a hardware description language (HDL), and there are many such languages, 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, RHDL (Ruby Hardware Description Language), etc., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, as long as the method flow is logically programmed using the above-mentioned hardware description languages and programmed into an integrated circuit, a hardware circuit implementing the logical method flow can be easily obtained.

[0185] The controller can be implemented in any suitable way, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code, such as software or firmware, executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. The skilled person will also appreciate that, in addition to implementing the controller in pure computer readable program code, it is possible to implement the controller in the form of logic gates, switches, an application specific integrated circuit, a programmable logic controller and an embedded microcontroller, etc. to perform the same functions by logically programming the method steps. Such a controller can therefore be considered to be a hardware component, and the means included therein to perform the various functions can also be considered to be structures within the hardware component. Alternatively, or even additionally, the means to perform the various functions can be considered to be both a software module implementing the method and a structure within a hardware component.

[0186] The systems, apparatuses, modules or units illustrated by the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not rule out that with the development of future computer technologies, computers implementing the functions of the above embodiments can be personal computers, laptop computers, vehicle human-computer interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or combinations of any of these devices.

[0187] Although the method operations of the embodiments of the present specification are described in sequential order, some of the operations can in practical implementations be performed concurrently, in parallel, or in a different order. The above description of the embodiments of the present specification is provided as an example only and is not intended to be limiting. For example, the steps recited in the examples or flow charts can include more, fewer, or different steps than those described. The order in which the steps are presented is merely one example and is not intended to be limiting. The steps can be performed in an order different than presented, or performed in parallel, or in a different order, for example in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment. The terms "comprise", "comprising", or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Exclusion of such elements is only present if it is expressly stated that these elements are excluded. For example, use of the terms "first", "second", or the like does not denote any order or importance, but rather the terms are used to distinguish one element from another.

[0188] For ease of description, the above apparatuses are described in various modules with different functions. Of course, when implementing one or more of the present specification, the functions of the modules can be implemented in one or more software and / or hardware, or the modules implementing the same function can be implemented by a combination of sub-modules or sub-units. The above-described apparatus embodiments are only illustrative, for example, the division of the units is only a logical function division, and in actual implementation, another division mode can be used, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed each other can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0189] The present application is described with reference to flowcharts and / or block diagrams of methods, apparatus (system) and computer program products according to embodiments of the application. It should be understood that each flow and / or block 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 apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus produce a means for implementing the functions specified in the flowcharts and / or block diagrams. These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing apparatus to work in a specific manner, so that the instructions stored in the computer-readable memory produce a product of manufacture that includes an article of manufacture that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The apparatus implementing the functions of one or more flows and / or blocks Figure 1 The apparatus implementing the functions of one or more flows and / or blocks

[0190] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0191] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the Figure 1 function specified in the flow or flows and / or blocks Figure 1 Figure 1 of the block or blocks.

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

[0193] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory. The memory is an example of computer-readable media.

[0194] Computer-readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as 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 tapes, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to computing devices. According to the definition herein, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

[0195] Those skilled in the art will appreciate that the one or more embodiments described herein can be provided as a method, a system or a computer program product. Accordingly, the one or more embodiments described herein can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the one or more embodiments described herein can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable code.

[0196] The one or more embodiments described herein can be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The one or more embodiments described herein can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.

[0197] The various embodiments described in this specification are described in the context of progressive embodiments, with each embodiment building on the previous one. The same or similar parts between embodiments are cross-referenced as appropriate. Each embodiment focuses on the differences between that embodiment and the previous one. In particular, the system embodiments are described relatively simply, as they are substantially similar to the method embodiments. In the description of the specification, the use of the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" means that the particular feature, structure, material or characteristic being described is included in at least one embodiment or example of the specification. Illustrative descriptions of the above terms do not necessarily refer to the same embodiment or example in this specification. Furthermore, the particular features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples. Moreover, the skilled person can combine and combine the features of different embodiments or examples and characteristics of different embodiments or examples, without contradiction.

[0198] The above description merely provides examples of the one or more embodiments described in this specification and does not limit the one or more embodiments described in this specification. The one or more embodiments described in this specification can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the one or more embodiments described in this specification should be included in the scope of the claims.

Claims

1. An account management method comprising: obtaining, by a service component of a service end, from a client component of a client end, scenario identity registration data from a user party, wherein an identity document associated with a decentralized identity of the user party is stored on an identity chain, the scenario identity registration data comprising selected scenario list data configured to indicate one or more scenarios selected by the user party from candidate scenario list data and first signature data generated by signing the selected scenario list data with a control private key of the user party, scenario information associated with the user party being included in the identity document associated with the decentralized identity of the user party; configuring, by the service component, scenario information associated with the user party according to the scenario identity registration data, comprising: verifying, by the service component, the first signature data with the control public key of the user party, when the verification passes, obtaining, by the service component, the identity document associated with the decentralized identity of the user party from the identity chain, updating, by the service component, the scenario information included in the identity document according to the selected scenario list data, and transmitting, by the service component, the updated identity document to the identity chain for storage, wherein the control public key matches the control private key and the control public key is included in the identity document associated with the decentralized identity of the user party; and configuring, by the service component, a scenario-associated scenario identity of the user party on a scenario chain associated with a scenario, wherein the identity chain and the scenario chain are different blockchains.

2. The account management method according to claim 1, wherein The candidate scenario list data is transmitted by the service component to the client component.

3. The account management method according to claim 1, wherein The control private key is stored in a first trusted execution environment of the client end, and the first signature data is generated by signing the selected scenario list data with the control private key in the first trusted execution environment.

4. The account management method according to claim 1, wherein The control private key is stored in a key escrow end different from the client end and the service end.

5. The account management method according to claim 1, wherein The service component configuring the scenario-associated scenario identity of the user party on the scenario chain comprises: establishing, by the service component, a scenario account of the user party on the scenario chain as the scenario identity.

6. The account management method according to claim 1, wherein The service component configuring the scenario-associated scenario identity of the user party on the scenario chain comprises: binding, by the service component, identity information of the user party as the scenario identity to a smart contract on the scenario chain.

7. The account management method of claim 1, further comprising: registering, at the service component, a scenario chain associated with a scenario of an operator party.

8. The account management method according to claim 7, wherein Registering, at the service component, the scenario chain associated with the scenario of the operator party comprises: obtaining, by the service component, scenario registration data from the operator party, wherein the scenario registration data comprises scenario chain configuration data of the scenario chain associated with the scenario, smart contract configuration data, and scenario description data; establishing, by the service component, a connection between the service component and the scenario chain according to the scenario chain configuration data; and registering, at the service component, the scenario chain associated with the scenario of the operator party. deploying, by the service component, smart contracts of the scenario chain according to the smart contract configuration data; and recording, by the service component, at least part of scenario registration data including the scenario description data to establish a scenario. 9.The account management method of claim 1, further comprising: registering, on the identity chain, a decentralized identity of the user party.

10. The account management method according to claim 9, wherein Registering, on the identity chain, a decentralized identity of the user party includes: obtaining, by the service component, identity registration data of the user party from the client component, wherein the identity registration data includes identity verification information; verifying, by the service component, the identity verification information; when the verification is passed, assigning, by the service component, a decentralized identity to the user party and transmitting the decentralized identity to the first trusted execution environment; obtaining, by the service component, a control public key of the user party from the first trusted execution environment; configuring, by the service component, an identity document associated with the decentralized identity of the user party according to the decentralized identity and the control public key; and registering, by the service component, the decentralized identity of the user party on the identity chain based on the identity document.

11. The account management method according to claim 10, wherein The identity verification information includes two-factor information and biological identity information.

12. The account management method according to claim 10, wherein The identity registration data further includes username information. When the verification is passed, assigning, by the service component, a decentralized identity to the user party includes: establishing, by the service component, a decentralized identity associated with the username information for the user party.

13. The account management method of claim 10, wherein, Transmitting, by the service component, the decentralized identity to the first trusted execution environment includes: signing, by the service component, the decentralized identity with a service private key to generate second signature data, and transmitting, by the service component, the decentralized identity and the second signature data to the first trusted execution environment.

14. The account management method according to claim 13, wherein Registering, on the identity chain, a decentralized identity of the user party further includes: verifying, in the first trusted execution environment, the second signature data with a service public key, wherein the service public key matches the service private key; when the verification is passed, generating, in the first trusted execution environment, a control public key and a control private key of the user party, wherein the control public key matches the control private key; and transmitting the decentralized identity and the control public key from the first trusted execution environment to the service component, and storing the control private key in the first trusted execution environment. 15.The account management method of claim 1, further comprising: generating a recovery public key and a recovery private key of the user party, wherein the recovery public key matches the recovery private key.

16. The account management method according to claim 15, wherein Generating a recovery public key and a recovery private key of the user party includes: obtaining, by the service component, recovery key data of the user party from the client component; generating, by the service component, a recovery public key and a recovery private key of the user party according to the recovery key data; and storing, by the service component, the decentralized identity of the user party and the recovery public key on the identity chain in association.

17. The account management method of claim 16, wherein, Generating a recovery public key and a recovery private key of the user party further includes: The client component obtains recovery key data from the user party and transmits the recovery key data to the first trusted execution environment; In the first trusted execution environment, the recovery key data is signed with a control private key of the user party to generate third signature data, and the third signature data is transmitted from the first trusted execution environment to the client component.

18. The account management method of claim 17, wherein, The service component generates the recovery public key and the recovery private key of the user party according to the recovery key data, including: The service component verifies the third signature data with the control public key of the user party; and When the verification is passed, the service component generates the recovery public key and the recovery private key of the user party.

19. The account management method of claim 15, wherein, The service component generates the recovery public key and the recovery private key of the user party, including: The service component obtains the recovery key data of the user party from the client component and transmits the recovery key data to a trusted chain, wherein the trusted chain is stored and run in a second trusted execution environment of the service end; In the second trusted execution environment, the recovery public key and the recovery private key of the user party are generated according to the recovery key data, wherein the recovery private key is stored in the second trusted execution environment; The service component obtains the recovery public key of the user party from the second trusted execution environment; and The service component stores the decentralized identity and the recovery public key of the user party on the identity chain in association.

20. The account management method according to claim 19, wherein, The service component generates the recovery public key and the recovery private key of the user party, including: The client component obtains the recovery key data from the user party and the chain public key of the trusted chain; The client component encrypts the recovery key data with the chain public key to generate encrypted recovery key data, and transmits the encrypted recovery key data to the first trusted execution environment; In the first trusted execution environment, the encrypted recovery key data is signed with a control private key of the user party to generate fourth signature data, and the fourth signature data is transmitted from the first trusted execution environment to the client component.

21. The account management method according to claim 20, wherein The service component obtains the recovery key data of the user party from the client component and transmits the recovery key data to a trusted chain, including: The service component verifies the fourth signature data with the control public key of the user party; and When the verification is passed, the service component transmits the encrypted recovery key data to the trusted chain.

22. The account management method of claim 21, wherein, In the second trusted execution environment, the recovery public key and the recovery private key of the user party are generated according to the recovery key data, including: In the second trusted execution environment, the encrypted recovery key data is decrypted with a chain private key of the trusted chain to generate the recovery key data, wherein the chain public key matches the chain private key; and In the second trusted execution environment, the recovery public key and the recovery private key of the user party are generated according to the recovery key data, and the recovery key data is stored.

23. The account management method of claim 19, wherein, The trusted chain and the identity chain are the same blockchain.

24. The account management method according to claim 16 or 19, wherein, The recovery key data includes a recovery question set by the user party and a recovery answer matching the recovery question.

25. The account management method of claim 15, further comprising: updating the control public key and the control private key of the user party with the recovery public key and the recovery private key of the user party.

26. The account management method of claim 25, wherein, updating the control public key and the control private key of the user party with the recovery public key and the recovery private key of the user party comprises: the service component obtaining identity verification information of the user party from the client component; the service component verifying the identity verification information; when the verification passes, signing based on the updated control public key of the user party with the recovery private key of the user party to generate fifth signature data; the service component verifying the fifth signature data with the recovery public key of the user party; and when the verification passes, the service component updating an identity document associated with the decentralized identity of the user party to configure the updated control public key in the identity document.

27. The account management method of claim 26, wherein, when the verification passes, signing based on the updated control public key of the user party with the recovery private key of the user party to generate fifth signature data comprises: when the verification passes, the service component obtaining the updated control public key of the user party from the client component; the service component hashing the updated control public key to generate a first hash value; the service component transmitting the first hash value to a key escrow end; and in the key escrow end, signing the first hash value with the recovery private key of the user party to generate the fifth signature data.

28. The account management method of claim 25, wherein, updating the control public key and the control private key of the user party with the recovery public key and the recovery private key of the user party comprises: the service component obtaining identity verification information of the user party from the client component; the service component verifying the identity verification information; when the verification passes, the service component obtaining a recovery question in the recovery key data set by the user party from a trusted chain, and transmitting the decentralized identity of the user party and the recovery question to the client component, wherein the trusted chain is stored and run in a second trusted execution environment of the service end; the service component obtaining first key update data from the client, wherein the first key update data includes the decentralized identity of the user party, answer information to the recovery question, and the updated control public key; the service component transmitting second key update data generated based on the first key update data to the trusted chain; the service component obtaining sixth signature data generated by signing at least part of the second key update data with the recovery private key of the user party from the trusted chain; the service component verifying the sixth signature data with the recovery public key of the user party; and when the verification passes, the service component updating an identity document associated with the decentralized identity of the user party to configure the updated control public key in the identity document.

29. The account management method of claim 28, wherein, The second key update data includes a decentralized identity of the user party, answer information for the recovery question, and a second hash value generated by hashing the updated control public key.

30. The account management method according to claim 29, wherein Updating the control public key and the control private key of the user party with the recovery public key and the recovery private key of the user party further includes: in the second trusted execution environment, comparing the answer information with a recovery answer in the recovery key data; when the answer information is consistent with the recovery answer, signing the second hash value with the recovery private key of the user party to generate sixth signature data; and transmitting the sixth signature data from the second trusted execution environment to the service component.

31. The account management method of claim 28, wherein, Updating the control public key and the control private key of the user party with the recovery public key and the recovery private key of the user party further includes: The client component obtains answer information from the user party; and in the first trusted execution environment, generating an updated control public key and an updated control private key, and transmitting the updated control public key from the first trusted execution environment to the service component, and saving the updated control private key in the first trusted execution environment.

32. The account management method of claim 24, wherein, Updating the control public key and the control private key of the user party with the recovery public key and the recovery private key of the user party further includes: The service component updates the scenario identity of the user party to configure the updated control public key in the scenario identity.

33. An account management device, comprising: a communication module configured to obtain, from a client component of a client, scenario identity registration data of a user party, wherein an identity document associated with a decentralized identity of the user party is stored on an identity chain, the scenario identity registration data includes selected scenario list data and first signature data, the selected scenario list data is configured to indicate one or more scenarios selected by the user party from candidate scenario list data, the first signature data is generated by signing the selected scenario list data with a control private key of the user party, and scenario information associated with the user party is included in the identity document associated with the decentralized identity of the user party; and a scenario identity registration module configured to configure, according to the scenario identity registration data, scenario information associated with the user party, and configure a scenario identity associated with a scenario of the user party on a scenario chain associated with the scenario, wherein configuring, according to the scenario identity registration data, scenario information associated with the user party includes verifying the first signature data with the control public key of the user party, when the verification passes, obtaining the identity document associated with the decentralized identity of the user party from the identity chain, updating the scenario information included in the identity document according to the selected scenario list data, and transmitting the updated identity document to the identity chain for storage by the identity chain, wherein the control public key matches the control private key, and the control public key is included in the identity document associated with the decentralized identity of the user party.

34. The account management device of claim 33, further comprising: a scenario chain registration module configured to register a scenario chain of the operator associated with a scenario.

35. The account management device of claim 33, further comprising: an identity registration module configured to register a decentralized identity of the user party on the identity chain.

36. The account management device of claim 33, further comprising: a recovery key module configured to generate a recovery public key and a recovery private key of the user party, wherein the recovery public key matches the recovery private key.

37. The account management device of claim 36, further comprising: a key update module configured to update a control public key and a control private key of the user party with the recovery public key and the recovery private key of the user party.

38. An account management system, comprising: the account management device of any one of claims 33 to 37; a client; and a blockchain storing an identity document and a scenario identity associated with a decentralized identity of a user party. ​

Images