Key management method, device, equipment, medium and product

Abstract

The embodiment of the invention provides a key management method and device, equipment, a medium and a product, and the method comprises the steps: responding to a first triggering event of a Kth private key in L groups of key pairs, and determining L node sets in a block chain network corresponding to the L groups of key pairs; respectively acquiring a first fusion polynomial share from the T nodes in the (K-2) th node set, and respectively acquiring a second fusion polynomial share from the T nodes in the (K-1) th node set; determining the polynomial share of the (K-1) th private key in the L groups of key pairs according to the obtained T first fusion polynomial shares and T second fusion polynomial shares; the polynomial share of the (K-1) th private key is used for generating the (K-1) th private key. According to the embodiment of the invention, the security of the private key can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to key management methods, key management devices, computer equipment, computer-readable storage media, and computer program products. Background Technology

[0002] With the continuous development and application of computer technology, blockchain technology has also developed rapidly. Because information stored on the blockchain cannot be forged or tampered with, using blockchain technology for business data processing has become a current trend. In blockchain systems, to prevent the loss or leakage of private keys, cold wallet technology is used to store them. A cold wallet is a dedicated storage device that keeps the private key permanently offline. However, because cold wallet technology uses centralized storage, it is susceptible to single points of failure and device loss, which reduces the security of the private key. Therefore, improving the security of private keys is a pressing issue that needs to be addressed. Summary of the Invention

[0003] This application provides a key management method, apparatus, device, medium, and product that can improve the security of private keys.

[0004] On one hand, embodiments of this application provide a key management method, the method comprising:

[0005] In response to the first triggering event of the Kth private key in the L key pairs, determine the L node sets in the blockchain network corresponding to the L key pairs; the public key and the corresponding random number shard in each key pair are stored in the corresponding node set, the Kth private key is the currently used private key, L is a positive integer greater than or equal to 3, and K is a positive integer greater than or equal to 3 and less than or equal to L.

[0006] The first fusion polynomial share is obtained from each of the T nodes in the (K-2)th node set, and the second fusion polynomial share is obtained from each of the T nodes in the (K-1)th node set. The first fusion polynomial share is determined by the T nodes in the (K-2)th node set according to the first share mask parameter and the polynomial share of their respective stored public keys. The second fusion polynomial share is determined by the T nodes in the (K-1)th node set according to the second share mask parameter and the polynomial share of their respective stored random numbers. The second share mask parameter is the opposite of the first share mask parameter, and T is a positive integer greater than or equal to 2.

[0007] Based on the obtained T first fusion polynomial shares and T second fusion polynomial shares, determine the polynomial share of the (K-1)th private key in the L key pairs; the polynomial share of the (K-1)th private key is used to generate the (K-1)th private key, and the (K-1)th private key is configured as the currently used private key.

[0008] On the other hand, embodiments of this application provide a key management device, which includes:

[0009] The response unit is used to respond to the first triggering event of the Kth private key in the L key pairs and determine the L node sets in the blockchain network corresponding to the L key pairs; the public key and the corresponding random number shard in each key pair are stored in the corresponding node set, the Kth private key is the currently used private key, L is a positive integer greater than or equal to 3, and K is a positive integer greater than or equal to 3 and less than or equal to L.

[0010] The acquisition unit is used to acquire a first fusion polynomial share from T nodes in the (K-2)th node set, and to acquire a second fusion polynomial share from T nodes in the (K-1)th node set. The first fusion polynomial share is determined by T nodes in the (K-2)th node set according to the first share mask parameter and the polynomial share of their respective stored public keys. The second fusion polynomial share is determined by T nodes in the (K-1)th node set according to the second share mask parameter and the polynomial share of their respective stored random numbers. The second share mask parameter is the negative of the first share mask parameter, and T is a positive integer greater than or equal to 2.

[0011] The processing unit is used to determine the polynomial share of the (K-1)th private key in the L key pairs based on the obtained T first fusion polynomial shares and T second fusion polynomial shares; the polynomial share of the (K-1)th private key is used to generate the (K-1)th private key, and the (K-1)th private key is configured as the currently used private key.

[0012] In one possible implementation, the processing unit is also used for:

[0013] Based on the elliptic curve and L random numbers, generate L sets of key pairs;

[0014] Identify L sets of nodes and manage the set of nodes from the blockchain network;

[0015] Store the public key and corresponding random number fragment of each of the L key pairs into the corresponding node set of the L node set, and store the Lth private key fragment of the L key pairs into the management node set; the Lth private key is the private key used initially.

[0016] In one possible implementation, the processing unit, when generating L key pairs based on the elliptic curve and L random numbers, specifically performs the following:

[0017] For the Mth key pair, generate the private key of the Mth key pair based on the Mth random number among L random numbers and the target public key; the target public key is either the initial public key or the public key of the (M-1)th key pair. The initial public key is determined based on the elliptic curve, and M is any positive integer less than or equal to L.

[0018] Generate the public key for the Mth key pair based on the private key and elliptic curve in the Mth key pair;

[0019] After storing the Lth private key fragment from the L key pairs into the management node set, the processing unit 403 is further used for:

[0020] Write the Lth public key from the L key pairs into the blockchain, and perform data cleanup on the elliptic curve, L random numbers, and L key pairs.

[0021] In one possible implementation, the processing unit is also used for:

[0022] Obtain the polynomial share of the stored public key from each of the T nodes in the (K-1)th node set, and determine the (K-1)th public key based on the obtained polynomial shares of the T public keys;

[0023] Obtain the polynomial share of the stored random number from each of the T nodes in the Kth node set, and determine the Kth random number based on the polynomial share of the obtained T random numbers;

[0024] Based on the (K-1)th public key, the Kth random number, the elliptic curve, and the Kth public key, perform generational relationship verification;

[0025] If the generational relationship verification passes, then proceed with the step of obtaining the first fusion polynomial share from each of the T nodes in the (K-2)th node set.

[0026] In one possible implementation, the processing unit, when performing generational relationship verification based on the (K-1)th public key, the Kth random number, the elliptic curve, and the Kth public key, specifically performs the following:

[0027] Generate relation verification based on the (K-1)th public key, the Kth random number, the elliptic curve, and the Kth private key;

[0028] If the relationship verification passes, the verification information of the (K-1)th public key and the verification information of the Kth random number are obtained from the blockchain.

[0029] Data verification is performed based on the (K-1)th public key, the verification information of the (K-1)th public key, the Kth random number, and the verification information of the Kth random number.

[0030] If the data verification passes, then the intergenerational relationship verification is confirmed.

[0031] In one possible implementation, the processing unit, when used, is specifically used for:

[0032] In response to a second triggering event from the target node in the management node set regarding the polynomial share of the stored Kth private key, the target polynomial share is obtained from each of the T nodes in the management node set; the target polynomial share is determined by the T nodes in the management node set based on the polynomial share of the Kth private key stored by each of them.

[0033] Based on the obtained T target polynomial shares, determine the updated polynomial share of the Kth private key; the updated polynomial share of the Kth private key is used to generate the Kth private key.

[0034] In one possible implementation, when the processing unit is used to obtain the target polynomial share from each of the T nodes in the management node set, it specifically performs the following:

[0035] Determine the T nodes in the management node set whose polynomial share of the Kth private key is in a normal state;

[0036] Obtain the target polynomial share from each of the T nodes;

[0037] The target polynomial share is obtained by performing share conversion processing on the polynomial share of the stored Kth private key by T nodes in the management node set to obtain the additive share of the private key, and then performing sharding processing on the additive share of the private key for each node in the management node set.

[0038] In one possible implementation, the acquisition unit, when acquiring the first fusion polynomial share from each of the T nodes in the (K-2)th node set, is specifically used for:

[0039] Send a first private key replacement request for the Kth private key to each of the T nodes in the (K-2)th node set;

[0040] Receive the first fusion polynomial shares returned by T nodes in the (K-2)th node set, and obtain T first fusion polynomial shares;

[0041] Specifically, the first private key replacement request instructs each of the T nodes in the (K-2)th node set to perform share conversion processing on the polynomial share of the stored public key to obtain the additive share of the public key, and to perform sharding processing on the first share mask parameter for the T nodes in the (K-2)th node set to obtain the additive share of the first share mask parameter, and to perform sharding processing on the first fusion result of the additive share of the public key and the additive share of the first share mask parameter for each node in the management node set to obtain the first fusion polynomial share corresponding to each node in the management node set.

[0042] In one possible implementation, the acquisition unit, when acquiring the second fusion polynomial share from each of the T nodes in the (K-1)th node set, is specifically used for:

[0043] Send a second private key replacement request for the Kth private key to each of the T nodes in the (K-1)th node set;

[0044] Receive the second fusion polynomial shares returned by T nodes in the (K-1)th node set, and obtain T second fusion polynomial shares;

[0045] Specifically, the second private key replacement request is used to instruct each of the T nodes in the (K-1)th node set to perform share conversion processing on the polynomial share of the stored random number to obtain the additive share of the random number, and to perform sharding processing on the second share mask parameter for the T nodes in the (K-1)th node set to obtain the additive share of the second share mask parameter, and to perform sharding processing on the second fusion result of the additive share of the random number and the additive share of the second share mask parameter for each node in the management node set to obtain the second fused polynomial share corresponding to each node in the management node set.

[0046] Accordingly, embodiments of this application provide a computer device, which includes:

[0047] A processor is a tool for implementing computer programs.

[0048] A computer-readable storage medium storing a computer program adapted to be loaded by a processor and executed by the aforementioned key management method.

[0049] Accordingly, embodiments of this application provide a computer-readable storage medium storing a computer program. When the computer program is read and executed by the processor of a computer device, the computer device performs the aforementioned key management method.

[0050] Accordingly, this application provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the aforementioned key management method.

[0051] In response to a first triggering event (such as private key leakage, user-initiated private key replacement, or timed automatic private key replacement) of the Kth private key currently used in the L key pairs, this application determines the L node sets in the blockchain network corresponding to the L key pairs; it obtains first fusion polynomial shares from T nodes in the (K-2)th node set and second fusion polynomial shares from T nodes in the (K-1)th node set; then, based on the obtained T first fusion polynomial shares and T second fusion polynomial shares, it determines the polynomial share of the (K-1)th private key in the L key pairs, thereby updating the stored polynomial share of the Kth private key to the polynomial share of the (K-1)th private key, thus achieving private key replacement. This method generates L key pairs and stores the public key and corresponding random number shards of each key pair in the corresponding node set. This ensures that in the event of a private key leakage, private key replacement can be performed based on the data stored in the relevant node set shards in the L node sets, guaranteeing the security of the private key. Furthermore, the first fusion polynomial share is determined based on the first share mask parameter, and the second fusion polynomial share is determined based on the second share mask parameter. By introducing the first share mask parameter and the second share mask parameter, the share of the public key and the share of the random number are protected from being leaked. This avoids the security risks caused by nodes in the same set of nodes jointly cracking the relevant information of the key pair, and further improves the security of the private key. Attached Figure Description

[0052] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0053] Figure 1A This is a schematic diagram of the architecture of a key management system provided in an embodiment of this application;

[0054] Figure 1B This is a schematic diagram of a blockchain structure provided in an embodiment of this application;

[0055] Figure 1C This is a schematic diagram illustrating a process for generating a new block, provided in an embodiment of this application.

[0056] Figure 1D This is a schematic diagram of another key management system architecture provided in an embodiment of this application;

[0057] Figure 2 This is a flowchart illustrating a key management method provided in an embodiment of this application;

[0058] Figure 3This is a flowchart illustrating another key management method provided in an embodiment of this application;

