CN113435888B

CN113435888B - Account data processing method, device, equipment and storage medium

Info

Publication number: CN113435888B
Application number: CN202110753750.6A
Authority: CN
Inventors: 黄焕坤; 杨常青; 蓝虎; 刘区城; 朱耿良; 廖志勇; 时一防; 张劲松; 刘攀; 王宗友; 周开班
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-04-13
Filing date: 2020-04-13
Publication date: 2022-05-31
Anticipated expiration: 2040-04-13
Also published as: CN111476573A; CN111476573B; CN113435888A

Abstract

The embodiment of the application discloses an account data processing method, device, equipment and storage medium, comprising the following steps: acquiring a service processing request sent by a first user terminal; when the service processing request is determined to be a legal request, generating a first original account of a first user based on a user public key, and writing the first original account into a trusted execution environment; calling a trusted application program in a trusted execution environment to generate a key pair corresponding to a first original account; generating K anonymous accounts associated with the first original account based on the sub public keys in the K sub key pairs, and establishing mapping hash values between the first original account and the K anonymous accounts; and when each anonymous account and the mapping hash value corresponding to each anonymous account are written into the block chain to which the central node belongs, each anonymous account is returned to the first user terminal, so that the first user terminal executes the target service based on each anonymous account. By adopting the embodiment of the application, the safety of the real account information of the user can be ensured.

Description

Account data processing method, device, equipment and storage medium

The present application is a divisional application of a chinese patent application with an application number of 202010285628.6, entitled "a method, an apparatus, a device and a storage medium for processing account data" filed by the chinese patent office on 13/04 in 2020, and the entire contents of the divisional application are incorporated by reference in the present application.

Technical Field

The present application relates to the field of blockchain technologies, and in particular, to an account data processing method, apparatus, device, and storage medium.

Background

At present, when asset transfer is performed in a blockchain system, asset transfer is performed by using a real account stored in a user terminal, for example, when asset transfer is performed between a user terminal a and a user terminal B in a blockchain, the user terminal a may send some asset information (e.g., an electronic ticket XX) to real account information (e.g., a transaction account 2) of the user terminal B according to own real account information (e.g., a transaction account 1), that is, after the user terminal a and the user terminal B complete asset transaction, a transaction record including the real account information may be directly disclosed on a chain, so that there is a risk that the real account information of a user is directly exposed on the blockchain, and further, security of the user account information is reduced.

Disclosure of Invention

The embodiment of the application provides an account data processing method, device, equipment and storage medium, which can ensure the safety of real account information of a user.

One aspect of the present embodiment provides an account data processing method, where the method is executed by a central node deployed with a trusted execution environment, and the method includes:

acquiring a service processing request sent by a first user terminal; the service processing request carries a user public key of a first user corresponding to the first user terminal; the user public key is used for indicating the central node to generate a first original account of the first user;

when the service processing request is determined to be a legal request, generating a first original account of a first user based on a user public key, and writing the first original account into a trusted execution environment;

calling a trusted application program in a trusted execution environment to generate a key pair corresponding to a first original account; the key pair comprises K sub-key pairs; k is a positive integer; each of the K sub-key pairs comprises a sub-public key configured for the first primary account;

generating K anonymous accounts associated with the first original account based on the sub public keys in the K sub key pairs, and establishing mapping hash values between the first original account and the K anonymous accounts;

and when each anonymous account and the mapping hash value corresponding to each anonymous account are written into the block chain to which the central node belongs, each anonymous account is returned to the first user terminal, so that the first user terminal executes the target service based on each anonymous account.

An aspect of the present embodiment provides an account data processing method, where the method is executed by a first user terminal, and includes:

sending a service processing request to a central node with a trusted execution environment; the service processing request carries a user public key of a first user corresponding to the first user terminal; the user public key is used for indicating the central node to generate a first original account of the first user;

receiving K anonymous accounts returned by the central node; k is a positive integer; the K anonymous accounts are generated by the central node based on the sub public keys in the K sub key pairs corresponding to the first original account; the K sub-key pairs are generated by the central node invoking a trusted application in the trusted execution environment.

An aspect of an embodiment of the present application provides an account data processing apparatus, where the apparatus operates in a central node deployed with a trusted execution environment, and includes:

the acquisition module is used for acquiring a service processing request sent by a first user terminal; the service processing request carries a user public key of a first user corresponding to the first user terminal; the user public key is used for indicating the central node to generate a first original account of the first user;

the generating module is used for generating a first original account of the first user based on the user public key and writing the first original account into the trusted execution environment when the service processing request is determined to be a legal request;

the calling module is used for calling a trusted application program in the trusted execution environment to generate a key pair corresponding to the first original account; the key pair comprises K sub-key pairs; k is a positive integer; each of the K sub-key pairs comprises a sub-public key configured for the first primary account;

the establishing module is used for generating K anonymous accounts associated with the first original account based on the sub public keys in the K sub secret key pairs and establishing mapping hash values between the first original account and the K anonymous accounts;

and the returning module is used for returning each anonymous account to the first user terminal when the mapping hash value corresponding to each anonymous account and each anonymous account is written into the block chain to which the central node belongs, so that the first user terminal executes the target service based on each anonymous account.

The service processing request comprises registration service data information and user signature information which are associated with the first user terminal; the user signature information is obtained after the first user terminal signs the registered service data information through a user private key of the first user;

the device also includes:

the signature verification module is used for verifying the signature of the user signature information based on the user public key to obtain a signature verification result;

the first determining module is used for determining that the first user is a legal user and determining a service processing request initiated by the first user as a legal request when the verification result indicates that the verification is successful;

and the second determining module is used for determining that the first user is an illegal user and determining the service processing request initiated by the first user as an illegal request when the verification result indicates that the verification fails.

Wherein, this generation module includes:

the first hash calculation unit is used for performing hash calculation on the user public key through a first hash rule and a second hash rule when the service processing request is determined to be a legal request, so as to obtain a public key hash value corresponding to the user public key;

the second hash calculation unit is used for taking the address version number of one byte as the head of the public key hash value to obtain a first splicing character string, performing hash calculation on the first splicing character string to obtain a hash value to be processed corresponding to the first splicing character string, and acquiring a check value of the public key hash value from the hash value to be processed;

and the encoding unit is used for obtaining a second splicing character string by taking the check value as the tail part of the first splicing character string, encoding the second splicing character string, taking the encoded character string obtained after the encoding processing as a first original account of the first user, and writing the first original account into the trusted execution environment.

Wherein, this calling module includes:

the calling unit is used for calling the trusted application program in the trusted execution environment, acquiring a private key generation rule in the trusted application program, and generating K sub-private keys associated with the first original account according to the private key generation rule;

the generating unit is used for generating sub public keys respectively corresponding to the K sub private keys according to a Hash encryption rule in the trusted application program; one sub private key corresponds to one sub public key, and one sub private key and one sub public key are used for constructing one sub private key pair;

and the first determining unit is used for determining K sub-key pairs corresponding to the first original account according to the K sub-private keys and the sub-public keys corresponding to the K sub-private keys respectively, and taking the K sub-key pairs as key pairs corresponding to the first original account.

Wherein, this establishment module includes:

a first obtaining unit for obtaining a sub-key pair M from the K sub-key pairs_i(ii) a i is a positive integer less than or equal to K; sub-key pair M_iIn which the sub public key Y is included_iAnd a sub private key X_i(ii) a Sub public key Y_iIs composed of a sub-private key X_iObtained through a Hash encryption rule in a trusted application program; sub private key X_iIs obtained by a private key generation rule in the trusted application;

a second determination unit for determining the sub-key pair M_iThe sub public key Y in_iCarrying out Hash calculation to obtain a sub public key Y_iCorresponding sub public key hash value, obtaining address character string and check character string associated with sub public key hash value, and determining sub key pair M based on address character string, sub public key hash value and check character string_iA corresponding anonymous account;

the encryption unit is used for encrypting the first original account through a trusted public key in a trusted key pair associated with a trusted execution environment in the trusted execution environment when an anonymous account of each of the K sub-key pairs is obtained, so as to obtain encrypted account encryption information;

the establishing unit is used for establishing a Hash mapping relation table between the account encryption information and the K anonymous accounts and determining mapping Hash values between the first original account and the K anonymous accounts according to the K Hash mapping relations in the Hash mapping relation table; a hash mapping relationship is used to determine a mapped hash value.

Wherein, the device still includes:

the system comprises a packaging processing module, a verification processing module and a verification processing module, wherein the packaging processing module is used for packaging each anonymous account in the K anonymous accounts and the mapping hash value corresponding to each anonymous account to obtain a to-be-verified block to be written into a block chain to which a central node belongs;

the broadcast module is used for broadcasting the to-be-verified block to the consensus node on the block chain so that the consensus node can perform consensus on the acquired to-be-verified block to obtain a consensus result; the common identification node and the central node are block chain nodes on the block chain;

and the writing module is used for determining that the block chain nodes on the block chain achieve consensus and writing the block to be verified into the block chain as a target block if the consensus result exceeding 1/2 in the consensus results returned by the consensus nodes indicates that the consensus is successful.

The K anonymous accounts comprise a first anonymous account, and the first anonymous account is used for indicating a first user terminal to execute a target service for transferring assets to a second user terminal corresponding to a second anonymous account;

the device also includes:

the request receiving module is used for receiving an asset transfer request sent by a first user terminal based on a first anonymous account; the asset transfer request carries asset information corresponding to the target service, asset signature information corresponding to the asset information and a target mapping hash value associated with the first anonymous account; the asset signature information is obtained by a first user terminal through signing the asset information through a sub-private key of the first anonymous account;

the searching module is used for searching a target Hash mapping relation associated with the target Hash mapping value and the first anonymous account in a Hash mapping relation table after the asset signature information is successfully verified through a sub public key corresponding to a sub private key of the first anonymous account, and determining account encryption information corresponding to the first original account based on the target Hash mapping relation; the target Hash mapping relation is one Hash mapping relation in a Hash mapping relation table;

the decryption module is used for decrypting the account encrypted information based on the trusted private key in the trusted key pair to obtain a first original account corresponding to the first user terminal;

and the transfer module is used for acquiring the asset information from the first primary account and transferring the asset information to the second user terminal through the first anonymous account so that the second user terminal stores the asset information to a second primary account associated with the second anonymous account through the central node.

Wherein the asset information comprises an asset amount for performing the asset transfer;

the transfer module includes:

the second obtaining unit is used for obtaining the asset quantity in the asset information from the first original account and writing the asset quantity into the first anonymous account when detecting that the asset information corresponding to the target service exists in the first original account;

and the locking unit is used for locking the asset quantity according to the anonymous sub public key of the second anonymous account and sending the locked asset quantity to the second anonymous account through the first anonymous account so as to enable a second user terminal corresponding to the second anonymous account to be unlocked based on the anonymous sub private key corresponding to the anonymous sub public key to obtain the asset quantity.

Wherein, this transfer module still includes:

the writing unit is used for writing the asset quantity into a second original account corresponding to a second user in the trusted execution environment according to the incidence relation between the second anonymous account and the second original account corresponding to the second anonymous account; the second user is a user of the second user terminal; the second primary account is a primary account of a second user existing in the user set of the trusted execution environment; the associative relationship is determined by a mapping hash value between the encrypted data information of the second anonymous account and the second primary account.

One aspect of the present application provides a computer device, comprising: a processor, a memory, a network interface;

