Data processing method and related equipment

Abstract

The data processing method comprises the following steps: a second client extracts a public key of a second user from an identity certificate of the second user, performs hierarchical encryption on data by using the public key of the second user to obtain a ciphertext, and stores the ciphertext and the identity certificate of the second user in a block chain network; and the first client obtains the ciphertext and the identity certificate of the second user from the block chain network, and verifies the legality of the identity certificate of the second user by using the root certificate. And when the verification is passed, the first client extracts the first derived information from the identity certificate of the first user and extracts the second derived information from the identity certificate of the second user. Wherein the derivation information indicates a derivation path of the identity certificate. And the first client determines a private key of the second user according to the derived information and the private key of the first user, and decrypts the ciphertext according to the private key of the second user to obtain data. According to the method, an authentication mechanism of an identity certificate is used for carrying out identity authentication on a public key, the identity trust problem is solved, and the visibility of data divided according to levels is realized.

Description

[0001] This application claims priority to Chinese Patent Application No. 202410809099.3, filed with the State Intellectual Property Office of China on June 20, 2024, entitled "A Blockchain Data Processing Method and Related Equipment", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of blockchain technology, and in particular to a data processing method, a blockchain management system, a computing device cluster, a computer-readable storage medium, and a computer program product. Background Technology

[0003] Blockchain technology is a novel distributed infrastructure and computing paradigm that uses a block-chain data structure to verify and store data, a consensus algorithm of distributed nodes to generate and update data, cryptography to ensure the security of data transmission and access, and smart contracts composed of automated script code to program and manipulate data.

[0004] Blockchain technology has broad application prospects in many fields, such as digital government and financial transaction settlement. In many blockchain application scenarios, there is a need for hierarchical data visibility. Hierarchical visibility allows users / nodes at higher levels to view the data of users / nodes at lower levels, but users / nodes at lower levels cannot view the data of users / nodes at higher levels, and data is not visible between users / nodes at the same level.

[0005] Hierarchical encryption allows for hierarchical visibility. Currently, widely used hierarchical encryption schemes include derivative-based schemes, which use typical asymmetric public and private keys for encryption and decryption. However, the public key itself cannot solve the problems of authenticity and validity, usually requiring the use of a trusted third-party institution, introducing centralization risks, increasing costs, and making it difficult to meet business needs. Summary of the Invention

[0006] This application provides a data processing method that combines the identity certificates used by users in a blockchain network when conducting transactions or verifying signatures with derivative-based layered encryption. The layered encryption utilizes the authentication mechanism of the identity certificate when using public keys and other information to verify the identity of the public key, thus resolving the trust issue related to the public key's identity. This method eliminates the need for an additional third-party institution to prove the authenticity and validity of the public key, avoiding centralized risks, reducing costs, and meeting business needs. This application also provides a blockchain management system, computing device cluster, computer-readable storage medium, and computer program products corresponding to the above method.

[0007] Firstly, this application provides a data processing method. This method is applied to a blockchain management system. The blockchain management system includes a first client, a second client, and a blockchain network. The first client is a client of a first user, and the second client is a client of a second user.

[0008] Specifically, the second client extracts the second user's public key from the second user's identity certificate, uses the second user's public key to encrypt the data in layers to obtain ciphertext, and stores the ciphertext and the second user's identity certificate in the blockchain network. Then, the first client retrieves the ciphertext and the second user's identity certificate from the blockchain network and verifies the legitimacy of the second user's identity certificate using the root certificate. If the verification is successful, the first client extracts first derivation information from the first user's identity certificate and second derivation information from the second user's identity certificate. The first derivation information indicates the derivation path of the first user's identity certificate, and the second derivation information indicates the derivation path of the second user's identity certificate. The first client determines the second user's private key based on the first derivation information, the second derivation information, and the first user's private key. The first client decrypts the ciphertext using the second user's private key to obtain the data.

[0009] This method combines the identity certificates used by users on a blockchain network when conducting transactions or verifying signatures with derivation-based layered encryption. Specifically, it automatically appends layered encryption derivation information, such as the derivation path of the identity certificate, when generating or creating a user's identity certificate. Layered encryption utilizes the authentication mechanism of the identity certificate when using public keys and other information to verify the identity of the public key, resolving the issue of trust in the public key's identity. This method eliminates the need for an additional third-party institution to prove the authenticity and validity of the public key, avoiding centralized risks and reducing costs, thus meeting business needs. Furthermore, users no longer need to distribute and store dedicated keys for layered encryption, simplifying key management and enhancing security. In addition, data encrypted with the public key extracted from the user's identity certificate can naturally be monitored by upper-level users, addressing the problem of insufficient oversight and constructing a blockchain identity system with inherent oversight attributes.

[0010] In some possible implementations, the first client can determine the hierarchical relationship between the first user and the second user based on the first and second derived information. Then, the first client extracts the user identifier of the second user from the second derived information based on the hierarchical relationship. Next, the first client determines the private key of the second user using the user identifier of the second user and the private key of the first user through a derivation algorithm.

[0011] In this method, upper-level users can deduce the private keys of lower-level users based on the user hierarchy. Lower-level users' data is visible to upper-level users, thus achieving hierarchical visibility of data. Furthermore, this method eliminates the need for users to perform additional key management, simplifying user operations and reducing user costs.

[0012] In some possible implementations, the first client can concatenate the first user's private key, the first user's chaincode, and the second user's user identifier to obtain the concatenated result. The first client then performs a hash operation on the concatenated result to obtain the second user's private key. The first user's chaincode can be a random number, such as a 256-bit random number. By combining the user identifier and the random number to generate the lower-level user's key, the lower-level user's key can be prevented from relying solely on the upper-level user's key, further enhancing key security.

