CN116260648A

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

Info

Publication number: CN116260648A
Application number: CN202310245619.8A
Authority: CN
Inventors: 陈远; 李书博; 孙善禄; 代平
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2023-03-14
Filing date: 2023-03-14
Publication date: 2023-06-13

Abstract

The embodiment of the specification provides an account management method, account management equipment and an account management system. The account management method comprises the following steps: the method comprises the steps that a service component of a service end obtains scene identity registration data from a client component of a client; the service component configures scene information associated with the user side according to the scene identity registration data; and the service component configures a scenario identity of the user party associated with the scenario on the scenario chain.

Description

Account management method, account management device and account management system

Technical Field

The embodiment of the specification belongs to the technical field of blockchains, and particularly relates to an account management method, account management equipment and an account management system.

Background

With the continuous development of the digitizing process, more and more business scenarios are developed to provide corresponding services for the user side. Typically, the user side needs to establish his identity or account under each service scenario, and the operator of the service scenario may manage the identities or accounts of all its users in a centralized manner. This will result in the same user party often being split between multiple identities or accounts in multiple business scenarios, which is difficult to integrate effectively. In addition, since the upper layer application of the operator is generally used for proxy to perform the specific operation of the user side, a certain security risk is also brought. Thus, there is a need for an improved way of managing the identity or account of a user in multiple business scenarios.

Disclosure of Invention

An objective of one or more embodiments of the present disclosure is to provide an account management method, an account management device, and an account management system, so as to integrate identities of users in different business scenarios, and implement distributed account management to ensure account security.

According to a first aspect of one or more embodiments of the present specification, there is provided an account management method, comprising: the method comprises the steps that a service component of a service side obtains scene identity registration data from a client component of a client side, wherein an identity document associated with a decentralised identity of the client side is stored on an identity chain; the service component configures scene information associated with the user side according to the scene identity registration data; and the service component configures a scenario identity of the user party associated with the scenario on the scenario chain.

According to a second aspect of one or more embodiments of the present specification, there is provided an account management device comprising a communication module configured to obtain context identity registration data from a user side from a client component of a client, wherein an identity document associated with a de-centralised identity of the user side is stored on an identity chain, and a context identity registration module configured to configure context information associated with the user side in accordance with the context identity registration data, and to configure context identities associated with a context of the user side on the context chain.

According to a third aspect of one or more embodiments of the present specification, there is provided an account management system comprising an account management device as described above, a client, and a blockchain storing identity documents and scene identities associated with a de-centralised identity of a user side.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings that are needed in the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a decentralised identity of a registered user party on a chain of identities in an account management method of one embodiment of the present disclosure;

FIG. 2 is a flow diagram of a scenario chain associated with a scenario for registering an operator at a service component in an account management method according to an embodiment of the present disclosure;

FIG. 3 is a flow chart of an account management method according to an embodiment of the present disclosure;

FIG. 4 is a schematic diagram of an account management method in a specific example of the present disclosure;

FIG. 5 is a schematic diagram of generating a recovery public key and a recovery private key for a user side in an account management method according to an embodiment of the present disclosure;

FIG. 6 is a schematic diagram of generating a recovery public key and a recovery private key for a user side in an account management method according to another embodiment of the present disclosure;

FIG. 7 is a schematic diagram of updating a control public key and a control private key of a user side with a recovery public key and a recovery private key of the user side in an account management method according to an embodiment of the present disclosure;

FIG. 8 is a schematic diagram of updating a control public key and a control private key of a user side with a recovery public key and a recovery private key of the user side in an account management method according to another embodiment of the present disclosure;

FIG. 9 is a schematic diagram of an account management device in an embodiment of the present disclosure;

FIG. 10 is a schematic diagram of an account management system in one embodiment of the present disclosure.

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

The blockchain is a distributed network data storage technology constructed by utilizing an encryption algorithm and a point-to-point transmission technology, and has the characteristics of decentralization, tamper resistance, traceability and the like. In a blockchain, data may no longer be stored in a centralized hardware or administrative authority, but rather maintained together by blockchain nodes that are entitlement and obligation peers; data can be recorded on a plurality of nodes of a system constructed by a blockchain technology, so that the data stored in a local blockchain of any node can be checked at any time; once the data is verified and added to the blockchain, the data can be permanently stored, and the data cannot be tampered by utilizing a consensus algorithm and a hash chain type data storage technology, so that the safety and the authenticity of the data are ensured.

The trusted execution environment (Trusted Execution Environment, TEE) refers to a secure trusted area (trust zone) in a server or client to ensure the security, confidentiality and integrity of code and data placed therein. The trusted execution environment provides an isolated execution environment or independently running small operating system which directly provides a few services in a system call (directly processed by a trust zone kernel), codes and data of the small operating system can run in the trusted execution environment, and the small operating system can not be interfered by a conventional operating system in the running process, so that confidentiality, integrity and safety of the codes and the data are guaranteed.

The blockchain technology based de-centralized identity service (Decentralized Identifier Service, DIS) may provide users with self-controlled de-centralized identities (DID) that are not limited by a single registry, identity facilitator, or authentication center. However, current DIS systems mainly serve business scenarios at the enterprise end (B-end), in most of which a key escrow approach is used to help the client (C-end) or user side manage keys. Thus, multiple keys of the same user side are often independent from each other between different traffic scenarios, in other words, identities of the same user side in different traffic scenarios are split from each other, and are difficult to be effectively integrated. Furthermore, the on-chain operations on the user side are typically performed by the upper layer application proxy, which cannot guarantee that the upper layer application does not simulate the behavior of the user side for disfigurement, and thus there is a certain security compliance risk.

In order to solve the above-mentioned problems, one or more embodiments of the present disclosure provide an account management method for directly providing an account management service for a user, where the account management method can help the user to safely manage a key, can combine a hosting mode of DIS technology to uniformly manage on-chain accounts under each service scenario, so that identities of the user are decoupled from the service scenario, and can assist the user in performing on-chain operations capable of guaranteeing privacy security through an intelligent contract.