the processor is connected to a memory and a network interface, wherein the network interface is used for providing a data communication function, the memory is used for storing a computer program, and the processor is used for calling the computer program to execute the method in the above aspect in the embodiment of the present application.

An aspect of the present application provides a computer-readable storage medium storing a computer program comprising program instructions that, when executed by a processor, perform the method of the above-mentioned aspect of the embodiments of the present application.

An aspect of the present application provides an account data processing apparatus, where the apparatus is operated in a first user terminal, and the apparatus includes:

the sending module is used for sending a service processing request to a central node with a trusted execution environment; the service processing request carries a user public key of a first user corresponding to the first user terminal; the user public key is used for indicating the central node to generate a first original account of the first user;

the receiving module is used for receiving K anonymous accounts returned by the central node; k is a positive integer; the K anonymous accounts are generated by the central node based on the sub public keys in the K sub key pairs corresponding to the first original account; the K sub-key pairs are generated by the central node invoking a trusted application in the trusted execution environment.

Wherein, the sending module includes:

the signature unit is used for signing the registration service data information associated with the first user terminal based on a user private key of the first user corresponding to the first user terminal to obtain user signature information;

the request generating unit is used for generating a service processing request which is used for sending to a central node with a trusted execution environment based on user signature information, registered service data information and a user public key corresponding to a user private key; the service processing request is used for instructing the central node to perform signature verification on the user signature information based on the user public key carried by the service processing request.

In this embodiment of the application, the central node deployed with the trusted execution environment may be configured to store a first primary account of the first user terminal, that is, when a first primary account of the first user (here, real account information of the first user) is generated through a user public key of the first user corresponding to the first user terminal, the first primary account of the first user may be written into the trusted execution environment for storage. Further, the central node may invoke a trusted application deployed in the trusted execution environment to derive K anonymous accounts associated with the first primary account, and may further establish a mapping hash value between the first primary account and each anonymous account, where the mapping hash value may be used to reflect a hash mapping relationship between the first primary account and the anonymous account. Further, it may be understood that, after successfully writing the mapping hash value corresponding to each anonymous account and each anonymous account in the K anonymous accounts into the blockchain, the central node may ensure validity of multiple anonymous accounts derived from the first original account, and may further return the anonymous accounts to the first user terminal, so that the first user terminal may ensure that the anonymous accounts (i.e., the derived virtual account information) are disclosed on the blockchain instead of the real account information of the first user after performing a target service (e.g., performing an asset transfer service) with another user terminal (e.g., a second user terminal) through any anonymous account in the K anonymous accounts, so as to ensure security of the real account information of the user. It can be understood that, because the first original account is stored in the trusted memory of the trusted execution environment, the external user or even the first user cannot know the real information of the first original account, so that when an asset transfer service (i.e., a target service) is executed between the first user terminal and the second user terminal, the risk that the first original account of the first user is leaked is reduced, and the security of the real account information of the user is further improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a schematic diagram of a blockchain network structure according to an embodiment of the present disclosure;

fig. 2 is a schematic view of a scenario for performing data interaction according to an embodiment of the present application;

fig. 3 is a schematic flowchart of an account data processing method according to an embodiment of the present application;

fig. 4 is a schematic view of a scenario for verifying validity of a service processing request according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a scenario for generating a primary account according to an embodiment of the present application;

fig. 6a is a schematic view of a scenario in which a trusted execution environment in a central node is verified by a verification server according to an embodiment of the present application;

fig. 6b is a schematic diagram of a scenario for generating an anonymous account according to an embodiment of the present application;

fig. 7 is a schematic diagram of an uplink scenario provided in an embodiment of the present application;

fig. 8 is a schematic flowchart of an account data processing method according to an embodiment of the present application;

fig. 9 is a schematic view of a scenario for executing a target service according to an embodiment of the present application;

FIG. 10 is a schematic diagram of a scenario for generating an asset transfer request according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of an account data processing apparatus according to an embodiment of the present application;

FIG. 12 is a schematic diagram of a computer device provided by an embodiment of the present application;

fig. 13 is a schematic structural diagram of an account data processing apparatus according to an embodiment of the present application;

FIG. 14 is a schematic diagram of a computer device provided by an embodiment of the present application;

fig. 15 is a schematic structural diagram of an account data processing system according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

Please refer to fig. 1, which is a block chain network structure according to an embodiment of the present disclosure. The blockchain network structure shown in fig. 1 may be applied to a blockchain system, which may be a distributed system formed by a plurality of nodes connected by a form of network communication. The blockchain system may include, but is not limited to, a blockchain system corresponding to a federation chain. As shown in fig. 1, the blockchain system may include a plurality of nodes, which may specifically include node 10A, node 10B, node 10C, …, and node 10N. The user terminal cluster shown in fig. 1 may include a plurality of user terminals, and as shown in fig. 1, the plurality of user terminals may specifically include a user terminal 100a, a user terminal 100b, a user terminal 100c, …, and a user terminal 100 n.

It should be understood that, in the embodiments of the present application, a blockchain node where a trusted execution environment is deployed may be referred to as a central node, where the central node may be any form of computer device, such as a server, a user terminal, and the like, accessing into the blockchain network, and a specific form of the central node where the trusted execution environment is deployed will not be limited herein. For convenience of understanding, the embodiment of the present application may select a node in the blockchain system shown in fig. 1 as a central node in the blockchain network. For example, the embodiment of the present application may use the node 10A in the blockchain system as a central node. The node 10A may perform service data interaction with each user terminal in the user terminal cluster.

Optionally, the blockchain system may include a central node cluster, and the central nodes in the central node cluster may also share the original account of the user terminal associated with the node 10A. It is understood that the primary accounts can be shared among the central nodes because the central nodes are all deployed with the same trusted execution environment, so that the trusted execution environment in one central node can perform encrypted data transmission with the trusted execution environment in another central node, and the security of the primary accounts stored in the trusted execution environments can be ensured.

It will be appreciated that the node 10A (i.e., the central node) may be used to generate accounts, manage accounts, conduct transactions from accounts, etc. The accounts herein may include both primary accounts and anonymous accounts. The primary account can be real account information of a user of each user terminal stored in a trusted execution environment of the central node; the anonymous account may be a trusted application in a trusted execution environment deployed in the central node, and K pieces of virtual account information derived for the primary account, where K may be a positive integer.

As shown in fig. 1, the node 10A may perform service data interaction with each user terminal in the user terminal cluster. Wherein, each ue in the ue cluster may include: intelligent terminals such as smart phones, tablet computers, desktop computers and the like. It is understood that the embodiment of the present application may select one of the plurality of ues in the ue cluster shown in fig. 1 as the target ue associated with the central node (e.g., node 10A). For example, in this embodiment, the user terminal 100a in the user terminal cluster may be referred to as a target user terminal, and a target user terminal that requests data interaction with the central node may be referred to as a first user terminal. The user corresponding to the first user terminal can be referred to as a first user in the embodiment of the application. In the embodiment of the present application, another user terminal (for example, the user terminal 100b) in the user terminal cluster may be used as a second user terminal associated with the central node, and a user corresponding to the second user terminal may be referred to as a second user.

When other nodes in the blockchain system work normally, anonymous accounts issued by the central node to user terminals on the blockchain and mapping hash values corresponding to the anonymous accounts can be obtained, that is, the nodes in the blockchain system can be used for maintaining the same blockchain, and anonymous accounts of all users accessing the blockchain system can be recorded on a shared account book of the blockchain. For convenience of distinction, in the embodiments of the present application, the anonymous accounts of the first user disclosed on the blockchain may be collectively referred to as a first anonymous account, and the anonymous accounts of the second user disclosed on the blockchain may be collectively referred to as a second anonymous account. For example, before the node 10A in the blockchain system needs to write the generated first anonymous account and the mapping hash value corresponding to the first anonymous account into the blockchain, the obtained first anonymous account and the mapping hash value corresponding to the first anonymous account may be identified by another node (e.g., an identifying common node) in the blockchain system according to an identifying common algorithm, so that the mapping hash value corresponding to the first anonymous account and the first anonymous account generated by the node 10A may be written into the blockchain when the identifying common node succeeds, and consistency of data (here, the mapping hash values corresponding to the anonymous account and the anonymous account) stored in the nodes participating in the maintaining of the blockchain together may be ensured.

It should be understood that a Trusted Execution Environment (TEE) is deployed in a secure area on the host processor of the central node (e.g., node 10A), which can ensure the security, confidentiality and integrity of code and data loaded into the Environment. The TEE in the central node may be used to provide an isolated execution environment in the memory of the device to ensure the security of the primary account (i.e., real account information) stored on each user of the TEE. It is understood that the TEE of the central node may be protected by SGX (Intel Software Guard Extension), and nodes on a blockchain (e.g., a federation chain) corresponding to the blockchain network shown in fig. 1 may verify the validity of the hardware signature by means of the SGX's verification function (e.g., the transaction may be verified by a sub-public key of the anonymous account from which the transaction originated) to ensure the validity and integrity of the corresponding anonymous account.

The application program with the derivative anonymous account function written into the trusted memory of the trusted execution environment can be called as a trusted application program. The trusted application program can comprise a plurality of subprograms, and each subprogram can correspond to an account data processing rule; the account data processing rule may specifically include a private key generation rule, a hash encryption rule, and an account generation rule. The private key generation rule may be used to generate a sub-private key associated with the first primary account, the hash encryption rule may be used to generate a sub-public key corresponding to the sub-private key, and the account generation rule may be used to generate a plurality of anonymous accounts derived from the primary account.

It should be understood that the node 10A deployed with the trusted execution environment may obtain the service request sent by the user terminal 100A, and may further verify the validity of the service request. In this embodiment, the service request for generating the anonymous account of the user (i.e., the first user) corresponding to the first user terminal (e.g., the user terminal 100a) may be referred to as a service processing request. The service processing request may carry a user public key of a user (e.g., user 1) corresponding to the user terminal 100A, where the user public key may be used to instruct the node 10A to generate an original account of the user 1. In the embodiment of the application, the primary account of the first user corresponding to the first user terminal may be referred to as a first primary account.

When the node 10A determines that the service processing request is a legal request, the node 10A may generate a first primary account (for example, account a) of the user 1 based on the user public key of the user 1, and may further write the first primary account into a user set in the trusted execution environment, so as to ensure security of the first primary account. Wherein the set of users in the trusted execution environment may be used to store primary accounts of users corresponding to user terminals associated with the central node. For example, the number of the user terminals having a network connection relationship with the central node may be multiple (taking 3 as an example), and specifically may include the user terminal 100a, the user terminal 100b, and the user terminal 100 c. At this time, the user set in the trusted execution environment of the central node may include the primary account (account a) of the user 1 corresponding to the user terminal 100a, the primary account (account B) of the user 2 corresponding to the user terminal 100B, and the primary account (account C) of the user 3 corresponding to the user terminal 100C.

Further, the node 10A may invoke a trusted application in the trusted execution environment, generating a key pair corresponding to the first primary account. Wherein, the key pair may contain K sub-key pairs; k may be a positive integer; each of the K sub-key pairs may include a sub-public key configured for the first primary account and a sub-private key corresponding to the sub-public key.

It should be appreciated that node 10A may generate K anonymous accounts associated with the first primary account based on the child public keys of the K child key pairs. For example, account A₁…, Account A_K. Further, the node 10A may establish mapping hash values between the first primary account and the K anonymous accounts, and may write mapping hash values corresponding to each anonymous account of the K anonymous accounts and each anonymous account into a block chain to which the central node belongs (e.g., the block chain in the block chain network shown in fig. 1). At this time, the node 10A may return K anonymous accounts directly to the user terminal 100A so that the user terminal 100A may perform the target service on a per anonymous account basis.

