A digital identity management method, blockchain node and system

Abstract

A digital identity management method, blockchain node, and system, the system comprising a management device, a blockchain, and a user device, wherein the blockchain stores identity information of a user corresponding to a first account, the management device comprising a master public key and a master private key, and the management device being configured to: obtain the identity information of the user corresponding to the first account from the blockchain; generate an identity information list of the user, and generate a first child private key based on the identity information list, the master public key, and the master private key; send the first child private key and the identity information list to the blockchain; the blockchain being configured to store the first child private key and the identity information list; and the user device being configured to obtain the first child private key and the identity information list from the blockchain, and generate an identity signature for an account using the first child private key and preset policy information.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of blockchain technology, and in particular, relate to a digital identity management method, blockchain node, and system. Background Art

[0002] Blockchain is a novel application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain system, data blocks are linked sequentially in chronological order to form a chain-like data structure, cryptographically guaranteeing an unalterable and unforgeable distributed ledger. Due to its decentralized, tamper-proof, and autonomous nature, blockchain is gaining increasing attention and application. Currently, users typically participate in blockchain-based businesses anonymously, and the identities of the actual users associated with the blockchain accounts involved in a transaction cannot be determined from blockchain transactions. Summary of the Invention

[0003] The purpose of this invention is to provide a digital identity management solution for managing the digital identity corresponding to a blockchain account.

[0004] In a first aspect, the present specification provides a digital identity management system, including a management device, a blockchain, and a user device. The blockchain stores identity information of a user corresponding to a first account. The management device includes a master public key and a master private key generated based on an attribute encryption algorithm.

[0005] The management device is configured to: obtain identity information of a user corresponding to the first account from the blockchain; generate an identity information list of the user; generate a first child private key based on the identity information list, the master public key, and the master private key, wherein the identity information list includes the first account and the identity information; and send the first child private key and the identity information list to the blockchain;

[0006] The blockchain is used to store the first sub-private key and the identity information list;

[0007] The user device is used to obtain the first sub-private key and the identity information list from the blockchain, perform attribute signing based on the first sub-private key and preset policy information, and generate an identity signature for the first account, where the preset policy information includes the first account and the identity identifier of the user.

[0008] In one embodiment, the user device is further configured to send the identity signature to the blockchain, and the blockchain is further configured to store the identity signature and the first account in association.

[0009] In one embodiment, a first contract is deployed in the blockchain, and when the management device sends the first child private key and the identity information list to the blockchain, it is specifically configured to: send a first transaction to the blockchain that calls the first contract, where the first transaction includes the first child private key and the identity information list;

[0010] When storing the first sub-private key and the identity information list, the blockchain is specifically used to: store the first sub-private key and the identity information list in association with the first account in the account information list in the contract state of the first contract according to the first transaction.

[0011] In one embodiment, the first contract makes the first sub-private key and the identity information list non-updatable and non-deletable after being stored in the account information list.

[0012] In one embodiment, the first transaction includes a first account and a first ciphertext obtained by encrypting the sub-private key of the first account and the identity information list, the first ciphertext is generated by encrypting the public key of the first account, and the blockchain, when storing the first sub-private key and the identity information list, is specifically used to: store the first ciphertext in the account information list in association with the first account.

[0013] In one embodiment, the user device is further used to generate the first account, and send a second transaction to the blockchain through the first account to call the first contract. The second transaction includes identity information of the user corresponding to the first account. The blockchain is also used to store the identity information in the contract state of the first contract in association with the first account according to the second transaction.

[0014] In one embodiment, the second transaction includes a second ciphertext of the user identity information, and the second ciphertext is generated by encrypting the public key of the second account corresponding to the management device. When storing the user identity information, the blockchain is specifically used to associate the second ciphertext with the first account and store it in the contract status of the first contract.

[0015] In one embodiment, the system further comprises an authentication device,

[0016] The authentication device is configured to: obtain the master public key and the identity signature of the first account from the blockchain; verify the identity signature using the master public key and the preset policy information, and upload the user attribute information corresponding to the first account to the blockchain if the verification passes;

[0017] The management device is further configured to obtain user attribute information of the first account from the blockchain, generate an attribute list of the first account, the attribute list including the first account and the user attribute information, generate a second child private key based on the attribute list, the master public key, and the master private key, and upload the second child private key and the attribute list to the blockchain;

[0018] The user device is further used to obtain the second sub-private key and the attribute list from the blockchain, and perform an attribute signature based on the second sub-private key and the second policy information to obtain a second signature, where the second policy information includes the first account and at least one item of attribute information in the attribute list, and the second signature is used to prove that the user corresponding to the first account has the attribute corresponding to the at least one item of attribute information.

[0019] In one embodiment, the user device is further configured to: send a third transaction for creating the first account to the blockchain through the first account; and the blockchain is further configured to create the first account in a state database according to the third transaction.

[0020] A second aspect of this specification provides a digital identity management method, executed by a blockchain node, wherein the blockchain stores identity information of a user corresponding to a first account, the method comprising:

[0021] Sending identity information of a user corresponding to the first account to a management device, the management device including a master public key and a master private key generated based on an attribute encryption algorithm;

[0022] receiving, from the management device, a first sub-private key and an identity information list corresponding to the first account, the identity information list including the first account and the identity information, the first sub-private key being generated based on the identity information list, the master public key, and the master private key;

[0023] Storing the first sub-private key and the identity information list;

[0024] The first sub-private key and the identity information list are sent to a user device, so that the user device uses the first sub-private key and preset policy information to generate an identity signature for the first account, where the preset policy information includes the first account and the identity identifier of the user.

[0025] In one embodiment, the method further includes: receiving the identity signature from the user device, and storing the identity signature in association with the first account.