In the account management method of one or more embodiments of the present specification, information interaction between a client and a server is generally involved. The client may include a mobile terminal such as a smart phone, a tablet computer, a smart television of a user. The client may run based on an android operating system, an IOS operating system, or other operating systems, without limitation. The first trusted execution environment may be provided in the client for secure storage and computation, etc., and further a client component provided outside the first trusted execution environment may be included in the client for other storage and computation. The service end can comprise a service component for providing corresponding service for the user side, and the service end can further comprise one or more blockchains for recording the identity information of the user side. In addition, in some embodiments, a second trusted execution environment may also be set in the server, and a blockchain or the like may be stored in the second trusted execution environment, so as to ensure the security of the data. In some embodiments, the client component and the service component may be based on a distributed mobile on-terminal component service implemented in a blockchain, which may provide a distributed trusted link to enable interactions between the mobile and the blockchain service.

In one or more embodiments herein, an account management method may include registering a user's de-centralized identity on an identity chain. The user side's decentralised identity may be registered or established independently of a specific service scenario, and accordingly, an identity chain may also exist independently of a specific service scenario, and then the user side may further establish a scenario identity corresponding to each service scenario based on the general decentralised identity.

In some embodiments, the information contained in the Identity account associated with the off-center avatar on the Identity chain may include the Identity of the user (Identity) and the Identity document (Doc). Specifically, a blockchain account may be opened on the identity chain with which a blockchain operation of the information may be performed. One or more intelligent contracts may be placed under the blockchain account for implementing the corresponding functions. The identity account may be an account established under a preset smart contract for recording information of the user side. The user-side decentralized identity and public key may be defined in an identity document of an identity account. The identity document may include one or more public keys, including, for example, one or more control public keys set by the user, and a recovery public key, etc., as will be described in detail below. In some embodiments, scene information (scene) of a business scene associated with the user side may also be defined in the identity document, and may specifically indicate content of the scene, a blockchain in which the scene is located, and a smart contract related to the scene, etc. However, it will be appreciated that in some embodiments, the context information associated with the user side may not be stored on the blockchain, depending on factors such as the user side's intent, but rather may be stored in an off-chain database that is separate from the blockchain setting or elsewhere, without limitation. It follows that in the identity document stored on the identity chain, at least the user-side de-centralized identity and the public key are included. In addition, in order to establish a connection between the user side and the service scenario, the scenario identity of the user may be recorded in the scenario chain. The scene identity may exist in the form of a scene account on the scene chain or in the form of identity information in an intelligent contract bound to the scene chain. In particular, in some embodiments, the scenario chain may snoop the DID smart contracts on the identity chain. Once the user side gives an instruction that a certain service scene needs to be opened (for example, the user can select a scene in the scene list to be opened), the scene chain corresponding to the service scene can acquire the DID of the service scene to be opened from the identity chain, and a corresponding scene account is established on the scene chain. Similar to the identity account, the scenario account may be under a smart contract established under a scenario chain. In addition, the scene account may synchronize necessary information, such as a synchronization control public key, etc., from an identity document corresponding to the DID, or other information related to the business scene may be additionally recorded in the scene account. In some embodiments, the scene identity of the user party recorded on the scene chain may include at least a scene identification indicating the scene, a decentralised identity of the user, and at least one public key (including a control public key and a recovery public key, etc.). However, it is understood that other contents may be included in the scene identity of the user side, as long as the service scene in which the user side is located, the identity of the user side, and related information of the user side required for completing the corresponding service activity can be determined by the scene identity.

In particular, as shown in FIG. 1, registering a user's side's de-centralized identity on a chain of identities may include:

in step S101, the service component obtains identity registration data of the user side from the client component.

Wherein the identity registration data may include identity verification information. In some embodiments, the identity registration data may also include user name information (nickname) of the user party on the identity chain, and the like. Identity verification information may be used to authenticate the user party to the real person (KYC). In some embodiments, the identity verification information may include two-element information (identification card number and name). Alternatively, the identity verification information may include information such as other numbers (e.g., passport numbers, driver license numbers, tax numbers, bank card numbers, cell phone numbers, uniform social credit codes of organizations such as businesses, etc.) and names that can uniquely indicate the user side. Meanwhile, the identity verification information may further include biometric information of the user side, for example, may include at least one of facial information, fingerprint information, and sound information of the user side.

Registering the user-side's decentralized identity on the identity chain may then include:

step S103, the service component verifies the identity verification information.

In particular, the service component may verify identity verification information provided by the user party through an identity verification platform. The identity verification platform may be provided on the identity chain or separately from the identity chain (e.g., the identity verification platform may be a centralized identity verification platform provided by a public security authority). 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 side 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 side is matched with the pre-stored information or not, and returns a verification result to the service component.

Returning to fig. 1, registering the decentralised identity of the user party on the identity chain may further comprise:

step S105, when the verification is passed, the service component distributes the decentralised identity for the user side; and

in step S107, the service component transmits the decentralized identity to the first trusted execution environment.

Wherein the service component assigning the user-side a de-centralized identity may include establishing a de-centralized identity (DID) associated with the username information for the user-side.

In addition, to ensure that the user-side off-centered identity is securely transferred from the service component to the first trusted execution environment, the service component transferring the off-centered identity to the first trusted execution environment may include the service component signing the off-centered identity with the service private key to generate second signed data, and the service component transferring the off-centered identity and the second signed data to the first trusted execution environment.

Accordingly, as shown in fig. 1, registering the decentralized identity of the user party on the identity chain may further comprise:

in step S109, in the first trusted execution environment, the second signature data is signed with the service public key.

Wherein the service public key and the service private key may be based on asymmetric encryption algorithms, e.g. based on the public key cryptosystem (RSA). The information signed by the service private key is checked by the service public key, so that the information can be ensured to be sourced from the expected service component, and the safety is ensured.

Further, as shown in fig. 1, registering the decentralized identity of the user party on the identity chain may further comprise:

step S111, when the signature verification passes, a control public key and a control private key of a user side are generated in a first trusted execution environment;