[0013] In this method, the first user can be the direct superior user of the second user. The first user can deduce the second user's key through a single key generation, thus enabling efficient decryption of the second user's data.

[0014] In some possible implementations, the first client can determine the third user's private key using a derivation algorithm based on the first user's private key and the third user's user identifier, with the third user being a sub-user of the first user. Alternatively, the first client can determine the second user's private key using a derivation algorithm based on the third user's private key and the second user's user identifier, with the second user being a sub-user of the third user.

[0015] In this method, the first user can be a non-direct parent user of the second user (such as an indirect parent user). The first user can deduce the private key of the lower-level users layer by layer until the private key of the second user is derived. In this way, upper-level users can view and supervise the data of lower-level users at any level, realizing the visibility of data divided by hierarchy.

[0016] In some possible implementations, the second derived information is generated based on the first derived information and the user identifier of the second user. For example, the second derived information can be generated by accumulating the first derived information and the user identifier of the second user, and the first derived information can be generated by accumulating the user identifier of the first user and the user identifier of the user above the first user.

[0017] This method generates derived information by accumulating user identifiers, which enables the extraction of hierarchical relationships based on the derived information, and then performs key management based on the hierarchical relationships, laying the foundation for data visibility to be divided by hierarchy.

[0018] In some possible implementations, the first client can extract the first derived information from the extended fields of the first user's identity certificate. This allows for the combination of identity certificates and layered encryption without altering the structure of the identity certificate, offering high compatibility and usability.

[0019] Secondly, this application provides a blockchain management system. The blockchain management system includes a first client, a second client, and a blockchain network, wherein the first client is a client of a first user, and the second client is a client of a second user;

[0020] The second client is used to extract the public key of the second user from the identity certificate of the second user, use the public key of the second user to encrypt the data in layers to obtain ciphertext, and store the ciphertext and the identity certificate of the second user in the blockchain network;

[0021] The first client is configured to obtain the ciphertext and the identity certificate of the second user from the blockchain network, and verify the legitimacy of the identity certificate of the second user using the root certificate;

[0022] The first client is further configured to, upon successful verification, extract first derived information from the first user's identity certificate and second derived information from the second user's identity certificate, wherein the first derived information is used to indicate the derivation path of the first user's identity certificate and the second derived information is used to indicate the derivation path of the second user's identity certificate.

[0023] The first client is further configured to determine the private key of the second user based on the first derived information, the second derived information, and the private key of the first user;

[0024] The first client is also configured to decrypt the ciphertext using the second user's private key to obtain the data.

[0025] In some possible implementations, the first client is specifically used for:

[0026] Based on the first derived information and the second derived information, determine the hierarchical relationship between the first user and the second user;

[0027] Based on the hierarchical relationship, extract the user identifier of the second user from the second derived information;

[0028] The private key of the second user is determined by a derivation algorithm based on the user identifier of the second user and the private key of the first user.

[0029] In some possible implementations, the first client is specifically used for:

[0030] The private key of the first user, the chaincode of the first user, and the user identifier of the second user are concatenated to obtain the concatenation result;

[0031] Perform a hash operation on the concatenated result to obtain the private key of the second user.

[0032] In some possible implementations, the first client is specifically used for:

[0033] Based on the private key of the first user and the user identifier of the third user, the private key of the third user is determined by a derivation algorithm, and the third user is a sub-user of the first user;

[0034] Based on the private key of the third user and the user identifier of the second user, the private key of the second user is determined by a derivation algorithm, and the second user is a sub-user of the third user.

[0035] In some possible implementations, the second derived information is generated based on the first derived information and the user identifier of the second user.

[0036] In some possible implementations, the first client is specifically used for:

[0037] Extract the first derived information from the extended fields of the first user's identity certificate.

[0038] Thirdly, this application provides a computing device cluster. The computing device cluster includes at least one computing device, which includes at least one processor and at least one memory. The at least one processor and the at least one memory communicate with each other. The at least one processor is used to execute instructions stored in the at least one memory to cause the computing device or the computing device cluster to perform the data processing method as described in the first aspect or any implementation thereof.

[0039] Fourthly, this application provides a computer-readable storage medium storing instructions that instruct a computing device or a cluster of computing devices to perform the data processing method described in the first aspect or any implementation thereof.

[0040] Fifthly, this application provides a computer program product containing instructions that, when run on a computing device or a cluster of computing devices, causes the computing device or cluster of computing devices to perform the data processing method described in the first aspect or any implementation thereof.

[0041] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0042] To more clearly illustrate the technical methods of this application, the accompanying drawings used will be briefly described below.

[0043] Figure 1A A schematic diagram of a conventional derivative provided for this application;

[0044] Figure 1B A schematic diagram illustrating an enhanced derivative provided in this application;

[0045] Figure 2 A schematic diagram of the architecture of a blockchain management system provided for this application;

[0046] Figure 3 An interactive flowchart of a data processing method provided in this application;

[0047] Figure 4 A flowchart of data encryption and decryption in a data processing method provided in this application;

[0048] Figure 5 A schematic diagram of the structure of a computing device provided in this application;

[0049] Figure 6 This application provides a schematic diagram of the structure of a computing device cluster;

[0050] Figure 7 This is a schematic diagram of another computing device cluster provided in this application. Detailed Implementation

[0051] The terms "first" and "second" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" and "second" may explicitly or implicitly include one or more of that feature.

[0052] First, some technical terms involved in the embodiments of this application will be introduced.

[0053] A blockchain network is a technological infrastructure that provides ledger and smart contract services for applications. Specifically, it's a peer-to-peer network system that uses cryptography and consensus mechanisms to establish and store a massive chain of transaction data. Blockchain networks can be categorized based on data access permissions: public blockchains, consortium blockchains, and fully private blockchains. Public blockchains have lower barriers to data access, allowing any user to access the data via computer. Consortium blockchains offer data access only to organizations or institutions within the consortium, while private blockchains restrict access to specific organizations or institutions. Because data is publicly available on the blockchain network, visibility can be hierarchically defined to meet security requirements.