[0026] In one embodiment, a first contract is deployed in the blockchain, and receiving the first sub-private key and the identity information list corresponding to the first account from the management device includes receiving a first transaction that calls the first contract from the management device, the first transaction including the first sub-private key and the identity information list;

[0027] The storing the first sub-private key and the identity information list includes: storing the first sub-private key and the identity information list in association with the first account in an account information list in the contract state of the first contract.

[0028] In one embodiment, storing the first sub-private key and the identity information list further includes: setting the stored first sub-private key and the identity information list to be non-updatable and non-deletable.

[0029] In one embodiment, the first transaction includes the first account and a first ciphertext obtained by encrypting the sub-private key of the first account and the identity information list, the first ciphertext being generated by encrypting the public key of the first account, and storing the first sub-private key and the identity information list in association with the first account in the account information list includes: storing the first ciphertext in association with the first account in the account information list.

[0030] A third aspect of the present specification provides a blockchain node, wherein the blockchain stores identity information of a user corresponding to a first account, the node comprising:

[0031] a sending unit, configured to send the identity information of the user corresponding to the first account to a management device, wherein the management device includes a master public key and a master private key generated based on an attribute encryption algorithm;

[0032] a receiving unit, configured to receive, from the management device, a first sub-private key and an identity information list corresponding to the first account, the identity information list including the first account and the identity information, the first sub-private key being generated based on the identity information list, the master public key, and the master private key;

[0033] a storage unit, configured to store the first sub-private key and the identity information list;

[0034] The sending unit is further configured to send the first sub-private key and the identity information list to a user device, so that the user device generates an identity signature for the first account using the first sub-private key and preset policy information, where the preset policy information includes the first account and the identity identifier of the user.

[0035] A fourth aspect of this specification provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the method described in the second aspect.

[0036] A fifth aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the second aspect is implemented.

[0037] The digital identity management solution provided in the embodiments of this specification is based on blockchain and attribute encryption technology. The management agency provides a list of identity information and sub-private keys of blockchain accounts, thereby building a trusted digital identity corresponding to the blockchain account, and conveniently performing real-name verification of the blockchain account based on the identity signature of the blockchain account, thereby binding the blockchain account in the digital world with the real user in the physical world. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0039] Figure 1 A diagram of a blockchain architecture in one embodiment is shown;

[0040] Figure 2 A schematic diagram of the architecture of a digital identity management system provided in an embodiment of this specification;

[0041] Figure 3 A flowchart of a digital identity management method provided in an embodiment of this specification;

[0042] Figure 4 This is a schematic diagram of the process of generating a signature based on the attribute signature algorithm in an embodiment of this specification;

[0043] Figure 5 Schematic diagram of the process of verifying a signature based on the attribute signature algorithm in the embodiment of this specification;

[0044] Figure 6 A flowchart of a digital identity management method provided in another embodiment of this specification;

[0045] Figure 7 This is a schematic diagram of the process of generating a signature based on the attribute signature algorithm in an embodiment of this specification;

[0046] Figure 8Schematic diagram of the process of verifying a signature based on the attribute signature algorithm in the embodiment of this specification;

[0047] Figure 9 This is an architectural diagram of a blockchain node provided in an embodiment of this specification. DETAILED DESCRIPTION

[0048] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0049] Figure 1 FIG1 shows a blockchain architecture diagram in one embodiment. Figure 1 In the blockchain architecture diagram shown, blockchain 100 includes, for example, six nodes, node 1 through node 6. The lines between the nodes schematically represent P2P (Peer to Peer) connections. These nodes can store the full ledger, i.e., the state of all blocks and all accounts. Each node in the blockchain can generate the same state in the blockchain by executing the same transaction, and each node in the blockchain can store the same state database. It is understood that Figure 1 Although the blockchain is shown as including six nodes, the embodiments of this specification are not limited to this and may include other numbers of nodes. Specifically, the nodes included in the blockchain can meet Byzantine Fault Tolerance (BFT) requirements. This Byzantine Fault Tolerance requirement can be understood as allowing Byzantine nodes to exist within the blockchain without externally displaying Byzantine behavior. Generally, some Byzantine Fault Tolerance algorithms require the number of nodes to be greater than 3f+1, where f is the number of Byzantine nodes, such as the Practical Byzantine Fault Tolerance (PBFT) algorithm.

[0050] A transaction in the blockchain field can refer to a task unit executed and recorded in the blockchain. A transaction typically includes a send field (From), a receive field (To), and a data field (Data). In the case of a transfer transaction, the From field indicates the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field indicates the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount. In the case of a transaction calling a smart contract in the blockchain, the From field indicates the account address initiating the transaction, the To field indicates the account address of the contract called by the exchange, and the Data field includes data such as the function name in the called contract and the parameters passed to the function, which are used to retrieve the function code from the blockchain and execute the function code when the transaction is executed.

[0051] Blockchains offer smart contract functionality. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions within the blockchain system. Smart contracts can be defined in code. Calling a smart contract on the blockchain involves initiating a transaction directed to the smart contract address, allowing each node in the blockchain to execute the smart contract code in a distributed manner. It should be noted that in addition to user-created smart contracts, smart contracts can also be set up by the system in the genesis block. Furthermore, accounts with system administrator privileges can create or modify system-level contracts (referred to as system contracts). These system contracts can be used to add data structures for different business operations to the blockchain.

[0052] In the scenario of deploying a contract, for example, Bob sends a transaction containing the information of creating a smart contract (ie deploying the contract) to Figure 1 In the blockchain shown, the transaction's data field contains the code (such as bytecode or machine code) for the contract to be created. The transaction's to field is empty, indicating that the transaction is for deploying the contract. After the nodes reach consensus through the consensus mechanism, they determine the contract address "0x6f8ae93..." Each node adds a contract account corresponding to the smart contract's contract address to the state database, allocates state storage corresponding to the contract account, and saves the contract code in the contract's state storage, successfully creating the contract.