step S113, transmitting the decentralised identity and the control public key from the first trusted execution environment to the service component; and

step S115, storing the control private key in the first trusted execution environment.

Wherein the control public key and the control private key are also based on asymmetric encryption algorithms, e.g. on public key cryptosystem (RSA). In various service scenarios, a user may sign related information in a first trusted execution environment by using a control private key thereof, while an opposite party receiving signature data may use a control public key of the user side to sign the signature data in a corresponding service scenario, and update required information into an identity chain and/or a scene chain after the sign verification is passed. Because the control private key is generated in the first trusted execution environment of the client and is stored in the first trusted execution environment without leaking outside the first trusted execution environment, the control private key can be well ensured to be used by the user, and the safety of data and business is further ensured. In a specific example, the control public key and the control private key may be generated based on an elliptic curve signature algorithm, e.g., using an R1 curve. However, it will be appreciated that other digital signature algorithms may be employed to generate the control public key and the control private key, without limitation.

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, the generated control private key may not be used to sign the information to be transmitted, but the control public key may be directly transmitted to the service component together with the decentralized identity (or the control public key). However, it will be appreciated that in other specific examples, the decentralized identity and control public key (or control public key) may be signed in the first trusted execution environment using the private key of the first trusted execution environment to generate corresponding signature data, and the decentralized identity and control public key (or control public key) may be transmitted to the service component along with the corresponding signature data, and the service component may verify the signature data using the received public key of the first trusted execution environment and perform subsequent steps after the verification passes.

Further, as shown in fig. 1, after the service component obtains the control public key of the user side from the first trusted execution environment, registering the decentralized identity of the user side on the identity chain may further include:

In step S117, the service component configures an identity document associated with the user-side decentralized identity according to the decentralized identity and the control public key.

The identity document of the user side can be configured based on a preset document format according to requirements, and the method is not limited herein. As described above, at least the user-side de-centralized identity and control public key are included in the identity document.

in step S119, the service component registers the user' S de-centralized identity on the identity chain based on the identity document.

In particular, registration of the user-side de-centralized identity may be accomplished by invoking a corresponding intelligent contract on the identity chain. Firstly, a blockchain account can be opened on an identity chain, and a service component can utilize the blockchain account to transmit the configured identity document to a corresponding intelligent contract so as to register the identity account based on the identity document under the intelligent contract, thereby realizing the decentralization identity of a registered user side on the identity chain.

As shown in fig. 1, after the user side's decentralised identity is successfully registered or established on the identity chain, the identity chain may also feed back a success message to the service component, which may further feed back a success message to the client component, so that the user side knows the registration of its decentralised identity on the client.

After registering the user's decentralised identity on the identity chain, the user may establish their corresponding scenario identities under various specific business scenarios based on the decentralised identity. As a precondition, the account management method may further comprise registering, at the service component, a scenario chain of the operator associated with the scenario. After preregistering the context chains corresponding to the various business contexts, the service component can assist the user-side in establishing the corresponding context identities based on their decentralised identities.

In particular, as shown in fig. 2, registering an operator's scenario chain associated with a scenario at a service component may include:

in step S201, the service component acquires scene registration data from the operator.

The context registration data may include context chain configuration data, smart contract configuration data, and context description data for a context chain associated with the context.

The service component may then perform an operation of initializing the scene chain according to the scene chain configuration data, i.e. step S203 shown in fig. 2, and find a corresponding scene chain according to the scene chain configuration data, so that a connection with the scene chain can be established. In this way, the service component can interact with information between the scene chain. When the connection is established successfully, the context chain may transmit a success message to the service component, and the service component may further transmit a success message to the operator to inform the operator of the current context chain initialization state.

Furthermore, as shown in fig. 3, registering the scenario chain of the operator associated with the scenario at the service component may further comprise: in step S205, the service component deploys the smart contracts of the scene chain according to the smart contract configuration data. In this way, the service component can instruct the scene chain to complete the desired operation by invoking the corresponding smart contract. Similarly, after deployment of the smart contract is completed, the scenario chain may transmit a success message to the service component, and the service component may further transmit the success message to the operator to inform the operator of the current smart contract deployment status.

After completing the connection between the service component and the scene chain and deploying the smart contract in the service component, step S207 may be performed, the service component recording at least part of the scene registration data including the scene description data to establish the scene. Wherein the scene description data is used for describing or illustrating relevant basic information of the scene. In some embodiments, the recorded partial scene registration data may also include scene chain identifications for indicating scene chains, smart contract information for describing smart contracts, and other extension information, etc. The service component can record at least some of the scene registration data described above on the blockchain or in an off-chain database, without limitation. Similarly, upon completion of the establishment of the scenario, the service component may transmit a success message to the operator informing the operator of the current scenario establishment status.

Upon completion of registration of the scene chain at the service component, the user may select a desired joining business scene from the scenes provided by the service component based on the de-centralized identity and complete registration of the scene identity on the scene chain associated with the selected scene. Specifically, as shown in fig. 3, the account management method may include:

in step S310, the service component of the server obtains scene identity registration data from the user side from the client component of the client.

In some embodiments, the scene identity registration data may include selected scene list data configured to indicate one or more scenes selected by the user. In a particular example, a user may select one or more scenes that they desire to join from candidate scene list data provided by a service component to produce selected scene list data. In addition, in some embodiments, the user side may also sign the selected scene list data to ensure security.

As shown in fig. 4, the service component of the server side obtains scene identity registration data from the user side from the client component of the client side specifically may include:

step S301, the service component actively or based on the request of the client component transmits the candidate scene list data to the client component;

Step S303, the client component obtains the selected one or more scenes from the user side and configures selected scene list data according to the one or more scenes;

step S305, the client component transmits the selected scene list data to the first trusted execution environment;

step S307, in the first trusted execution environment, signing the selected scene list data by using the control private key of the user side to generate first signature data;

step S309, transmitting the first signature data from the first trusted execution environment to the client component; and