The target service may be an asset transfer service, and the asset information corresponding to the asset transfer service may be virtual assets (e.g., bitcoins, ethernet coins, etc.) in a financial scenario, game assets (e.g., game coins, game diamonds, etc.) in a game scenario, or ticket assets (e.g., electronic ticket XX) in an electronic ticket processing scenario, etc. Optionally, the target service may also be a communication service, such as telephone, short message, mail, etc. The asset information corresponding to the communication service can be content information edited by a short message, content information edited by a mail and the like. The target service may also be a service in other forms, which is not limited herein.

Therefore, the original account of the user corresponding to each user terminal can be written into the trusted execution environment of the central node, and the target service can be executed based on the anonymous account of the user. Because in the trusted execution environment of the central node, the operation can be performed only by a processor (CPU) instruction of the central node, the security of the original account is improved, and the risk that the privacy information of the user is leaked is reduced.

For easy understanding, please refer to fig. 2, which is a schematic diagram of a scenario for performing data interaction according to an embodiment of the present application. The central node 210 in this embodiment may be a central node in the block chain network shown in fig. 1, and a trusted execution environment, for example, the node 10A shown in fig. 1, may be deployed on the central node. The ue 200 in this embodiment may be any one of the ue in the ue cluster shown in fig. 1, for example, the ue 100 a.

In this embodiment, a user (for example, user 1) corresponding to the user terminal 200 (i.e., the first user terminal) may be referred to as a first user. As shown in fig. 2, the user terminal 200 may sign the registered service data information associated with the user terminal 200 based on the user private key of the user 1, to obtain signed signature information. The embodiment of the application can refer to signature information obtained by signing the submitted registration service data information by the user terminal based on the user private key as user signature information. The data information submitted by the user corresponding to the user terminal during registration can be called as registration service data information in the embodiment of the application. For example, the registration service data information may include basic information of the user 1 (e.g., a user name of the user 1, a business scope of the user 1, a user public key of the user 1, etc.).

Further, the user terminal 200 may generate the service processing request sent to the central node 210 based on the user signature information, the registered service data information, and the user public key corresponding to the user private key. At this time, the central node 210 may verify the user signature information based on the user public key carried in the service processing request, and obtain a signature verification result. When the verification result indicates that the verification is successful, the central node 210 may determine the user 1 as a valid user, and may determine the service processing request initiated by the user 1 as a valid request. When the verification result indicates that the verification fails, the central node 210 may determine the user 1 as an illegal user, and may determine the service processing request initiated by the user 1 as an illegal request.

It is to be appreciated that when the central node 210 determines that the transaction request is a legitimate request, the central node 210 may generate a primary account (i.e., a first primary account, e.g., account a) for user 1 based on the user public key and store the primary account to the set of users in the trusted execution environment. Further, central node 210 may invoke a trusted application stored in the trusted execution environment to generate key pair M corresponding to account a_i. Wherein the key pair may contain K sub-key pairs, e.g. sub-key pair M₁…, subkey pair M_K. K may be a positive integer. It will be appreciated that a sub-key pair M_iMay contain a sub public key Y_iAnd the sub public key Y_iCorresponding sub-private key X_i. Where i may be a positive integer less than or equal to K. For example, the subkey pair M₁May contain a sub public key Y₁And the sub public key Y₁Corresponding sub-private key X₁. It should be appreciated that central node 210 may generate K anonymous accounts associated with account a based on the child public keys of the K child key pairs. For example, account A₁…, Account A_K。

Further, the central node 210 encrypts the account a in the trusted execution environment through the trusted public key in the trusted key pair associated with the trusted execution environment, so as to obtain encrypted account encryption information 1. The trusted key pair is obtained by initializing the trusted execution environment, and may include a trusted public key and a trusted private key. The trusted private key is built in hardware for protection. At this time, the central node 210 may establish the account encryption information 1 corresponding to the account a and the hash mapping relationships between the K anonymous accounts, and further may establish the hash mapping relationship table between the original account and the anonymous account through the hash mapping relationships. The central node 210 may use a hash value obtained by performing hash calculation on the account encryption information 1 and each anonymous account of the K anonymous accounts as a mapping hash value corresponding to each anonymous account.

At this time, the central node 210 may perform a packing process on each anonymous account in the K anonymous accounts and the mapping hash value corresponding to each anonymous account, so as to obtain a to-be-verified block to be written into a block chain to which the central node belongs (for example, a block chain corresponding to the block chain network shown in fig. 1). Further, the central node 210 may broadcast the to-be-verified block to the consensus node on the block chain, so that the consensus node performs consensus on the acquired to-be-verified block to obtain a consensus result. When there is a consensus result exceeding 1/2 in the consensus results returned by the consensus nodes indicating that the consensus was successful, central node 210 may determine that the blockchain nodes on the blockchain agree. At this point, the central node 210 may write the block to be verified as the target block into the block chain.

When the central node 210 writes each anonymous account and the mapping hash value corresponding to each anonymous account into the block chain to which the central node 210 belongs, the central node 210 may return each anonymous account to the user terminal 200 as a service processing result corresponding to the service processing request, so that the user terminal 200 may execute the target service based on each anonymous account.

For a specific implementation manner of deriving an anonymous account for performing a target service by a central node deployed with a trusted execution environment based on an original account of a user terminal, reference may be made to the following embodiments corresponding to fig. 3 to fig. 10.

Further, please refer to fig. 3, which is a flowchart illustrating an account data processing method according to an embodiment of the present application. The method may be performed by a central node deployed with a trusted execution environment, and may specifically refer to the following description of step S101 to step S105. As shown in fig. 3, the method may include:

step S101, a service processing request sent by a first user terminal is obtained.

It should be understood that, before the central node deployed with the trusted execution environment performs step S101, the first user terminal having a network connection relationship with the central node may sign the registration service data information associated with the first user terminal based on a user private key of the first user corresponding to the first user terminal, so that user signature information may be obtained. Further, the first user terminal may generate the service processing request based on the user signature information, the registered service data information, and the user public key corresponding to the user private key. Further, the first user terminal may send the service processing request to the central node, and at this time, the central node may obtain the service processing request. The service processing request may be used to instruct the central node to perform signature verification on the user signature information based on a user public key carried by the service processing request. The user public key may be used to instruct the central node to generate a first primary account for the first user.

The central node in this embodiment may be the central node 210 in the embodiment corresponding to fig. 2, and the central node 210 may be a central node in the block chain network in the embodiment corresponding to fig. 1, for example, the node 10A. The first ue in this embodiment may be the ue 200 in the embodiment corresponding to fig. 2, and the ue 200 may be any one ue in the ue cluster in the embodiment corresponding to fig. 1, for example, the ue 100 a.

For easy understanding, please refer to fig. 4, which is a schematic diagram illustrating a scenario that verifies the validity of a service processing request according to an embodiment of the present application. As shown in fig. 4, the ue 400 may be any ue in the ue cluster in the embodiment corresponding to fig. 1, for example, the ue 100 a. The central node 410 may be a central node in the blockchain network in the embodiment corresponding to fig. 1, for example, the node 10A. A trusted execution environment is deployed on the central node. A trusted application in the trusted execution environment having derivative anonymous account functionality.

As shown in fig. 4, the user terminal 400 (i.e., the first user terminal) may sign the registration service data information associated with the user terminal 400 based on the user 1 (i.e., the user private key of the first user) corresponding to the user terminal 400, so as to obtain user signature information. The registration service data information may include basic information of the user 1 (e.g., a user name of the user 1, an enterprise business scope of the user 1, a user public key of the user 1, etc.). It can be understood that the user terminal 400 may perform hash calculation on the registered service data information, so as to obtain the summary information h of the registered service data information, and perform digital signature on the summary information h based on the user private key of the user terminal 400, so as to obtain the user signature information. Wherein, the user signature information includes the digital signature and the registration service data information.

Further, the user terminal 400 may generate a service processing request for sending to the central node 410 based on the user signature information, the registered service data information, and the user public key corresponding to the user private key, so that the central node 410 may check the signature of the user signature information based on the user public key of the user 1 carried in the service processing request, thereby obtaining a signature checking result. It can be understood that the central node 410 may check the digital signature based on the user public key of the user 1 to obtain the digest information H of the registered service data information, and perform hash calculation on the registered service data information by using the same hash algorithm as that of the user terminal 400, so as to obtain the digest information H of the registered service data information. Further, the central node 410 may compare the digest information H obtained after signature verification with the digest information H obtained by performing hash calculation, so as to obtain a signature verification result.

If the summary information H is different from the summary information H, it may be understood that the signature verification result obtained by the central node 410 indicates that the signature verification fails, and at this time, the central node 410 may determine the user 1 as an illegal user, and may determine the service processing request initiated by the user 1 as an illegal request. If the summary information H is the same as the summary information H, it can be understood that the signature verification result obtained by the central node 410 indicates that the signature verification is successful, and at this time, the central node 410 may determine the user 1 as a valid user, and may determine the service processing request initiated by the user 1 as a valid request.

Step S102, when the service processing request is determined to be a legal request, generating a first primary account of the first user based on the user public key, and writing the first primary account into the trusted execution environment.

Specifically, when the service processing request is determined to be a legal request, the central node may perform hash calculation on the user public key through the first hash rule and the second hash rule to obtain a public key hash value corresponding to the user public key; further, the central node may use the address version number of one byte as the header of the public key hash value to obtain a first concatenation character string, and may further perform hash calculation on the first concatenation character string to obtain a to-be-processed hash value corresponding to the first concatenation character string. At this time, the central node may obtain a check value of the public key hash value from the hash value to be processed, and obtain the second concatenated string by using the check value as the tail of the first concatenated string. Further, the central node may perform encoding processing on the second concatenation character string, use the encoded character string obtained after the encoding processing as a first original account of the first user, and write the first original account into the user set in the trusted execution environment.

For easy understanding, please refer to fig. 5, which is a schematic view of a scenario for generating a primary account according to an embodiment of the present application. As shown in fig. 5, the user public key in the embodiment of the present application may be the user public key of the user 1 corresponding to the user terminal 400 in the embodiment corresponding to fig. 4. The central node in this embodiment of the application may be the central node 410 with the trusted execution environment deployed in the embodiment corresponding to fig. 4.

As shown in fig. 5, when determining that the service processing request sent by the user terminal 400 is a legal request, the central node 410 may generate an original account (e.g., account a shown in fig. 5) of the user 1 based on the user public key. It should be understood that, the central node 410 may perform hash calculation on the user public key carried in the service processing request through the first hash rule and the second hash rule, so as to obtain a public key hash value corresponding to the user public key. The first hash rule and the second hash rule may be different hash rules.

It is understood that a hash rule, i.e. a one-way hash algorithm, also called hash function (or hash algorithm), is a function that changes an arbitrary input message string into a fixed-length output string, which is called a hash value of the message, and is generally used for generating a message digest, encrypting a key, and the like. Specifically, the algorithm outputs a fixed-length value after calculating an input message, and the output value is also called a "hash value" or a message digest, and the length of the output value is usually between 128 and 256 bits.

