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 and a blockchain, wherein the blockchain stores attribute information of a user corresponding to a first account, the management device comprising a master public key and a master private key for generating based on an attribute encryption algorithm, the management device being configured to: obtain the attribute information of the user corresponding to the first account from the blockchain; generate a first attribute list of the user, and generate a first child private key based on the first attribute list, the master public key, and the master private key, wherein the first attribute list includes the first account and the attribute information; send the first child private key and the first attribute list to the blockchain; and the blockchain being configured to store the first child private key and the first attribute list.

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 and a blockchain, wherein the blockchain stores attribute 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 attribute information of a user corresponding to the first account from the blockchain; generate a first attribute list of the user; generate a first child private key based on the first attribute list, the master public key, and the master private key, wherein the first attribute list includes the first account and the attribute information; and send the first child private key and the first attribute list to the blockchain;

[0006] The blockchain is used to store the first sub-private key and the first attribute list.

[0007] In one embodiment of the first aspect, the system also includes a user device, and the user device is used to: obtain a sub-private key and an attribute list corresponding to the first account from the blockchain, perform an attribute signature based on the sub-private key and first policy information to obtain a first signature, wherein the first policy information includes at least one attribute in the attribute list, and the first signature is used to prove that the user corresponding to the first account has all the attributes included in the first policy information.

[0008] In one implementation of the first aspect, a first contract is deployed in the blockchain, and when the management device sends the first sub-private key and the first attribute list to the blockchain, it is specifically configured to: send a first transaction to the blockchain that invokes the first contract, where the first transaction includes the first sub-private key and the first attribute list;

[0009] When storing the first sub-private key and the first attribute list, the blockchain is specifically used to: store the first sub-private key and the first attribute 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.

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

[0011] In one implementation of the first aspect, the system further includes an authentication device, the attribute information includes identity information of the user,

[0012] The management device is further configured to obtain the user's identity information from the blockchain, create a first account after verifying the user's identity information, generate a second attribute list for the user, the second attribute list including the first account and the user's identity information, generate a second child private key based on the second attribute list, the master public key, and the master private key, and upload the second child private key and the second attribute list to the blockchain;

[0013] The user device is further configured to obtain the second sub-private key and the second attribute list from the blockchain, perform attribute signing based on the second sub-private key and the second policy information to obtain a second signature, and send the second signature and the second policy information to the authentication device, where the second policy information includes the first account and the user identity information in the second attribute list;

[0014] The authentication device is configured to verify the second signature based on the pre-acquired master public key and the second policy information, and if the verification passes, upload the first attribute corresponding to the first account to the blockchain;

[0015] The blockchain is further configured to store the first attribute in association with the first account.

[0016] In one embodiment of the first aspect, when uploading the first attribute corresponding to the first account to the blockchain, the authentication device is specifically used to: send a second transaction to the blockchain to call the first contract, where the second transaction includes the first account and the first attribute; and the blockchain is used to store the first attribute of the user in association with the first account in the authentication information list in the contract status of the first contract according to the second transaction.

[0017] In one embodiment of the first aspect, when uploading the first attribute corresponding to the first account to the blockchain, the authentication device is further specifically used to: send to the blockchain a third signature of the second account of the authentication authority corresponding to the authentication device for the second transaction; when the blockchain is used to store the first attribute in association with the first account in the authentication information list according to the second transaction, it is specifically used to: store the first attribute of the user and the third signature in association with the first account in the authentication information list according to the second transaction.

[0018] In one embodiment of the first aspect, when the management device obtains the attribute information of the user corresponding to the first account from the blockchain, it is specifically used to obtain the first attribute and the third signature stored in association with the first account from the authentication information list; when the management device generates the first attribute list of the user, it is specifically used to generate a first attribute list after verifying that the second account corresponds to the certification authority and the third signature is verified, and the first attribute list includes the first attribute.

[0019] In one embodiment of the first aspect, the authentication device is further configured to: send a third transaction to the blockchain for invoking the first contract, the third transaction being used to register the authentication authority, the third transaction including information about the authentication authority; and the blockchain is further configured to store the information about the authority in the contract state of the first contract according to the third transaction;