in step S311, the client component transmits the selected scene list data to the service component together with the first signature data.

However, it will be appreciated that in other embodiments, the control private key of the user side may also be stored in a key holder end of a third party other than the client and the server. In this case, the selected scene list data may be signed in the key holder end with the control private key of the user side to generate the first signature data.

Returning to fig. 3, the account management method may further include:

in step S330, the service component configures context information associated with the user side according to the context identity registration data.

In particular, as shown in fig. 4, the service component, according to the context identity registration data, configuring context information associated with the user side may include:

in step S313, the service component signs the first signature data with the control public key of the user side.

Wherein the control public key and the control private key are matched and, as described above, the control public key may be included in an identity document managed with the user's de-centralized identity, so that the service component may obtain the user's control public key from the identity chain.

Then, when the check-out passes, the service component may update the context information associated with the user-side according to the selected context list data.

In some embodiments, the context information associated with the user-side may be contained in an identity document on the identity chain of the user-side. Accordingly, as shown in fig. 4, when the verification passes, the service component updating the context information associated with the user party according to the selected context list data may include:

step S315, when the verification passes, the service component acquires an identity document associated with the decentralised identity of the user side from the identity chain;

step S317, the service component updates scene information contained in the identity document according to the selected scene list data; and

In step S319, the service component transmits the updated identity document to the identity chain for storage by the identity chain.

In addition, after completion of the uplink storage of the identity document, the identity chain may transmit a success message to the service component for feedback.

However, in other embodiments, the context information may not be included in the identity document for uplink storage, but rather may be stored in an under-chain database that is separate from the identity chain and context chain settings or elsewhere to better protect the privacy of the user side. In this case, the service component may obtain the context information from the in-chain database or the like and return the updated context information to the in-chain database or the like for storage after the update of the context information is completed.

As shown in fig. 3 and 4, the account management method may further include:

in step S350, the service component configures a scene identity associated with the scene for the user on the scene chain.

In particular, in some embodiments, the service component configuring the context identity of the user party associated with the context on the context chain may include the service component establishing a context account of the user party as the context identity on the context chain. The scene accounts on the scene chain may be similar to the identity accounts on the identity chain, and the scene accounts may include scene identity documents in which information such as scene identification, user side de-centralized identity, and public key is recorded.

Alternatively, in other embodiments, the service component may bind the identity information of the user side as a scene identity into an intelligent contract on the scene chain to enable configuration of the scene identity of the user side associated with the scene on the scene chain. That is, operations associated with the user's scene identity may be accomplished by invoking an intelligent contract on the scene chain, without establishing the user's account directly on the scene chain.

As shown in fig. 4, after completing the configuration of the scene identity, the scene chain may further transmit a success message to the service component, and the service component may further transmit the success message to the client component, so as to inform the user of the configuration status of the scene identity.

As described above, the identity document of the user-side de-centralized identity may be stored on an identity chain, while the scenario identities associated with the respective business scenarios may be established on the respective scenario chain. In a particular example, each scene may correspond to a chain of scenes. In another specific example, multiple scenes may correspond to the same scene chain. Alternatively, in yet another specific example, one scene may also correspond to a plurality of scene chains. Additionally, in some cases, at least a portion of the scene chain and the identity chain may be the same blockchain to conserve blockchain resources. However, it is understood that the identity chain and the scene chain may also be set as different blockchains, respectively.