For example, the first hash rule may be the SHAS256 algorithm (one hash function) and the second hash rule may be the ripemm 160 algorithm (another hash function). For any length of message, the hash output value of the SHA256 algorithm is a 16-system character string, and since the 16-system character string occupies one byte for every two characters and one byte is equal to 8 bits, a 256-bit value is obtained by using the SHA256 hash function. In addition, the hash output value of the ripemm 160 algorithm is typically a 16-ary string. Since a 16-ary string takes up one byte every two characters, one byte being equal to 8 bits, the result using the ripemm 160 encryption function is a 160-bit value.

Further, the central node may use the address version number of one byte as the header of the public key hash value shown in fig. 5, so that the concatenation string 1 may be obtained. The splicing character string 1 can be referred to as a first splicing character string in the embodiment of the application. For example, if the blockchain network to which the central node belongs is a bitcoin network, the one byte may be "0", i.e., 0x 00. At this time, the central node may concatenate 0x00 with the public key hash value to obtain the concatenation string 1 shown in fig. 5.

At this time, the central node may perform hash calculation on the concatenation string 1, so that a hash value corresponding to the concatenation string 1 may be obtained. In this embodiment of the present application, a hash value corresponding to a first concatenation character string (for example, the concatenation character string 1 shown in fig. 5) may be referred to as a hash value to be processed. For example, when the central node performs hash calculation on the splicing character string 1, the splicing character string 1 may be calculated twice by using the SHAS256 algorithm, so as to obtain a hash value to be processed. The hash function used for the hash calculation and the number of times of calculation used are not limited here.

Further, the central node may obtain a check value of the public key hash value from the hash value to be processed. For example, the central node may use the first 4 bytes of the hash value to be processed as the check value of the public key hash value. It can be understood that the central node may use the check value as the tail of the concatenation string 1 to obtain the concatenation string 2. In this embodiment, the concatenation character string 2 may be referred to as a second concatenation character string. Further, the central node may perform encoding processing on the concatenation character string 2, and use the encoded character string obtained after the encoding processing as a first original account (for example, account a) of a first user (user 1 shown in fig. 4), for example, 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa, and then the central node may write the account a into a user set in the trusted execution environment.

Step S103, invoking a trusted application program in the trusted execution environment, and generating a key pair corresponding to the first primary account.

Specifically, the central node may invoke a trusted application in the trusted execution environment, and may further obtain a private key generation rule in the trusted application, and generate K sub-private keys associated with the first primary account according to the private key generation rule. Further, the central node may generate the sub public keys corresponding to the K sub private keys respectively through a hash encryption rule in the trusted application program. One sub-private key may correspond to one sub-public key, and one sub-private key and one sub-public key may be used to construct one sub-key pair. It should be understood that the central node may determine K sub-key pairs corresponding to the first primary account according to the K sub-private keys and sub-public keys corresponding to the K sub-private keys, respectively, and further may use the K sub-key pairs as key pairs corresponding to the first primary account.

For easy understanding, please refer to fig. 6a, which is a schematic view of a scenario in which a verification server verifies a trusted execution environment in a central node according to an embodiment of the present application. As shown in fig. 6a, the central node 60 in the embodiment of the present application may be a central node deployed with a trusted execution environment, for example, the node 10A shown in fig. 1. The trusted application running in the trusted execution environment may be an application with derivative anonymous account functionality.

It should be understood that, when the trusted application is deployed in the trusted execution environment, the trusted application to be deployed may be signed and issued with unique certificate information by the verification server, and the certificate information may be stored in a database associated with the verification server. It is understood that, when the trusted application in the trusted execution environment is called, the central node 60 may first send a corresponding verification instruction to the verification server shown in fig. 6a, so that the verification server verifies the certificate information of the trusted application through the database shown in fig. 6 a.

It will be appreciated that the check server as shown in fig. 6a may retrieve the check instruction sent by the central node 60. The verification instruction may carry certificate information (e.g., certificate information a) corresponding to the trusted application sent by the central node 60. At this time, the verification server may acquire the stored certificate information (e.g., certificate information a) corresponding to the above-described trusted application from a database associated with the verification server based on the verification instruction. Further, the verification server may match the certificate information a with the certificate information a.

If the matching result of the certificate information a and the certificate information a indicates that the matching is successful, it can be understood that the certificate information a uploaded by the central node 60 is legal, and thus the trusted execution environment to which the trusted application program belongs can be indirectly determined to be the security execution environment. If the matching result of the certificate information a and the certificate information a indicates that the matching fails, it may be understood that the certificate information a uploaded by the central node 60 does not have validity, and thus, the trusted execution environment to which the trusted application program belongs may be indirectly determined to be a dangerous execution environment.

Further, the central node may invoke a trusted application in the trusted execution environment, and may further obtain a private key generation rule in the trusted application, where the private key generation rule may be a deterministic algorithm, such as a bip32 algorithm, a bip39 algorithm, a bip44 algorithm, and the like. It will be appreciated that the central node may generate the mnemonic associated with the first primary account according to a private key generation rule (e.g., the bip39 algorithm). The mnemonic words may be 12, 15, 18, 21 or 24 words, and are not limited herein. Further, after obtaining the mnemonics, the central node may generate K child private keys according to private key generation rules (e.g., the bip32 algorithm and the bip44 algorithm). It is understood that the generated sub-private key may be a 64-bit random number represented by a 16-ary 64-bit string.

At this time, the central node may obtain the hash encryption rule in the trusted application program, and generate the sub public keys corresponding to the K sub private keys, respectively. The hash encryption rule may be an elliptic curve algorithm, for example, the SECP256K1 algorithm. Because the SECP256K1 algorithm can calculate the sub public key corresponding to the sub private key when the sub private key is known; and the sub private key cannot be calculated reversely when the sub public key is known, so that the safety of the sub private key can be ensured.

It is to be understood that a sub-private key and a corresponding sub-public key of the sub-private key may form a key pair. For example, a sub-private key X₁And the sub private key X₁Corresponding sub public key Y₁A key pair M can be formed₁. According to the embodiment of the application, the sub public keys corresponding to the K sub private keys respectively can be obtained according to the K sub private keys, and finally, the K sub private key pairs corresponding to the first original account are obtained according to the K sub private keys and the sub public keys corresponding to the K sub private keys respectively.

And step S104, generating K anonymous accounts associated with the first primary account based on the sub public keys in the K sub secret key pairs, and establishing mapping hash values between the first primary account and the K anonymous accounts.

In particular, the amount of the solvent to be used,the central node can obtain the sub-key pair M from the K sub-key pairs_iAnd further can be used for the sub-secret key pair M_iSub public key Y in_iCarrying out Hash calculation to obtain a sub public key Y_iThe corresponding child public key hash value. Wherein i can be a positive integer less than or equal to K; sub-key pair M_iMay contain a sub public key Y_i(ii) a Sub public key Y_iIs formed by a sub-key pair M_iOf (2) a sub private key X_iObtained through a Hash encryption rule in a trusted application program; sub private key X_iIs derived from the private key generation rules in the trusted application. Further, the central node may obtain the address string and the check string associated with the sub public key hash value, and determine the sub key pair M based on the address string, the sub public key hash value, and the check string_iA corresponding anonymous account. It should be appreciated that in deriving the anonymous account for each of the K sub-key pairs, the central node may encrypt the first primary account via a trusted public key of a trusted key pair associated with the trusted execution environment, such that encrypted account encryption information may be derived. Further, the central node may establish a hash mapping relationship table between the account encryption information and the K anonymous accounts, and determine a mapping hash value between the first original account and the K anonymous accounts according to the K hash mapping relationships in the hash mapping relationship table. Wherein one hash mapping relationship may be used to determine one mapped hash value.

For easy understanding, please refer to fig. 6b, which is a schematic diagram of a scenario for generating an anonymous account according to an embodiment of the present application. The central node shown in fig. 6b may be a central node deployed with a trusted execution environment, and a trusted memory of the trusted execution environment may store a trusted application program with a derivative anonymous account function. The trusted application program may include a plurality of subprograms, and specifically may include a subprogram 1, a subprogram 2, and a subprogram 3. Each subroutine may correspond to an account data processing rule. For example, subroutine 1 may correspond to a private key generation rule, subroutine 2 may correspond to a hash encryption rule, and subroutine 3 may correspond to an account generation rule.

The account a in this embodiment may be an original account corresponding to the first user terminal, and the number of anonymous accounts generated by the central node and associated with the original account (for example, the account a) may be 4 as an example, so as to explain a specific implementation process of deriving the anonymous account by the central node.

As shown in FIG. 6b, the central node may invoke subroutine 1 in the trusted application, generating 4 sub-private keys associated with account A, namely, sub-private key X₁Sub private key X₂Sub private key X₃And a sub-private key X₄. Further, the central node may invoke subprogram 2 in the trusted application program to generate the sub public keys corresponding to the 4 sub private keys, respectively. I.e. the child private key X₁May correspond to a sub public key Y₁Sub private key X₂May correspond to a sub public key Y₂Sub private key X₃May correspond to a sub public key Y₃And a sub-private key X₄May correspond to a sub public key Y₄。

At this time, the central node may encrypt the child private key X₁And the child public key Y₁As a sub-key pair M₁Sub private key X₂And the child public key Y₂As a sub-key pair M₂Sub private key X₃And the child public key Y₃As a sub-key pair M₃Sub private key X₄And the child public key Y₄As a sub-key pair M₄Thus, 4 sub-key pairs can be obtained, and the 4 sub-key pairs are used as the key pair corresponding to the account a.

Further, the central node may invoke subroutine 3 in the trusted application, generating 4 anonymous accounts associated with account a based on the child public keys in the child key pairs. For example, the central node may obtain the sub-key pair M from 4 sub-key pairs₁And may further be used to pair the subkey M₁The sub public key Y in₁Carrying out Hash calculation to obtain a sub public key Y₁The corresponding child public key hash value 1. Further, the central node may obtain the address string 1 and the check string 1 associated with the sub public key hash value 1, and based on the address string 1, the sub public key hash value 1 and the check string 1, may determine thatSub-key pair M₁Corresponding anonymous account (e.g., account A)₁)。

The central node can continuously obtain the sub-key pair M from the 4 sub-key pairs₂And further can be used for the sub-secret key pair M₂The sub public key Y in₂Carrying out Hash calculation to obtain a sub public key Y₂The corresponding child public key hash value 2. Further, the central node may obtain the address string 2 and the check string 2 associated with the sub public key hash value 2, and based on the address string 2, the sub public key hash value 2 and the check string 2, may determine the sub key pair M₂Corresponding anonymous account (e.g., account A)₂)。

The central node can continuously obtain the sub-key pair M from the 4 sub-key pairs₃And further can be used for the sub-secret key pair M₃The sub public key Y in₃Carrying out Hash calculation to obtain a sub public key Y₃The corresponding child public key hash value 3. Further, the central node may obtain the address string 3 and the check string 3 associated with the sub public key hash value 3, and based on the address string 3, the sub public key hash value 3 and the check string 3, may determine the sub key pair M₃Corresponding anonymous account (e.g., account A)₃)。

The central node can continuously obtain the sub-key pair M from the 4 sub-key pairs₄And further can be used for the sub-secret key pair M₄The sub public key Y in₄Carrying out Hash calculation to obtain a sub public key Y₄The corresponding child public key hash value 4. Further, the central node may obtain the address string 4 and the check string 4 associated with the sub public key hash value 4, and based on the address string 4, the sub public key hash value 4, and the check string 4, may determine the sub key pair M₄Corresponding anonymous account (e.g., account A)₄)。