[0020] The management device is used to obtain the organization information from the blockchain, create the second account after verifying the organization information, and store the second account and the organization information in association.

[0021] In one embodiment of the first aspect, the user device is further used to: send a fourth transaction to the blockchain to call the first contract, the fourth transaction is used to register the user, and the fourth transaction includes the user identity information; the blockchain is further used to store the user identity information in the contract state of the first contract according to the fourth transaction.

[0022] In one embodiment of the first aspect, the fourth transaction includes a second ciphertext of the user identity information, and the second ciphertext is generated by encrypting the public key of the third account corresponding to the management device. When storing the user identity information, the blockchain is specifically used to store the second ciphertext in the contract state of the first contract.

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

[0024] Sending attribute information of the 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;

[0025] receiving, from the management device, a first sub-private key and a first attribute list corresponding to the first account, where the first attribute list includes the first account and the attribute information, and the first sub-private key is generated based on the first attribute list, the master public key, and the master private key;

[0026] The first sub-private key and the first attribute list are stored.

[0027] A third aspect of the present specification provides a blockchain node, wherein attribute information of a user corresponding to a first account is stored in the blockchain, and the blockchain node includes:

[0028] a sending unit, configured to send attribute information of the 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;

[0029] a receiving unit, configured to receive, from the management device, a first sub-private key and a first attribute list corresponding to the first account, wherein the first attribute list includes the first account and the attribute information, and the first sub-private key is generated based on the first attribute list, the master public key, and the master private key;

[0030] A storage unit is configured to store the first sub-private key and the first attribute list.

[0031] 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.

[0032] 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.

[0033] Through the digital identity management solution provided in the embodiments of this specification, based on blockchain and attribute encryption technology, the management agency provides the sub-private key and attribute list of the blockchain account, which can build a trusted digital identity corresponding to the blockchain account, and can conveniently authenticate the user corresponding to the blockchain account based on the digital identity of the blockchain account, thereby binding the blockchain account in the digital world with the physical user in the physical world. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] 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.

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

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

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

[0038] 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;

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

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

[0041] 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.

[0042] Figure 1 FIG1 shows a blockchain architecture diagram in one embodiment. Figure 1In 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.

[0043] 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.

[0044] Blockchains offer smart contract functionality. Smart contracts on blockchains are contracts whose execution can be triggered by transactions within the blockchain system. Smart contracts can be defined in code. Calling a smart contract on a blockchain involves initiating a transaction to the smart contract address, enabling each node in the blockchain to execute the smart contract code in a distributed manner. 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 within the blockchain.

[0045] 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.

[0046] In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to Figure 1 In 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.

[0047] 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.

[0048] 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, 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 form a complete identity entity. By generating an attribute list of the user corresponding to a blockchain account by a management device, including the blockchain account in this attribute list, generating a child private key based on a key generation algorithm in an attribute encryption system, and storing the child private key and attribute list in association with the blockchain account in the blockchain, a user can generate a signature based on an attribute signature algorithm. This signature can be used to verify that the user or account corresponds to one or more attributes.

[0049] Figure 2 This is a schematic diagram of the architecture of the digital identity management system provided in the embodiment of this specification. Figure 2 As shown, the system includes a blockchain 100, a user device 10, an authentication device 20, and a management device 30. The user device 10 can be any terminal device, such as a smartphone, a computing device, a notebook, a tablet computer, etc., without limitation. The user device 10 can upload the user's identity information to the blockchain 100 through the user's corresponding blockchain account. The authentication device 20 can upload the user's attribute information associated with the account, such as academic certificates, marriage certificates, years of work experience, etc., after verifying that the blockchain account corresponds to the user. It can be understood that Figure 2 Although only one authentication device 20 is shown, in practice, different attributes of a user can be uploaded by devices (i.e., authentication devices) from different organizations or units. The management device 30 is a trusted device that can obtain the user's identity information from the user device or the user's attribute information from the blockchain, generate the user's attribute list based on the user's attribute information, generate the user's sub-private key based on the key generation algorithm in the attribute encryption system, and upload the user's attribute list, sub-private key, and user account to the blockchain, thereby storing the digital identity corresponding to the blockchain account in the blockchain. The user can use the attribute list and sub-private key to generate a signature that complies with a certain policy to prove to other people or companies that the user or the user corresponding to the account has all the attributes included in the policy, where all the attributes included in the policy are one or more attributes in the user's attribute list.

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

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