[0054] Hierarchical encryption is an algorithmic model for data protection that implements hierarchical data access control, thereby enabling the visibility of data to be divided according to its levels. In this model, a master key is used to generate multiple subkeys, each with its own access permissions and encryption level. The highest-level key can access data at all levels, while lower-level keys can only access data at their corresponding level or below. Based on this, each user can hold their own public and private keys. Lower-level users' keys can be generated by higher-level users, and data encrypted by lower-level users can be decrypted by higher-level users using their own private keys, thus achieving data oversight. Simultaneously, higher-level users do not need to manage numerous lower-level users' private keys, reducing the complexity of key management and the risk of private key leakage.

[0055] Currently, the industry typically uses derivative-based hierarchical encryption to achieve hierarchical visibility of data. Typical implementations of derivative-based hierarchical encryption schemes can include hierarchical deterministic wallets or tiered deterministic wallets. Tiered deterministic wallets allow users to select a seed and deterministically derive a large number of key pairs from it in a tree structure. Users do not need to save these derived key pairs; they only need to keep the seed. When needed, the seed is imported into the wallet to authenticate assets controlled by all private keys derived from that seed.

[0056] Specifically, users can generate a seed using a mnemonic phrase, hash the seed to obtain the root private key and root public key, and use the root public-private key pair to derive multiple hierarchical sub-public-private key pairs. These public-private key pairs are then used for encryption and decryption. In hierarchical deterministic wallets, to prevent subkeys from relying solely on their parent keys, each public-private key pair corresponds to a 256-bit random number, called the chaincode, and their combination is called the extended key. There are two ways to generate subkeys: regular derivation and enhanced derivation. When the index i satisfies 0 ≤ i < 2... 31 When this happens, a subkey can be generated through conventional derivation, provided that index i satisfies 2.31 ≤i<2 32 When the value is -1, a subkey can be generated through enhanced derivation.

[0057] like Figure 1A As shown, in a typical derivation, the child private key and child chain code are generated from the parent public key, parent chain code, and index number. For example... Figure 1B As shown, in the enhanced derivation, the parent private key, parent chain key, and index number generate the child private key and child chain key. Upper-level users can deduce the lower-level user's private key based on the key pair derivation relationship, thereby enabling the decryption of data encrypted by the lower-level user.

[0058] However, while the above scheme uses asymmetric public-private keys for encryption and decryption, ensuring data immutability, the public key itself cannot guarantee authenticity and validity. Therefore, a trusted third-party institution is needed to verify the authenticity and validity of the public key. This introduces centralized risks and increases costs, making it difficult to meet business needs.

[0059] In view of this, this application provides a data processing method that combines the identity certificate used by users in a blockchain network when conducting transactions or verifying signatures with derivation-based layered encryption. Specifically, when generating or creating a user's identity certificate, derivation information of the layered encryption, such as the derivation path of the identity certificate, is automatically appended. Layered encryption can utilize the authentication mechanism of the identity certificate when using information such as public keys to verify the identity of the public key, thus resolving the issue of trust in the public key's identity. This method eliminates the need for an additional third-party institution to prove the authenticity and validity of the public key, avoiding centralized risks and reducing costs, thus meeting business needs. Furthermore, users no longer need to distribute and store dedicated keys for layered encryption, simplifying key management and enhancing security. In addition, data encrypted with the public key extracted from the user's identity certificate can naturally be monitored by upper-level users, addressing the problem of insufficient oversight and constructing a blockchain identity system with inherent oversight attributes.

[0060] The data processing method of this application can be executed by a blockchain management system. For ease of understanding, the system architecture of the blockchain management system of this application is described below with reference to the accompanying drawings.

[0061] See Figure 2The diagram illustrates the architecture of a blockchain network management system. The blockchain management system 10 includes a first client 102, a second client 104, and a blockchain network 200. The first client 102 is the client for a first user, and the second client 104 is the client for a second user. The second user is an upstream user of the first user; for example, the first user might be a regular user, and the second user might be a regulator. The blockchain network 200 includes multiple blockchain nodes 202. Each blockchain node 202 can be a node maintained or managed by an organization. For example, in a consortium blockchain, blockchain nodes 202 can be nodes maintained by different organizations. Figure 2 This example illustrates the use of multiple blockchain nodes (202) maintained by organizations A, B, C, and D respectively. Each organization possesses a root certificate and a root private key, the root certificate of which may be issued by a Certificate Authority (CA). Figure 2 Example illustration: Organization A has a CA root certificate, denoted as CA. a Organization B has a CA root certificate, denoted as CA. b Organization C has a CA root certificate, denoted as CA. c Organization D has a CA root certificate, denoted as CA. d A user's identity certificate can be derived from the root private key, and the identity certificate derived from the root private key can be verified for legitimacy through the root certificate. Each user holds their own private key and identity certificate, which are used to sign or verify signatures during on-chain transactions.

[0062] Figure 2 This example illustrates how an identity certificate is derived from the root private key of organization C for a user. When creating a user and generating their private key and identity certificate, the private key is no longer randomly generated. Instead, a hierarchical encryption algorithm is used to input derivation information. This derivation information can include a derivation path, which can be represented by the user's identifier and the identifiers of the parent user; therefore, it can also be called hierarchical identity information. The derivation path can be appended to an extension field of the identity certificate, allowing the user to deduce keys based on the derivation path in the extension field, thereby establishing a hierarchical regulatory relationship. In sensitive information encryption scenarios, the system no longer needs to create and distribute dedicated encryption keys separately. It directly uses the public key of the identity certificate for encryption and the private key for decryption. The upper-level regulator can decrypt the data using their own private key according to the hierarchical encryption algorithm, achieving data visibility to upper-level users but not to lower-level users, while simultaneously achieving a strong regulatory effect.