[0053] In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to Figure 1In the blockchain shown, the transaction's "from" field is the account address of the initiator (Bob), the "to" field ("0x6f8ae93...") represents the address of the smart contract being called, and the transaction's "data" field contains the method and parameters for calling the smart contract. After consensus is reached on the transaction within the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract and updating the state database based on the contract's execution.

[0054] Currently, blockchain users typically participate in blockchain-based businesses anonymously. Transactions in a blockchain can only identify the blockchain account initiating the activity, but not the identity of the real user corresponding to that blockchain account. This means that the business environment provided by the blockchain is separate from the real world, making it difficult to manage real-world users. For example, if a blockchain account engages in illegal activity, it is impossible to trace the real-world individual or organization associated with the account. However, with the increasing growth of blockchain-based economic activities, the demand for stronger identity authentication for blockchain accounts is growing.

[0055] The embodiments of this specification provide a method for managing digital identities for accounts in a blockchain. A digital identity is a set of data describing a person or thing, and is the sum of all information about a person in the digital world. A digital identity is composed of a variety of attributes. Identity can be described by attributes, such as name, identification, job, certificate, marital status, and other information. Attributes constitute a complete identity entity. A management device generates a list of user identity information corresponding to a blockchain account, including the blockchain account and user identity information. A child private key is generated based on a key generation algorithm in an attribute encryption system. The child private key and identity information list are stored in association with the blockchain account in the blockchain. This allows the user to generate an identity signature based on an attribute signature algorithm. This identity signature can be used to verify the identity information of the user corresponding to the account.

[0056] Figure 2 This is a schematic diagram of the architecture of the digital identity management system provided in the embodiment of this specification. Figure 2As shown, the system includes a blockchain 100, a user device 10, a management device 20, and an authentication device 30. User device 10 can be any terminal device, such as a smartphone, computing device, laptop, tablet, and so on, without limitation. User device 10 can upload the user's identity information to blockchain 100 through the user's corresponding blockchain account. Management device 20 is a trusted device that retrieves the user's identity information from the blockchain, generates an identity list based on the user's complete identity information, generates a sub-private key for the user using a key generation algorithm in an attribute encryption system, and uploads the user's identity list and sub-private key to the blockchain, associating them with the user's account. This stores the digital identity corresponding to the blockchain account in the blockchain. The user can use this identity list and sub-private key to generate an identity signature that complies with a specific policy, which can be used to prove to others or companies that the account has been authenticated and corresponds to the real user. Authentication device 30 is used by an authentication authority. An authentication authority is, for example, an institution that issues various certificates and documents to users, such as a school or administrative agency. The authentication device 30 can obtain the identity signature and verify the identity signature based on the attribute signature verification algorithm. After the verification is passed, the attribute information of the user associated with the account, such as academic certificate, marriage certificate, years of work, etc., can be uploaded. It can be understood that Figure 2 Although only one authentication device 30 is shown, in practice, different attributes of a user may be uploaded by devices (ie, authentication devices) of different institutions or units.

[0057] Figure 3 This is a flowchart of a digital identity management method provided in the embodiment of this specification. Figure 2 The blockchain 100, the user device 10, and the management device 20 in the embodiment are executed. When the blockchain 100 executes the method steps, it actually means that each node (for example, node 1 to node 6) in the blockchain 100 executes the method steps.

[0058] refer to Figure 3 ,First, in step S301, the management device 20 generates a master public key and a master private key.

[0059] The management device 20 may generate a master public key and a master private key through a ciphertext policy attribute based encryption (CP-ABE) system, and the master private key is kept by the management device 20. As another example, the management device 20 may correspond to multiple management devices, and the multiple management devices may use secure multi-party computation to generate the master public key and the master private key. The master private key is jointly maintained by the multiple management devices, and when the master private key is needed, the multiple management devices simultaneously participate in the computation.

[0060] Specifically, the management device 20 may call the CPABE_Setup() function in CP-ABE to generate the master private key msk and the master public key mpk.

[0061] In step S303 , the management device 20 uploads the master public key to the blockchain 100 .

[0062] Specifically, the management device 20 can send a transaction Tx1 to any blockchain node in the blockchain 100. This transaction Tx1 can be sent by the blockchain account A1 of the management organization corresponding to the management device 20. Account A1 corresponds to the account private key systemSK and the account public key systemPK. The private key systemSK can be used to generate the digital signature of transaction Tx1, and the public key systemPK can be used to verify the digital signature. This transaction Tx1 can call the digital identity management contract C1 (hereinafter referred to as contract C1) in the blockchain to upload the master public key to the blockchain. This contract can be deployed by the management device 20 to the blockchain to manage the digital identities corresponding to the blockchain accounts. After receiving this transaction, the blockchain node sends it to other nodes in the blockchain, allowing each node in the blockchain to execute the transaction. By executing this transaction, each node in the blockchain 100 stores the master public key in the blockchain. For example, the master public key can be stored in the contract state of contract C1, making it available to other devices from the blockchain.

[0063] In one embodiment, transaction Tx1 may also include the public key systemPK of account A1, so that each node in the blockchain 100 also stores the public key systemPK in the blockchain by executing transaction Tx1. In addition to being used to verify the digital signature of account A1, other devices can also use the public key systemPK to encrypt data uploaded to the blockchain, so that the data can only be obtained by the management device 20 by decrypting it using the private key systemSK. It is understood that each node in the blockchain can obtain the public key systemPK of account A1 through other means, for example, from the official homepage of the management agency, or from the key management agency, etc., without limitation.

[0064] In step S305 , the user device 10 generates a blockchain account of the user.