[0052] The management device 30 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 30. As another example, the management device 30 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.

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

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

[0055] Specifically, the management device 30 can send a transaction Tx1 to any blockchain node in the blockchain 100. This transaction Tx1 can be sent from the blockchain account A1 of the management organization corresponding to the management device 30. 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 30 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.

[0056] 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 30 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.

[0057] In step S305 , the authentication device 20 obtains the master public key from the blockchain 100 .

[0058] The authentication device 20 can receive the master public key mpk from any node in the blockchain 100 by sending a query transaction to call the contract C1. At the same time, the authentication device can also similarly obtain the public key systemPK of the account A1 corresponding to the management device 30 from the blockchain.

[0059] In step S307 , the user device 10 sends the user information to the management device 30 .

[0060] In one embodiment, the user device 10 only generates the user's account private key usk and account public key upk, but does not create the user's blockchain account. The user device 10 can call the service RegisterAccount() for creating a blockchain account provided by the management device 30 to create a blockchain account. Specifically, the user device 10 can obtain the public key systemPK of the management agency from the blockchain 100. The user device 10 calls the account registration function RegisterAccount(userinfocipher, upk), where userinfocipher is obtained, for example, by the following formula (1):

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

[0062] Wherein, userinfo represents user information, specifically user identity information, which includes, for example, the user's name, identity identifier, ID photo, etc. ECIES_ENCRYPT represents the encryption algorithm in the elliptic curve integrate encrypt scheme (ECIES) encryption and decryption algorithm.

[0063] After receiving the service request, the management device 30 can obtain the user information userinfo by the following formula (2):

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

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

[0066] After obtaining the user information and the user public key upk, the management device 30 performs identity verification and authentication based on the user information. After passing the review, it generates an account A2 corresponding to the user based on the public key upk and returns the account A2 to the user device 10.

[0067] At the same time, the certification authority corresponding to the authentication device 20 can similarly send the certification authority's institutional information to the management device 30. The authentication device 20 can also upload the institutional information by calling the account registration function to request the blockchain account of the certification authority.

[0068] In step S309 , the management device 30 uploads the user information to the blockchain 100 .

[0069] Management device 30 can upload account A2 or its public key upk to the blockchain by sending a transaction to the blockchain, in association with user information, such as the ciphertext format described above. After executing this transaction, each node in the blockchain can store userinfocipher in the contract state of contract C1, in association with account A2 or upk, for evidence storage.

[0070] In another embodiment, the user corresponding to user device 10 can create account A2 and the corresponding private key usk and public key upk. User device 10 can then send transaction Tx2 to blockchain 100 via account A2, invoking contract C1, thereby uploading user information to blockchain 100. This user information may include, for example, the user's name, identification, and ID photo. By executing transaction Tx2, each node in blockchain 100 can store this user information in association with account A2 in contract C1. Furthermore, the user information may also include account A2's public key upk, which can be used to verify digital signatures and encrypt data.

[0071] Among them, the user device 10 can obtain the public key systemPK of the management agency from the blockchain 100, so that the ciphertext userinfocipher of the user information can be included in the transaction Tx2. The ciphertext userinfocipher can be generated by the above formula (1).

[0072] The management device 30 can obtain user information or organization information from the blockchain 100 by sending a query transaction to the blockchain that calls the contract C1. In the case where the user information is encrypted using the public key systemPK of the management organization, the management device 30 can also decrypt the ciphertext using the private key systemSK of the management organization to obtain the user information.

[0073] In step S311 , the management device 30 generates an attribute list and a child private key of an account corresponding to the user.

[0074] Generate an attribute list Attrilist for the blockchain account A2. In the second embodiment, the management device 30 creates the blockchain account A2 after verifying the user information.

[0075] The attribute list Attrilist includes one or more attributes of the user corresponding to the account A2. For example, the attribute list Attrilist may include multiple attributes such as the account A2, the public key upk, the name, the identity identifier, and the passport data.

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