[0059] Figure 4 This is a schematic diagram of the structure of a key management device provided in this embodiment;

[0060] Figure 5 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0061] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0062] This application involves key pairs (including public and private keys), multinomial shares, additive shares, share mask parameters, and other data. When the above embodiments of this application are applied to specific products or technologies, the collection, use, and processing of related data should comply with relevant laws and regulations. Before collecting data, the information processing rules should be communicated and the individual consent of the recipient should be obtained. Data should be processed in strict accordance with laws and regulations and personal information processing rules, and technical measures should be taken to ensure the security of related data.

[0063] The key management system provided in the embodiments of this application is described below with reference to the accompanying drawings. The key management system is suitable for implementing the key management method provided in the embodiments of this application.

[0064] Please see Figure 1A This is a schematic diagram of the architecture of a key management system provided in an embodiment of this application. The key management system can refer to a blockchain system, which may include a blockchain network 10, multiple nodes 101 (such as node x, node a, node b, etc.), and a client 102, wherein:

[0065] Blockchain network 10 refers to a network used for data sharing between nodes. The blockchain network may include multiple nodes 101, among which consensus nodes may be included. Each node 101, during normal operation, can receive input information and maintain shared data (i.e., the blockchain) within the blockchain network based on the received input information. Each node in the blockchain network stores the same blockchain, which consists of a series of blocks sequentially generated in chronological order, such as... Figure 1AAs shown in the diagram, blocks 1, M-1, etc., are never removed once added to the blockchain. Blocks record the data submitted by nodes in the blockchain network. To ensure information exchange within the blockchain network, each node can be connected to another node, enabling point-to-point communication between any two nodes. This can be achieved through wired or wireless communication links. For example, when any node in the blockchain network receives input information, other nodes retrieve this input information according to the consensus algorithm and store it as part of the shared data, ensuring data consistency across all nodes in the blockchain network.

[0066] Client 102 can access the blockchain network and communicate with nodes in the blockchain network, such as sending transaction data to nodes. Of course, in some possible implementations, client 102 can also be one of the nodes in the blockchain network. The computing device where client 102 is located can be a smartphone, tablet, laptop, desktop computer, in-vehicle smart terminal, etc., and this application embodiment does not limit the scope.

[0067] It should be noted that, Figure 1A The number of nodes shown is merely illustrative. Any number of nodes can be deployed as needed. A node can refer to any form of computing device connected to the network, such as a server or an object terminal, which can all be added as a node.

[0068] Each node in a blockchain network has a corresponding node identifier, and each node can also store the node identifiers of other nodes in the blockchain network. This allows for the subsequent broadcasting of generated blocks to other nodes in the blockchain network based on their node identifiers. Each node can maintain a node identifier list as shown in Table 1, storing the node name and node identifier in this list. The node identifier can be an Internet Protocol (IP) address or any other information that can be used to identify the node; the node identifiers in Table 1 are merely examples.

[0069] Table 1

[0070] Node Name Node identifier Node 1 000.000.000.00a Node 2 000.000.000.00b … … Node N 000.000.000.00c

[0071] Each node in a blockchain network stores the same blockchain. A blockchain consists of multiple blocks; see [link to blockchain documentation]. Figure 1BA blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information feature values, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature values ​​of the current block, the block header feature values ​​of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0072] When generating the individual blocks in the blockchain, see Figure 1C When a node in the blockchain receives input information, it verifies the input information. After verification, it stores the input information in a memory pool and updates its hash tree used to record the input information. Then, it updates the timestamp to the time the input information was received and tries different random numbers multiple times to calculate the feature value, ensuring that the calculated feature value satisfies the following formula:

[0073] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET

[0074] Wherein, SHA256 is the feature value algorithm used to calculate the feature value; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header feature value of the parent block of the current block; merkle_root is the feature value of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value for a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the feature value threshold, which can be determined based on nbits.

[0075] Thus, when a random number satisfying the above formula is calculated, the information can be stored accordingly, generating a block header and a block body to obtain the current block. Subsequently, the node containing the blockchain sends the newly generated block to other nodes in its blockchain network based on the node identifiers of other nodes in the blockchain network. The other nodes verify the newly generated block and, after verification, add the newly generated block to their stored blockchain.

[0076] In a blockchain network, smart contracts can run on nodes, enabling various transactions. A smart contract is an immutable, automatically executing computer program that runs on the blockchain. It's code that executes when certain conditions are met. Developers can define contract logic using programming languages, publish it to the blockchain (smart contract registration), and execute it based on the contract terms, triggered by keys or other events. The blockchain also provides functions for upgrading and deregistering smart contracts.

[0077] In a blockchain system, the leakage of private keys means the loss of assets. Therefore, designing a private key replacement scheme after a private key leakage and a share update scheme after a private key loss is crucial. Based on this, this application proposes a distributed key management scheme, distributing private keys across multiple servers in a secret-sharing manner. To address the issues of private key replacement after leakage and share update after loss, a key generation scheme based on a chain relationship is designed. Here, secret sharing can refer to polynomial secret sharing (i.e., Shamir secret sharing). Shamir secret sharing involves the distributor decomposing a secret (e.g., the private key) into n Shamir shares (i.e., polynomial shares) using a random polynomial, and distributing these n polynomial shares to n holders. Any at least T polynomial shares from the n sub-secrets can recover the secret, while any fewer than T polynomial shares cannot obtain any information about the secret. For example, the secret to be shared can be denoted as secret P, and the polynomial shares of secret P can be denoted as... .

[0078] Specifically, during the key initialization phase, a blockchain user can generate L sets of key pairs (i.e., L generations of key pairs; for example, the first key pair in the L sets is the first generation key pair, the second key pair in the L sets is the second generation key pair, and so on). The i-th key pair can be denoted as (d... i ,p i ), where i∈[1,L], d i p represents the private key in the i-th key pair. i Let d represent the public key in the i-th key pair. The L-generation key pairs satisfy a chain generation relationship, meaning that the private key in the next generation key pair is derived from the public key in the previous generation key pair through the function F, i.e., d i =F(p) i-1 The function F is used to establish associations between multiple key pairs of the same blockchain user.

[0079] The function F can satisfy the following relationship: d i =p (i-1)x +p (i-1)y +r i , where d i It is the private key in the i-th generation key pair, p (i-1) It is the public key in the (i-1)th generation key pair, r i This is the random number corresponding to the i-th generation key pair. It should be noted that when the blockchain uses the Elliptic Curve Digital Signature Algorithm (ECDSA), the public key p in the (i-1)-th generation key pair... (i-1) p is a point on the elliptic curve (i-1) =(p (i-1)x ,p (i-1)y ), where p (i-1)x p is the x-coordinate of the point. (i-1)y Let be the ordinate of the point.

[0080] During the key pair usage phase, the Lth generation key pair (d) is used first. L ,p L If the private key d in the Lth generation key pair L Leakage (such as private key d) L If the first triggering event occurs, the Lth generation key pair is invalidated, and the previous generation key pair, i.e., the (L-1)th generation key pair (d) is replaced. L-1 ,p L-1 It is put into use. Similarly, if the private key d in the (L-1)th generation key pair... L-1 If the key is leaked, the L-1 generation key pair will be invalidated, and the previous generation key pair, i.e., the L-2 generation key pair (d) will be discarded. L-1 ,p L-1 ) and so on.

[0081] Based on the above solution, please refer to Figure 1D , Figure 1D This is a schematic diagram of another key management system architecture provided in this application embodiment. The system mainly includes two types of participants: private key owners (such as blockchain users user1, user2, user3, etc.) and a set of servers. This scheme supports generational updates after private key leakage and share updates after private key loss. The server holding the share of the currently used private key can be called the current generation server, and the server holding the data needed for future generational updates (such as the share of public keys for each generation and the corresponding random number share) can be called the previous generation server. Each blockchain user can use the above key management system for distributed key storage. Subsequent embodiments will use blockchain user user1 as an example for illustration; for simplicity, it will be uniformly referred to as the private key owner (user). It should be noted that both the current generation server and the previous generation server can be nodes in the blockchain network; therefore, the private key owner (user) can correspond to one of the current generation servers.

[0082] Based on this, the embodiments of this application may include L sets of nodes (e.g., L sets of previous generation servers) and a set of management nodes (e.g., a set of current generation servers). The L sets of nodes can be denoted as {S1, S2, S3, ..., S...} L Let the number of nodes in each of the L node sets be {n1, n2, n3, ..., n}. L }, n i The set of management nodes can be greater than or equal to 2. U The number of nodes in the management node set is n. It should be noted that when the private key owner corresponds to one of the current servers, all nodes in the management node set jointly hold the share of the currently used private key; when the private key owner does not correspond to one of the current servers, but to a user device outside the blockchain network, then all nodes in the management node set and the user device jointly hold the share of the currently used private key. Subsequent embodiments will use the former as an example.

[0083] Based on this, the public key and its corresponding random number in the first-generation key pair can be fragmented and stored in node set S1; the public key and its corresponding random number in the second-generation key pair can be fragmented and stored in node set S2; the public key and its corresponding random number in the third-generation key pair can be fragmented and stored in node set S3, and so on, until the public key and its corresponding random number in the last-generation key pair (such as the Lth-generation key pair) can be fragmented and stored in node set S4. L Furthermore, the currently used private key (such as the private key in the Lth generation key pair) can be sharded and stored in the management node set S. U middle.

[0084] It should be noted that the following security assumptions are met in this embodiment: the private key owner (i.e., the blockchain user) is trustworthy and will not actively disclose the private key. Furthermore, in the node set (including L node sets and the management node set), it is assumed that the number of collusion attempts by nodes in each generation of node sets is less than a threshold t, and nodes in different generations of node sets cannot collude across generations. Under the security assumption of no collusion, this scheme satisfies both forward and backward security, ensuring the security of the private key.

[0085] The key management method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0086] This application provides a key management method, which can be executed by a computer device, such as a computer device that can be... Figure 1A Node 101 or client 102 in the key management system shown can also be Figure 1D The example shows a management node in a key management system. For instance... Figure 2 As shown, the key management method may include, but is not limited to, the following steps S201-S203:

[0087] S201. In response to the first triggering event of the Kth private key in the L key pair, determine the set of L nodes in the blockchain network corresponding to the L key pair.

[0088] In this embodiment, the public key and corresponding random number shards in each key pair are stored in the corresponding node set. For example, the L node sets can be denoted as {S1, S2, S3, ..., S...} L } Then, the public key and the corresponding random number in the first key pair of L key pairs can be stored in the node set S1 in a shard, the public key and the corresponding random number in the second key pair can be stored in the node set S2 in a shard, and so on.

[0089] It should be noted that the fragmented storage in this embodiment can be implemented using a secret sharing method. For example, the public key and corresponding random number in each key pair can be fragmented and stored in the corresponding node set using a polynomial secret sharing method. Taking the public key and random number in the first key pair as an example, if the first node set includes n nodes, then the public key in the first key pair can be decomposed into n polynomial shares using a random polynomial, and these n polynomial shares can be distributed to the n nodes in the first node set. The threshold for polynomial secret sharing can be set to T, meaning that at least T polynomial shares from the n polynomial shares can be used to recover the public key, while fewer than T polynomial shares cannot. Similarly, the random number in the first key pair can be decomposed into n polynomial shares using a random polynomial (the threshold for polynomial secret sharing can be set to T), and these n polynomial shares can be distributed to the n nodes in the first node set. For details on how the public key and the corresponding random number shards in other key pairs are stored in the corresponding node sets, please refer to the handling of the public key and random number in the first key pair. It will not be repeated here.