Thus, the central node may get 4 anonymous accounts associated with the first primary account, account a₁Account A₂Account A₃And account A₄. Further, the central node may establish a mapping hash between the first primary account and the 4 anonymous accounts. It can be understood thatIn the trusted execution environment, the central node may encrypt the account a with a trusted public key in a trusted key pair associated with the trusted execution environment, so as to obtain encrypted account encryption information 1. The central node may establish a hash mapping relationship table between the account encryption information 1 and the 4 anonymous accounts, and determine a mapping hash value between the first original account and the 4 anonymous accounts according to the 4 hash mapping relationships in the hash mapping relationship table.

For understanding, please refer to table 1, which is a hash mapping relationship table between the first primary account and the anonymous account provided in the embodiment of the present application. The user terminal corresponding to the first original account (e.g., account a) may be a first user terminal (e.g., user terminal a).

TABLE 1

As shown in table 1, the account encryption information 1 is obtained by the central node performing encryption processing on the account a through the trusted public key in the trusted key pair associated with the trusted execution environment. The account a may be an original account of a user (e.g., user 1) corresponding to the user terminal a having a network connection relationship with the central node. It is understood that the number of anonymous accounts of the user 1 generated by the central node in the trusted execution environment may be multiple, for example, 4, and specifically may include account a₁Account A₂Account A₃And account A₄. Wherein, account A₁Has a hash mapping relation with the account encryption information 1 and is connected with the account A₁The associated mapped hash value is hash value a₁. Account A₂Has a hash mapping relation with the account encryption information 1 and is in a hash mapping relation with the account A₂The associated mapped hash value is hash value a₂. Account A₃Has a hash mapping relation with the account encryption information 1 and is connected with the account A₃The associated mapped hash value is hash value a₃. Account A₄And accountThe encrypted information 1 has a hash mapping relation with the account A₄The associated mapped hash value is hash value a₄。

Further, please refer to fig. 7, which is a schematic diagram of an uplink scenario provided in an embodiment of the present application. As shown in fig. 7, a central node 700 in the embodiment of the present application may be deployed with a block link point of a trusted execution environment, where the block link point may be a central node of a block chain network in the embodiment corresponding to fig. 1, for example, the node 10A. Each consensus node 710 in the consensus network belongs to a blockchain network with the central node 700.

The blockchain 7 shown in fig. 7 may be a blockchain in a blockchain network corresponding to the blockchain system in fig. 1, where the blockchain 7 may be an identical blockchain shared by each node in the blockchain network to which the central node 700 belongs, and each node may obtain information stored in the blockchain 7. The blockchain 7 includes a block 70a, blocks 70b, …, a block 70n, and a target block, wherein the block 70a can be referred to as a created block of the blockchain 7. The target block in the blockchain 7 contains each anonymous account of the K anonymous accounts of the user 1 corresponding to the user terminal 200 (i.e., the first user terminal) and the mapping hash value corresponding to each anonymous account, as shown in fig. 2. Wherein K is a positive integer.

The central node 700 may write the mapping hash value corresponding to each anonymous account and each anonymous account into the blockchain 7 in the blockchain network corresponding to the central node 700. In other words, the central node 700 can obtain the chunk 70n with the largest generation timestamp from the blockchain 7. Further, the central node 700 may perform a packaging process on each anonymous account in the K anonymous accounts and a mapping hash value corresponding to each anonymous account, so as to obtain a to-be-verified block to be written into the block chain 7 to which the central node 700 belongs. At this time, the central node 700 may broadcast the to-be-verified block to the consensus node 710 on the block chain, so that the consensus node 710 performs consensus on the obtained to-be-verified block to obtain a consensus result. If the consensus result returned by the consensus node 710 includes consensus results exceeding 1/2 indicating that the consensus is successful, the central node 700 may determine that the chunk link points on the chunk chain have consensus, and may write the chunk to be verified into the chunk chain 7, that is, the chunk to be verified is used as the next chunk of the chunk 70n, so that each anonymous account and the mapping hash value corresponding to each anonymous account may be written into the chunk chain 7 in the chunk chain network corresponding to the central node 700.

Step S105, when the mapping hash value corresponding to each anonymous account and each anonymous account is written into the block chain to which the central node belongs, each anonymous account is returned to the first user terminal, so that the first user terminal executes the target service based on each anonymous account.

Specifically, when writing each anonymous account and the mapping hash value corresponding to each anonymous account into the blockchain to which the central node belongs, the central node may return each anonymous account to the first user terminal. At this time, the first user terminal may execute the target service based on any one of the anonymous accounts with the second user terminal having a network connection relationship with the first user terminal.

It should be understood that, as shown in fig. 2, when writing each anonymous account and the mapping hash value corresponding to each anonymous account into the block chain to which the central node 210 belongs, the central node 210 may take each anonymous account of the K anonymous accounts as a service processing result of the service processing request, and return each anonymous account to the user terminal 200.

Further, please refer to fig. 8, which is a flowchart illustrating an account data processing method according to an embodiment of the present application. The method may be performed interactively by a central node, having a trusted execution environment deployed therewith, and by a first user terminal. The central node where the trusted execution environment is deployed may be the central node 210 corresponding to fig. 2, and the first user terminal may be the user terminal 200 corresponding to fig. 2. As shown in fig. 8, the method may include:

step S201, a first user terminal sends a service processing request to a central node deployed with a trusted execution environment.

It should be understood that, before performing step S201, the first user terminal having a network connection relationship with the central node may sign the registration service data information associated with the first user terminal based on the user private key of the first user corresponding to the first user terminal, so that the user signature information may be obtained. Further, the first user terminal may generate, based on the user signature information, the registered service data information, and the user public key corresponding to the user private key, a service processing request for sending to the central node where the trusted execution environment is deployed, and may further send the service processing request to the central node.

Step S202, when the central node determines that the service processing request is a legal request, a first primary account of the first user is generated based on the user public key, and the first primary account is written into the trusted execution environment.

Step S203, the central node invokes a trusted application program in the trusted execution environment to generate a key pair corresponding to the first primary account.

Step S204, the central node generates K anonymous accounts associated with the first primary account based on the sub public keys in the K sub key pairs, and establishes mapping hash values between the first primary account and the K anonymous accounts.

In step S205, when writing each anonymous account and the mapping hash value corresponding to each anonymous account into the blockchain to which the central node belongs, the central node returns each anonymous account to the first user terminal, so that the first user terminal executes the target service based on each anonymous account.

For specific implementation of steps S201 to S205, reference may be made to the description of steps S101 to S105 in the embodiment corresponding to fig. 3, which will not be described herein again.

Step S206, the first user terminal sends an asset transfer request based on the first anonymous account.

Specifically, the first user terminal may sign the asset information through a sub-private key of the first anonymous account to obtain asset signature information. The first anonymous account may be used to instruct the first user terminal to execute a target service of asset transfer to a second user terminal corresponding to the second anonymous account. The asset information may include an amount of assets available for asset transfer. Further, the first user terminal may generate a request for sending an asset transfer to the central node based on the asset information corresponding to the target service, the asset signature information, and the target mapping hash value associated with the first anonymous account. At this point, the central node may receive the asset transfer request.

Step S207, after the asset signature information is successfully verified by the central node through the sub public key corresponding to the sub private key of the first anonymous account, the central node searches for a target hash mapping relationship associated with the target mapping hash value and the first anonymous account in the hash mapping relationship table, and determines account encryption information corresponding to the first original account based on the target hash mapping relationship.

Specifically, when receiving an asset transfer request sent by a first user terminal, a central node may verify asset signature information carried by the asset transfer request, and when the verification is successful, may search a target hash mapping relationship associated with a target mapping hash value and a first anonymous account in a hash mapping relationship table established by the central node. Further, the central node may determine, based on the target hash mapping relationship, account encryption information corresponding to the first primary account.

And step S208, the central node decrypts the account encrypted information based on the trusted private key in the trusted key pair to obtain a first original account corresponding to the first user terminal.

Specifically, the central node may decrypt, based on a trusted private key in the trusted execution environment, the account encryption information determined based on the target hash mapping relationship, so as to obtain a first original account of the first user corresponding to the first user terminal.

Step S209, the central node acquires the asset information from the first primary account, and transfers the asset information to the second user terminal through the first anonymous account, so that the second user terminal stores the asset information in the second primary account associated with the second anonymous account through the central node.

Specifically, when detecting that asset information corresponding to the target service exists in the first primary account, the central node may obtain the asset amount in the asset information from the first primary account, and write the asset amount into the first anonymous account. Further, the central node may lock the asset amount according to the anonymous child public key of the second anonymous account, and send the locked asset amount to the second anonymous account through the first anonymous account. At this time, the second user terminal corresponding to the second anonymous account may unlock the second user terminal to obtain the amount of the asset based on the anonymous sub-private key corresponding to the anonymous sub-public key. Further, the central node may write the asset amount into a second primary account corresponding to a second user in the trusted execution environment according to an association relationship between the second anonymous account and the second primary account corresponding to the second anonymous account; the second primary account is a primary account of a second user existing in the user set of the trusted execution environment; the associative relationship is determined by a mapping hash value between the encrypted data information of the second anonymous account and the second primary account.

The specific implementation of steps S206 to S209 may refer to the following description in the embodiment corresponding to fig. 9. Further, please refer to fig. 9, which is a scene diagram illustrating a target service execution according to an embodiment of the present application. Both the user terminal 910 and the user terminal 920 may be any user terminal in the user terminal cluster in the embodiment corresponding to fig. 1, and the central node 900 may be a block link point deployed with a trusted execution environment, where the block link point may be a central node in the block link network in the embodiment corresponding to fig. 1, for example, a node 10A.

The first user terminal in this embodiment may be the user terminal 910, the first user may be a user 1 corresponding to the user terminal 910, and the first primary account may be a primary account (for example, account a) of the user 1. The second user terminal in this embodiment may be the user terminal 920, the second user may be the user 2 corresponding to the user terminal 920, and the second original account may be an original account (for example, account B) of the user 2. The application scenario in the embodiment of the present application may take an electronic ticket processing scenario as an example, so as to illustrate a process in which the central node sends asset information (electronic ticket XX) in the account a corresponding to the user terminal 910 to the user terminal 920.

It should be appreciated that the user terminal 910 may send the asset transfer request to the central node 900 based on the first anonymous account. For ease of understanding, please refer to fig. 10, which is a schematic diagram of a scenario for generating an asset transfer request according to an embodiment of the present application. As shown in fig. 10, the ue in the embodiment of the present application may be the ue 910 shown in fig. 9. The user terminal 910 may receive each of K (e.g., 4) anonymous accounts associated with user 1 returned by the central node 900, which may specifically include account a₁Account A₂Account A₃And account A₄。

At this time, the user terminal 910 may select one anonymous account (e.g., account a) for performing the target service from the set of anonymous accounts shown in fig. 10₃) As a first anonymous account. The selection mode of the first anonymous user may be randomly selected, or may be directly determined according to the second user terminal executing the target service. For example, account A₁A target service in a financial scenario, Account A, may be performed with a second user terminal (e.g., user terminal 10)₂The target service in the game scenario may be executed with a second user terminal (e.g., user terminal 20), Account A₃The target service in the electronic ticket processing scenario, account a, may be executed with a second user terminal (e.g., user terminal 30)₄A target service in a life scenario (e.g., taxi taking, take out, etc.) may be performed with a second user terminal (e.g., user terminal 40). Therefore, when the user terminal 910 performs a target service of transferring electronic tickets with a second user terminal (i.e., the user terminal 920 shown in fig. 9), the user terminal 910 can directly transfer the account a₃The first anonymous account is determined to be used for carrying out the target business.