[0077] sk=CPABE_keygen(Attrilist, msk, mpk) (3)

[0078] As can be seen from formula (3), the input parameters of the function CPABE_keygen() include Attrilist, msk and mpk. The sub-private key sk is generated by the attribute-based encryption algorithm. The sub-private key sk can be used to perform attribute signing based on the signature policy to obtain a signature to prove that account A2 or the user corresponding to account A2 has the specific attributes in Attrilist (that is, it satisfies the signature policy), and mpk can be used to verify that the signature is true based on the signature policy, that is, to verify that account A2 or the user corresponding to account A2 has the specific attributes in Attrilist.

[0079] In step S313 , the management device 30 uploads the account's sub-private key and attribute list to the blockchain 100 .

[0080] The management device 30 may send a transaction Tx4 to the blockchain 100 to call the contract C1, so as to store the attribute list Attrilist and the sub-private key sk of the account A2 in the account information list Accountinfolist in the contract state of the contract C1.

[0081] The management device 30 may include in the transaction Tx4 the ciphertext accountCipher obtained by encrypting the attribute list Attrilist and the sub-private key sk using the public key upk of the account A2, and store the ciphertext in Accountinfolist to better protect user privacy.

[0082] After executing transaction Tx4, each node in blockchain 100 stores the attribute list Attrilist and the child private key sk in association with account A2 in Accountinfolist in the contract state of contract C1, or stores the ciphertext accountCipher in association with account A2.

[0083] Specifically, in AccountInfoList, the ciphertext accountCipher, i.e., {A2, accountCipher}, can be stored in association with account A2, so that the user can obtain the account information corresponding to account A2 from AccountInfoList based on account A2. In the case where the user applies to register account A2, the user device 10 can obtain the created account A2 from the management device. In another embodiment, in AccountInfoList, the public key upk and the ciphertext accountCipher, i.e., {A2, upk, accountCipher}, can be stored in association with account A2, so that the user can obtain the account information corresponding to account A2 from AccountInfoList based on the public key upk.

[0084] In step S315 , the user device 10 obtains the child private key and attribute list of account A2 from the blockchain 100 .

[0085] 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, and queries the account information corresponding to account A2 or public key upk in Accountinfolist. After receiving the query transaction, the blockchain node finds the corresponding account information in Accountinfolist based on account A2 or public key upk. This account information includes the sub-private key and attribute list corresponding to account A2, and sends this account information to user device 10. If accountCipher is stored in Accountinfolist, accountCipher is sent to user device 10. After receiving accountCipher, user device 10 decrypts accountCipher using the user's private key usk to obtain the sub-private key and attribute list corresponding to account A2.

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

[0087] In the physical world, a certification authority might issue a paper certification certificate to the user corresponding to user device 10. For example, after completing their studies at a university, 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 issue the attributes corresponding to the paper certificate to the individual's corresponding blockchain account and thereby complete the digital identity corresponding to the blockchain account, user device 10 can generate proof data based on an attribute signature algorithm to prove that the blockchain account corresponds to the user's identity identifier. This proof data is the signature generated by the attribute signature algorithm.

[0088] Specifically, the user device 10 can perform attribute signature on the data data1 agreed with the certification authority 20 to obtain the signature sign1. The signature policy information policy1 includes the blockchain account A2 and identity in the user's attribute list Attrilist, that is, policy1 = {A2, identity}. Where data1 is generated, for example, as shown in the following formula (4):

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

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

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

[0092] sign1=CPABE_sign(sk,policy1,data1) (5)

[0093] The CPABE_sign() function in formula (5) is an attribute signature function. By inputting sk, policy1, and data1 into the attribute signature function, the signature is successful only when the attribute list Attrilist 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 identity identifier and that the binding relationship has been verified by the management agency.

[0094] In step S319 , the user device 10 sends the signature sign1 and the policy information policy1 to the authentication device 20 .

[0095] Specifically, in order to protect the privacy information of the user in policy1, the user device 10 can use the public key of the certification authority corresponding to the authentication device 20 to encrypt sign1 and policy1, and send the encrypted ciphertext to the authentication device 20, so that the authentication device 20 can decrypt the ciphertext using the private key of the certification authority to obtain sign1 and policy1.