[0063] like Figure 2As shown, the first-tier regulator can derive the identity certificate of the first-tier regulated user based on the root certificate of organization C. The second-tier regulator can derive the identity certificate of the second-tier regulated user based on the identity certificate of the first-tier regulator. Ordinary users can derive their identity certificates based on the identity certificate of the second-tier regulator. It should be noted that the identity certificates of users at all levels can also be derived by the CA based on the CA root certificate.

[0064] After deriving the identity certificate, the lower-level user's client can initiate on-chain transactions. These on-chain transactions can be ciphertext obtained by encrypting data using the lower-level user's public key and storing it on the blockchain network. The upper-level user's client can retrieve the ciphertext from the blockchain network, deduce the lower-level user's private key using its own private key, decrypt the ciphertext, and thus obtain the data.

[0065] In this scenario, the upper-level user can be the first user, and the lower-level user can be the second user. The client for the first user is designated as first client 102, and the client for the second user is designated as second client 104.

[0066] The second client 104 is used to extract the second user's public key from the second user's identity certificate, use the second user's public key to encrypt the data in layers to obtain ciphertext, and then store the ciphertext and the second user's identity certificate in the blockchain network 200.

[0067] The first client 102 is used to obtain ciphertext and the identity certificate of the second user from the blockchain network 200, extract first derived information from the first user's identity certificate, and extract second derived information from the second user's identity certificate. The first derived information is used to indicate the derivation path of the first user's identity certificate, and the second derived information is used to indicate the derivation path of the second user's identity certificate. Then, the private key of the second user is determined based on the first derived information, the second derived information, and the private key of the first user. Based on the private key of the second user, the ciphertext is decrypted to obtain the data.

[0068] In on-chain transaction scenarios, the blockchain management system 10 maintains the functionality and usage of private keys and identity certificates, ensuring high availability and compatibility. When creating a new user, derived information is input, and the new user's identity certificate is derived based on this information, generating the new user's private key. The derived information is appended to the identity certificate, enabling layered encryption and decryption capabilities. Correspondingly, when using layered encryption, the blockchain management system 10 directly uses the user's private key and identity certificate (e.g., the public key from the identity certificate) for encryption and decryption, thus achieving automatic monitoring of on-chain data and efficient oversight. Furthermore, this scheme eliminates the need for additional key pairs, and users no longer need to distribute or store dedicated keys for layered encryption, simplifying key management and improving security. Moreover, combining layered encryption with identity certificates used for on-chain transactions or signature verification provides a mechanism to verify the identity of sensitive data owners.

[0069] It should be noted that, Figure 2 Taking the second user as the second-level regulator as an example, in practical applications, the second user can also be the first-level regulator (the indirect upper-level user of the first user). Alternatively, the first user can also be the second-level regulator, and correspondingly, the second user becomes the first-level regulator. In this case, the specific implementation of derived identity certificates and layered encryption based on identity certificates can be found in [link to relevant documentation]. Figure 2 The relevant descriptions of the embodiments will not be repeated here.

[0070] based on Figure 2 The blockchain management system 10 shown in this application also provides a data processing method. This will be described below with reference to the accompanying drawings.

[0071] See Figure 3 The diagram illustrates an interactive flowchart of a data processing method, which may include a derived identity certificate stage, a data encryption stage, and a data decryption stage. The different stages are described in detail below.

[0072] During the identity certificate derivation phase, the CA can generate a root private key and a root certificate, such as a CA root private key and a CA root certificate. First client 102 derives the first user's private key and identity certificate based on the CA root private key. Second client 104 derives the second user's private key and identity certificate based on the CA root private key. Specifically, second client 104 can derive the first user's private key and identity certificate from the CA root private key, and then derive the second user's private key and identity certificate from the first user's private key and identity certificate.

[0073] The CA root private key and the private keys of users at all levels can be generated using a derivation algorithm, rather than randomly. This derivation algorithm can include, but is not limited to, algorithms based on Bitcoin Improvement Proposals (BIPs). BIPs are Bitcoin's technical standards, and BIP numbers can be assigned through a selection process. For example, a hierarchical deterministic wallet is added to a BIP through a selection process and is assigned the BIP number BIP32. Based on this, the CA root private key and the private keys of users at all levels can be generated using a derivation algorithm based on BIP32.

[0074] CA root certificates and identity certificates for users at all levels can be generated using derived algorithms. Identity certificates can be in digital certificate format. In consortium blockchains, identity authentication typically uses X.509 digital certificates under the Public Key Infrastructure (PKI) system. X.509 is a standard that defines the structure and characteristics of digital certificates. A digital certificate includes at least one of the following: public key, holder information, issuer information, and validity period. Under the X.509 standard, each participant possesses a public-private key pair. The private key is held by the participant and used to sign transactions, while the public key is publicly provided and used to verify transaction signatures. An X.509 digital certificate is a collection of public key and identity information, signed by a trusted third party (such as a Certificate Authority (CA)). Any user who obtains an identity certificate can verify the match between the public key and identity information in the identity certificate by checking the signature, thereby determining the identity of the transaction initiator.

[0075] During the data encryption phase, the second client 104 extracts the second user's public key from the second user's identity certificate and encrypts the plaintext data (denoted as M) to obtain ciphertext (denoted as C). Then, the second client 104 can use the ciphertext and the second user's identity certificate {C, Cert} n} All uploaded to the blockchain. Cert n This represents the identity certificate of the second user. The second client 104 can append the second user's identity certificate to the ciphertext and then perform the on-chain operation. The blockchain network 200 can store the aforementioned ciphertext and identity certificate.