[0065] Specifically, the user device 10 may first generate a public-private key pair, such as a public key upk and a private key usk, to serve as the public-private key for the blockchain account to be generated. The user device 10 may then invoke an account generation algorithm (e.g., from any blockchain node or locally) to generate account A2 based on the public key upk.

[0066] After generating account A2, user device 10 can generate a transaction with account A2 as the sending account and send the transaction to the blockchain. After reaching a consensus on the transaction, each node in the blockchain executes the transaction separately, thereby creating storage space for account A2 in the state database for storing the account information of account A2, thereby completing the creation of account A2 in the blockchain.

[0067] In step S307 , the user device 10 uploads the user identity information corresponding to the account A2 to the blockchain 100 .

[0068] Specifically, user device 10 can send transaction Tx2 to blockchain 100 through account A2 to invoke contract C1, thereby uploading the user's identity information to blockchain 100. This identity information may include, for example, the user's name, identification, passport, and other information. By executing transaction Tx2, each node in blockchain 100 can store this user's identity information in the contract state of contract C1 in association with account A2. For example, the contract state of contract C1 includes a list of user uploaded information. By executing transaction Tx2, each node can store this user's identity information in the user uploaded information list in association with account A2.

[0069] The user device 10 can obtain the public key systemPK of the management agency 20 from the blockchain 100, so that the ciphertext userinfocipher of the user identity information can be included in the transaction Tx2. The ciphertext is encrypted using the public key systemPK of the management agency. Specifically, the ciphertext userinfocipher can be generated by the following formula (1):

[0070] userinfocipher=ECIES_ENCRYPT(systemPK,userinfo) (1)

[0071] Where userinfo represents the user identity information uploaded by the user, and ECIES_ENCRYPT represents the encryption algorithm in the elliptic curve integrate encrypt scheme (ECIES) encryption and decryption algorithm.

[0072] In step S309 , the management device 20 obtains the user identity information corresponding to the account A2 from the blockchain 100 .

[0073] The management device 20 can obtain the account A2 and the user identity information corresponding to the account A2 from the blockchain 100, which are associated and stored in the user upload information list in the contract state of contract C1, by sending a query transaction Tx3 to the blockchain to call contract C1. In the case where the user identity information is encrypted using the public key systemPK of the management agency, the management device 20 can decrypt the ciphertext using the private key systemSK of the management agency to obtain the user identity information. Specifically, the user identity information userinfo can be obtained using the following formula (2):

[0074] userinfo=ECIES_DECRYPT(systemSK,Userinfocipher) (2)

[0075] ECIES_DECRYPT represents the decryption algorithm in the elliptic curve integrate encrypt scheme (ECIES) encryption and decryption algorithm.

[0076] In step S311 , the management device 20 generates an identity information list and an identity sub-private key of an account corresponding to the user.

[0077] After receiving the user identity information from the blockchain, the management device 20 performs identity verification and authentication based on the user identity information. It also verifies whether the identity identifier already has an authenticated blockchain account on the blockchain to ensure that the identity identifier corresponds to a unique account on the blockchain. For example, the management device 20 can query the blockchain account corresponding to the identity identifier from the contract status of contract C1 by sending a transaction to the blockchain to invoke contract C1.

[0078] In the event that the audit fails, the management device 20 may send a transaction to call contract C1 to the blockchain to record relevant information that account A2 authentication failed in the contract status of contract C1.

[0079] If the review passes, management device 20 generates an identity information list Attrilist1 for blockchain account A2. This list includes account A2 and one or more pieces of identity information for the user corresponding to account A2. For example, this list may include multiple pieces of identity information, such as account A2, name, identity identifier, and passport data.

[0080] Afterwards, as shown in the following formula (3), the management device 20 may call the sub-private key generation function CPABE_keygen() in the CPABE attribute encryption algorithm to generate the sub-private key sk1 corresponding to the account A2:

[0081] sk1=CPABE_keygen(Attrilist1, msk, mpk) (3)

[0082] As can be seen from formula (3), the input parameters of the function CPABE_keygen() include Attrilist1, msk and mpk. The sub-private key sk1 is generated by the attribute-based encryption algorithm. The sub-private key sk1 can be used to perform attribute signing based on the signature policy to obtain an identity signature to prove that account A2 corresponds to a specific real user, and mpk can be used to verify that the signature is true based on the signature policy, that is, to verify that account A2 corresponds to a specific real user.

[0083] In step S313 , the management device 20 uploads the account's sub-private key and identity information list to the blockchain 100 .

[0084] The management device 20 may send a transaction Tx4 to the blockchain 100 to invoke contract C1, which is used to store the identity information list Attrilist1, child private key sk1, and authentication status of account A2 in the account information list Accountinfolist1 in the contract status of contract C1. The account information list is used to store the account information of each account.

[0085] In addition, the user's public key upk may be included in the previous transaction Tx2. After executing transaction Tx2, the public key upk is also stored in the user's uploaded information list on the blockchain in association with account A2. Therefore, management device 20 can also obtain the user's public key upk from the blockchain. Management device 20 may include in transaction Tx4 the ciphertext accountCipher, obtained by encrypting the identity information list Attrilist1 and the child private key sk1 using account A2's public key upk, and store this ciphertext in Accountinfolist1 to better protect user privacy.

[0086] After executing transaction Tx4, each node in blockchain 100 stores the identity information list Attrilist1, the child private key sk1, and the "authentication passed" status in association with account A2 in Accountinfolist1 in the contract state of contract C1, or stores the ciphertext accountCipher and the authentication passed status in association with account A2. Furthermore, Accountinfolist1 may also store the public key upk in association with account A2.