[0096] In step S321 , the authentication device 20 verifies the signature sign1 using the master public key mpk and the policy information policy1 .

[0097] The authentication device 20 can calculate data1 according to formula (4) in accordance with the pre-agreed agreement. Then, the authentication device 20 can verify the signature sign1 using the following formula (6) to obtain the verification result result1:

[0098] result1=CPABE_verify(mpk,policy1,data1,sign1) (6)

[0099] In formula (6), CPABE_verify is a function used to verify the signature. By inputting mpk, policy1, data1, and sign1 as parameters into the CPABE_verify function, the function can output true or false as the verification result. Specifically, if sign1 is indeed successfully signed based on all the attributes in policy1, the function outputs true, thereby verifying that account A2 is bound to the identity identifier.

[0100] In step S323 , the authentication device 20 uploads the user attributes corresponding to the account A2 to the blockchain 100 .

[0101] After verifying that account A2 is bound to the user's identity, authentication device 20 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 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.

[0102] The authentication device 20 can upload the user attributes corresponding to account A2 to the blockchain 100 by sending a transaction Tx5 that calls contract C1. This transaction Tx5 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 Tx5 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):

[0103] infocipher=ECIES_ENCRYPT(systempk,info) (7)

[0104] 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.

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

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

[0107] 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.

[0108] When executing transaction Tx5, 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.

[0109] In step S325 , the management device 30 obtains the newly added user attributes corresponding to account A2 from the blockchain 100 .

[0110] The management device 30 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.

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

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

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

[0114] 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 associated with management device 30 also verifies the legitimacy and validity of the information info off-chain, including verifying the certification authority's qualifications and the validity of the issuance time.

[0115] In step S327 , the management device 30 updates the attribute list and child private key of the account A2 .

[0116] After all of the above verifications pass, the management device 30 adds one or more attributes of account A2 included in the information info to the attribute list Attrilist of account A2, thereby obtaining an updated attribute list for account A2. For example, the updated attribute list may include multiple attributes such as account A2, public key upk, name, identification data, passport data, master's degree, university degree, and computer science major. The management device 30 may then generate an updated child private key sk for account A2 based on formula (3).

[0117] In step S329 , the management device 30 uploads the updated child private key and attribute list of account A2 to the blockchain 100 .

[0118] In step S331 , the user device 10 obtains the updated sub-private key and attribute list of account A2 from the blockchain 100 .

[0119] For step S329 and step S331, reference may be made to the above description of step S313 and step S315, which will not be repeated here.

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

[0121] In step S333 , the user device 10 generates a signature using the updated sub-private key and the policy information.

[0122] Similar to step S317, the user device 10 may calculate a new signature sign2 based on formula (10) to verify any attribute in the attribute list Attrilist possessed by the account A2, which is defined by the policy information policy2:

[0123] sign2=CPABE_sign(sk,policy2,data2) (10)

[0124] In formula (10), 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 exceed a preset amount, the credit value of account A2 exceeds a preset value, etc. The verifier can agree with the user corresponding to account A2 on the attribute signature policy policy2 = {A2, assets greater than x yuan, credit value greater than y}.

[0125] The user device 10 may then generate a signature sign2 based on formula (10), Figure 4 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 4As 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 "account A2 identity proof." By inputting policy2, sk, and data2 as parameters into the attribute signature algorithm, signature sign2 is successfully generated only when the attribute list Attrilist corresponding to account A2 includes all attributes in policy2. This sign2 serves as proof data 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.

[0126] 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}.

[0127] The verifier can use formula (11) to verify sign2:

[0128] Result2=CPABE_verify(mpk,policy2,data2,sign2) (11)

[0129] Figure 5 Schematic diagram of the process of verifying signature based on attribute signature algorithm in the embodiment of this specification. Figure 5 As shown in , by inputting the above-mentioned policy2, mpk, data2 and sign2 into the attribute signature verification algorithm, that is, CPABE_verify() in formula (11), 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 Attrilist 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.