[0090] In this embodiment, L is a positive integer greater than or equal to 3, and K is a positive integer greater than or equal to 3 and less than or equal to L. This is because only when the number of key pairs L is greater than or equal to 3 can the polynomial share of the L-1 private key in the L key pairs be determined based on the T first fusion polynomial shares obtained from the L-2 node set and the T second fusion polynomial shares obtained from the L-1 node set when the L-1 private key is leaked, thereby achieving at least one private key replacement. The larger L is, the more times the private key replacement can be performed.

[0091] In this embodiment, the first triggering event can be a private key leakage event, a user-initiated private key replacement event, or a timed private key replacement event. Taking the Kth private key as the currently used private key as an example, the first triggering event for the Kth private key can be an event where the Kth private key is leaked. The first triggering event can also be a user-initiated event for replacing the Kth private key (for example, the currently used Kth key pair has been in use for too long, and the user considers the key insecure or no longer wants to use it, hoping to put the K-1 key pair into use). The first triggering event can also be a timed event for replacing the Kth private key, for example, automatically triggering key replacement every preset first period (e.g., 60 days) to put the K-1 key pair into use. When the computer device detects the first triggering event for the Kth private key, it needs to determine the L sets of nodes in the blockchain network corresponding to the L key pairs, so as to obtain the data required for private key replacement (such as the share of each generation of public keys and the corresponding share of random numbers) from the L sets of nodes. The above method enables not only automatic private key replacement when the private key is leaked, but also private key replacement when the user intends to replace it, thereby improving the flexibility of private key replacement. It can also automatically initiate private key replacement at regular intervals, thereby improving the intelligence level of private key replacement.

[0092] In one possible implementation, a first trigger event is generated when the currently used private key is leaked (e.g., the Kth private key is leaked). This first trigger event can be generated by any node in the blockchain network (e.g., a node in a set of L nodes, or a node in a set of management nodes) upon detecting the leak of the currently used private key, and obtained by a computer device. Alternatively, the first trigger event can be generated when a blockchain user reports an anomaly message indicating a leak of the currently used private key to any node in the blockchain network, and any node generates the first trigger event based on the anomaly message. This embodiment of the application does not limit this approach. Furthermore, the first trigger event can also be generated when a user performs a trigger operation for private key replacement (e.g., submits a private key replacement request for the Kth private key) or when the system periodically triggers a private key replacement; these details will not be elaborated upon here.

[0093] S202. Obtain the first fusion polynomial share from each of the T nodes in the (K-2)th node set, and obtain the second fusion polynomial share from each of the T nodes in the (K-1)th node set; the first fusion polynomial share is determined by the T nodes in the (K-2)th node set according to the first share mask parameter and the polynomial share of their respective stored public keys, and the second fusion polynomial share is determined by the T nodes in the (K-1)th node set according to the second share mask parameter and the polynomial share of their respective stored random numbers.

[0094] In this embodiment, the threshold for polynomial secret sharing is set to T, where T is a positive integer greater than or equal to 2. Therefore, any T nodes in the (K-2)th node set can determine the first fused polynomial share based on the first share mask parameter and the polynomial share of their respective stored public keys (i.e., the polynomial share of the public keys in the (K-2)th key pair). Similarly, any T nodes in the (K-1)th node set can determine the second fused polynomial share based on the second share mask parameter and the polynomial share of their respective stored random numbers (i.e., the polynomial share of the random numbers corresponding to the (K-1)th key pair). Furthermore, the computer device obtains the first fused polynomial shares from the T nodes in the (K-2)th node set, resulting in a total of T first fused polynomial shares, and obtains the second fused polynomial shares from the T nodes in the (K-1)th node set, resulting in a total of T second fused polynomial shares, which are used to calculate the polynomial share of the (K-1)th private key.

[0095] In this embodiment, since the L-generation key pairs satisfy a chain generation relationship, that is, the private key in the later generation key pair is derived from the public key in the previous generation key pair through function F, function F can satisfy the following relationship: d i =p (i-1)x +p (i-1)y +r i Therefore, in one implementation, the computer device can determine the polynomial share of the public keys stored by the T nodes in the (K-2)th node set (corresponding to the p mentioned above). (i-1)x +p (i-1)y The multinomial share of the random numbers stored in the T nodes of the (K-1)th node set (corresponding to the above r) i This method can obtain a polynomial share of the (K-1)th private key. However, the above method has low security because T nodes in the (K-2)th node set can collude to recover the (K-2)th private key, and T nodes in the (K-1)th node set can collude to recover the (K-1)th random number.

[0096] Therefore, to enhance the security of the private key, this application introduces a first share mask parameter and a second share mask parameter to protect the public key share and the random number share from being leaked. The second share mask parameter is the opposite of the first share mask parameter (i.e., the sum of the first and second share mask parameters is 1). This way, after incorporating the first share mask parameter into the first fusion polynomial share and the second share mask parameter into the second fusion polynomial share, the computer device determines the polynomial share of the (K-1)th private key in the L key pairs based on the first and second fusion polynomial shares. The influence of the first and second share mask parameters is canceled out, ensuring that they do not affect the accuracy of the final calculated polynomial share of the (K-1)th private key. This also avoids the security risk of collusion among peer nodes (such as nodes in the same node set jointly cracking information related to the key pair), thus improving the security of the private key.

[0097] It should be noted that the T nodes in the (K-2)th node set can be selected by the computer device from the (K-2)th node set, or they can be selected by the (K-2)th node set through voting. There is no restriction here. The method for determining the T nodes in the (K-1)th node set is similar and will not be repeated here.

[0098] S203. Based on the obtained T first fusion polynomial shares and T second fusion polynomial shares, determine the polynomial share of the (K-1)th private key in the L key pairs.

[0099] In this embodiment, the computer device can determine the polynomial share of the previous generation private key of the currently used private key L that has been leaked, based on the obtained T first fusion polynomial shares and T second fusion polynomial shares. This polynomial share is the polynomial share of the (K-1)th private key in the key pair. For example, the computer device can add the T first fusion polynomial shares and the T second fusion polynomial shares to obtain the polynomial share of the (K-1)th private key. The polynomial share of the (K-1)th private key is used to generate the (K-1)th private key, and the (K-1)th private key is configured as the currently used private key. This completes the private key replacement (for the computer device, this means updating the stored polynomial share of the Kth private key to the polynomial share of the (K-1)th private key).

[0100] It should be noted that the computer device in this embodiment can refer to a node (which can be denoted as the target node) corresponding to the private key owner in the management node. The target node updates the polynomial share of the stored Kth private key to the polynomial share of the K-1th private key. In addition, for each other node in the management node besides the target node, it is also necessary to obtain the first fusion polynomial share from T nodes in the K-2th node set (the first fusion polynomial share obtained by each node in the management node is different), and obtain the second fusion polynomial share from T nodes in the K-1th node set (the second fusion polynomial share obtained by each node in the management node is different). Then, based on the obtained T first fusion polynomial shares and T second fusion polynomial shares, the polynomial share of the K-1th private key is determined.

[0101] Subsequently, each node in the management system (including the target node) updates the stored polynomial share of the Kth private key to the polynomial share of the (K-1)th private key, while simultaneously invalidating the stored polynomial share of the Kth private key and configuring the (K-1)th private key as the currently used private key. Afterward, when the private key owner needs to use the (K-1)th private key, they can determine any T nodes (or more than T) from the management system, obtain the stored polynomial shares of the (K-1)th private key from each of these T nodes, and then reconstruct the (K-1)th private key based on the obtained T polynomial shares of the (K-1)th private key, and use it (e.g., for signing).

[0102] Based on the above embodiments, the beneficial effects of this application are as follows: In response to a first triggering event (such as private key leakage) of the Kth private key currently used in the L key pairs, this application determines the L node sets corresponding to the L key pairs in the blockchain network; and obtains first fusion polynomial shares from T nodes in the (K-2)th node set and second fusion polynomial shares from T nodes in the (K-1)th node set; then, based on the obtained T first fusion polynomial shares and T second fusion polynomial shares, determines the polynomial share of the (K-1)th private key in the L key pairs, thereby updating the stored polynomial share of the Kth private key to the polynomial share of the (K-1)th private key, thus achieving private key replacement. The above method generates L key pairs and stores the public key and corresponding random number shards of each key pair in the L key pairs in the corresponding node sets, so that when a private key is leaked, private key replacement can be performed based on the data stored in the relevant node set shards in the L node sets, ensuring the security of the private key. Furthermore, the first fusion polynomial share is determined based on the first share mask parameter, and the second fusion polynomial share is determined based on the second share mask parameter. By introducing the first share mask parameter and the second share mask parameter, the share of the public key and the share of the random number are protected from being leaked. This avoids the security risks caused by nodes in the same set of nodes jointly cracking the relevant information of the key pair, and further improves the security of the private key.

[0103] This application provides another key management method, which can be executed by a computer device, such as a computer device that can be... Figure 1A Node 101 or client 102 in the key management system shown can also be Figure 1D The example shows a management node in a key management system. For instance... Figure 3 As shown, the key management method may include, but is not limited to, the following steps S301-S306:

[0104] S301. In response to the first triggering event of the Kth private key in the L key pair, determine the set of L nodes in the blockchain network corresponding to the L key pair.

[0105] In this embodiment, the public key and corresponding random number shards in each key pair are stored in the corresponding node set. The Kth private key is the currently used private key, L is a positive integer greater than or equal to 3, and K is a positive integer greater than or equal to 3 and less than or equal to L. The specific implementation of step S301 is described in the preceding embodiment of step S201, and will not be repeated here.

[0106] Before introducing step S302, the key pair generation method and distributed storage method will be explained here. In one possible implementation, the computer device can perform the following steps (1)-(3):

[0107] (1) Generate L key pairs based on the elliptic curve and L random numbers.

[0108] In this embodiment, elliptic curves can be used in cryptography to generate public keys. For example, in an elliptic curve digital signature algorithm, a public key can refer to a point on the elliptic curve (including its x and y coordinates). Therefore, a computer device can generate L key pairs based on the elliptic curve and L random numbers.

[0109] In one possible implementation, for step (1) above, i.e., generating L key pairs based on the elliptic curve and L random numbers, one implementation can be as follows: steps (i)-(ii):

[0110] (i) For the Mth key pair, generate the private key in the Mth key pair based on the Mth random number among the L random numbers and the target public key; the target public key is either the initial public key or the public key in the (M-1)th key pair. The initial public key is determined based on the elliptic curve, and M is any positive integer less than or equal to L.

[0111] (ii) Generate the public key of the Mth key pair based on the private key and elliptic curve in the Mth key pair.

[0112] In steps (i)-(ii) above, the L key pairs satisfy a chain generation relationship, that is, the private key in the next generation key pair is derived from the public key in the previous generation key pair through function F, and function F can satisfy the following relationship: d i =p (i-1)x +p (i-1)y +r i Based on this, for the Mth key pair, the private key of the Mth key pair can be generated using the Mth random number from the L random numbers and the target public key. Then, the public key of the Mth key pair can be generated using the private key of the Mth key pair and the elliptic curve. The generation method for each of the L key pairs can be calculated using the above method.

[0113] For example, a computer device can select a point from an elliptic curve and determine that point as the initial public key, which can be denoted as p0 = (p 0x ,p 0y ), where p 0x Let x be the x-coordinate of the point and p. 0y Let r be the ordinate of the point. The i-th random number among L random numbers can be denoted as r. i The L random numbers are all known.