[0087] In one implementation, contract C1 can set the information in Accountinfolist1 to be immutable and non-deletable. This ensures that once a blockchain account is bound to a user, the child private key sk1 remains unchanged. Consequently, the attribute signature derived using the child private key sk1 and the pre-set signature strategy remains unchanged. Because this attribute signature proves the identity of the user corresponding to the account, it can be referred to as an identity signature. This eliminates the need for users to recalculate their identity signatures and allows them to reuse the first calculated identity signature.

[0088] In step S315 , the user device 10 obtains the sub-private key and identity information list of account A2 from the blockchain 100 .

[0089] User device 10 can send a transaction to any node in blockchain 100 to invoke contract C1. This transaction includes account A2 or public key upk, in order to query account information corresponding to account A2 in Accountinfolist1. After receiving the query transaction, the blockchain node finds the corresponding account information in Accountinfolist1 based on account A2 or public key upk. This account information includes the sub-private key and identity information list corresponding to account A2, and sends this account information to user device 10. If accountCipher is stored in Accountinfolist1, the accountCipher is sent to user device 10. After receiving the accountCipher, user device 10 decrypts the accountCipher using the user's private key usk to obtain the sub-private key and identity information list corresponding to account A2.

[0090] In step S317 , the user device 10 generates an identity signature using the sub-private key and the policy information.

[0091] The user device 10 can generate proof data for proving that the blockchain account corresponds to the user's identity based on the attribute signature algorithm. The proof data is also the signature generated by the attribute signature algorithm.

[0092] Figure 4 This is a schematic diagram of the process of generating an identity signature in the embodiment of this specification. Figure 4 As shown, the user device 10 can use the sub-private key sk1 to perform attribute signature on the preset data data1 to obtain the signature sign1. The signature policy information policy1 includes the blockchain account A2 and the identity identifier in the user's identity information list Attrilist1, that is, policy1 = {A2, identity identifier}. Wherein data1 is generated, for example, as shown in the following formula (4):

[0093] data1=HASH(identity identifier+A2) (4)

[0094] The “+” in formula (4) indicates combining the identity identifier and A2. The combining method is not limited. For example, the identity identifier and A2 may be concatenated together.

[0095] The signature sign1 can be generated as shown in the following formula (5):

[0096] sign1=CPABE_sign(sk1,policy1,data1) (5)

[0097] The CPABE_sign() function in formula (5) is an attribute signature function. By inputting sk1, policy1, and data1 into the attribute signature function, the signature is successful only when the identity information list Attrilist1 includes all the attributes in policy1 (i.e., A2 and the identity identifier). Otherwise, the signature fails. Therefore, the generated signature sign1 can be used to prove that account A2 is bound to the user's identity identifier and that this binding relationship has been verified by the management agency.

[0098] In step S319, the user device uploads the identity signature to the blockchain.

[0099] After generating the identity signature sign1, user device 10 can invoke contract C1 by sending a transaction Tx5 to the blockchain. This transaction Tx5 includes the identity signature sign1 and uses account A2 as the sending account. By executing transaction Tx5, each node in the blockchain can store sign1, for example, in association with account A2 in the identity signature list in the contract state of contract C1. Because contract C1 sets sk1 to be immutable, the signature sign1 remains unchanged. Other users can then retrieve the signature sign1 from the blockchain and use it to verify that account A2 corresponds to a specific user ID.

[0100] Figure 5 This is a schematic diagram of the process of verifying identity signature in the embodiment of this specification. Figure 5As shown, other user devices can obtain the master public key mpk pre-stored by the management device from the blockchain. After that, by inputting the above policy1, mpk, data1, and sign1 into the attribute signature verification algorithm, the attribute signature verification algorithm outputs "true" if the identity signature verification passes, which proves that account A2 and the user ID in policy1 are indeed in the same identity information list. Therefore, account A2 corresponds to the user ID. If the attribute signature verification algorithm fails, the attribute signature verification algorithm outputs "false", which proves that account A2 does not correspond to the user ID.

[0101] In the embodiment of this specification, in addition to storing the above-mentioned identity information list and the corresponding sub-private key sk1 in the blockchain, the management agency can also generate a user attribute list and the corresponding sub-private key sk2, so that the signature generated by the sub-private key sk2 and the attribute list can be used to prove the attributes of the user corresponding to the account.

[0102] Figure 6 This is a flow chart of a digital identity management method in another embodiment of this specification. Figure 2 The blockchain 100, user device 10, management device 20 and authentication device 30 are executed.

[0103] like Figure 6 As shown, first, in step S601, the user device 10 sends the user's blockchain account A2 and identity to the authentication device 30.

[0104] In the physical world, a certification authority might issue a paper certification certificate to the user corresponding to user device 10. For example, when a university graduate completes their studies, the university will issue a degree certificate to the individual. In this case, the university is a certification authority. In order for the certification authority to assign the attributes corresponding to the paper certificate to the individual's corresponding blockchain account to complete the digital identity corresponding to the blockchain account, user device 10 can send the user's blockchain account A2 and identity identifier to the authentication device 30, triggering the authentication device 30 to upload the user's degree attributes to the blockchain.

[0105] Specifically, in order to protect the user's privacy information, the user device 10 can use the public key of the certification authority corresponding to the authentication device 30 to encrypt the identity, and send the encrypted ciphertext to the authentication device 30, so that the authentication device 30 can obtain the user's identity by decrypting the ciphertext using the private key of the certification authority.

[0106] In step S603 , the authentication device 30 obtains the master public key mpk and the identity signature of the account A2 from the blockchain 100 .

[0107] Specifically, the authentication device 30 can send a transaction to call contract C1 to any blockchain node to query the master public key of the management device 20 and the identity signature of account A2. After receiving the transaction, the blockchain node obtains the master public key mpk and the identity signature sign1 of account A2 in the contract status of contract C1 by executing the transaction, and returns mpk and sign1 to the authentication device 30.