[0076] During the data decryption phase, the first client 102 can obtain the ciphertext and the second user's identity certificate from the blockchain network 200. The first client 102 can also verify the legitimacy of the identity certificate obtained from the blockchain network 200 based on the CA root certificate to confirm identity. Upon successful verification, the first client 102 can use its private key and the first derived information from the first user's ID card certificate and the second derived information from the second user's ID card certificate to deduce the second user's private key using a layered encryption algorithm. Then, it uses the second user's private key to decrypt the ciphertext and obtain the plaintext data.

[0077] Next, with reference to the accompanying drawings, the data encryption and decryption process in the data processing method provided in this application will be described in detail.

[0078] See Figure 4 The flowchart illustrates a data processing method that utilizes a blockchain management system 10. The blockchain management system 10 includes a first client 102, a second client 104, and a blockchain network 200. The first client 102 is a client for a first user, and the second client 104 is a client for a user. The method includes the following steps:

[0079] S402, the second client 104 extracts the second user's public key from the second user's identity certificate.

[0080] The second user's identity certificate can be derived from the root private key using a derivation algorithm. Specifically, the second user's private key can be generated based on the root private key, the second user's public key can be further generated based on the second user's private key, and the identity certificate can be generated based on the derivation information and the second user's public and private keys.

[0081] Specifically, the second client 104 can generate the second user's private key using a derivation algorithm based on the private key of the second user's parent user and the user identifier of the second user. When generating the second user's private key using the derivation algorithm, the chaincode of the second user's parent user can also be input and output.

[0082] The second user's private key can be a sub-private key, denoted as SK. child The private key of the parent user of the second user can be the parent's private key, denoted as SK. parent The chaincode of the second user can be a sub-chaincode, denoted as code. child The chaincode of the parent user of the second user can be the parent chaincode, denoted as code. parent The user identifier can be an index number, and the second user's user identifier can also be an index. child The second client 104 can derive the second user's private key according to the following formula. Furthermore, the second client 104 can also generate:

[0083] SK child code child =Hash 512 (SK parent ||code parent ||index child (1)

[0084] The derived private key can use an algorithm based on BIP32. In practice, the parent private key SK can be used first. parent Parent chain code parent The index number of the sub-user. child The keys are concatenated, and then a hash operation is performed on the concatenated result, such as a hash512 operation. In this example, the private key can be 256 bits, and the chaincode can be 256 bits.

[0085] Then, the second client 104 can generate the second user's public key based on the second user's private key. The second user's public key can be a sub-public key, denoted as PK. parent The second client 104 can generate the second user's public key using the following formula:

[0086]

[0087] in, This indicates the dot product operation of elliptic curves, where "G" represents the base point.

[0088] Next, the second client 104 can derive the second user's identity certificate based on the second user's private key, the second user's public key, and the second derived information (the second user's derived information). This derived information, denoted as a message, represents the hierarchical relationship between users and is typically formed by accumulating user identifiers. When generating a sub-user, the sub-user's user identifier (such as an index) can be added to the message to obtain the sub-user's message. The sub-user's message can be stored in the extended field of the identity certificate, allowing upper-level users to deduce the sub-user's private key based on their own private key and the aforementioned message.

[0089] In this example, the second user is a sub-user, and the second user's identity certificate can be denoted as Cert. child It can be based on the sub-private key SK child Public key PK child Sub-user derived information messages identity For details on generation, please refer to the following formula:

[0090] Cert child =Sign(SKchild PK child ||message identity (3)

[0091] In this case, the derived identity certificate can be obtained by concatenating (or linking) the sub-public key and the sub-user's derived information, and then signing the sub-private key and the concatenation result.

[0092] Based on this, the second client 104 can extract the second user's public key from the second user's identity certificate.

[0093] S404, the second client 104 uses the second user's public key to encrypt the data in layers to obtain ciphertext.

[0094] The second user's public key is generated using a derived hierarchical encryption algorithm. Based on this, the second client 104 can use the second user's public key to encrypt data using the hierarchical encryption algorithm, thereby obtaining ciphertext.

[0095] S406, the second client 104 stores the ciphertext and the identity certificate of the second user in the blockchain network 200.

[0096] Specifically, the second client 104 can append the second user's identity certificate to the ciphertext, for example, by appending it to the end of the ciphertext. Then, the second client 104 performs an on-chain operation on the ciphertext, thereby storing the ciphertext with the appended second user's identity certificate to the blockchain network 200. In some examples, the second client 104 can also perform on-chain operations on the ciphertext and the second user's identity certificate separately, thereby storing both the ciphertext and the second user's identity certificate to the blockchain network 200.

[0097] S408, the first client 102 obtains the ciphertext and the second user's identity certificate from the blockchain network 200.

[0098] The first client 102 can perform on-chain read operations to obtain ciphertext and the second user's identity certificate from the blockchain network 200. Specifically, the first client 102 can read the ciphertext and the second user's identity certificate from the ledger maintained by the chain nodes.

[0099] S410, the first client 102 uses the root certificate to verify the legitimacy of the second user's identity certificate.

[0100] Specifically, the second user's identity certificate is derived from the root certificate. Based on this, the first client 102 can use the root certificate to verify the legitimacy of the second user's identity certificate. The root certificate may include a root public key and a root private key. The root public key can be publicly disclosed, and the first client 102 can verify whether the identity certificate has been tampered with based on the fingerprint of the identity certificate.

[0101] Specifically, before issuing an identity certificate, the CA can use the root private key to determine the hash value of the issued identity certificate using a fingerprint algorithm. This hash value typically requires the corresponding root public key for decryption. When verifying the identity certificate, the first client 102 can use the same fingerprint algorithm to calculate a different hash value for the second user's identity certificate. If the hash value determined by the first client 102 based on the fingerprint algorithm is the same as the hash value obtained from parsing the signature on the identity certificate, it means the identity certificate has not been tampered with, and the validity verification of the identity certificate passes. If the hash value determined based on the fingerprint algorithm is different from the hash value obtained from parsing the signature on the identity certificate, it means the identity certificate has been tampered with, and the validity verification of the identity certificate fails.

[0102] S412, the first client 102 extracts first derived information from the identity certificate of the first user and extracts second derived information from the identity certificate of the second user.

[0103] The first derived information indicates the derivation path of the first user's identity certificate, and the second derived information indicates the derivation path of the second user's identity certificate. The derivation path can be generated cumulatively using user identifiers, such as index numbers. Based on this, the first derived information may include the user identifier of the first user and the user identifier of the user above the first user, and the second derived information may include the user identifier of the second user and the user identifier of the user above the second user. The user identifiers can be recorded sequentially in array form or sequentially in directory form to indicate the derivation hierarchy.

[0104] To facilitate understanding, an example is provided below. In this example, the user ID of the first user is "id1", and the user ID of the second user is "id2".

[0105] For the second user with index "id2", the second derived information can be represented as:

[0106] message: "derive_path":["id1","id2"].

[0107] The user identifiers in the array are recorded in order, specifically according to the derivation relationship (derivation hierarchy relationship). Based on this, it can be determined that the first user is the parent user of the second user.

[0108] For the second user with index "id2", the second derived information can also be represented as:

[0109] message: "derive_path":" / id1 / id2".

[0110] User identifiers in the directory are recorded according to derivative or hierarchical relationships. Based on this directory, it can be determined that the first user is the parent user of the second user.

[0111] In some possible implementations, derived information can be appended to the extended fields of the identity certificate. Based on this, the first client 102 can read the first derived information from the extended fields of the first user's identity certificate, such as reading the derived path of the first user's identity certificate. Similarly, the first client 102 can read the second derived information from the extended fields of the second user's identity certificate, such as reading the derived path of the second user's identity certificate.

[0112] S414, The first client 102 determines the private key of the second user based on the first derived information, the second derived information and the private key of the first user.

[0113] Specifically, the first client 102 can determine the hierarchical relationship between the first user and the second user based on the first derived information and the second derived information. For example, the first client 102 can compare the first derived information and the second derived information. When the length of the second derived information is greater than the length of the first derived information, and the second derived information includes the first derived information, it can be determined that the first user is the upper-level user of the second user. The first client 102 can extract the user identifier of the second user from the second derived information based on the hierarchical relationship. For example, when it is determined that the first user is the upper-level user of the second user, the first client 102 can extract the identifier of the second user from the second derived information. Considering that the second derived information can be generated based on the first derived information and the user identifier of the second user, the first client 102 can compare the second derived information and the first derived information, and determine the difference information as the user identifier of the second user. Then, the first client 102 can determine the private key of the second user based on the private key of the first user and the identifier of the second user through a derivation algorithm. The process of determining the private key of the second user based on the private key of the first user and the identifier of the second user through a derivation algorithm can be referred to the relevant content description of formula (1) above, and will not be repeated here. It should be noted that when the first user is not the direct superior of the second user, but an indirect superior, the first client 102 can extract the user identifiers (index) of different users layer by layer to deduce the private keys of the lower-level users.

[0114] In some possible implementations, the first client 102 concatenates the first user's private key, the first user's chaincode, and the second user's user identifier to obtain the concatenation result. Then, the first client 102 performs a hash operation on the concatenation result to obtain the second user's private key.

[0115] In some other possible implementations, the first client 102 determines the private key of the third user using a derivation algorithm based on the private key of the first user and the user identifier of the third user, where the third user is a sub-user of the first user. Then, the first client 102 determines the private key of the second user using the private key of the third user and the user identifier of the second user, where the second user is a sub-user of the third user.

[0116] S416. The first client 102 decrypts the ciphertext using the second user's private key to obtain the data.

[0117] Since the ciphertext is obtained by encrypting the plaintext data using the public key of the second user derived from the layered encryption algorithm, the second client 102 can use the private key of the second user in combination with the layered encryption algorithm to decrypt the ciphertext and obtain the plaintext data.

[0118] Based on the above description, this application provides a data processing method. This method combines the private key and identity certificate used for transaction signing and verification in a blockchain network with layered encryption. Derivative information, specifically user hierarchy relationships, is carried through extended fields of the identity certificate, enabling the identity certificate to not only be used for transaction signing and verification but also to possess layered encryption and decryption capabilities. Furthermore, this method can verify the legitimacy of the identity certificate using the root private key, eliminating the need for a trusted third party to resolve the authenticity and validity of the public key, avoiding centralized risks, reducing costs, and meeting business needs.

[0119] Based on the aforementioned data processing method, this application also provides a blockchain management system 10. The blockchain management system 10 of this application will be described below from the perspective of functional modularity.

[0120] See Figure 2 The diagram shows the architecture of a blockchain management system 10, which includes a first client 102, a second client 104, and a blockchain network 200. The first client 102 is the client for a first user, and the second client 104 is the client for a second user.

[0121] The second client 104 is used to extract the public key of the second user from the identity certificate of the second user, use the public key of the second user to encrypt the data in layers to obtain ciphertext, and store the ciphertext and the identity certificate of the second user in the blockchain network;

[0122] The first client 102 is used to obtain the ciphertext and the identity certificate of the second user from the blockchain network, and to verify the legality of the identity certificate of the second user using the root certificate;

[0123] The first client 102 is further configured to, when verification is successful, extract first derived information from the first user's identity certificate and extract second derived information from the second user's identity certificate, wherein the first derived information is used to indicate the derived path of the first user's identity certificate and the second derived information is used to indicate the derived path of the second user's identity certificate.

[0124] The first client 102 is further configured to determine the private key of the second user based on the first derived information, the second derived information, and the private key of the first user;

[0125] The first client 102 is also configured to decrypt the ciphertext using the second user's private key to obtain the data.

[0126] The first client 102 and the second client 104 can be client software or client hardware. Furthermore, the blockchain node 202 in the blockchain network 200 can refer to either software or hardware used to form the blockchain network 200.

[0127] When implemented through software, the first client 102 and the second client 104 can be applications running on computing devices. These applications can be dedicated clients or browsers. The aforementioned applications can also be virtualized and provided to users as virtualization services. Virtualization services can include virtual machine (VM) services, bare metal server (BMS) services, or container services. Specifically, a VM service can be a service that uses virtualization technology to create a pool of virtual machine (VM) resources on multiple physical hosts, providing VMs for users to use on demand. A BMS service is a service that uses virtualization technology to create a pool of BMS resources on multiple physical hosts, providing BMS for users to use on demand. A container service is a service that uses virtualization technology to create a pool of container resources on multiple physical hosts, providing containers for users to use on demand. A VM is a simulated virtual computer, that is, a logical computer. A BMS is a scalable, high-performance computing service with computing performance indistinguishable from traditional physical machines, featuring secure physical isolation. A container is a kernel virtualization technology that can provide lightweight virtualization to isolate user space, processes, and resources. It should be understood that the VM service, BMS service, and container service mentioned above are merely specific examples. In practical applications, virtualization services can also include other lightweight or heavyweight virtualization services, which are not specifically limited here.

[0128] When implemented in hardware, the first client 102 and the second client 104 may include at least one computing device. For example, the first client 102 may be a terminal for a first user, and the second client 104 may be a terminal for a second user. Alternatively, the first client 102 and the second client 104 may also be devices implemented using application-specific integrated circuits (ASICs) or programmable logic devices (PLDs). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0129] In some possible implementations, the first client 102 is specifically used for:

[0130] Based on the first derived information and the second derived information, determine the hierarchical relationship between the first user and the second user;

[0131] Based on the hierarchical relationship, extract the user identifier of the second user from the second derived information;

[0132] The private key of the second user is determined by a derivation algorithm based on the user identifier of the second user and the private key of the first user.

[0133] In some possible implementations, the first client 102 is specifically used for:

[0134] The private key of the first user, the chaincode of the first user, and the user identifier of the second user are concatenated to obtain the concatenation result;

[0135] Perform a hash operation on the concatenated result to obtain the private key of the second user.

[0136] In some possible implementations, the first client 102 is specifically used for:

[0137] Based on the private key of the first user and the user identifier of the third user, the private key of the third user is determined by a derivation algorithm, and the third user is a sub-user of the first user;

[0138] Based on the private key of the third user and the user identifier of the second user, the private key of the second user is determined by a derivation algorithm, and the second user is a sub-user of the third user.

[0139] In some possible implementations, the second derived information is generated based on the first derived information and the user identifier of the second user.

[0140] In some possible implementations, the first client 102 is specifically used for:

[0141] Extract the first derived information from the extended fields of the first user's identity certificate.

[0142] This application also provides a computing device 500. For example... Figure 5 As shown, the computing device 500 includes a bus 502, a processor 504, a memory 506, and a communication interface 508. The processor 504, the memory 506, and the communication interface 508 communicate with each other via the bus 502. The computing device 500 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 500.

[0143] Bus 502 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 5 The bus 502 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 502 may include a path for transmitting information between various components of the computing device 500 (e.g., memory 506, processor 504, communication interface 508).

[0144] Processor 504 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0145] Memory 506 may include volatile memory, such as random access memory (RAM). Memory 506 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD). Memory 506 stores executable program code, which processor 504 executes to implement the aforementioned data processing method. Specifically, memory 506 stores instructions for the blockchain management system 200 to execute the data processing method. For example, memory 506 stores instructions for implementing the functions of the first client 102, the second client 104, and / or the blockchain node 202. It should be noted that in some cases, a computing device 500 may execute instructions for implementing the functions of the first client 102 in one data processing process and instructions for implementing the functions of the second client 104 in another data processing process.

[0146] The communication interface 508 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 500 and other devices or communication networks.

[0147] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0148] like Figure 6 As shown, the computing device cluster includes at least one computing device 500. The memory 506 of one or more computing devices 500 in the computing device cluster may store instructions from the same blockchain management system 200 for executing data processing methods.

[0149] In some possible implementations, one or more computing devices 500 in the computing device cluster can also be used to execute some of the instructions used by the blockchain management system 200 to execute data processing methods. In other words, a combination of one or more computing devices 500 can jointly execute the instructions used by the blockchain management system 200 to execute data processing methods.

[0150] It should be noted that the memory 506 in different computing devices 500 in the computing device cluster can store different instructions for executing some functions of the blockchain management system 200.

[0151] Figure 7 One possible implementation is shown. For example... Figure 7 As shown, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. For example, computing devices 500A, 500B, 500C, 500D, and 500E are connected via a network. Specifically, each computing device can connect to the network through its own communication interface. In this possible implementation, the memory 506 in computing device 500A stores instructions for executing the functions of the first client 102, and the memory 506 in computing device 500B stores instructions for executing the second client 104. Simultaneously, the memories 506 in computing devices 500C, 500D, and 500E store instructions for executing the functions of the blockchain node 202.

[0152] Figure 7 The connection method between the computing device clusters shown can be based on the fact that the data processing method provided in this application requires a large amount of resources for encryption / decryption, key generation, and on-chain storage. Therefore, the functions implemented by the first client 102, the second client 104, and the blockchain node 202 are respectively assigned to independent computing devices for execution. For example, the function of the first client 102 is assigned to computing device 500A, the function of the second client 104 is assigned to computing device 500B, and the function of the blockchain node 202 is assigned to computing devices 500C, 500D, and 500E. It should be noted that... Figure 7 The example of a blockchain network 200 including 3 blockchain nodes 202 is used for illustration. In actual applications, the blockchain network 200 may include more than 3 blockchain nodes 202.