[0130] In addition, the user corresponding to account A2 can also generate a signature using formula (10) to prove that the user has specific attributes. For example, policy2 may include the attributes {identity identifier, master's degree, computer science major}. The signature generated using this policy can be used to prove that the user has a master's degree and a computer science major. The verifier can verify the signature in a similar manner as above.

[0131] Figure 6 This is an architectural diagram of a blockchain node provided in an embodiment of this specification, wherein the blockchain stores attribute information of a user corresponding to a first account, and the blockchain node includes:

[0132] A sending unit 61 is configured to send attribute 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;

[0133] a receiving unit 62 configured to receive, from the management device, a first sub-private key and a first attribute list corresponding to the first account, wherein the first attribute list includes the first account and the attribute information, and the first sub-private key is generated based on the first attribute list, the master public key, and the master private key;

[0134] The storage unit 63 is configured to store the first sub-private key and the first attribute list.

[0135] Through the digital identity management solution provided in the embodiments of this specification, based on blockchain and attribute encryption technology, the management agency provides the sub-private key and attribute list of the blockchain account, which can build a trusted digital identity corresponding to the blockchain account, and can conveniently authenticate the user corresponding to the blockchain account based on the digital identity of the blockchain account, thereby binding the blockchain account in the digital world with the physical user in the physical world.

[0136] 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.

[0137] 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.

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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.

[0142] 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.

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

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

[0145] 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.

[0146] 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.

[0147] 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.

[0148] 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.

[0149] 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.

[0150] 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, an authentication device, a user device, and a blockchain, wherein the blockchain stores first attribute information of a user corresponding to a first account, the first attribute information including the user's identity information, and the management device includes a master public key and a master private key generated based on an attribute encryption algorithm. The management device is configured to: obtain first attribute information of a user corresponding to the first account from the blockchain; generate a first attribute list for the user; generate a first child private key based on the first attribute list, the master public key, and the master private key, wherein the first attribute list includes the first account and the first attribute information; and send the first child private key and the first attribute list to the blockchain; The blockchain is used to store the first sub-private key and the first attribute list; The user device is configured to obtain the first sub-private key and the first attribute list from the blockchain, perform an attribute signature based on the first sub-private key and the first policy information to obtain a first signature, and send the first signature and the first policy information to the authentication device, where the first policy information includes the first account and the identity information of the user in the first attribute list; The authentication device is used to verify the first signature based on the pre-acquired master public key and the first policy information, and if the verification is successful, upload the second attribute corresponding to the first account to the blockchain.

2. The system according to claim 1, wherein the management device is further configured to: obtain second attribute information of the user corresponding to the first account from the blockchain, wherein the second attribute information includes the identity information of the user and the second attribute; generating a second attribute list for the user, the second attribute list including the first account and the second attribute information, and generating a second child private key based on the second attribute list, the master public key, and the master private key; Send the second child private key and the second attribute list to the blockchain.

3. According to the system of claim 1, the user device is further used to: obtain a second sub-private key and a second attribute list corresponding to the first account from the blockchain, perform an attribute signature based on the second sub-private key and second policy information to obtain a second signature, and the second policy information includes at least one attribute in the second attribute list.

4. The system according to claim 1 or 3, wherein a first contract is deployed in the blockchain, and when the management device sends the first sub-private key and the first attribute list to the blockchain, the management device is specifically configured to: send a first transaction to the blockchain that invokes the first contract, wherein the first transaction includes the first sub-private key and the first attribute list; When storing the first sub-private key and the first attribute list, the blockchain is specifically used to: store the first sub-private key and the first attribute 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.

5. The system according to claim 4, wherein the first transaction includes a first account and a first ciphertext obtained by encrypting a first sub-private key and the first attribute list of the first account, the first ciphertext being generated by encrypting the first sub-private key and the first attribute list using the public key of the first account, and the blockchain, when storing the first sub-private key and the first attribute list, is specifically configured to: store the first ciphertext in association with the first account in the account information list according to the first transaction.

6. The system according to claim 4, wherein the management device is further configured to create a first account after verifying the identity information of the user; The blockchain is further configured to store the second attribute in association with the first account.

7. According to the system according to claim 2, when uploading the second attribute corresponding to the first account to the blockchain, the authentication device is specifically used to: send a second transaction to the blockchain that calls the first contract, wherein the second transaction includes the first account and the second attribute; and the blockchain is used to store the second attribute of the user in association with the first account in the authentication information list in the contract status of the first contract according to the second transaction.

8. According to the system of claim 7, when uploading the second attribute corresponding to the first account to the blockchain, the authentication device is further specifically used to: send to the blockchain the third signature of the second account of the authentication agency corresponding to the authentication device for the second transaction; when the blockchain is used to store the second attribute in association with the first account in the authentication information list according to the second transaction, it is specifically used to: store the second attribute of the user and the third signature in association with the first account in the authentication information list according to the second transaction.

9. According to the system of claim 8, when the management device obtains the attribute information of the user corresponding to the first account from the blockchain, it is specifically used to obtain the second attribute and the third signature stored in association with the first account from the authentication information list; when the management device generates the second attribute list of the user, it is specifically used to generate the second attribute list after verifying that the second account corresponds to the authentication authority and the third signature is verified.

10. The system according to claim 9, wherein the authentication device is further configured to: send a third transaction to the blockchain for invoking the first contract, the third transaction being used to register the authentication authority, the third transaction including information about the authentication authority; and the blockchain is further configured to store the information about the authority in the contract state of the first contract according to the third transaction; The management device is used to obtain the organization information from the blockchain, create the second account after verifying the organization information, and store the second account and the organization information in association.

11. The system according to claim 6, wherein: The user device is further used to: send a fourth transaction to the blockchain to call the first contract, the fourth transaction is used to register the user, and the fourth transaction includes the user's identity information; the blockchain is also used to store the user's identity information in the contract state of the first contract according to the fourth transaction.

12. According to the system of claim 11, the fourth transaction includes a second ciphertext of the user's identity information, the second ciphertext is generated by encrypting the public key of the third account corresponding to the management device, and the blockchain is specifically used to store the second ciphertext in the contract state of the first contract when storing the user's identity information.

13. A digital identity management method, executed by a blockchain node, wherein the blockchain stores attribute information of a user corresponding to a first account, the attribute information including the user's identity information, the method comprising: Sending first attribute 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, the first attribute information including identity information of the user; receiving, from the management device, a first sub-private key and a first attribute list corresponding to the first account, wherein the first attribute list includes the first account and the identity information, and the first sub-private key is generated based on the first attribute list, the master public key, and the master private key; storing the first sub-private key and the first attribute list; A second sending unit, configured to send the first sub-private key and the first attribute list to a user equipment; A second receiving unit is used to receive a second attribute corresponding to the first account uploaded by an authentication device; the second attribute is uploaded when the first verification passes, the first verification includes verifying the first signature based on the pre-acquired master public key and first policy information, and the first signature is obtained by the user device signing the attribute based on the second sub-private key and the second policy information.

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

15. The method according to claim 14, wherein the first transaction includes the first account and a first ciphertext encrypted by encrypting a first sub-private key and the first attribute list of the first account, the first ciphertext being generated by encrypting the first account using a public key, and wherein storing the first sub-private key and the first attribute 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.

16. A blockchain node, wherein the blockchain stores attribute information of a user corresponding to a first account, the attribute information including identity information of the user, the blockchain node comprising: a first sending unit, configured to send first attribute 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, the first attribute information including identity information of the user; a first receiving unit, configured to receive, from the management device, a first sub-private key and a first attribute list corresponding to the first account, wherein the first attribute list includes the first account and identity information, and the first sub-private key is generated based on the first attribute list, the master public key, and the master private key; a storage unit, configured to store the first sub-private key and the first attribute list; A second sending unit, configured to send the first sub-private key and the first attribute list to a user equipment; A second receiving unit is used to receive a second attribute corresponding to the first account uploaded by an authentication device; the second attribute is uploaded when the first verification passes, the first verification includes verifying the first signature based on the pre-acquired master public key and first policy information, and the first signature is obtained by the user device signing the attribute based on the second sub-private key and the second policy information.

17. 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 13 to 15.

Images