[0108] In step S605 , the authentication device 30 verifies the signature sign1 using the master public key mpk and the policy information policy1 .

[0109] The authentication device 30 can determine that the signature policy corresponding to the signature sign1 is the above-mentioned policy1 according to the instructions of the user device 10 or the rules preset in the blockchain. At the same time, the authentication device 30 can calculate data1 according to the instructions of the user device 10 or the pre-agreed agreement according to formula (4). Then, the authentication device 30 can verify the signature sign1 according to the following formula (6) to obtain the verification result result1:

[0110] Result1=CPABE_verify(mpk,policy1,data1,sign1) (6)

[0111] In formula (6), CPABE_verify is a function used to verify the signature. Figure 5 As described in [1], by passing mpk, policy1, data1, and sign1 as parameters to the CPABE_verify function, the function outputs true or false as the verification result. If sign1 is indeed successfully signed based on all the attributes in policy1, the function outputs true, thus verifying that account A2 is bound to the identity.

[0112] In step S607 , the authentication device 30 uploads the user attributes corresponding to the account A2 to the blockchain 100 .

[0113] After verifying that account A2 is bound to the user's identity, authentication device 30 compares the identity in policy 1 with the identity corresponding to the certificate. If they match, it indicates that the user corresponding to account A2 is the same as the user corresponding to the certificate. Therefore, it also verifies that account A2 possesses one or more attributes corresponding to the certificate. For example, if the certificate is a master's degree certificate from a university's computer science department, the attributes associated with the master's degree certificate may include: master's degree, computer science major, and university graduation.