[0114] Therefore, for the first key pair, the private key in the first key pair can be generated based on function F, using the first random number from L random numbers and the target public key (which is the initial public key in this case). For example, substituting the initial public key p0 and the first random number r1 into function F yields the private key d1 in the first key pair. Then, the public key p1 in the first key pair is calculated based on the private key d1 and elliptic curve calculation, using the following formula: p i =d i ·G, where G is a parameter of the elliptic curve (such as base point, modulus, etc.).

[0115] For the second key pair, the private key in the second key pair can be generated based on the function F, using the second random number and the target public key (which is the public key in the (M-1)th key pair, i.e., the public key in the first key pair). For example, the public key p in the first key pair... (1) Substituting the first random number r2 into function F, we obtain the private key d1 in the second key pair. Then, we substitute the private key d2 and the parameters of the elliptic curve into formula p. i =d i ·G, thus obtaining the public key p2 in the second key pair. The generation methods for the other key pairs are the same as those for the second key pair, and will not be repeated here.

[0116] Steps (i)-(ii) above generate L sets of key pairs based on a chained generation relationship, ensuring the uniqueness of each generation of key pairs and clearly defining the chained structure between the key pairs. This chained structure facilitates subsequent key updates and management. Simultaneously, this chained structure requires attackers to obtain the current generation's random number and the previous generation's public key to deduce the private key, significantly increasing the difficulty of cracking and ensuring the security of the private key. Furthermore, each generation of key pairs is generated based on the same chained generation relationship, ensuring the consistency of the generation relationship between key pairs. This consistency makes the use and verification of key pairs more reliable.

[0117] (2) Determine L sets of nodes and the management node set from the blockchain network.

[0118] In this embodiment of the application, the computer device can determine, from the blockchain network, a set of L nodes for storing the polynomial share of the Lth generation private key and the polynomial share of the random number corresponding to the Lth generation private key, and a set of management nodes for storing the polynomial share of the currently used private key (i.e., the Lth private key).

[0119] (3) Store the public key and the corresponding random number fragment of each key pair in the L key pairs into the corresponding node set in the L node set, and store the Lth private key fragment in the L key pairs into the management node set; the Lth private key is the private key used initially.

[0120] For example, the computer device can fragment the public key of the first key pair and store it in the first node set, and simultaneously fragment the random number corresponding to the first key pair (i.e., the first random number) and store it in the first node set. The storage methods for the public keys and random numbers of other key pairs can refer to the above method, and will not be repeated here. Then, the computer device stores the Lth private key fragment in the management node set.

[0121] Steps (1)-(3) above generate L sets of key pairs, and store the public keys and random numbers of the L sets of key pairs in L sets of nodes, and store the Lth private key in the management node set, thereby reducing the risk of single point of failure and attack and improving the security of the blockchain system. At the same time, when a certain set of key pairs is abnormal (such as key leakage or loss), key replacement or key share can be performed based on the data stored in different nodes, thereby ensuring the continuous availability and stability of the blockchain system.

[0122] In one possible implementation, after step (3) above, i.e., storing the Lth private key in the L key pair in the management node set, the computer device can also perform the following steps: write the Lth public key in the L key pair into the blockchain (that is, the Lth public key will be made public), and perform data cleanup processing on the elliptic curve, L random numbers and L key pairs.

[0123] By clearing the original data associated with the Lth public key in the L key pairs after writing it into the blockchain, the long-term storage of sensitive information is reduced. This means that even if the blockchain system is attacked later, attackers will not be able to access this sensitive data, thereby reducing the risk of data leakage and preventing attackers from using this sensitive information to deduce or reconstruct the key pairs, thus improving the security of the data and the blockchain system.

[0124] For example, a computer device can construct a multinomial share generation function. and Then the public key p ix Input to function In the middle, the public key p iy Input to function In the middle, the random number r i Input to function In the middle, the Lth private key is input into the function. Then, the computer device can publish the Lth public key and clear the generated elliptic curve, L random numbers, and L key pairs.

[0125] After this, each node in the L node sets can be selected from the function. sum function The horizontal axis share of the public key is obtained from each of the following (denoted as ). <p ix >), Vertical axis share (denoted as <p iy >), and from the function The polynomial share of obtaining random numbers (denoted as ) <d L >).

[0126] For example, the polynomial share storage method for the public key, private key, and random number can be shown in Table 2 below:

[0127] Table 2

[0128]

[0129] Where, {S1,S2,S3,…,S L } represents a set of L nodes, S U Let L represent the set of management nodes. Each of the L node sets stores the polynomial share of the corresponding public key and the polynomial share of the random number. The management node set stores the polynomial share of the Lth private key.

[0130] In one possible implementation, for each node in each of the L node sets, each node can store one or both of the following: a polynomial share of the public key and a polynomial share of the random number. For example, taking node set S1 as an example, in one possible implementation, S1 may include T nodes, each storing a polynomial share of the public key and a polynomial share of the random number. In another possible implementation, S1 may include 2T nodes, with T nodes storing a polynomial share of the public key and the remaining T nodes storing a polynomial share of the random number.

[0131] Based on this, the specific implementation of obtaining the first fusion polynomial share from T nodes in the (K-2)th node set in the aforementioned embodiment can refer to obtaining the first fusion polynomial share from T nodes in the (K-2)th node set that store the polynomial share of the public key. Similarly, the specific implementation of obtaining the second fusion polynomial share from T nodes in the (K-1)th node set in the aforementioned embodiment can refer to obtaining the second fusion polynomial share from T nodes in the (K-1)th node set that store the polynomial share of the random number; this will not be elaborated further here.

[0132] S302. Obtain the polynomial share of the stored public key from each of the T nodes in the (K-1)th node set, and determine the (K-1)th public key based on the obtained polynomial shares of the T public keys.

[0133] In this embodiment of the application, each node in the (K-1)th node set stores a polynomial share of the (K-1)th public key. Therefore, the computer device can obtain the stored polynomial share of the (K-1)th public key from any T nodes in the (K-1)th node set, and determine the (K-1)th public key based on the obtained T polynomial shares of the (K-1)th public key.

[0134] For example, a computer device can recover the (K-1)th public key by processing the T polynomial shares (i.e., Shamir shares) of the obtained public key by invoking the Shamir secret recovery algorithm.

[0135] S303. Obtain the polynomial share of the stored random number from each of the T nodes in the Kth node set, and determine the Kth random number based on the obtained polynomial share of the T random numbers.

[0136] In this embodiment of the application, each node in the Kth node set stores a polynomial share of the Kth random number. Therefore, the computer device can obtain the stored polynomial share of the Kth random number from any T nodes in the Kth node set, and determine the Kth random number based on the obtained polynomial shares of the T Kth random numbers.

[0137] For example, a computer device can recover the Kth random number by processing the polynomial shares (i.e., Shamir shares) of the T random numbers obtained by calling the Shamir secret recovery algorithm.

[0138] S304. Based on the (K-1)th public key, the Kth random number, the elliptic curve, and the Kth public key, perform generational relationship verification.

[0139] In this embodiment, generational relationship verification refers to confirming whether a certain generation key pair (e.g., the (K-1)th generation key pair) conforms to a predetermined generation relationship with the previous generation key pair (e.g., the Kth generation key pair) (e.g., verifying whether it conforms to function F). By verifying generational relationship, the correctness of the generation relationship between different generations of key pairs can be ensured, preventing the misuse or unauthorized private use of private keys, thereby improving the security and stability of private keys and the blockchain system.

[0140] In one possible implementation, the generational relationship verification may include two stages: relationship generation verification and data verification. Based on this, for step S304 above, one implementation may be as follows: steps (i)-(iv):

[0141] (i) Generate relation verification based on the (K-1)th public key, the Kth random number, the elliptic curve and the Kth private key.

[0142] For example, a computer device can verify whether the following conditions are met:

[0143] p i =(p (i-1)x +p (i-1)y +r i )·G

[0144] Substitute the x and y coordinates of the (K-1)th public key into p. (i-1)x and p (i-1)y In the middle, substitute the Kth random number into r i In the middle, substitute the parameters of the elliptic curve into G, and substitute the Kth private key into p. i If the above conditions are met, it means that the generation relationship verification is successful.

[0145] (ii) If the relationship verification is successful, the verification information of the (K-1)th public key and the verification information of the Kth random number are obtained from the blockchain.

[0146] In this embodiment of the application, the verification information of T public keys and the verification information of T random numbers are calculated by the computer device after generating T public keys and T random numbers, and the verification information of T public keys and T random numbers are uploaded to the blockchain for data verification.

[0147] For example, for any generated random number (and the same applies to the public key), a computer device can calculate the verification information for this random number. This verification information can be a commitment value, such as the hash value obtained by hashing the random number. The aforementioned commitment value could mean that Alice, the promisor, promises a message to Bob, the recipient. The commitment process requires that when Alice makes the promise to Bob, Bob cannot obtain any information about the promised message, but after a period of time, Alice can verify the information she promised to Bob, and Alice cannot deceive Bob.

[0148] (iii) Perform data verification based on the (K-1)th public key, the verification information of the (K-1)th public key, the Kth random number, and the verification information of the Kth random number.

[0149] In this embodiment, the computer device can verify the accuracy of the (K-1)th public key using the verification information of the (K-1)th public key, and verify the correctness of the Kth random number using the verification information of the Kth random number. Once the (K-1)th public key and the Kth random number are verified, the data verification is considered successful.

[0150] For example, a computer device can perform a hash calculation on the (K-1)th public key to obtain a first hash value. If the first hash value is the same as the verification information of the (K-1)th public key (such as a second hash value), then the (K-1)th public key is considered to have passed verification. Similarly, a computer device can perform a hash calculation on the Kth random number to obtain a third hash value. If the third hash value is the same as the verification information of the Kth random number (such as a fourth hash value), then the Kth random number is considered to have passed verification.

[0151] (iv) If the data verification is successful, then the intergenerational relationship verification is successful.

[0152] If both the generation relationship verification and the data verification pass, it means that the generational relationship verification has passed.

[0153] The above steps (i)-(iv) incorporate a verification mechanism that combines generation relationship verification and data verification in the generation relationship verification process. Generation relationship verification ensures the correctness of the key generation process and ensures that the generation relationship of the key pair meets expectations, while data verification ensures that the public key and random number data are authentic and valid. Through the above multi-layer verification mechanism, the accuracy and diversity of generation relationship verification are improved.

[0154] S305. If the generational relationship verification is successful, the first fusion polynomial share is obtained from the T nodes in the K-2 node set, and the second fusion polynomial share is obtained from the T nodes in the K-1 node set.

[0155] In this embodiment of the application, the first fusion polynomial share is determined by T nodes in the (K-2)th node set according to the first share mask parameter and the polynomial share of their respective stored public keys, and the second fusion polynomial share is determined by T nodes in the (K-1)th node set according to the second share mask parameter and the polynomial share of their respective stored random numbers.

[0156] Steps S302-S305 above perform generational relationship verification based on the polynomial shares of public keys stored by the T nodes in the (K-1)th node set and the polynomial shares of random numbers stored by the T nodes in the Kth node set. This verifies whether a certain generation key pair (e.g., the (K-1)th generation key pair) conforms to a predetermined generation relationship (e.g., verifying whether it conforms to function F) with the previous generation key pair (e.g., the Kth generation key pair). Generational relationship verification ensures the correctness of the generation relationship between different generations of key pairs, prevents misuse or unauthorized private key use, and thus improves the security and stability of the private key and the blockchain system.