Further, the user terminal 910 may be based on a sub-private key of the first anonymous account (i.e., account A)₃Sub private key of) to sign asset information (e.g., electronic ticket XX) corresponding to the target service, so that asset signature information can be obtained. At this time, the user terminal 910 may communicate with the account a based on the asset information, the asset signature information, and the asset signature information₃The associated target mapping hash value (e.g.,hash value a₃) An asset transfer request is generated for transmission to the central node. As shown in FIG. 9, the central node 900 may receive an asset transfer request sent by a user terminal 910 and may be based on a child public key of a first anonymous account (e.g., account A)₃The sub public key) to check the asset signature information carried in the asset transfer request, and when the check is successful, the asset information (namely the electronic bill XX) can be obtained. The signature verification process of the asset signature information by the central node may refer to the signature verification process of the user signature information by the central node in fig. 4, which is not described again.

The hash mapping table shown in fig. 9 may contain the hash mapping relationship associated with the anonymous account of the user 1 (as shown in the above table 1). For example, with account A₁The associated hash mapping relationship may be hash mapping relationship 10a shown in fig. 9, and account a₂The associated hash mapping relationship may be hash mapping relationship 10b shown in fig. 9, and account a₃The associated hash mapping relationship may be hash mapping relationship 10c shown in fig. 9, and account a₄The associated hash mapping may be hash mapping 10d shown in fig. 9.

Further, the central node 900 may find the hash value mapped with the target (i.e. hash value a) in the hash mapping relation table as shown in fig. 9₃) And a first anonymous account (i.e., account A)₃) The associated target hash-map (e.g., hash-map 10c shown in fig. 9). It should be understood that account A₃May have a hash mapping relationship with the account encryption information 1. At this time, the central node 900 may decrypt the queried encrypted data information 1 based on a trusted private key in a trusted key pair in the trusted execution environment, so as to obtain an original account (for example, account a) corresponding to the user terminal 910, and further, the central node 900 may obtain the account a corresponding to the user 1 from the user set shown in fig. 9.

It should be understood that the trusted execution environment deployed in the central node 900 may be used to store the primary accounts of a plurality of users, the set of primary accounts of the users may be collectively referred to as a user set, it should be understood that the primary accounts of the user set are all protected by the trusted execution environment, and external users include real account information that the users themselves are difficult to know about the primary accounts. The user set may include primary accounts corresponding to users, for example, primary account of user 1 (e.g., account a) corresponding to user terminal 910, primary account of user 2 (e.g., account B) corresponding to user terminal 920, …, and primary account of user 3 (e.g., account C) corresponding to user terminal 930.

At this time, the central node 900 may detect asset information in the account a, and when it is detected that asset information corresponding to the target service exists in the account a, may obtain an asset amount (i.e., the electronic ticket XX) corresponding to the asset information from the account a, and write the electronic ticket XX into the first anonymous account.

Further, central node 900 may obtain a second anonymous account from the blockchain network (e.g., account B) for performing the target service₁) And locking the electronic bill XX according to the anonymous sub public key, so as to obtain the locked electronic bill XX. At this time, the central node 900 may transmit the locked electronic ticket XX to the account B of the user terminal 920₁And further allows the user terminal 920 to be based on account B₁The anonymous sub private key unlocks the locked electronic bill XX, so that the electronic bill XX can be obtained.

Further, please refer to table 2, which is a hash mapping relationship table between the second primary account and the anonymous account provided in the embodiment of the present application. The user terminal corresponding to the second original account (e.g., account B) may be a second user terminal (e.g., user terminal 920).

TABLE 2

As shown in Table 2 above, account encryption information 2 is used by central node 900 to encrypt account B with a trusted public key of a trusted key pair associated with a trusted execution environmentAnd (4) processing the obtained product. The account B may be an original account of a user (e.g., user 2) corresponding to the user terminal 920 having a network connection relationship with the central node 900. The number of anonymous accounts of the user 2 generated by the central node 900 in the trusted execution environment may be multiple, for example, 3, and specifically may include an account B₁Account B₂And account B₃. Wherein account B₁Has a hash mapping relation with the account encryption information 2 and is connected with the account B₁The associated mapped hash value is hash value b₁. Account B₂Has a hash mapping relation with the account encryption information 2 and is connected with the account B₂The associated mapped hash value is hash value b₂. Account B₃Has a hash mapping relation with the account encryption information 2 and is connected with the account B₃The associated mapped hash value is hash value b₃。

It will be appreciated that the user terminal 920 may write the electronic ticket XX in the second anonymous account to the second original account stored in the trusted memory by the central node 900 when the user terminal 920 unlocks the funding amount (i.e., the electronic ticket XX). It should be understood that the central node 900 may query the account B of the user terminal 920 in table 2 above₁An association with account B of the user terminal 920. Wherein, the central node 900 can look up the account B in the table 2₁The corresponding account encryption information 2 may further be decrypted based on the trusted private key in the trusted key pair, so as to obtain the original account (i.e., account B) corresponding to the user terminal 920. At this point, the central node 920 may write the electronic ticket XX into account B, thereby enabling the transfer of asset information.

Optionally, taking a game scene as an example, the asset information in the target service may also be a virtual asset in the game scene, for example, a game chip used for purchasing a virtual item. In this gaming scenario, the user terminal 910 may send asset information (e.g., gaming tokens) in the account (anonymous account or primary account) of user 1 to which the user terminal 910 corresponds to a second anonymous account (e.g., account B) of the user terminal 920 through the central node 900₂) Such that the user terminal 920 may further aggregate the gaming currency transferred to the second anonymous account into account B associated with the second anonymous account via the central node 900.

For instance, the user terminal 910 may be based on a first anonymous account of user 1 (e.g., account A)₂) And sending an asset transfer request aiming at the target service to the central node. The asset transfer request may carry asset signature information and asset information for signing the asset information based on the user private key of the user 1. At this time, the central node 900 may verify the asset signature information based on the user public key of the user 1, and may detect the account a when the verification is successful₂The asset information of (1). As shown in fig. 10, each anonymous account in the set of anonymous accounts of the user 1 may temporarily store asset information obtained after a transaction with another user terminal. For example, account A₂In which 3 game pieces can be stored. Central node 900 may aggregate the asset amount corresponding to the asset information of each anonymous account in user 1's set of anonymous accounts to user 1's primary account (e.g., account a) on an aggregation day (e.g., monday) associated with user 1. Wherein, the summary day associated with the user 1 may be determined by the user 1 corresponding to the user terminal 910. For example, a day of the month (15 days per month), a day of the week (monday), a time of day (two afternoon hours per day), etc.

It will be appreciated that if account A is considered₂The amount of money corresponding to the asset information stored in (1) may include 15 coins, and thus may be understood as an account a₂The asset information of (2) has asset information corresponding to the target service, and at this time, the central node 900 may slave to account a₂Directly acquire the asset amount (for example, 10 coins) of the asset information corresponding to the target service. If account A₂The asset information of (2) includes only 3 game pieces in the asset amount, and it can be understood that account A is an account₂The asset amount corresponding to the asset information is not enough to pay the asset amount of the asset information corresponding to the target service (i.e. the above 10 coins), at this time, the central node 900 needs to look up the account a based on the hash mapping table shown in fig. 9₂A hash mapping relation (e.g., hash mapping relation 10b) with the account encryption information 1, and thus the account a can be determined₂The corresponding primary account of user 1 (i.e., account a). Having account A in detecting account A₂When the asset amount of the asset amount corresponding to the target service is poor (i.e., 7 tokens), the central node 900 may obtain the 7 tokens from account a and write the 7 tokens to account a in the trusted execution environment₂To account A₂The asset amount in the target business can meet the asset information yield corresponding to the target business. At this point, central node 900 may be credited from account A₂The asset amount (i.e. 10 coins) of the asset information corresponding to the target service is obtained.

Further, the central node may obtain a second anonymous account (e.g., account B)₂) The anonymous sub-public key performs asset locking on the 10 game coins to obtain locked game coins, and sends the locked game coins to the account B₂Further enabling the user terminal 920 to be based on account B₂The anonymous sub-private key of (a) unlocks the locked tokens, so that 10 tokens can be obtained.

It is understood that the central node 900 may account B for the summary day determined by user 2 corresponding to user terminal 920₂The asset amount corresponding to the asset information included in (B) and the asset amount of the asset information included in the other anonymous account of the user 2 are collected into the original account (i.e., account B) of the user 2 based on the above table 2. With account B₂For example, during a summary day associated with user 2 (e.g., 10 am each day), central node 900 may query user terminal 920 for account B in Table 2 above₂An association with account B of the user terminal 920. Wherein, the central node 900 can look up the account B in the table 2₂The corresponding account encryption information 2 may further be decrypted based on the trusted private key in the trusted key pair, so as to obtain the original account (i.e., account B) corresponding to the user terminal 920. At this point, the central node 920 may write the 10 tokens into account B.

Further, please refer to fig. 11, which is a schematic structural diagram of an account data processing apparatus according to an embodiment of the present application. The account data processing means may be a computer program (comprising program code) running on a computer device, e.g. an application software; the account data processing device can be used for executing corresponding steps in the method provided by the embodiment of the application. As shown in fig. 11, the account data processing apparatus 1 may operate in a central node deployed with a trusted execution environment, where the central node may be the node 210 in the embodiment corresponding to fig. 2. The account data processing apparatus 1 may include: the system comprises an acquisition module 10, a signature verification module 11, a first determination module 12, a second determination module 13, a generation module 14, a calling module 15, an establishment module 16, a packaging processing module 17, a broadcasting module 18, a writing module 19, a returning module 20, a request receiving module 21, a searching module 22, a decryption module 23 and a transferring module 24.

The obtaining module 10 is configured to obtain a service processing request sent by a first user terminal; the service processing request carries a user public key of a first user corresponding to the first user terminal; the user public key is used for indicating the central node to generate a first original account of the first user;

the signature verification module 11 is configured to verify the signature of the user signature information based on the user public key to obtain a signature verification result;

the first determining module 12 is configured to determine that the first user is a valid user and determine a service processing request initiated by the first user as a valid request when the verification result indicates that the verification is successful;

the second determining module 13 is configured to determine that the first user is an illegal user and determine the service processing request initiated by the first user as an illegal request when the verification result indicates that the verification fails.

The generating module 14 is configured to generate a first primary account of the first user based on the user public key and write the first primary account into the trusted execution environment when it is determined that the service processing request is a legal request.

Wherein the generating module 14 comprises: a first hash calculation unit 141, a second hash calculation unit 142, and an encoding unit 143.

The first hash calculation unit 141 is configured to, when it is determined that the service processing request is a legal request, perform hash calculation on the user public key according to the first hash rule and the second hash rule to obtain a public key hash value corresponding to the user public key;

the second hash calculation unit 142 is configured to obtain a first splicing character string by using the address version number of one byte as the head of the public key hash value, perform hash calculation on the first splicing character string to obtain a hash value to be processed corresponding to the first splicing character string, and obtain a check value of the public key hash value from the hash value to be processed;

the encoding unit 143 is configured to obtain a second splicing character string by using the check value as the tail of the first splicing character string, perform encoding processing on the second splicing character string, use the encoded character string obtained after the encoding processing as a first original account of the first user, and write the first original account into the trusted execution environment.