In one or more embodiments herein, to facilitate the user side to add or modify the control public key and the control private key (e.g., in the event that the user side's client is lost or stolen by others, etc.), the account management method may further include generating a recovery public key and a recovery private key for the user side. Wherein the recovery public key and the recovery private key are matched, e.g. the recovery public key and the recovery private key may be based on an asymmetric encryption algorithm, e.g. on the public key cryptosystem (RSA). In the case where the user side needs to newly 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 restoration public key and the restoration private key.

In one embodiment, generating the recovery public key and the recovery private key for the user side may include: the service component obtains recovery key data for the user side from the client component.

The recovery key data may be used to verify the identity of the user when the user requests to add or modify the control public key and the control private key, in other words, the recovery key data may be used to confirm that the party requesting to add or modify the control public key and the control private key is the user corresponding to the associated decentralised identity. The user side can set the recovery key data in various ways. For example, in a specific example, the recovery key data may include a recovery question set by the user side and a recovery answer matching the recovery question. When the user side needs to newly add or modify the control public key and the control private key, answer information for the restoration question may be provided, and when the provided answer information is consistent with a restoration answer stored in advance, the identity of the user side may be confirmed, thereby continuing the operation of newly adding or modifying the control public key and the control private key, as will be described in detail later. Alternatively, the user side may configure the recovery key data in other manners, for example, the user side may include a recovery password or the like in the recovery key data, which is not limited herein.

In order to ensure the security of the recovery key data, the user side may also use the control private key to sign the recovery key data to generate third signature data, and transmit the recovery key data and the third signature data together from the client component to the service component, so as to instruct the service component to generate the recovery public key and the recovery private key. Specifically, as shown in fig. 5, generating the recovery public key and the recovery private key of the user side may include:

step S401, the client component acquires the recovery key data from the user side and transmits the recovery key data to the first trusted execution environment;

step S403, in the first trusted execution environment, signing the recovery key data with the control private key of the user side to generate third signature data, and transmitting the third signature data from the first trusted execution environment to the client component; and

in step S405, the service component acquires the recovery key data and the third signature data from the client component.

Further, generating the recovery public key and the recovery private key of the user side may further include: the service component generates a recovery public key and a recovery private key of the user side according to the recovery key data.

Specifically, as shown in fig. 5, the service component generating the recovery public key and the recovery private key of the user side according to the recovery key data may include:

Step S407, the service component performs signature verification on the third signature data by using the control public key of the user side; and

in step S409, when the verification passes, the service component generates a recovery public key and a recovery private key of the user side.

In a specific example, the recovery public key and the recovery private key may be generated based on an elliptic curve signature algorithm, e.g., using an R1 curve. However, it will be appreciated that other digital signature algorithms may be employed to generate the recovery public key and the recovery private key, without limitation.

Further, generating the recovery public key and the recovery private key of the user side may further include:

in step S411, the service component stores the user side' S de-centralized identity and the recovery public key in association on the identity chain.

In this way, when the user side needs to newly add or modify the control public key and the control private key, the restoration public key and the restoration private key can be employed to secure the process of resetting the control key, as will be described in detail later.

In addition, when the recovery public key and the recovery private key of the user side are successfully generated, the service component may transmit a success message to the client component to inform the user side of the establishment states of the recovery public key and the recovery private key.

However, in the above embodiment, the recovery public key and the recovery private key are generally generated in the service component, which causes a certain security risk that the recovery private key may be compromised. In order to solve the above-mentioned problem, in another embodiment of the present disclosure, a second trusted execution environment may be set in the server, and a recovery public key and a recovery private key may be generated in the second trusted execution environment, and the recovery private key may be stored in a trusted chain in the second trusted execution environment, so as to improve security of the recovery key. In some embodiments, the information to be transferred into the second trusted execution environment may be encrypted using a chain public key of the trusted chain, decrypted using a chain private key that matches the chain public key in the trusted chain, and then subjected to a corresponding privacy calculation to ensure security.

Specifically, generating the recovery public key and the recovery private key of the user side may include: the service component obtains the recovery key data of the user side from the client component and transmits the recovery key data to the trusted chain.

Similarly, the recovery key data may be used to verify the identity of the user side when the user side requests a new or modified control public key and control private key. In a specific example, the recovery key data may include a recovery question set by the user side and a recovery answer matching the recovery question. Alternatively, the user side may configure the recovery key data in other ways, without limitation.

In order to ensure the security of the recovery key data, the recovery key data can be encrypted by using a chain public key of a trusted chain, the encrypted recovery key data is signed by using a control private key of a user side to generate fourth signature data, the encrypted recovery key data and the fourth signature data are transmitted to a service component together, and the service component transmits the encrypted recovery key data which passes through the verification sign to a second trusted execution environment. Specifically, as shown in fig. 6, generating the recovery public key and the recovery private key of the user side may include:

step S421, the client component obtains the recovery key data from the user side;

step S423, the client component obtains a chain public key from the trusted chain;

step S425, the client component encrypts the recovery key data with the chain public key to produce encrypted recovery key data;

step S427, the client component transmits the encrypted recovery key data to the first trusted execution environment;

in 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 signed data, and the fourth signed data is transferred from the first trusted execution environment to the client component.

Accordingly, as shown in fig. 6, generating the recovery public key and the recovery private key of the user side may include:

step S431, the service component obtains the encrypted recovery key data and the fourth signature data from the client component;

step S433, the service component performs signature verification on the fourth signature data by using the control public key of the user side;

in step S435, when the verification passes, the service component transmits the encrypted recovery key data to the trusted chain.

It will be appreciated that in other embodiments, the service component may also directly transfer the recovery key data to a trusted chain in the second trusted execution environment at the server without signing the encrypted recovery key data.

Further, generating the recovery public key and the recovery private key of the user side may also include generating, in the second trusted execution environment, the matched recovery public key and recovery private key of the user side from the recovery key data.

Specifically, as shown in fig. 6, in the second trusted execution environment, generating the matched recovery public key and recovery private key of the user side according to the recovery key data may include:

step S437, in the second trusted execution environment, decrypting the encrypted recovery key data with the chain private key of the trusted chain to generate recovery key data; and

In step S439, in the second trusted execution environment, the matched recovery public key and recovery private key of the user side are generated according to the recovery key data, and the recovery key data is stored.

As described above, the recovery public key and the recovery private key are matched, and they may be based on an asymmetric encryption algorithm, for example, on the public key cryptosystem (RSA). In a specific example, the recovery public key and the recovery private key may be generated based on an elliptic curve signature algorithm, e.g., using an R1 curve. However, it will be appreciated that other digital signature algorithms may be employed to generate the recovery public key and the recovery private key, as is not limited in this regard.

In addition, since the recovery key data 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 ensured, and illegal addition or modification of the control public key and the control private key of the user side by other people except the user side by using the leaked recovery key data is avoided.

Further, as shown in fig. 6, generating the recovery public key and the recovery private key of the user side may further include:

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

In step S443, the service component stores the user-side decentralized identity and the recovery public key in association on the identity chain.

In some embodiments of the present description, to conserve blockchain resources, the trusted chain and the identity chain may be the same blockchain and disposed in a second trusted execution environment of the server. For blockchains disposed in a second trusted execution environment, it is common to interact with the outside world in a secure manner appropriate for the trusted execution environment. Accordingly, the identity document stored on the identity chain may have better security. However, it will be appreciated that in other embodiments, the trusted chain and the identity chain may be two different blockchains, with at least the recovery key data and the recovery private key of the user side stored on the trusted chain and the de-centralized identity of the user side and its identity document stored on the identity chain.

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 control public key and the control private key can be securely newly added or modified by using the restoration public key and the restoration private key thereof. That is, the account management method of one or more embodiments of the present specification may further include updating the control public key and the control private key of the user side with the restoration public key and the restoration private key of the user side.

In some embodiments, as shown in fig. 7, updating the control public key and the control private key of the user side with the recovery public key and the recovery private key of the user side may include:

in step S501, the service component obtains identity verification information from the user side from the client component.

As described above, identity verification information may be used to authenticate the user party to the real person (KYC). In some embodiments, the identity verification information may include two-element information (identification card number and name). Alternatively, the identity verification information may include information such as other numbers (e.g., passport numbers, driver license numbers, tax numbers, bank card numbers, cell phone numbers, uniform social credit codes of organizations such as businesses, etc.) and names that can uniquely indicate the user side. Meanwhile, the identity verification information may further include biometric information of the user side, for example, may include at least one of facial information, fingerprint information, and sound information of the user side.

Then, as shown in fig. 7, updating the control public key and the control private key of the user side with the recovery public key and the recovery private key of the user side may include:

in step S503, the service component verifies the identity verification information.

Further, when the verification passes, the restoration private key of the user side may be used to sign based on the updated control public key of the user side to generate fifth signature data.

Wherein the recovery private key of the user side may be stored in a key escrow tube end of the third party and the fifth signature data is generated in the key escrow tube end.

Further, in some embodiments, the hash value of the updated control public key may be signed to produce fifth signed data. Specifically, as shown in fig. 7, when the verification passes, signing with the recovery private key of the user side based on the updated control public key of the user side to generate fifth signature data may include:

step S505, when the verification is passed, the service component obtains the updated control public key of the user side from the client component;

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

step S509, the service component transmits the first hash value to the key holder end;

in step S511, in the key holder end, the first hash value is signed with the recovery private key of the user side to generate fifth signature data.

It will be appreciated that in other embodiments, the updated control public key may also be directly signed to produce fifth signed data.

Then, as shown in fig. 7, continuing to step S513, the service component signs the fifth signature data with the restoration public key of the user side; and

in step S515, when the verification passes, the service component updates the identity document associated with the user-side de-centralized identity to configure the updated control public key in the identity document.

As described above, the service component may obtain an identity document of the user's de-centralized identity 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 storage in the chain. Furthermore, after the configuration is successful, the identity chain may transmit a success message to the service component.

Further, as shown in fig. 7, updating the control public key and the control private key of the user side with the recovery public key and the recovery private key of the user side may further include:

in step S517, the service component updates the scene identity of the user party to configure the updated control public key in the scene identity.

In particular, the service component may update a scenario account on a scenario chain or correspondingly update identity information in an intelligent contract of a scenario chain.

In other embodiments, as shown in fig. 8, updating the control public key and the control private key of the user side with the recovery public key and the recovery private key of the user side may include:

in step S521, the service component obtains identity verification information from the user side from the client component.

Then, proceeding to step S523, the service component verifies the identity verification information.

Further, updating the control public key and the control private key of the user side with the recovery public key and the recovery private key of the user side may include:

step S525, when the verification is passed, the service component acquires the recovery problem in the recovery key data set by the user side from the trusted chain; and

in step S527, the service component transmits the user-side decentralized identity and recovery question to the client component.

The trusted chain is stored and operated in a second trusted execution environment of the server. The client component may present the recovery question to the user party and obtain answer information from the user party (step S529).

Then, continuing to step S531, the client component transmits the answer information to the first trusted execution environment;

step S533, in the first trusted execution environment, generating an updated control public key and an updated control private key, wherein the updated control private key is stored in the first trusted execution environment; and

in step S535, the decentralised identity of the user party, the answer information, and the updated control public key are included in the first key update data and transmitted to the service component.

In some embodiments, the first key update data may also be signed with the updated control private key in the first trusted execution environment and transmitted to the service component along 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 checked by using the updated control public key, and then subsequent operations are performed.

After the service component obtains the first key update data from the client, second key update data generated based on the first key update data may be transmitted to the trusted chain so that the trusted chain verifies the identity of the user. In some embodiments, the second key update data may include a decentralised identity of the user party, answer information for the recovery question, and a second hash value resulting from a hash calculation of the updated control public key.

Returning to fig. 8, updating the control public key and the control private key of the user side with the recovery public key and the recovery private key of the user side may include:

step S537, the service component calculates the updated control public key to generate a second hash value; and

in step S539, the service component includes the decentralised identity of the user party, the answer information and the second hash value in the second key update data for transmission to the trusted chain.

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

step S541, in the second trusted execution environment, comparing the answer information with the recovered answer in the recovered key data;

step S543, when the answer information is consistent with the recovered answer, the second hash value is signed by the recovered private key of the user side to generate sixth signature data; and

in step S545, the sixth signed data is transferred from the second trusted execution environment to the service component.

After the service component obtains the sixth signature data from the second trusted execution environment, the process may continue to step S547, where the service component performs signature verification on the sixth signature data using the recovery public key of the user side; and

In step S549, when the verification passes, the service component updates the identity document associated with the off-center avatar of the user party to configure the updated control public key in the identity document.

Further, as shown in fig. 8, updating the control public key and the control private key of the user side with the recovery public key and the recovery private key of the user side may further include:

In addition, after the configuration is successful, the scenario chain may transmit a success message to the service component, which further transmits the success message to the client component.

The account management method of one or more embodiments of the present description can assist the C-terminal user in managing the scene identity and corresponding on-chain assets in each scene. Specifically, based on the trusted execution environment technology, the security of the private key stored therein can be ensured. In addition, a decentralization identity system is constructed based on the blockchain, and the identity information is decoupled from a specific service scene, so that the user can manage the identity information conveniently. For example, in the case of a newly added service scenario, the service scenario may be extended by a newly added scenario chain, simplifying the newly added scenario flow.

One or more embodiments of the present specification also provide an account management apparatus, as shown in fig. 9, which may include a communication module 910 and a scene identity registration module 920. Wherein the communication module 910 may be configured to obtain context identity registration data from a client component of the client, the context identity registration module 920 may be configured to configure context information associated with the user based on the context identity registration data, and to configure context identities associated with the context of the user on a context chain.

In addition, the account management device may further comprise one or more of a context chain registration module 930 configured to register a context chain of the operator's associated context, an identity registration module 940 configured to register a de-centralized identity of the user's 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's party, and a key update module 960 configured to update a control public key and a control private key of the user's party with the recovery public key and the recovery private key of the user's party for performing the respective steps in the account management method as above.

One or more embodiments of the present specification also provide an account management system, as shown in FIG. 10, that may include one or more account management devices 900, clients 800, and blockchains 700 storing identity documents and scene identities associated with a user-side de-centralized identity, as described above. The blockchain 700 may provide an off-center avatar service to enable distributed account management, which may be one or more of the identity chain, scene chain, and trusted chain described above.

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the user programming the device. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, 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., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, 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 may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation device is a server system. Of course, the present application does not exclude that as future computer technology evolves, the computer implementing the functions of the above-described embodiments may be, for example, a personal computer, a laptop computer, a car-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by the figures. The terms "comprises," "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 may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.

For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other forms.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may 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 instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may 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 functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of the present description 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-ROM, optical storage, etc.) having computer-usable program code embodied therein.