[0157] In one possible implementation, for the step of obtaining the first fusion polynomial share from the T nodes in the K-2th node set in step S305 above, one implementation can be as follows: (1)-(2):

[0158] (1) Send the first private key replacement request for the Kth private key to each of the T nodes in the K-2 node set.

[0159] (2) Receive the first fusion polynomial shares returned by T nodes in the K-2 node set respectively, and obtain T first fusion polynomial shares.

[0160] In this embodiment of the application, the first private key replacement request is used to instruct each of the T nodes in the (K-2)th node set to perform share conversion processing on the polynomial share of the stored public key to obtain the additive share of the public key, and to perform sharding processing on the first share mask parameter for the T nodes in the (K-2)th node set to obtain the additive share of the first share mask parameter, and to perform sharding processing on the first fusion result of the additive share of the public key and the additive share of the first share mask parameter for each node in the management node set to obtain the first fused polynomial share corresponding to each node in the management node set.

[0161] In steps (1)-(2) above, the computer device sends a first private key replacement request to T nodes in the (K-2)th node set, requesting each of these T nodes to determine the first fusion polynomial share based on the polynomial share of the stored public key, and receives the first fusion polynomial shares returned by the T nodes respectively, thereby improving the automation level of the private key replacement process. Simultaneously, the T nodes in the (K-2)th node set introduce a first share mask parameter during the calculation of the first fusion polynomial share, thus ensuring that the public key share is not leaked, avoiding the security risks caused by nodes in the same node set jointly cracking the relevant information of the key pair, and further improving the security of the private key.

[0162] The following will use any one of the T nodes in the (K-2)th node set (denoted as the first node) as an example to illustrate the method for generating the first fusion polynomial share. The process can be described in the following steps (a1)-(a4):

[0163] (a1) The first node performs share conversion on the polynomial shares of the stored public key to obtain the additive shares of the public key.

[0164] In one possible implementation, since the polynomial share of the stored public key can include both the horizontal and vertical polynomial shares, the additive share of the public key can also include both the horizontal and vertical additive shares. Based on this, the share conversion process in step (a1) can be as follows: The first node determines the first conversion parameter based on the horizontal polynomial shares of the public key stored by the T nodes in the (K-2)th node set; then, it determines the horizontal additive share based on the first conversion parameter and the stored horizontal polynomial shares of the public key, and determines the vertical additive share based on the first conversion parameter and the stored vertical polynomial shares of the public key.

[0165] For example, the first node first calculates the first transformation parameter (which can be denoted as λ). j Let j represent the first node being the j-th node among the T nodes in the (K-2)-th node set, where each of the T nodes in the (K-2)-th node set has a different transformation parameter. The formula for calculating the first transformation parameter is as follows:

[0166]

[0167] Where, x j x represents the x-coordinate of the polynomial share of the public key held by the first node; k The x-coordinate represents the polynomial share of the public key held by each of the T nodes in the (K-2)th node set, excluding the first node.

[0168] Then, the first node can be processed using the Lagrange formula for share conversion, which is as follows:

[0169] [p (i-2)x ] j =λ j <p (i-2)x > j

[0170] [p (i-2)y ] j =λ j <p (i-2)y > j

[0171] Among them, [p (i-2)x ] j The x-axis of the public key is an additive share. <p (i-2)x > j The x-axis polynomial share of the public key stored in the first node, [p (i-2)y ] j The additive share of the public key's y-axis. <p (i-2)y > j The y-axis polynomial share of the public key stored in the first node.

[0172] (a2) The first node performs fragmentation processing on the first share mask parameter for the T nodes in the K-2 node set to obtain the additive share of the first share mask parameter.

[0173] For example, the first share mask parameter is denoted as ε. The T nodes of the (K-2)th node set perform additive secret sharing for the first share mask parameter. Each node will obtain an additive share of the first share mask parameter, denoted as [ε].

[0174] Additive secret sharing refers to splitting secret P into additive shares s. i (i∈[1,n]), and distributed to share holder P. i (i∈[1,n]), the secret value can be recovered by all share holders cooperating to add up the sum of the additional shares.

[0175] (a3) The additive share of the public key is fused with the additive share of the first share mask parameter to obtain the first fusion result.

[0176] For example, the first node can add the additive share of the public key to the additive share of the first share mask parameter to obtain the first fusion result, which can be represented as [p (i-2)x ]+[p (i-2)y ]+[ε.

[0177] (a4) Perform sharding on the first fusion result for each node in the management node set to obtain the first fusion polynomial share corresponding to each node in the management node set.

[0178] For example, the first node can share the first fusion result with each node in the management node set through polynomial secret sharing. Then, it will obtain the first fusion polynomial share corresponding to each node in the management node set. The first fusion polynomial share can be denoted as <[p (i-2)x ]+[p (i-2)y ]+[ε]>.

[0179] In one possible implementation, for the step of obtaining the second fusion polynomial share from the T nodes in the K-1th node set in step S305 above, one implementation can be as follows: (1)-(2):

[0180] (1) Send a second private key replacement request for the Kth private key to each of the T nodes in the K-1 node set.

[0181] (2) Receive the second fusion polynomial shares returned by T nodes in the K-1 node set respectively, and obtain T second fusion polynomial shares.

[0182] In this embodiment of the application, the second private key replacement request is used to instruct each of the T nodes in the K-1 node set to perform share conversion processing on the polynomial share of the stored random number to obtain the additive share of the random number, and to perform sharding processing on the second share mask parameter for the T nodes in the K-1 node set to obtain the additive share of the second share mask parameter, and to perform sharding processing on the second fusion result of the additive share of the random number and the additive share of the second share mask parameter for each node in the management node set to obtain the second fused polynomial share corresponding to each node in the management node set.

[0183] In steps (1)-(2) above, the computer device sends a second private key replacement request to T nodes in the (K-1)th node set, requesting each of these T nodes to determine the second fusion polynomial share based on the polynomial share of the stored random number, and receives the second fusion polynomial shares returned by the T nodes respectively, thereby improving the automation level of the private key replacement process. Simultaneously, the T nodes in the (K-1)th node set introduce a second share mask parameter during the calculation of the second fusion polynomial share, thus ensuring that the random number share is not leaked, avoiding the security risks caused by nodes in the same node set jointly cracking the relevant information of the key pair, and further improving the security of the private key.

[0184] The following will use any one of the T nodes in the (K-1)th node set (denoted as the second node) as an example to illustrate the method for generating the second fusion polynomial share. The process can be described in the following steps (b1)-(b4):

[0185] (b1) The second node performs share conversion on the polynomial share of the stored random number to obtain the additive share of the random number.

[0186] In one possible implementation, the second node first calculates the second transformation parameter (which can be denoted as λ). j Here, j represents the second node being the j-th node among the T nodes in the (K-1)-th node set, and the second transformation parameters corresponding to the T nodes in the (K-1)-th node set are all different. The calculation formula for the second transformation parameter can be found in the calculation formula for the first transformation parameter, and will not be repeated here.

[0187] Then, the second node can use the Lagrange formula to convert the polynomial share of the stored random numbers into an additive share of the random numbers, which will not be elaborated here. The additive share of random numbers can be denoted as [r i-1 ].

[0188] (b2) The second node performs fragmentation processing on the second share mask parameter for the T nodes in the K-1 node set to obtain the additive share of the second share mask parameter.

[0189] For example, the second share mask parameter is denoted as -ε, and the second share mask parameter is the negative form of the first share mask parameter. The T nodes of the K-1th node set perform additive secret sharing for the second share mask parameter, and each node will obtain an additive share of the second share mask parameter, denoted as [-ε].

[0190] (b3) The additive share of the random number is fused with the additive share of the second share mask parameter to obtain the second fusion result.

[0191] For example, the second node can add the additive share of the random number to the additive share of the second share mask parameter to obtain the second fusion result, which can be represented as [r i-1 ]+[-ε.

[0192] (b4) Perform sharding on the second fusion result for each node in the management node set to obtain the second fusion polynomial share corresponding to each node in the management node set.

[0193] For example, the second node can share the second fusion result with each node in the management node set through polynomial secret sharing. Then, it will obtain the second fusion polynomial share corresponding to each node in the management node set. The second fusion polynomial share can be denoted as <[r i-1 ]+[-ε]>.

[0194] S306. Based on the obtained T first fusion polynomial shares and T second fusion polynomial shares, determine the polynomial share of the (K-1)th private key in the L key pairs.

[0195] For example, a computer device can add the obtained T first fusion polynomial shares and T second fusion polynomial shares to obtain the polynomial share of the (K-1)th private key. The polynomial share of the (K-1)th private key can be denoted as d. i-1 The calculation formula can be as follows:

[0196] d i*1 =Σ(<[p (i-2)x ]+[p (i-2)y ]+[ε]>+<[r i-1 ]+[-ε]>)

[0197] In one possible implementation, a second triggering event is generated when the polynomial share of the Kth private key stored by the target node in the management node set is lost (e.g., the share of the private key in the currently used key pair stored by a blockchain user is lost). This second triggering event can be generated by the target node (e.g., the node corresponding to the blockchain user in the blockchain) when it detects the loss of the polynomial share of the stored private key. Alternatively, the second triggering event can be generated when the blockchain user reports an anomaly message indicating the share loss to the target node, and the target node then generates the second triggering event based on the anomaly message; this embodiment does not limit the specific implementation. Furthermore, a second triggering event can also be generated when the user actively performs an update triggering operation for the polynomial share of the stored Kth private key (e.g., when the user submits an update request for the polynomial share of the stored Kth private key). Alternatively, the private key share update can be triggered periodically, for example, automatically generating a second triggering event every preset second time interval (e.g., 40 days); this will not be elaborated further here. The above method enables not only automatic updates of private key shares when they are lost, but also updates when the user expresses an intention to update their private key shares, thus improving the flexibility of private key share updates. Furthermore, it allows for automatic updates at set intervals, thereby enhancing the intelligence of private key share updates.

[0198] Based on this, the computer device can also perform the following steps (1)-(2):

[0199] (1) In response to the second triggering event of the target node in the management node set for the polynomial share of the stored Kth private key, the target polynomial share is obtained from each of the T nodes in the management node set; the target polynomial share is determined by the T nodes in the management node set according to the polynomial share of the stored Kth private key.

[0200] In one possible implementation, for the step (1) above, which involves obtaining the target polynomial share from each of the T nodes in the management node set, one implementation can be as follows: steps (i)-(ii):

[0201] (i) Determine the T nodes whose polynomial share of the Kth private key stored in the management node set is in a normal state.

[0202] (ii) Obtain the target polynomial share from each of the T nodes.

[0203] In steps (i)-(ii) above, the computer device can determine T nodes from the management node set that store the polynomial share of the Kth private key in a normal state, that is, determine T nodes that fully store the polynomial share of the Kth private key. Then, it retrieves the target polynomial share determined by each of these T nodes. This method filters out nodes that have experienced share storage failures or anomalies, ensuring that information is only retrieved from nodes in a normal state. This filtering mechanism reduces the risk of retrieving data from abnormal or unreliable nodes, thereby improving the accuracy and reliability of updates after private key share loss, and ensuring the security and stability of the system.

[0204] In this embodiment of the application, the target polynomial share is obtained by performing share conversion processing on the polynomial share of the stored Kth private key by T nodes in the management node set to obtain the additive share of the private key, and then performing sharding processing on the additive share of the private key for each node in the management node set.

[0205] The following will use any one of the T nodes in the management node set (denoted as the third node) as an example to illustrate the method for generating the target polynomial share. The process can be described in the following steps (c1)-(c2):

[0206] (c1) Perform share conversion on the polynomial share of the stored Kth private key to obtain the additive share of the private key.

[0207] In one possible implementation, the third node first calculates the third transformation parameter (which can be denoted as λ). j Here, j represents the j-th node among the T nodes in the management node set, and the third transformation parameter is different for each of the T nodes in the management node set. The calculation formula for the third transformation parameter can be found in the calculation formula for the first transformation parameter, and will not be repeated here.

[0208] Then, the third node can use the Lagrange formula to convert the polynomial share of the stored Kth private key into an additive share of the Kth private key, which will not be elaborated here. The additive share of the random number can be denoted as [d L ].

[0209] (c2) The additive share of the private key is sharded for each node in the set of management nodes to obtain the target polynomial share.

[0210] For example, a third node can share an additive share of its private key with each node in the management node set through polynomial secret sharing. This will yield the target polynomial share for each node in the management node set. The target polynomial share can be denoted as <[d L ]>.

[0211] (2) Based on the obtained T target polynomial shares, determine the updated polynomial share of the Kth private key; the updated polynomial share of the Kth private key is used to generate the Kth private key.

[0212] In this embodiment, each node in the management node set (including a computer device, which can be one node in the management node set) can obtain T target polynomial shares to determine the updated polynomial share of the Kth private key. For example, each node in the management node set can sum the obtained T target polynomial shares to generate the updated polynomial share of the Kth private key, denoted as d. L .

[0213] In steps (1)-(2) above, when the computer device detects the second triggering event, it can automatically trigger the private key share update process, that is, obtain the target polynomial share from the T nodes in the management node set, and determine the updated polynomial share of the Kth private key based on the obtained T target polynomial shares. This automated private key share update process can reduce unnecessary manual private key share update operations, reduce operation and maintenance costs, ensure the continuous availability and security of the blockchain system, and reduce the service interruption time caused by the loss of private key shares.

[0214] The key management method provided in this application can be considered a backend data storage scheme, which can be well applied to blockchain private key protection scenarios. Blockchain private key protection is a crucial issue in blockchain systems. This solution implements a secure blockchain private key protection scheme, avoiding the risk of key leakage in client and server memory. Addressing common blockchain private key leakage and loss issues, this solution designs a replacement scheme after private key leakage and a scheme for updating the share held by participants after private key loss. Furthermore, it implements the (T,N) threshold property, meaning that selecting any T nodes from N nodes is sufficient to complete the replacement after private key leakage or the share update after private key loss.

[0215] This scheme introduces two concepts: random number and commitment value. If the random number r is not introduced... l Then the private key d i and public key p (i-1) The relationship between them is deterministic and can be determined based on p. (i-1) Derive d i Therefore, it is necessary to introduce a random number r. i And private key d i and public key p (i-1) The holding server cannot be the same. If a commitment value is not generated, an attacker can forge the public-private key pair (d′). l-1 ,p′ l-1 ) and r′ l Make it satisfy d l =p′ l-1 +r′ l This leads to the creation of a forged new private key d′ l-1 It has been put into use.

[0216] The key management method provided in this application will be illustrated below with examples:

[0217] The key management method provided in this application specifically refers to a key distributed management method based on secret sharing, which includes three protocols: KeyGen key initialization protocol, KeyIterate key replacement protocol, and UpdateKeyShare private key share loss update protocol.

[0218] The KeyGen key initialization protocol can be represented as:

[0219] The protocol input may include: elliptic curves Safety parameter λ.

[0220] Public output may include: the Lth generation public key p L The set of commitments is C.

[0221] Private outputs from each party may include:

[0222] ① The set of nodes in the i-th generation, S i j nodes server in (i∈[1,…,L]) i,j (j∈[1,…,|S i Output of |]): <p ix >, <p iy >, <r i >, which are public keys p i =(p ix ,p iy The x-coordinate p ix Shamir share, ordinate p iy Shamir share and random number r i The shamir share. Where, |S i | is the set of servers of generation i, S i The number of nodes in the system.

[0223] ② Set of management nodes S U And the user's output: <d L > That is, the Lth generation private key d L The Shamir share. The KeyGen key initialization protocol flow can be as follows:

[0224] (1) User user (such as the target node in the management node set) generates L random numbers r i And calculate the commitment value c(r) for each random number. i ) = Com(r i ), and record it on the blockchain, i∈[1,…,L].

[0225] (2) User user generates a public key p0 for an elliptic curve, according to formula d i =p (i-1)x +p (i-1)y +r i and p i =d i G generates L sets of key pairs and simultaneously calculates the commitment value c(p) of each public key. i ) = Com(p i ), and record it on the blockchain, i∈[1,…,L].