For specific implementation manners of the first hash calculation unit 141, the second hash calculation unit 142, and the encoding unit 143, reference may be made to the description of step S102 in the embodiment corresponding to fig. 3, and details will not be further described here.

The calling module 15 is configured to call a trusted application in the trusted execution environment, and generate a key pair corresponding to the first primary account; the key pair comprises K sub-key pairs; k is a positive integer; each of the K sub-key pairs contains a sub-public key configured for the first primary account.

Wherein, this calling module 15 includes: calling section 151, generating section 152, and first determining section 153.

The invoking unit 151 is configured to invoke a trusted application in the trusted execution environment, obtain a private key generation rule in the trusted application, and generate K sub-private keys associated with the first original account according to the private key generation rule;

the generating unit 152 is configured to generate sub public keys corresponding to the K sub private keys respectively according to a hash encryption rule in the trusted application; one sub private key corresponds to one sub public key, and one sub private key and one sub public key are used for constructing one sub private key pair;

the first determining unit 153 is configured to determine K sub-key pairs corresponding to the first primary account according to the K sub-private keys and sub-public keys corresponding to the K sub-private keys, respectively, and use the K sub-key pairs as key pairs corresponding to the first primary account.

For specific implementation manners of the invoking unit 151, the generating unit 152, and the first determining unit 153, reference may be made to the description of step S103 in the embodiment corresponding to fig. 3, and details will not be further described here.

The establishing module 16 is configured to generate K anonymous accounts associated with the first primary account based on the sub public keys of the K sub key pairs, and establish a mapping hash value between the first primary account and the K anonymous accounts.

Wherein, the establishing module 16 includes: a first acquisition unit 161, a second determination unit 162, an encryption unit 163, and a creation unit 164.

The first obtaining unit 161 is configured to obtain a sub-key pair M from the K sub-key pairs_i(ii) a i is a positive integer less than or equal to K; sub-key pair M_iIn which the sub public key Y is included_i(ii) a Sub public key Y_iIs formed by a sub-key pair M_iOf (2) a sub private key X_iObtained through a Hash encryption rule in a trusted application program; sub private key X_iIs obtained by a private key generation rule in the trusted application;

the second determining unit 162 is used for determining the sub-key pair M_iThe sub public key Y in_iCarrying out Hash calculation to obtain a sub public key Y_iCorresponding sub public key hash value, obtaining address character string and check character string associated with sub public key hash value, and determining sub key pair M based on address character string, sub public key hash value and check character string_iA corresponding anonymous account;

the encrypting unit 163 is configured to, when obtaining an anonymous account of each of the K sub-key pairs, encrypt, in the trusted execution environment, the first original account by using a trusted public key in the trusted key pair associated with the trusted execution environment, so as to obtain encrypted account encryption information;

the establishing unit 164 is configured to establish a hash mapping relationship table between the account encryption information and the K anonymous accounts, and determine a mapping hash value between the first original account and the K anonymous accounts according to the K hash mapping relationships in the hash mapping relationship table; a hash mapping relationship is used to determine a mapped hash value.

For specific implementation manners of the first obtaining unit 161, the second determining unit 162, the encrypting unit 163 and the establishing unit 164, reference may be made to the description of step S104 in the embodiment corresponding to fig. 3, and details will not be further described here.

The packaging processing module 17 is configured to package each anonymous account in the K anonymous accounts and the mapping hash value corresponding to each anonymous account to obtain a to-be-verified block to be written into the block chain to which the central node belongs;

the broadcasting module 18 is configured to broadcast the to-be-verified block to the consensus node on the block chain, so that the consensus node performs consensus on the acquired to-be-verified block to obtain a consensus result; the common node and the central node are block chain nodes on a block chain;

the writing module 19 is configured to determine that the block chain nodes on the block chain achieve consensus and write the block to be verified into the block chain as the target block if the consensus result exceeding 1/2 in the consensus results returned by the consensus nodes indicates that the consensus is successful.

The returning module 20 is configured to, when writing each anonymous account and the mapping hash value corresponding to each anonymous account into the blockchain to which the central node belongs, return each anonymous account to the first user terminal, so that the first user terminal executes the target service based on each anonymous account.

the request receiving module 21 is configured to receive an asset transfer request sent by the first user terminal based on the first anonymous account; the asset transfer request carries asset information corresponding to the target service, asset signature information corresponding to the asset information and a target mapping hash value associated with the first anonymous account; the asset signature information is obtained by the first user terminal signing the asset information through the sub-private key of the first anonymous account;

the searching module 22 is configured to search a target hash mapping relationship associated with the target mapping hash value and the first anonymous account in the hash mapping relationship table after the asset signature information is successfully verified through the sub public key corresponding to the sub private key of the first anonymous account, and determine account encryption information corresponding to the first original account based on the target hash mapping relationship; the target Hash mapping relation is one Hash mapping relation in a Hash mapping relation table;

the decryption module 23 is configured to decrypt the account encrypted information based on the trusted private key in the trusted key pair to obtain a first original account corresponding to the first user terminal;

the transfer module 24 is configured to obtain the asset information from the first primary account, and transfer the asset information to the second user terminal through the first anonymous account, so that the second user terminal stores the asset information in the second primary account associated with the second anonymous account through the central node.

the transfer module 24 includes: a second acquisition unit 241, a locking unit 242, and a writing unit 243.

The second obtaining unit 241 is configured to, when it is detected that asset information corresponding to the target service exists in the first original account, obtain the asset amount in the asset information from the first original account, and write the asset amount into the first anonymous account;

the locking unit 242 is configured to lock the asset amount according to the anonymous sub public key of the second anonymous account, and send the locked asset amount to the second anonymous account through the first anonymous account, so that the second user terminal corresponding to the second anonymous account is unlocked based on the anonymous sub private key corresponding to the anonymous sub public key to obtain the asset amount.

The writing unit 243 is configured to write the asset amount into a second primary account corresponding to a second user in the trusted execution environment according to an association relationship between the second anonymous account and the second primary account corresponding to the second anonymous account; the second user is a user of the second user terminal; the second primary account is a primary account of a second user existing in the user set of the trusted execution environment; the associative relationship is determined by a mapping hash value between the encrypted data information of the second anonymous account and the second primary account.

For specific implementation manners of the second obtaining unit 241, the locking unit 242, and the writing unit 243, reference may be made to the description of step S209 in the embodiment corresponding to fig. 8, and details will not be further described here.

For specific implementation manners of the obtaining module 10, the signature checking module 11, the first determining module 12, the second determining module 13, the generating module 14, the calling module 15, the establishing module 16, the packing processing module 17, the broadcasting module 18, the writing module 19, the returning module 20, the request receiving module 21, the searching module 22, the decrypting module 23 and the transferring module 24, reference may be made to the description of step S201 to step S209 in the embodiment corresponding to fig. 8, and details will not be further described here. In addition, the beneficial effects of the same method are not described in detail.