One or more embodiments of the present specification may 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. One or more embodiments of the present specification may 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 may be located in both local and remote computer storage media including memory storage devices.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present specification. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.

The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in the scope of the claims.

Claims

1. An account management method, comprising:

the method comprises the steps that a service component of a service side obtains scene identity registration data from a client component of a client side, wherein an identity document associated with a decentralised identity of the client side is stored on an identity chain;

the service component configures scene information associated with the user side according to the scene identity registration data; and

the service component configures a context identity associated with a context for the user-side on a context chain.

2. The account management method of claim 1, wherein the scene identity registration data includes selected scene list data configured to indicate one or more scenes selected by the user party from candidate scene list data.

3. The account management method of claim 2 wherein the candidate scene list data is transmitted by the service component to the customer component.

4. The account management method of claim 2, wherein the scene identity registration data further comprises first signature data generated by signing the selected scene list data with a control private key of the user side.

5. The account management method of claim 4 wherein the control private key is stored in a first trusted execution environment of the client and the selected scene list data is signed with the control private key in the first trusted execution environment to generate the first signature data.

6. The account management method of claim 4, wherein the control private key is stored in a different key holder end than the client and the server.

7. The account management method of claim 4, wherein the service component configuring context information associated with the user party according to the context identity registration data comprises:

the service component signs the first signature data with a control public key of the user side, wherein the control public key is matched with the control private key and is contained in an identity document associated with the decentralized identity of the user side; and

When a check passes, the service component updates context information associated with the user party according to the selected context list data.

8. The account management method of claim 7, wherein the context information associated with the user-side is contained in an identity document associated with the user-side's de-centralized identity;

when the check-out passes, the service component updating context information associated with the user party according to the selected context list data comprises:

when the verification passes, the service component acquires an identity document associated with the decentralised identity of the user side from the identity chain; and

the service component updates the context information contained in the identity document according to the selected context list data and transmits the updated identity document to the identity chain for storage by the identity chain.

9. The account management method of claim 7, wherein the context information associated with the user side is stored in an under-chain database that is set independently of the identity chain and the context chain.

10. The account management method of claim 1, wherein the service component configuring the scene identity of the user party associated with a scene on a scene chain comprises:

The service component establishes a scene account of the user party on the scene chain as the scene identity.

11. The account management method of claim 1, wherein the service component configuring the scene identity of the user party associated with a scene on a scene chain comprises:

the service component binds the identity information of the user side as the scene identity into an intelligent contract on the scene chain.

12. The account management method of claim 1, wherein the identity chain and the scene chain are the same blockchain.

13. The account management method of claim 1, wherein the identity chain and the scene chain are different blockchains.

14. The account management method of claim 1, further comprising:

a scenario chain of an operator associated with a scenario is registered at the service component.

15. The account management method of claim 14 wherein registering, at the service component, a context chain of an operator associated with a context comprises:

the service component obtains scene registration data from the operator, wherein the scene registration data comprises scene chain configuration data, intelligent contract configuration data and scene description data of a scene chain associated with a scene;

The service component establishes connection with the scene chain according to the scene chain configuration data;

the service component deploys intelligent contracts of the scene chain according to the intelligent contract configuration data; and

the service component records at least part of the scene registration data including the scene description data to establish a scene.

16. The account management method of claim 1, further comprising:

registering the user-side de-centralized identity on the identity chain.

17. The account management method of claim 16 wherein registering the user-side off-center avatar on the identity chain comprises:

the service component obtains identity registration data of the user side from the client component, wherein the identity registration data comprises identity verification information;

the service component verifies the identity verification information;

when verification is passed, the service component distributes a decentralised identity to the user side and transmits the decentralised identity to the first trusted execution environment;

the service component obtains a control public key of the user side from the first trusted execution environment;

The service component configures an identity document associated with the user side decentralized identity according to the decentralized identity and the control public key; and

the service component registers the user-side de-centralized identity on the identity chain based on the identity document.

18. The account management method according to claim 17, wherein the identity verification information includes two-element information and biometric information.

19. The account management method of claim 17 wherein the identity registration data further includes username information;

when the verification is passed, the service component assigns a decentralised identity to the user party comprising:

the service component establishes a de-centralized identity for the user party that is associated with the username information.

20. The account management method of claim 17 wherein the service component transmitting the de-centralized identity into the first trusted execution environment comprises:

the service component signs the off-center avatar with a service private key to generate second signed data, and

the service component transmits the de-centralized identity and the second signature data into the first trusted execution environment.

21. The account management method of claim 20 wherein registering the user-side de-centralized identity on the identity chain further comprises:

in the first trusted execution environment, signing the second signature data by using a service public key, wherein the service public key is matched with the service private key;

when the signature verification passes, a control public key and a control private key of the user side are generated in the first trusted execution environment, wherein the control public key is matched with 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.

22. The account management method of claim 1, further comprising:

and generating a recovery public key and a recovery private key of the user side, wherein the recovery public key is matched with the recovery private key.

23. The account management method of claim 22, wherein generating the recovery public key and recovery private key for the user side comprises:

the service component obtains recovery key data of the user side from the client component;

The service component generates a recovery public key and a recovery private key of the user side according to the recovery secret key data; and

the service component stores the user-side de-centralized identity and the recovery public key in association on the identity chain.

24. The account management method of claim 23 wherein generating the user-side recovery public key and recovery private key further comprises:

the client component obtains recovery key data from the user side and transmits the recovery key data to the first trusted execution environment;

in the first trusted execution environment, signing the recovery key data with a control private key of the user side to generate third signature data, and transmitting the third signature data from the first trusted execution environment to the client component.

25. The account management method of claim 24, wherein the service component generating the user-side recovery public key and recovery private key from the recovery key data comprises:

the service component performs signature verification on the third signature data by using a control public key of the user side; and

when the verification passes, the service component generates a recovery public key and a recovery private key of the user side.

26. The account management method of claim 22, wherein generating the recovery public key and recovery private key for the user side comprises:

the service component acquires the recovery key data of the user side from the client component and transmits the recovery key data to a trusted chain, wherein the trusted chain is stored and operated in a second trusted execution environment of the service side;

generating a recovery public key and a recovery private key of the user side according to the recovery key data in the second trusted execution environment, wherein the recovery private key is stored in the second trusted execution environment;

the service component obtains a recovery public key of the user side from the second trusted execution environment; and

the service component stores the user-side de-centralized identity and a recovery public key in association on the identity chain.

27. The account management method of claim 26 wherein generating the user-side recovery public key and recovery private key further comprises:

the client component obtains recovery key data from the user side and a chain public key of the trusted chain;

the client component encrypting the recovery key data with the chain public key to produce encrypted recovery key data and transmitting the encrypted recovery key data to the first trusted execution environment;

In the first trusted execution environment, signing the encrypted recovery key data with a control private key of the user side to generate fourth signature data, and transmitting the fourth signature data from the first trusted execution environment to the client component.

28. The account management method of claim 27 wherein the service component obtaining recovery key data for the user side from the client component and transmitting the recovery key data to a trusted chain comprises:

the service component performs signature verification on the fourth signature data by using a control public key of the user side; and

when the verification passes, the service component transmits the encrypted recovery key data to the trusted chain.

29. The account management method of claim 28, wherein generating, in the second trusted execution environment, the recovery public key and recovery private key for the user party from the recovery key data comprises:

decrypting, in the second trusted execution environment, the encrypted recovery key data with a chain private key of the trusted chain to produce the recovery key data, wherein the chain public key matches the chain private key; and

And in the second trusted execution environment, generating a recovery public key and a recovery private key of the user side according to the recovery key data, and storing the recovery key data.

30. The account management method of claim 26 wherein the trusted chain is the same blockchain as the identity chain.

31. An account management method according to claim 23 or 26, wherein the recovery key data includes a recovery question set by a user side and a recovery answer matching the recovery question.

32. The account management method of claim 22, further comprising:

and 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.

33. The account management method of claim 32, wherein updating the control public key and control private key of the user party with the recovery public key and recovery private key of the user party comprises:

the service component obtains identity verification information of the user side from the client component;

the service component verifies the identity verification information;

when verification passes, signing with the recovery private key of the user side based on the updated control public key of the user side to generate fifth signature data;

The service component performs signature verification on the fifth signature data by using a recovery public key of the user side; and

when the verification passes, the service component updates an identity document associated with the user-side de-centralized identity to configure an updated control public key in the identity document.

34. The account management method of claim 33 wherein signing with the recovery private key of the user party based on the updated control public key of the user party to produce fifth signature data when verification passes comprises:

when verification passes, the service component obtains an updated control public key of the user side from the client component;

the service component performs hash calculation on the updated control public key to generate a first hash value;

the service component transmits the first hash value to a key holder end; and

in the key-holder end, the first hash value is signed with a recovery private key of the user side to produce the fifth signed data.

35. The account management method of claim 32, wherein updating the control public key and control private key of the user party with the recovery public key and recovery private key of the user party comprises:

the service component verifies the identity verification information;

when the verification is passed, the service component acquires a recovery problem in recovery key data set by the user side from a trusted chain, and transmits the decentralised identity of the user side and the recovery problem to the client component, wherein the trusted chain is stored and operated in a second trusted execution environment of the service side;

the service component obtains first key update data from the client, wherein the first key update data comprises a decentralised identity of the user side, answer information for the recovery question and an 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 obtains sixth signature data from the trusted chain generated by signing at least a portion of the second key update data with a recovery private key of the user side;

the service component performs signature verification on the sixth signature data by using a recovery public key of the user side; and

When the verification passes, the service component updates an identity document associated with the user-side off-center avatar to configure an updated control public key in the identity document.

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

37. The account management method of claim 36, wherein updating the control public key and control private key of the user side with the recovery public key and recovery private key of the user side further comprises:

comparing the answer information with the recovery answer in the recovery key data in the second trusted execution environment;

when the answer information is consistent with the recovery answer, signing the second hash value by using a recovery private key of the user side so as to generate sixth signature data; and

transmitting the sixth signature data from the second trusted execution environment to the service component.

38. The account management method of claim 35, wherein updating the control public key and control private key of the user side with the recovery public key and recovery private key of the user side further comprises:

The client component obtains answer information from the user side; and

in the first trusted execution environment, an updated control public key and an updated control private key are generated, the updated control public key is transmitted from the first trusted execution environment to the service component, and the updated control private key is stored in the first trusted execution environment.

39. The account management method of claim 31, wherein updating the control public key and control private key of the user side with the recovery public key and recovery private key of the user side further comprises:

the service component updates a scenario identity of the user party to configure an updated control public key in the scenario identity.

40. An account management device, comprising:

a communication module configured to obtain context identity registration data from a user party from a client component of a client, wherein an identity document associated with a de-centralized identity of the user party is stored on an identity chain; and

a context identity registration module configured to configure context information associated with the user party according to the context identity registration data, and to configure context identities associated with the context of the user party on a context chain.

41. The account management device of claim 40, further comprising:

and a scene chain registration module configured to register a scene chain of an operator associated with the scene.

42. The account management device of claim 40, further comprising:

an identity registration module configured to register a de-centralized identity of the user party on the identity chain.

43. The account management device of claim 40, further comprising:

and the recovery key module is configured to generate a recovery public key and a recovery private key of the user side, wherein the recovery public key is matched with the recovery private key.

44. The account management device of claim 43, further comprising:

and the key updating module is configured to update 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.

45. An account management system, comprising:

the account management apparatus according to any one of claims 40 to 44;

a client; and

a blockchain of identity documents and scene identities associated with the user-side de-centralized identity is stored.