[0226] (3) User user will pass the public key p ix Input to Shamir's share generation function In the middle, the public key p iy Input to function In the middle, the random number r i Input to function In the middle, the Lth private key d L Input to function middle.

[0227] (4) User user publishes the Lth public key p L And clear the generated elliptic curve, L random numbers and L key pairs.

[0228] (5) The set of the i-th node of the set of L nodes S i The node server in i,j From function The Shamir shares of the public key were obtained from each of them. <p ix > j , <p iy > j and the Shamir share of random numbers <r u > j .

[0229] (6) Management node set S U and users from Obtain Shamir's share of the Lth generation private key <d1> j .

[0230] The specific implementation methods of steps (1)-(6) above can be found in the relevant descriptions in the aforementioned method embodiments, and will not be repeated here.

[0231] The key iteration protocol KeyIterate can be represented as: (d i-1 ,p i-1 )←KeyIterate(i,d i ,{server i-1,j },{server i-2,j }).

[0232] The input to the protocol can include: (i, d) i ,T i-1 ,T i-2 ), representing the i-th generation private key d i The information has been leaked, where i ∈ [3,…,L]. The T nodes selected from the (i-1)th generation node set and the (i-2)th generation node set are denoted as {server}. i-1,j }、{server i-2,j }

[0233] Protocol objective: Generate the previous generation public / private key (d) i-1 ,p i-1 ).

[0234] Public output may include: the (i-1)th generation public key p i-1 .

[0235] Private outputs from each party: to the set of management nodes S U and user output <d i-1 > indicates the share of the previous generation private key.

[0236] The protocol process may include the following two stages: generational relationship verification (i.e., performing P...) i-1 and P i (Relationship verification) and will expose the private key d i Updated to d i-1 .

[0237] (I) Verification of intergenerational relationship.

[0238] (1) S i-1 Choose any T nodes as servers (i-1),j and send to the verification party (such as the user) <p (i-1)x >, <p (i-1)y >;S i Choose any T nodes as servers i,j and send to the verifier <r i >

[0239] (2) The verifier uses the Shamir secret recovery algorithm to recover p (i-1)x p (i-1)y and r i .

[0240] (3) Verification condition p i =(p (i-1)x +p (i-1)y +r i Whether G is true.

[0241] (4) Verify p i-1 and r i The commitment value C(p) i-1 ) and C(r i Is this correct?

[0242] The specific implementation methods of steps (1)-(4) above can be found in the relevant descriptions in the aforementioned method embodiments, and will not be repeated here.

[0243] (ii) The private key d was leaked i Updated to d i-1 .

[0244] (1) S i-2 Choose any T nodes as servers (i-2),j The public key p held by each of the T nodes. (i-2) The Shamir shares of the x and y axes can be converted into additive shares using the Lagrange formula in the aforementioned embodiments.

[0245] (2) S i-2 and S i-1 After each of the T selected nodes conducts secret negotiation, S i-2 The additive share [ε] of the random number ε obtained from T nodes, S i-1 The T nodes in the sequence obtain an additive share of the random number -ε [-ε].

[0246] (3) S i-2 For each of the T nodes, calculate [p] (i-2)x ]+[p (i-2)y ]+[ε], and perform it on the set of management nodes S U After sharing with the user Shamir's secret, <[p (i-2)x ]+[p (i-2)y ]+[ε]>, and distribute them to the management node set S U And users.

[0247] (4) S i-1 Choose any T nodes as servers (i-1),j The Shamir share held by each of the T nodes. <r i-1 >Convert to additive share[r] i-1 ]=λ j <r i-1 The Lagrange formula from the foregoing embodiments can be used for conversion.

[0248] (5) S i-1 For each of the T nodes, calculate [r] i-1 ]+[-ε], and apply it to the set of management nodes S U After sharing with user Shamir's secret, <[r i-1 ]+[-ε]〉, and send it to the set of management nodes S U And users.

[0249] (6) Management node set S U The user and the node set S will be received respectively. i-2 The T Shamir shares sent, and the node set S i-1 The new private key d is obtained by adding the T Shamir shares sent and summing them together. i-1 Shamir's share.

[0250] The specific implementation methods of steps (1)-(6) above can be found in the relevant descriptions in the aforementioned method embodiments, and will not be repeated here.

[0251] The UpdateKeyShare protocol for updating lost private key shares can be represented as: (d i )←UpdateKeyShare(i,U,{server U,j }).

[0252] The protocol input can include: (i, U, {server U,j }), representing the user's private key share when the currently used private key is of generation i. <d i Lost.

[0253] Private outputs from each party may include: outputs to the management node set S U Shamir's share of the updated contemporary private key output by the user <d i >

[0254] The protocol flow for updating lost private key shares (UpdateKeyShare) can be as follows:

[0255] (1) Set of management nodes S U Choose any T nodes as servers U,j Each node will hold a Shamir share of the private key. <d i >Convert to additive share[d i ]=λ <d i >