Further, please refer to fig. 12, which is a schematic diagram of a computer device according to an embodiment of the present application. As shown in fig. 12, the computer device 1000 may be the node 210 in the corresponding embodiment of fig. 2, and the computer device 1000 may include: at least one processor 1001, such as a CPU, at least one network interface 1004, a user interface 1003, memory 1005, at least one communication bus 1002. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may include a Display (Display) and a Keyboard (Keyboard), and the network interface 1004 may optionally include a standard wired interface and a wireless interface (e.g., WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk memory. The memory 1005 may optionally also be at least one storage device located remotely from the aforementioned processor 1001. As shown in fig. 12, a memory 1005, which is a kind of computer storage medium, may include therein an operating system, a network communication module, a user interface module, and a device control application program.

In the computer apparatus 1000 shown in fig. 12, the network interface 1004 is mainly used for network communication with a first user terminal and a second user terminal; the user interface 1003 is an interface for providing a user with input; and the processor 1001 may be used to invoke a device control application stored in the memory 1005 to implement:

It should be understood that the computer device 1000 described in this embodiment of the application may perform the description of the method for processing the account data in the embodiment corresponding to fig. 3 and fig. 8, and may also perform the description of the apparatus 1 for processing the account data in the embodiment corresponding to fig. 11, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.

Further, here, it is to be noted that: an embodiment of the present application further provides a computer-readable storage medium, where the computer program executed by the aforementioned account data processing apparatus 1 is stored in the computer-readable storage medium, and the computer program includes program instructions, and when the processor executes the program instructions, the description of the account data processing method in the embodiment corresponding to fig. 3 or fig. 8 can be performed, so that details are not described here again. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in embodiments of the computer-readable storage medium referred to in the present application, reference is made to the description of embodiments of the method of the present application. As an example, program instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network, which may comprise a block chain system.

Further, please refer to fig. 13, which is a schematic structural diagram of an account data processing apparatus according to an embodiment of the present application. The account data processing means may be a computer program (comprising program code) running on a computer device, e.g. an application software; the account data processing device can be used for executing corresponding steps in the method provided by the embodiment of the application. As shown in fig. 13, the account data processing apparatus 2 may be operated in a first user terminal, which may be 200 of the user terminal in the embodiment corresponding to fig. 2. The account data processing apparatus 2 may include: a transmitting module 100 and a receiving module 200.

The sending module 100 is configured to send a service processing request to a central node deployed with a trusted execution environment; the service processing request carries a user public key of a first user corresponding to the first user terminal; the user public key is used for instructing the central node to generate a first primary account of the first user.

Wherein, the sending module 100 includes: a signature unit 1010 and a request generation unit 1020.

The signature unit 1010 is configured to sign, based on a user private key of a first user corresponding to a first user terminal, registered service data information associated with the first user terminal to obtain user signature information;

the request generating unit 1020 is configured to generate a service processing request for sending to a central node where a trusted execution environment is deployed, based on user signature information, registered service data information, and a user public key corresponding to a user private key; and the service processing request is used for indicating the central node to carry out signature verification on the user signature information based on the user public key carried by the service processing request.

For a specific implementation of the list element 1010 and the request generating unit 1020, reference may be made to the description of step S201 in the embodiment corresponding to fig. 8, and details will not be further described here.

The receiving module 200 is configured to receive K anonymous accounts returned by the central node; k is a positive integer; the K anonymous accounts are generated by the central node based on the sub public keys in the K sub key pairs corresponding to the first original account; the K sub-key pairs are generated by the central node invoking a trusted application in the trusted execution environment.

For specific implementation of the sending module 100 and the receiving module 200, reference may be made to the description of step S201 to step S209 in the embodiment corresponding to fig. 8, and details will not be further described here. In addition, the beneficial effects of the same method are not described in detail.

Further, please refer to fig. 14, which is a schematic diagram of a computer device according to an embodiment of the present application. As shown in fig. 14, the computer device 3000 may be the user terminal 200 in the embodiment corresponding to fig. 2, and the computer device 3000 may include: at least one processor 3001, e.g., a CPU, at least one network interface 3004, a user interface 3003, memory 3005, at least one communication bus 3002. The communication bus 3002 is used to realize connection communication between these components. The user interface 3003 may include a Display screen (Display) and a Keyboard (Keyboard), and the network interface 3004 may optionally include a standard wired interface and a wireless interface (e.g., WI-FI interface). The memory 3005 may be a high-speed RAM memory or a non-volatile memory (e.g., at least one disk memory). The storage 3005 may optionally also be at least one storage device located remotely from the aforementioned processor 3001. As shown in fig. 14, the memory 3005, which is a kind of computer storage medium, may include therein an operating system, a network communication module, a user interface module, and a device control application program.

In the computer device 3000 shown in fig. 14, the network interface 3004 is mainly used for network communication with a central node in which a trusted execution environment is deployed; and the user interface 3003 is an interface mainly for providing input to the user; and the processor 3001 may be configured to invoke a device control application stored in the memory 3005 to implement:

It should be understood that the computer device 3000 described in this embodiment may perform the description of the account data processing method in the embodiment corresponding to fig. 8, and may also perform the description of the account data processing apparatus 2 in the embodiment corresponding to fig. 13, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.

Further, here, it is to be noted that: an embodiment of the present application further provides a computer-readable storage medium, where the computer program executed by the aforementioned account data processing apparatus 2 is stored in the computer-readable storage medium, and the computer program includes program instructions, and when the processor executes the program instructions, the description of the account data processing method in the embodiment corresponding to fig. 8 can be performed, so that details are not repeated here. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in embodiments of the computer-readable storage medium referred to in the present application, reference is made to the description of embodiments of the method of the present application. As an example, program instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network, which may comprise a block chain system.

Further, please refer to fig. 15, which is a schematic structural diagram of an account data processing system according to an embodiment of the present application. The account data processing system 3 may include an account data processing apparatus 1a and an account data processing apparatus 2 a. The account data processing apparatus 1a may be the account data processing apparatus 1 in the embodiment corresponding to fig. 11, and it is understood that the account data processing apparatus 1a may be integrated in the central node 210 in the embodiment corresponding to fig. 2, and therefore, details thereof will not be described here. The account data processing apparatus 2a may be the account data processing apparatus 2 in the embodiment corresponding to fig. 13, and it is understood that the account data processing apparatus 2a may be integrated in the user terminal 200 in the embodiment corresponding to fig. 2, and therefore, details thereof will not be described here. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in the embodiments of the account data processing system related to the present application, please refer to the description of the embodiments of the method of the present application.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.

The above disclosure is only for the purpose of illustrating the preferred embodiments of the present application and is not to be construed as limiting the scope of the present application, so that the present application is not limited thereto, and all equivalent variations and modifications can be made to the present application.

Claims

1. An account data processing method, comprising:

a first user terminal sends a service processing request to a central node with a trusted execution environment; the service processing request carries a user public key of a first user corresponding to the first user terminal; the user public key is used for instructing the central node to generate a first primary account of the first user;

when the central node determines that the service processing request is a legal request, generating the first primary account based on the user public key, and writing the first primary account into the trusted execution environment;

the central node calls a trusted application program in the trusted execution environment, acquires a private key generation rule in the trusted application program, and generates K sub-private keys associated with the first original account according to the private key generation rule; the K is a positive integer;

the central node generates sub public keys corresponding to the K sub private keys respectively through a Hash encryption rule in the trusted application program; one sub private key corresponds to one sub public key, and one sub private key and one sub public key are used for constructing one sub private key pair;

the central node determines K sub-key pairs corresponding to the first original account according to the K sub-private keys and sub-public keys corresponding to the K sub-private keys respectively, and takes the K sub-key pairs as key pairs corresponding to the first original account;

the central node calls an account generation rule in the trusted application program, generates K anonymous accounts associated with the first primary account based on the sub public keys in the K sub secret key pairs, and establishes mapping hash values between the first primary account and the K anonymous accounts;

when the central node writes each anonymous account and the mapping hash value corresponding to each anonymous account into the block chain to which the central node belongs, each anonymous account is returned to the first user terminal;

and when the first user terminal receives the K anonymous accounts returned by the central node, executing target service based on each anonymous account.

2. The method of claim 1, wherein sending, by the first user terminal, a traffic processing request to a central node deployed with a trusted execution environment comprises:

the first user terminal performs hash calculation on the registered service data information associated with the first user terminal to obtain summary information of the registered service data information;

the first user terminal signs the summary information of the registered service data information based on a user private key of a first user corresponding to the first user terminal to obtain user signature information;

the first user terminal generates a service processing request based on the user signature information, the registration service data information and a user public key corresponding to the user private key;

and the first user terminal sends the service processing request to a central node with a trusted execution environment.

3. The method of claim 2, further comprising:

when the central node receives the service processing request, the signature verification is carried out on the user signature information based on the user public key, and summary information after signature verification is obtained; the summary information after the signature verification is obtained by the first user terminal through Hash calculation on the registered service data information based on Hash algorithm;

the central node performs hash calculation on the registered service data information by using the same hash algorithm as the first user terminal to obtain hash-calculated abstract information;

the central node compares the summary information after the signature verification with the summary information after the hash calculation to obtain a signature verification result;

and when the verification result indicates that the verification is successful, the central node determines that the first user is a legal user and determines the service processing request initiated by the first user as a legal request.

4. The method according to claim 3, wherein the central node compares the digest information after the signature verification with the digest information after the hash calculation to obtain a signature verification result, and the method comprises:

the central node compares the summary information after the signature verification with the summary information after the hash calculation;

if the summary information after the signature verification is different from the summary information after the hash calculation, the central node obtains a signature verification result for indicating the signature verification failure;

and if the summary information after the signature verification is the same as the summary information after the hash calculation, the central node obtains a signature verification result for indicating that the signature verification is successful.

5. The method of claim 1, wherein the central node, when determining that the transaction processing request is a legitimate request, generates a first primary account of the first user based on the user public key, and writes the first primary account to the trusted execution environment, and wherein the method comprises:

when the central node determines that the service processing request is a legal request, performing hash calculation on the user public key through a first hash rule and a second hash rule to obtain a public key hash value corresponding to the user public key; the first hash rule and the second hash rule are different hash rules;

the central node takes the address version number of one byte as the head of the public key hash value, and splices the address version number and the public key hash value to obtain a first spliced character string;

the central node performs hash calculation on the first splicing character string to obtain a hash value to be processed corresponding to the first splicing character string, and acquires a check value of the public key hash value from the hash value to be processed;

and the central node takes the check value as the tail part of the first splicing character string to obtain a second splicing character string, encodes the second splicing character string, takes the encoded character string obtained after encoding as a first original account of the first user, and writes the first original account into a user set in the trusted execution environment.

6. The method of claim 1, wherein the central node invokes an account generation rule in the trusted application to generate K anonymous accounts associated with the first primary account based on the child public keys of the K child key pairs, and wherein establishing a mapping hash between the first primary account and the K anonymous accounts comprises:

the central node acquires a sub-key pair M from the K sub-key pairs_i(ii) a i is a positive integer less than or equal to K; the sub-key pair M_iIn which the sub public key Y is included_iAnd a sub private key X_i(ii) a Said sub public key Y_iIs formed by said sub-private key X_iObtained through the Hash encryption rule; the sub private key X_iIs derived from the private key generation rule;

the central node calls an account generation rule in the trusted application program to the sub-key pair M_iSaid sub public key Y in (1)_iCarrying out Hash calculation to obtain the sub public key Y_iCorresponding sub public key hash value, obtaining address character string and check character string associated with the sub public key hash value, and determining the sub key pair M based on the address character string, the sub public key hash value and the check character string_iA corresponding anonymous account;

when the central node obtains the anonymous account of each of the K sub-key pairs, in the trusted execution environment, the central node encrypts the first original account through a trusted public key in a trusted key pair associated with the trusted execution environment to obtain encrypted account encryption information;

the central node establishes a Hash mapping relation table between the account encryption information and K anonymous accounts, and determines mapping Hash values between the first original account and the K anonymous accounts according to K Hash mapping relations in the Hash mapping relation table; a hash mapping relationship is used to determine a mapped hash value.

7. The method of claim 1, wherein the set of anonymous accounts of the first user includes the K anonymous accounts returned by the central node; temporarily storing the asset yield corresponding to the asset information obtained after the transaction of the first user in each anonymous account of the K anonymous accounts;

the method further comprises the following steps:

the central node collects the asset amount corresponding to the asset information of each anonymous account in the anonymous account set to the first primary account of the first user in a collection day associated with the first user; the aggregation day associated with the first user is determined by the first user.

8. The method of claim 1, further comprising:

when the first user terminal executes the target service for transferring assets to a second user terminal corresponding to a second anonymous account, selecting one anonymous account for executing the target service from the anonymous account set of the first user according to the second user terminal, and taking the selected anonymous account as a first anonymous account; the anonymous account set comprises the K anonymous accounts returned by the central node;

the first user terminal signs the asset information corresponding to the target service through the sub-private key of the first anonymous account to obtain asset signature information;

and the first user terminal generates an asset transfer request for sending to the central node based on the asset information corresponding to the target service, the asset signature information and the target mapping hash value associated with the first anonymous account.

9. The method of claim 8, wherein the asset information corresponding to the target service comprises a resource amount for performing the asset transfer;

the method further comprises the following steps:

when the center node receives the asset transfer request sent by the first user terminal, verifying the asset signature information carried by the asset transfer request through a sub public key corresponding to a sub private key of the first anonymous account;

when the central node is successfully verified, detecting asset information stored in the first anonymous account;

if the asset amount corresponding to the asset information stored in the first anonymous account includes the asset amount used for transferring the asset, the central node determines that the asset information stored in the first anonymous account has the asset information corresponding to the target service;

and the central node acquires the asset information resource amount corresponding to the target service from the first anonymous account.

10. The method of claim 9, further comprising:

if the asset quantity corresponding to the asset information stored in the first anonymous account does not include the asset quantity for asset transfer, the central node takes a difference value between the asset quantity corresponding to the asset information stored in the first anonymous account and the asset quantity for asset transfer as an asset quantity difference of the asset information corresponding to the target service;

the central node searches a target Hash mapping relation associated with the target Hash mapping value and the first anonymous account in a Hash mapping relation table, and determines account encryption information corresponding to the first original account based on the target Hash mapping relation; the target hash mapping relation is a hash mapping relation in the hash mapping relation table;

the central node decrypts the account encryption information based on a trusted private key in a trusted key pair associated with the trusted execution environment to obtain the first original account corresponding to the first user terminal;

the central node detects asset information in the first primary account in a user set of the trusted execution environment;

when detecting that the asset quantity difference exists in the first primary account, the central node acquires the asset quantity difference from the first primary account and writes the asset quantity difference into the first anonymous account;

and the central node acquires the asset information resource yield corresponding to the target service from the first anonymous account written with the resource yield difference.

11. The method according to claim 9 or 10, characterized in that the method further comprises:

the central node acquires an anonymous sub public key of the second anonymous account from a block chain network to which the central node belongs;

the central node locks the asset quantity of the asset information corresponding to the target service according to the anonymous sub public key to obtain the locked asset quantity;

and the central node sends the locked asset quantity to the second anonymous account through the first anonymous account so that the second user terminal unlocks the locked asset quantity based on the anonymous sub-private key corresponding to the anonymous sub-public key to obtain the asset information asset quantity corresponding to the target service.

12. The method of claim 11, further comprising:

the central node writes the asset amount of the asset information corresponding to the target service into a second original account corresponding to a second user in the trusted execution environment according to the incidence relation between the second anonymous account and the second original account corresponding to the second anonymous account; the second user is a user of the second user terminal; the second primary account is a primary account of the second user existing in the user set; the incidence relation is determined by a mapping hash value between the encrypted data information of the second anonymous account and the second original account.

13. A computer device, comprising: a processor, a memory, and a network interface;

the processor is coupled to a memory for providing data communication functionality, a network interface for storing program code, and the processor is configured to invoke the program code to perform the method of any of claims 1-12.

14. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program comprising program instructions that, when executed by a processor, perform the method of any of claims 1-12.