[0114] The authentication device 30 can upload the user attributes corresponding to account A2 to the blockchain 100 by sending a transaction Tx6 that calls contract C1. This transaction Tx6 includes account A2 and one or more attributes corresponding to the paper certificate. Specifically, assuming that the information to be uploaded to the blockchain by the authentication authority is info = {A2, master's degree, graduated from a certain university, computer science major}, the transaction Tx6 can call Publishcert(A2, infocipher, infosign, A3 / companypk) in contract C1, where A3 is the blockchain account corresponding to the authentication authority, companypk is the public key of account A3, and infocipher is generated by the following formula (7):

[0115] Infocipher=ECIES_ENCRYPT(systempk,info) (7)

[0116] In formula (7), infocipher is the ciphertext obtained by encrypting the information info using the public key of the management agency, so that only the management agency can obtain the info.

[0117] The above infosign is generated by the following formula (8):

[0118] infosign=ECIES_SIGN(companySK,infohash) (8)

[0119] In formula (8), companySK is the private key of the blockchain account A3 of the certification authority, and infohash is the hash value of info. That is, infosign is the digital signature of the certification authority on the information info, which is used to verify that the information info is uploaded by the certification authority.

[0120] When executing transaction Tx6, each node in blockchain 100 can store {A2, infocipher, infosign, A3 / companypk} as an entry in the authentication information list Accountcertslist in the contract state of contract C1.

[0121] In step S609 , the management device 20 obtains the user attributes corresponding to the account A2 from the blockchain 100 .

[0122] The management device 20 can obtain the information in the authentication information list Accountcertslist by sending a transaction to call the contract to any node in the blockchain 100.

[0123] For example, the management device 20 receives the entry {A2, infocipher, infosign, A3 / companypk} in the authentication information list Accountcertslist from the blockchain node, and the management device 20 first verifies the validity of the info corresponding to the entry.

[0124] Specifically, the management device 20 first decrypts infocipher using the management organization's private key systemsk as shown in the following formula (9) to obtain the information info:

[0125] Info=ECIES_DECRYPT(systemsk,infocipher) (9)

[0126] Next, the pre-stored certification authority information for account A3 is retrieved based on A3 / companypk. This information includes account A3's public key, companypk, and account A3. The signature, infosign, of the information info is then verified using the public key, companypk. After the signature is verified, the management authority corresponding to management device 20 also verifies the legitimacy and legality of the information info off-chain, including verifying the certification authority's qualifications and the validity of the issuance time.

[0127] In step S611 , the management device 20 generates an attribute list and a child private key of the account A2 .

[0128] After all the above checks are passed, the management device 20 determines whether an attribute list of account A2 has been stored locally. The attribute list includes account A2 and one or more attributes of the user corresponding to account A2. The attributes are characteristic information other than the user's identity information, such as documents, certificates, etc. If the result of the determination is no, an attribute list Attrilist2 of account A2 is created, and the above-obtained user attributes are included in the attribute list. If the result of the determination is yes, the above-obtained user attributes are added to the existing attribute list Attrilist2 of account A2. For example, the updated attribute list Attrilist2 may include multiple attributes such as account A2, public key upk, master's degree, graduation from a certain university, computer major, etc. Afterwards, the management device 20 may generate another sub-private key sk2 of account A2 based on the following formula (10):

[0129] Sk2=CPABE_keygen(Attrilist2, msk, mpk) (10)

[0130] From formula (10), it can be seen that another sub-private key sk2 of account A2 corresponds to the attribute list Attrilist2 of account A2.

[0131] In step S613 , the management device 20 uploads the sub-private key sk2 and attribute list Attrilist2 of account A2 to the blockchain 100 .

[0132] Similar to uploading the sub-private key sk1 and attribute list Attrilist1 of account A2 above, management device 20 can upload the sub-private key sk2 and attribute list Attrilist2 of account A2 to the blockchain by sending a transaction to call contract C1. After receiving this transaction, each node in the blockchain stores the sub-private key sk2 and attribute list Attrilist2, or the ciphertext of the sub-private key sk2 and attribute list Attrilist2, in association with account A2 in another account information list Accountinfolist2.

[0133] Other certification authorities can update the attribute list Attrilist2 and sub-private key sk2 of account A2 in the same way, so that the digital identity corresponding to account A2 has various types of attributes.

[0134] In step S615, the user device 10 obtains the sub-private key sk2 and attribute list Attrilist2 of account A2 from the blockchain 100. The user device 10 can send a transaction to call the contract C1 to the blockchain node to query the sub-private key sk2 and attribute list Attrilist2 corresponding to account A2 in the account information list Attrilist2.

[0135] In step S617 , the user device 10 generates a signature using the child private key sk2 and the policy information policy2 .

[0136] The user device 10 can calculate the signature sign2 based on formula (11) to verify that the user corresponding to the account A2 has any attribute in the attribute list Attrilist2, which is defined by the policy information policy2:

[0137] sign2=CPABE_sign(sk2,policy2,data2) (11)

[0138] In formula (11), data2 is any data agreed upon between the user corresponding to user device 10 and the verifier, and policy2 is an attribute agreed upon by the user and the verifier. For example, the verifier is the user corresponding to account A4 in blockchain 100. Before the verifier conducts a transaction with account A2 through the blockchain (e.g., transferring digital assets to account A2), it needs to ensure that the user corresponding to account A2 meets certain attributes. For example, the assets of the user corresponding to account A2 are higher than a preset amount, the credit value of account A2 is higher than a preset value, etc. The verifier can agree with the user corresponding to account A2 on the attribute signature policy policy2 = {A2, assets higher than x yuan, credit value greater than y}.

[0139] Figure 7 This is a schematic diagram of the process of generating a signature based on the attribute signature algorithm in the embodiment of this specification. Figure 7 As shown, signature policy policy2 = {A2, assets > x, credit value > y}. This means that the signature policy requires account A2 to simultaneously include the following three attributes: A2, assets greater than x yuan, and credit value greater than y. data2 is any agreed-upon data, such as a string of characters "Account A2 attribute proof." By inputting policy2, sk2, and data2 as parameters into the attribute signature algorithm, signature sign2 is successfully generated only when the attribute list Attrilist2 corresponding to account A2 includes all attributes in policy2. This sign2 serves as proof data proving that account A2 corresponds to the attributes "assets > x" and "credit value > y." After generating signature sign2, user device 10 can send sign2 to the verifier device.

[0140] It can be understood that policy2 is not limited to requiring account A2 to include the three attributes of A2, assets greater than x yuan, and credit value greater than y. For example, policy2 can be {A2, {1 / 2}{assets>x, credit value>y}}, which requires account A2 to include the A2 attribute and at least one of the attributes of {assets greater than x yuan, credit value greater than y}.

[0141] The verifier can use formula (12) to verify sign2:

[0142] Result2=CPABE_verify(mpk,policy2,data2,sign2) (12)

[0143] Figure 8 Schematic diagram of the process of verifying signature based on attribute signature algorithm in the embodiment of this specification. Figure 8As shown in , by inputting the above-mentioned policy2, mpk, data2 and sign2 into the attribute signature verification algorithm, i.e., CPABE_verify() in formula (12), when the output Result2 is true, it is verified that account A2 and assets greater than x yuan and credit value greater than y are all attributes included in the attribute list Attrilist2 corresponding to account A2, that is, it is verified that the user corresponding to account A2 meets the conditions of assets greater than x yuan and credit value greater than y. Therefore, the verifier can initiate a transaction with account A2 through its account A4.

[0144] Figure 9 This is an architectural diagram of a blockchain node in an embodiment of this specification. The blockchain stores identity information of a user corresponding to a first account. The node includes:

[0145] A sending unit 91 is configured to send the identity information of the user corresponding to the first account to a management device, wherein the management device includes a master public key and a master private key generated based on an attribute encryption algorithm;

[0146] a receiving unit 92 configured to receive, from the management device, a first sub-private key and an identity information list corresponding to the first account, the identity information list including the first account and the identity information, the first sub-private key being generated based on the identity information list, the master public key, and the master private key;

[0147] Storage unit 93, used to store the first sub-private key and the identity information list;

[0148] The sending unit 91 is further configured to send the first sub-private key and the identity information list to a user device, so that the user device performs an attribute signature based on the first sub-private key and preset policy information to generate an identity signature for the first account, wherein the preset policy information includes the identity identifier of the first account and the user.

[0149] The embodiment of the present specification also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the following Figure 3 or Figure 6 The method shown.

[0150] The embodiment of this specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the following is achieved: Figure 3 or Figure 6 The method shown.

[0151] The digital identity management solution provided in the embodiments of this specification is based on blockchain and attribute encryption technology. The management agency provides a list of identity information and sub-private keys of blockchain accounts, thereby building a trusted digital identity corresponding to the blockchain account, and conveniently performing real-name verification of the blockchain account based on the identity signature of the blockchain account, thereby binding the blockchain account in the digital world with the real user in the physical world.

[0152] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0153] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0154] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0155] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0156] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

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

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

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

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

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

[0162] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

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

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

[0165] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, without conflict.

[0166] The foregoing is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification shall be included within the scope of the claims.

Claims

1. A digital identity management system, comprising a management device, a blockchain, an authentication device, and a user device, wherein the blockchain stores identity information of a user corresponding to a first account, the management device comprises a master public key and a master private key generated based on an attribute encryption algorithm, The management device is used to: obtain identity information of the user corresponding to the first account from the blockchain; Generate an identity information list of the user, and generate a first child private key based on the identity information list, the master public key, and the master private key, wherein the identity information list includes the first account and the identity information; Sending the first sub-private key and the identity information list to the blockchain; uploading the master public key to the blockchain; The blockchain is used to store the master public key, the first sub-private key and the identity information list; The user device is configured to obtain the first sub-private key and the identity information list from the blockchain, perform attribute signing based on the first sub-private key and preset policy information, generate an identity signature for the first account, and send the identity signature to the blockchain; the preset policy information includes the identity identifiers of the first account and the user; The blockchain is further configured to store the identity signature and the first account in association; The authentication device is used to: obtain the master public key and the identity signature of the first account from the blockchain; verify the identity signature using the master public key and the preset policy information, and if the verification passes, upload the user attribute information corresponding to the first account to the blockchain.