[0256] (2) Each node in the T nodes pairs [d i Oriented towards the set of management nodes S U Shamir secret sharing with users at a threshold of (t, n), denoted as <[d i ]>.

[0257] (3) Management node set S U The user will receive T shares of Shamir <[d i By accumulating these values, we can obtain the updated Shamir share after the private key share was lost. <d i >

[0258] The specific implementation methods of steps (1)-(3) above can be found in the relevant descriptions in the aforementioned method embodiments, and will not be repeated here.

[0259] The key management method provided in this application distributes multiple generations of key pairs for storage. When a private key is leaked, a new private key belonging to the same user can be updated according to the chain generation relationship. When a user's private key share is lost, the private key share can be updated without recovering the private key. The above method enhances the security and fault tolerance of the private key and improves the security and availability of the blockchain system.

[0260] The methods of the embodiments of this application have been described in detail above. In order to facilitate better implementation of the methods of the embodiments of this application, the apparatus of the embodiments of this application is provided below.

[0261] Please see Figure 4 This figure is a schematic diagram of a key management device provided in an embodiment of this application. The key management device can be installed in the computer equipment provided in this embodiment of the application, and the computer equipment can be as described above. Figure 1A Node 101 or client 102 in the key management system shown can also be Figure 1D The management node in the key management system shown. Figure 4 The key management device shown can be a computer program running on a computer device, which can be used to execute... Figure 2 or Figure 3 Some or all of the steps in the method embodiments shown. Please refer to [link / reference]. Figure 4 The key management device may include the following units:

[0262] The response unit 401 is used to respond to the first triggering event of the Kth private key in the L key pairs and determine the L node sets in the blockchain network corresponding to the L key pairs; the public key and the corresponding random number shard in each key pair are stored in the corresponding node set, the Kth private key is the currently used private key, L is a positive integer greater than or equal to 3, and K is a positive integer greater than or equal to 3 and less than or equal to L.

[0263] The acquisition unit 402 is used to acquire a first fusion polynomial share from T nodes in the (K-2)th node set, and to acquire a second fusion polynomial share from T nodes in the (K-1)th node set. The first fusion polynomial share is determined by T nodes in the (K-2)th node set according to the first share mask parameter and the polynomial share of their respective stored public keys. The second fusion polynomial share is determined by T nodes in the (K-1)th node set according to the second share mask parameter and the polynomial share of their respective stored random numbers. The second share mask parameter is the opposite of the first share mask parameter, and T is a positive integer greater than or equal to 2.

[0264] The processing unit 403 is used to determine the polynomial share of the (K-1)th private key in the L key pairs based on the obtained T first fusion polynomial shares and T second fusion polynomial shares; the polynomial share of the (K-1)th private key is used to generate the (K-1)th private key, and the (K-1)th private key is configured as the currently used private key.

[0265] In one possible implementation, the processing unit 403 is further configured to:

[0266] Based on the elliptic curve and L random numbers, generate L sets of key pairs;

[0267] Identify L sets of nodes and manage the set of nodes from the blockchain network;

[0268] Store the public key and corresponding random number fragment of each of the L key pairs into the corresponding node set of the L node set, and store the Lth private key fragment of the L key pairs into the management node set; the Lth private key is the private key used initially.

[0269] In one possible implementation, when processing unit 403 generates L key pairs based on the elliptic curve and L random numbers, it specifically performs the following tasks:

[0270] For the Mth key pair, generate the private key of the Mth key pair based on the Mth random number among L random numbers and the target public key; the target public key is either the initial public key or the public key of the (M-1)th key pair. The initial public key is determined based on the elliptic curve, and M is any positive integer less than or equal to L.

[0271] Generate the public key for the Mth key pair based on the private key and elliptic curve in the Mth key pair;

[0272] After storing the Lth private key fragment from the L key pairs into the management node set, the processing unit 403 is further used for:

[0273] Write the Lth public key from the L key pairs into the blockchain, and perform data cleanup on the elliptic curve, L random numbers, and L key pairs.

[0274] In one possible implementation, the processing unit 403 is further configured to:

[0275] Obtain the polynomial share of the stored public key from each of the T nodes in the (K-1)th node set, and determine the (K-1)th public key based on the obtained polynomial shares of the T public keys;

[0276] Obtain the polynomial share of the stored random number from each of the T nodes in the Kth node set, and determine the Kth random number based on the polynomial share of the obtained T random numbers;

[0277] Based on the (K-1)th public key, the Kth random number, the elliptic curve, and the Kth public key, perform generational relationship verification;

[0278] If the generational relationship verification passes, then proceed with the step of obtaining the first fusion polynomial share from each of the T nodes in the (K-2)th node set.

[0279] In one possible implementation, when processing unit 403 performs generational relationship verification based on the (K-1)th public key, the Kth random number, the elliptic curve, and the Kth public key, it specifically performs the following:

[0280] Generate relation verification based on the (K-1)th public key, the Kth random number, the elliptic curve, and the Kth private key;

[0281] If the relationship verification passes, the verification information of the (K-1)th public key and the verification information of the Kth random number are obtained from the blockchain.

[0282] Data verification is performed based on the (K-1)th public key, the verification information of the (K-1)th public key, the Kth random number, and the verification information of the Kth random number.

[0283] If the data verification passes, then the intergenerational relationship verification is confirmed.

[0284] In one possible implementation, when the processing unit 403 is used, it is specifically used for:

[0285] In response to a second triggering event from the target node in the management node set regarding the polynomial share of the stored Kth private key, the target polynomial share is obtained from each of the T nodes in the management node set; the target polynomial share is determined by the T nodes in the management node set based on the polynomial share of the Kth private key stored by each of them.

[0286] Based on the obtained T target polynomial shares, determine the updated polynomial share of the Kth private key; the updated polynomial share of the Kth private key is used to generate the Kth private key.

[0287] In one possible implementation, when processing unit 403 is used to obtain the target polynomial share from each of the T nodes in the management node set, it specifically performs the following:

[0288] Determine the T nodes in the management node set whose polynomial share of the Kth private key is in a normal state;

[0289] Obtain the target polynomial share from each of the T nodes;

[0290] The target polynomial share is obtained by performing share conversion processing on the polynomial share of the stored Kth private key by T nodes in the management node set to obtain the additive share of the private key, and then performing sharding processing on the additive share of the private key for each node in the management node set.

[0291] In one possible implementation, when obtaining the first fusion polynomial share from each of the T nodes in the (K-2)th node set, the obtaining unit 402 is specifically used for:

[0292] Send a first private key replacement request for the Kth private key to each of the T nodes in the (K-2)th node set;

[0293] Receive the first fusion polynomial shares returned by T nodes in the (K-2)th node set, and obtain T first fusion polynomial shares;

[0294] Specifically, the first private key replacement request instructs each of the T nodes in the (K-2)th node set to perform share conversion processing on the polynomial share of the stored public key to obtain the additive share of the public key, and to perform sharding processing on the first share mask parameter for the T nodes in the (K-2)th node set to obtain the additive share of the first share mask parameter, and to perform sharding processing on the first fusion result of the additive share of the public key and the additive share of the first share mask parameter for each node in the management node set to obtain the first fusion polynomial share corresponding to each node in the management node set.

[0295] In one possible implementation, when obtaining the second fusion polynomial share from the T nodes in the (K-1)th node set, the obtaining unit 402 is specifically used for:

[0296] Send a second private key replacement request for the Kth private key to each of the T nodes in the (K-1)th node set;

[0297] Receive the second fusion polynomial shares returned by T nodes in the (K-1)th node set, and obtain T second fusion polynomial shares;

[0298] Specifically, the second private key replacement request is used to instruct each of the T nodes in the (K-1)th node set to perform share conversion processing on the polynomial share of the stored random number to obtain the additive share of the random number, and to perform sharding processing on the second share mask parameter for the T nodes in the (K-1)th node set to obtain the additive share of the second share mask parameter, and to perform sharding processing on the second fusion result of the additive share of the random number and the additive share of the second share mask parameter for each node in the management node set to obtain the second fused polynomial share corresponding to each node in the management node set.

[0299] It should be noted that the functions of each unit of the key management device in the embodiments of this application can be specifically implemented according to the methods in the above method embodiments. The specific implementation process can be referred to the relevant descriptions in the various method embodiments of this application, which will not be repeated here.

[0300] According to another embodiment of this application, Figure 4 The units in the illustrated key management device can be individually or entirely merged into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the key management device may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0301] According to another embodiment of this application, the following can be achieved by running on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), a device capable of performing operations such as... Figure 2 or Figure 3 Computer programs for the steps involved in some or all of the methods shown, to construct, for example... Figure 4 The key management device shown herein, and the key management method for implementing the embodiments of this application, are described. A computer program may be recorded on, for example, a computer-readable storage medium, loaded onto the aforementioned computing device via the computer-readable storage medium, and executed therein.

[0302] Based on the above methods and apparatus embodiments, this application provides a computer device. Please refer to... Figure 5 This figure is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 5 The computer device shown includes at least a processor 501, an input interface 502, an output interface 503, and a computer-readable storage medium 504. The processor 501, input interface 502, output interface 503, and computer-readable storage medium 504 can be connected via a bus or other means.

[0303] Computer-readable storage medium 504 can be stored in the memory of a computer device. Computer-readable storage medium 504 is used to store computer programs, including program instructions. Processor 501 is used to execute the computer program stored in computer-readable storage medium 504. Processor 501 (or CPU (Central Processing Unit)) is the computing and control core of the computer device; it is suitable for implementing computer programs, specifically for loading and executing computer programs to achieve the above-mentioned functions. Figure 2 or Figure 3 The method flow is shown.

[0304] This application also provides a computer-readable storage medium (Memory), which is a memory device in a computer device used to store programs and data. It is understood that the computer-readable storage medium here can include both built-in storage media in the computer device and extended storage media supported by the computer device. The computer-readable storage medium provides storage space for storing the operating system of the computer device. Furthermore, the storage space also stores computer programs suitable for loading and execution by a processor. It should be noted that the computer-readable storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device; optionally, it can also be at least one computer-readable storage medium located remotely from the aforementioned processor.

[0305] Computer devices can be, for example, those described above. Figure 1A Node 101 or client 102 in the key management system shown can also be Figure 1D The illustrated key management system includes a management node. In a specific implementation, the processor 501 loads and executes the computer program stored in the computer-readable storage medium 504 to implement the corresponding steps of the key management method in each method embodiment of this application. Specifically, the computer program in the computer-readable storage medium 504 is loaded and executed by the processor 501, and the following steps are performed:

[0306] In response to the first triggering event of the Kth private key in the L key pairs, determine the L node sets in the blockchain network corresponding to the L key pairs; the public key and the corresponding random number shard in each key pair are stored in the corresponding node set, the Kth private key is the currently used private key, L is a positive integer greater than or equal to 3, and K is a positive integer greater than or equal to 3 and less than or equal to L.

[0307] The first fusion polynomial share is obtained from each of the T nodes in the (K-2)th node set, and the second fusion polynomial share is obtained from each of the T nodes in the (K-1)th node set. The first fusion polynomial share is determined by the T nodes in the (K-2)th node set according to the first share mask parameter and the polynomial share of their respective stored public keys. The second fusion polynomial share is determined by the T nodes in the (K-1)th node set according to the second share mask parameter and the polynomial share of their respective stored random numbers. The second share mask parameter is the opposite of the first share mask parameter, and T is a positive integer greater than or equal to 2.

[0308] Based on the obtained T first fusion polynomial shares and T second fusion polynomial shares, determine the polynomial share of the (K-1)th private key in the L key pairs; the polynomial share of the (K-1)th private key is used to generate the (K-1)th private key, and the (K-1)th private key is configured as the currently used private key.

[0309] In one possible implementation, processor 501 is also used for:

[0310] Based on the elliptic curve and L random numbers, generate L sets of key pairs;

[0311] Identify L sets of nodes and manage the set of nodes from the blockchain network;

[0312] Store the public key and corresponding random number fragment of each of the L key pairs into the corresponding node set of the L node set, and store the Lth private key fragment of the L key pairs into the management node set; the Lth private key is the private key used initially.

[0313] In one possible implementation, when the processor 501 is used to generate L key pairs based on the elliptic curve and L random numbers, it specifically performs the following:

[0314] For the Mth key pair, generate the private key of the Mth key pair based on the Mth random number among L random numbers and the target public key; the target public key is either the initial public key or the public key of the (M-1)th key pair. The initial public key is determined based on the elliptic curve, and M is any positive integer less than or equal to L.

[0315] Generate the public key for the Mth key pair based on the private key and elliptic curve in the Mth key pair;

[0316] After storing the Lth private key fragment from the L key pairs into the management node set, the processing unit 403 is further used for:

[0317] Write the Lth public key from the L key pairs into the blockchain, and perform data cleanup on the elliptic curve, L random numbers, and L key pairs.

[0318] In one possible implementation, processor 501 is also used for:

[0319] Obtain the polynomial share of the stored public key from each of the T nodes in the (K-1)th node set, and determine the (K-1)th public key based on the obtained polynomial shares of the T public keys;

[0320] Obtain the polynomial share of the stored random number from each of the T nodes in the Kth node set, and determine the Kth random number based on the polynomial share of the obtained T random numbers;

[0321] Based on the (K-1)th public key, the Kth random number, the elliptic curve, and the Kth public key, perform generational relationship verification;

[0322] If the generational relationship verification passes, then proceed with the step of obtaining the first fusion polynomial share from each of the T nodes in the (K-2)th node set.

[0323] In one possible implementation, when processor 501 performs generational relationship verification based on the (K-1)th public key, the Kth random number, the elliptic curve, and the Kth public key, it specifically performs the following:

[0324] Generate relation verification based on the (K-1)th public key, the Kth random number, the elliptic curve, and the Kth private key;

[0325] If the relationship verification passes, the verification information of the (K-1)th public key and the verification information of the Kth random number are obtained from the blockchain.

[0326] Data verification is performed based on the (K-1)th public key, the verification information of the (K-1)th public key, the Kth random number, and the verification information of the Kth random number.

[0327] If the data verification passes, then the intergenerational relationship verification is confirmed.

[0328] In one possible implementation, processor 501 is specifically used for:

[0329] In response to a second triggering event from the target node in the management node set regarding the polynomial share of the stored Kth private key, the target polynomial share is obtained from each of the T nodes in the management node set; the target polynomial share is determined by the T nodes in the management node set based on the polynomial share of the Kth private key stored by each of them.

[0330] Based on the obtained T target polynomial shares, determine the updated polynomial share of the Kth private key; the updated polynomial share of the Kth private key is used to generate the Kth private key.

[0331] In one possible implementation, when processor 501 is used to obtain the target polynomial share from each of the T nodes in the management node set, it specifically performs the following:

[0332] Determine the T nodes in the management node set whose polynomial share of the Kth private key is in a normal state;

[0333] Obtain the target polynomial share from each of the T nodes;

[0334] The target polynomial share is obtained by performing share conversion processing on the polynomial share of the stored Kth private key by T nodes in the management node set to obtain the additive share of the private key, and then performing sharding processing on the additive share of the private key for each node in the management node set.

[0335] In one possible implementation, when processor 501 is used to obtain the first fusion polynomial share from each of the T nodes in the (K-2)th node set, it specifically performs the following:

[0336] Send a first private key replacement request for the Kth private key to each of the T nodes in the (K-2)th node set;

[0337] Receive the first fusion polynomial shares returned by T nodes in the (K-2)th node set, and obtain T first fusion polynomial shares;

[0338] Specifically, the first private key replacement request instructs each of the T nodes in the (K-2)th node set to perform share conversion processing on the polynomial share of the stored public key to obtain the additive share of the public key, and to perform sharding processing on the first share mask parameter for the T nodes in the (K-2)th node set to obtain the additive share of the first share mask parameter, and to perform sharding processing on the first fusion result of the additive share of the public key and the additive share of the first share mask parameter for each node in the management node set to obtain the first fusion polynomial share corresponding to each node in the management node set.

[0339] In one possible implementation, when processor 501 is used to obtain the second fusion polynomial share from T nodes in the (K-1)th node set, it is specifically used for:

[0340] Send a second private key replacement request for the Kth private key to each of the T nodes in the (K-1)th node set;

[0341] Receive the second fusion polynomial shares returned by T nodes in the (K-1)th node set, and obtain T second fusion polynomial shares;

[0342] Specifically, the second private key replacement request is used to instruct each of the T nodes in the (K-1)th node set to perform share conversion processing on the polynomial share of the stored random number to obtain the additive share of the random number, and to perform sharding processing on the second share mask parameter for the T nodes in the (K-1)th node set to obtain the additive share of the second share mask parameter, and to perform sharding processing on the second fusion result of the additive share of the random number and the additive share of the second share mask parameter for each node in the management node set to obtain the second fused polynomial share corresponding to each node in the management node set.

[0343] In the several embodiments provided in this application, it should be understood that the disclosed methods, apparatus, systems, and computer devices can be implemented in other ways. The embodiments described above are merely illustrative, and the division of units is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0344] This application also provides a computer program product, which includes program instructions stored in a computer-readable storage medium. A processor of a computer device reads the program instructions from the computer-readable storage medium and executes the program instructions, causing the computer device to perform the aforementioned key management method, which will not be described in detail here.

[0345] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0346] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more program instructions. When the program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The program instructions can be stored in or transmitted through a computer-readable storage medium. The program instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates 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 disk (SSD)).

[0347] It should be noted that, in the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program with a predetermined function, which works together with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0348] It should be noted that 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 their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature specified with "first" or "second" may explicitly or implicitly include at least one of those features.

[0349] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A key management method, characterized in that, The method includes: In response to the first triggering event of the Kth private key in the L key pairs, the L node sets in the blockchain network corresponding to the L key pairs are determined; the public key and the corresponding random number shard in each key pair are stored in the corresponding node set, the Kth private key is the currently used private key, L is a positive integer greater than or equal to 3, and K is a positive integer greater than or equal to 3 and less than or equal to L; The first fusion polynomial share is obtained from T nodes in the (K-2)th node set, and the second fusion polynomial share is obtained from T nodes in the (K-1)th node set. The first fusion polynomial share is determined by the T nodes in the (K-2)th node set according to the first share mask parameter and the polynomial share of their respective stored public keys. The second fusion polynomial share is determined by the T nodes in the (K-1)th node set according to the second share mask parameter and the polynomial share of their respective stored random numbers. The second share mask parameter is the opposite of the first share mask parameter, and T is a positive integer greater than or equal to 2. Based on the obtained T first fusion polynomial shares and T second fusion polynomial shares, the polynomial share of the (K-1)th private key in the L key pairs is determined; the polynomial share of the (K-1)th private key is used to generate the (K-1)th private key, and the (K-1)th private key is configured as the currently used private key.

2. The method as described in claim 1, characterized in that, The method further includes: Based on the elliptic curve and L random numbers, generate L sets of key pairs; Determine L sets of nodes and a set of management nodes from the blockchain network; The public key and corresponding random number fragment of each of the L key pairs are stored in the corresponding node set of the L node sets, and the Lth private key fragment of the L key pairs is stored in the management node set; the Lth private key is the private key used initially.

3. The method as described in claim 2, characterized in that, The step of generating L key pairs based on the elliptic curve and L random numbers includes: For the Mth key pair, the private key in the Mth key pair is generated based on the Mth random number among the L random numbers and the target public key; the target public key is either the initial public key or the public key in the (M-1)th key pair, the initial public key is determined based on an elliptic curve, and M is any positive integer less than or equal to L; Generate the public key in the Mth key pair based on the private key in the Mth key pair and the elliptic curve; After storing the Lth private key fragment from the L key pairs into the management node set, the method further includes: Write the Lth public key from the L key pairs into the blockchain, and perform data cleanup on the elliptic curve, the L random numbers, and the L key pairs.

4. The method as described in claim 1, characterized in that, The method further includes: Obtain the polynomial share of the stored public key from each of the T nodes in the (K-1)th node set, and determine the (K-1)th public key based on the obtained polynomial shares of the T public keys; Obtain the polynomial share of the stored random number from each of the T nodes in the Kth node set, and determine the Kth random number based on the polynomial share of the obtained T random numbers; Based on the (K-1)th public key, the Kth random number, the elliptic curve, and the Kth public key, perform generational relationship verification; If the generational relationship verification is successful, then the step of obtaining the first fusion polynomial share from each of the T nodes in the (K-2)th node set is executed.

5. The method as described in claim 4, characterized in that, The generational relationship verification based on the (K-1)th public key, the Kth random number, the elliptic curve, and the Kth public key includes: Based on the (K-1)th public key, the Kth random number, the elliptic curve, and the Kth private key, perform relation verification; If the generation relationship verification passes, then the verification information of the (K-1)th public key and the verification information of the Kth random number are obtained from the blockchain; Data verification is performed based on the (K-1)th public key, the verification information of the (K-1)th public key, the Kth random number, and the verification information of the Kth random number; If the data verification passes, then the generational relationship verification is confirmed.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: In response to a second triggering event of a target node in the management node set for a polynomial share of the stored Kth private key, a target polynomial share is obtained from each of the T nodes in the management node set; the target polynomial share is determined by the T nodes in the management node set based on the polynomial share of the Kth private key they each store. Based on the obtained T target polynomial shares, determine the updated polynomial share of the Kth private key; the updated polynomial share of the Kth private key is used to generate the Kth private key.

7. The method as described in claim 6, characterized in that, The step of obtaining the target polynomial share from each of the T nodes in the management node set includes: From the set of management nodes, determine the T nodes whose polynomial share of the stored Kth private key is in a normal state; Obtain the target polynomial share from each of the T nodes; The target polynomial share is obtained by performing share conversion processing on the polynomial share of the stored Kth private key by T nodes in the management node set to obtain the additive share of the private key, and then performing sharding processing on the additive share of the private key for each node in the management node set.

8. The method according to any one of claims 1-5, characterized in that, The step of obtaining the first fusion polynomial share from each of the T nodes in the (K-2)th node set includes: Send a first private key replacement request for the Kth private key to each of the T nodes in the (K-2)th node set; Receive the first fusion polynomial shares returned by T nodes in the (K-2)th node set respectively, and obtain T first fusion polynomial shares; Specifically, the first private key replacement request is used to instruct each of the T nodes in the (K-2)th node set to perform share conversion processing on the polynomial share of the stored public key to obtain the additive share of the public key, and to perform sharding processing on the first share mask parameter for the T nodes in the (K-2)th node set to obtain the additive share of the first share mask parameter, and to perform sharding processing on the first fusion result of the additive share of the public key and the additive share of the first share mask parameter for each node in the management node set to obtain the first fused polynomial share corresponding to each node in the management node set.

9. The method according to any one of claims 1-5, characterized in that, The step of obtaining the second fusion polynomial share from each of the T nodes in the (K-1)th node set includes: Send a second private key replacement request for the Kth private key to each of the T nodes in the (K-1)th node set; Receive the second fusion polynomial shares returned by T nodes in the (K-1)th node set respectively, and obtain T second fusion polynomial shares; Specifically, the second private key replacement request is used to instruct each of the T nodes in the (K-1)th node set to perform share conversion processing on the polynomial share of the stored random number to obtain the additive share of the random number, and to perform sharding processing on the second share mask parameter for the T nodes in the (K-1)th node set to obtain the additive share of the second share mask parameter, and to perform sharding processing on the second fusion result of the additive share of the random number and the additive share of the second share mask parameter for each node in the management node set to obtain the second fused polynomial share corresponding to each node in the management node set.

10. A key management device, characterized in that, The device includes: A response unit is used to respond to a first triggering event of the Kth private key in the L key pairs and determine the L node sets in the blockchain network corresponding to the L key pairs; the public key and the corresponding random number shard in each key pair are stored in the corresponding node set, the Kth private key is the currently used private key, L is a positive integer greater than or equal to 3, and K is a positive integer greater than or equal to 3 and less than or equal to L; The acquisition unit is configured to acquire a first fusion polynomial share from T nodes in the (K-2)th node set, and a second fusion polynomial share from T nodes in the (K-1)th node set; the first fusion polynomial share is determined by the T nodes in the (K-2)th node set according to the first share mask parameter and the polynomial share of their respective stored public keys, and the second fusion polynomial share is determined by the T nodes in the (K-1)th node set according to the second share mask parameter and the polynomial share of their respective stored random numbers, wherein the second share mask parameter is the opposite of the first share mask parameter, and T is a positive integer greater than or equal to 2; The processing unit is configured to determine the polynomial share of the (K-1)th private key in the L key pairs based on the obtained T first fusion polynomial shares and T second fusion polynomial shares; the polynomial share of the (K-1)th private key is used to generate the (K-1)th private key, and the (K-1)th private key is configured as the currently used private key.

11. A computer device, characterized in that, The computer device includes: A processor is a tool for implementing computer programs. A computer-readable storage medium storing a computer program adapted to be loaded by the processor and executed as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and executed as described in any one of claims 1-9.

13. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the key management method as described in any one of claims 1-9.

Images