[0153] It should be understood that Figure 7 The functions of computing device 500A shown can also be performed by multiple computing devices 500. Similarly, the functions of computing device 500B can also be performed by multiple computing devices 500, and the functions of computing devices 500C, 500D, and 500E can also be performed by multiple computing devices.

[0154] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the data processing method described above in the blockchain management system 200.

[0155] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to perform the above-described data processing method.

[0156] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A data processing method, characterized by, The method is applied to a blockchain management system, the blockchain management system comprises a first client, a second client and a blockchain network, the first client is a client of a first user, the second client is a client of a second user, and the method comprises the following steps: The second client extracts the public key of the second user from the identity certificate of the second user, encrypts the data layer by layer using the public key of the second user to obtain ciphertext, and stores the ciphertext and the identity certificate of the second user to the blockchain network; The first client obtains the ciphertext and the identity certificate of the second user from the blockchain network, and verifies the legality of the identity certificate of the second user using a root certificate; When the verification is passed, the first client extracts first derivative information from the identity certificate of the first user and second derivative information from the identity certificate of the second user, the first derivative information is used to indicate the derivative path of the identity certificate of the first user, and the second derivative information is used to indicate the derivative path of the identity certificate of the second user; The first client determines the private key of the second user according to the first derivative information, the second derivative information and the private key of the first user; The first client decrypts the ciphertext according to the private key of the second user to obtain the data.

2. The method of claim 1, wherein, The first client determines the private key of the second user according to the first derivative information, the second derivative information and the private key of the first user, comprising: The first client determines the hierarchical relationship between the first user and the second user according to the first derivative information and the second derivative information; The first client extracts the user identifier of the second user from the second derivative information according to the hierarchical relationship; The first client determines the private key of the second user through a derivation algorithm according to the user identifier of the second user and the private key of the first user.

3. The method of claim 2, wherein, The first client determines the private key of the second user through a derivation algorithm according to the user identifier of the second user and the private key of the first user, comprising: The first client splices the private key of the first user and the chain code of the first user, the user identifier of the second user to obtain a splicing result; The first client performs a hash operation on the splicing result to obtain the private key of the second user.

4. The method of claim 2, wherein, The first client determines the private key of the second user through a derivation algorithm according to the user identifier of the second user and the private key of the first user, comprising: The first client determines the private key of the third user through a derivation algorithm according to the private key of the first user and the user identifier of the third user, the third user being a child user of the first user; The first client determines the private key of the second user through a derivation algorithm according to the private key of the third user and the user identifier of the second user, the second user being a child user of the third user.

5. The method according to any one of claims 1 to 4, characterized in that, The second derivative information is generated according to the first derivative information and the user identifier of the second user.

6. The method according to any one of claims 1 to 5, characterized in that, The first client extracts the first derivative information from the identity certificate of the first user, comprising: The first client extracts first derived information from an extension field of the identity certificate of the first user. 7.A blockchain management system, characterized by, The blockchain management system comprises a first client, a second client and a blockchain network, the first client is a client of a first user, and the second client is a client of a second user. The second client extracts a public key of the second user from an identity certificate of the second user, performs hierarchical encryption on data using the public key of the second user to obtain ciphertext, and stores the ciphertext and the identity certificate of the second user to the blockchain network. The first client acquires the ciphertext and the identity certificate of the second user from the blockchain network, and verifies the legality of the identity certificate of the second user using a root certificate. The first client further extracts first derived information from the identity certificate of the first user and second derived information from the identity certificate of the second user, the first derived information is used to indicate a derivation path of the identity certificate of the first user, and the second derived information is used to indicate a derivation path of the identity certificate of the second user. The first client further determines the private key of the second user according to the first derived information, the second derived information and the private key of the first user. The first client further decrypts the ciphertext to obtain the data according to the private key of the second user.

8. The system of claim 7, wherein, The first client is specifically configured to: determine a hierarchical relationship between the first user and the second user according to the first derived information and the second derived information; extract a user identifier of the second user from the second derived information according to the hierarchical relationship; determine the private key of the second user through a derivation algorithm according to the user identifier of the second user and the private key of the first user.

9. The system of claim 8, wherein, The first client is specifically configured to: splice the private key of the first user and chain code of the first user, and the user identifier of the second user to obtain a splicing result; perform a hash operation on the splicing result to obtain the private key of the second user.

10. The system of claim 8, wherein, The first client is specifically configured to: determine a private key of a third user through a derivation algorithm according to the private key of the first user and a user identifier of the third user, the third user being a child user of the first user; determine the private key of the second user through a derivation algorithm according to the private key of the third user and a user identifier of the second user, the second user being a child user of the third user.

11. The system according to any one of claims 7 to 10, characterized in that, The second derived information is generated according to the first derived information and the user identifier of the second user.

12. The system according to any one of claims 7 to 11, characterized in that, The first client is specifically configured to: extract first derived information from an extension field of the identity certificate of the first user.

13. A cluster of computing devices, characterized in that, The computing device cluster comprises at least one computing device, the at least one computing device comprising at least one processor and at least one memory, and the at least one memory storing computer readable instructions; the at least one processor executes the computer readable instructions to enable the computing device cluster to perform the data processing method according to any one of claims 1 to 6.

14. A computer-readable storage medium, characterized in that, comprising computer readable instructions for implementing the data processing method of any one of claims 1 to 6.

15. A computer program product, characterised in that, comprising computer readable instructions for implementing the data processing method of any one of claims 1 to 6.

Images