2. The system according to claim 1, wherein a first contract is deployed in the blockchain, and when the management device sends the first child private key and the identity information list to the blockchain, it is specifically configured to: send a first transaction to the blockchain that invokes the first contract, wherein the first transaction includes the first child private key and the identity information list; When storing the first sub-private key and the identity information list, the blockchain is specifically used to: store the first sub-private key and the identity information list in association with the first account in the account information list in the contract state of the first contract according to the first transaction.

3. The system according to claim 2, wherein: The first contract makes the first sub-private key and the identity information list non-updatable and non-deletable after being stored in the account information list.

4. The system according to claim 2, wherein the first transaction includes a first account and a first ciphertext, and the first ciphertext is generated by encrypting the sub-private key of the first account and the identity information list using the public key of the first account. When storing the first sub-private key and the identity information list, the blockchain is specifically used to: store the first ciphertext in association with the first account in the account information list.

5. According to the system of claim 2, the user device is further used to generate the first account, and send a second transaction to the blockchain through the first account to call the first contract, wherein the second transaction includes identity information of the user corresponding to the first account, and the blockchain is further used to associate the identity information with the first account and store it in the contract state of the first contract according to the second transaction.

6. According to the system of claim 5, the second transaction includes a second ciphertext of the user identity information, and the second ciphertext is generated by encrypting the public key of the second account corresponding to the management device. When storing the user identity information, the blockchain is specifically used to associate the second ciphertext with the first account and store it in the contract state of the first contract.

7. The system according to claim 1, wherein the management device is further configured to obtain user attribute information of the first account from the blockchain, generate an attribute list of the first account, wherein the attribute list includes the first account and the user attribute information, generate a second child private key based on the attribute list, the master public key, and the master private key, and upload the second child private key and the attribute list to the blockchain; The user device is further used to obtain the second sub-private key and the attribute list from the blockchain, perform attribute signing based on the second sub-private key and second policy information to obtain a second signature, where the second policy information includes the first account and at least one attribute information in the attribute list.

8. The system according to claim 5, wherein: The user device is further configured to: send a third transaction for creating the first account to the blockchain through the first account; and the blockchain is further configured to create the first account in a state database according to the third transaction.

9. A digital identity management method, executed by a blockchain node, wherein the blockchain stores identity information of a user corresponding to a first account, the method comprising: Sending identity information of a user corresponding to the first account to a management device, the management device including a master public key and a master private key generated based on an attribute encryption algorithm; receiving, from the management device, a first sub-private key and an identity information list corresponding to the first account, the identity information list including the first account and the identity information, the first sub-private key being generated based on the identity information list, the master public key, and the master private key; receiving the master public key from the management device; Storing the master public key, the first sub-private key, and the identity information list; Sending the first sub-private key and the identity information list to a user device, so that the user device performs attribute signing based on the first sub-private key and preset policy information to generate an identity signature for the first account, where the preset policy information includes the first account and the identity identifier of the user; receiving the identity signature from the user device, and storing the identity signature in association with the first account; Sending the master public key and the identity signature of the first account to an authentication device, so that the authentication device verifies the identity signature using the master public key and the preset policy information; Receive user attribute information of a first account from the authentication device; the attribute information is sent when the authentication device successfully verifies.

10. The method according to claim 9, wherein a first contract is deployed in the blockchain, and receiving the first sub-private key and the identity information list corresponding to the first account from the management device comprises receiving a first transaction from the management device that invokes the first contract, the first transaction including the first sub-private key and the identity information list; The storing of the first sub-private key and the identity information list includes: The first child private key and the identity information list are stored in association with the first account in an account information list in the contract state of the first contract.

11. The method according to claim 10, wherein: The first contract makes the first sub-private key and the identity information list non-updatable and non-deletable after being stored in the account information list.

12. The method according to claim 10, wherein the first transaction includes the first account and a first ciphertext, the first ciphertext being generated by encrypting the first account's sub-private key and the identity information list using the first account's public key, and storing the first sub-private key and the identity information list in association with the first account in the account information list comprises: The first ciphertext is stored in the account information list in association with the first account.

13. A blockchain node, wherein the blockchain stores identity information of a user corresponding to a first account, the node comprising: a sending unit, configured to send the identity information of the user corresponding to the first account to a management device, wherein the management device includes a master public key and a master private key generated based on an attribute encryption algorithm; a receiving unit, configured to receive, from the management device, a first sub-private key and an identity information list corresponding to the first account, the identity information list including the first account and the identity information, the first sub-private key being generated based on the identity information list, the master public key, and the master private key; The receiving unit is further configured to receive the master public key from the management device; a storage unit, configured to store the master public key, the first sub-private key, and the identity information list; The sending unit is further configured to send the first sub-private key and the identity information list to a user device, so that the user device performs an attribute signature based on the first sub-private key and preset policy information to generate an identity signature for the first account, wherein the preset policy information includes the first account and the identity identifier of the user; The storage unit is further configured to receive the identity signature from the user device and store the identity signature in association with the first account; The sending unit is further configured to send the master public key and the identity signature of the first account to an authentication device, so that the authentication device verifies the identity signature using the master public key and the preset policy information; The receiving unit is further configured to receive user attribute information of the first account from the authentication device; the attribute information is sent when the authentication device successfully verifies the user.

14. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 9 to 12.

Images