Distributed key generation and recovery method and system in block chain system

Abstract

The invention provides a distributed key generation and recovery method and system in a block chain system, and the method comprises the steps: carrying out the negotiation of a key seed between block chain nodes in the block chain system, and enabling each block chain node to obtain at least one seed segment; the seed fragments are backed up by participants corresponding to the corresponding block chain nodes; each block chain node injects a seed fragment maintained by the block chain node into a trusted execution environment of the block chain node and shares the seed fragment; in the trusted execution environment of each block chain node, recovering the obtained seed fragment not less than a preset threshold value into a key seed based on a key recovery protocol, deriving a service key based on the key seed, encrypting the service key by using a security key maintained by the corresponding trusted execution environment, and storing the encrypted service key; and the recovery end obtains the backup seed fragments provided by at least one part of participants, and recovers the obtained backup seed fragments not less than a preset threshold value into the key seed based on a key recovery protocol.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a distributed key generation and recovery method and system in a blockchain system. Background Art

[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. In the blockchain system, data blocks are combined into a chain data structure in a sequential manner according to time sequence, and a distributed ledger that cannot be tampered with or forged is guaranteed by cryptography. Due to the characteristics of blockchain such as decentralization, information cannot be tampered with, and autonomy, blockchain has also received more and more attention and application.

[0003] Enterprise-level blockchain systems often need to face the challenges of privacy and performance at the same time. Some common encryption technologies for solving privacy problems, such as homomorphic encryption and zero-knowledge proof, are not only highly complex and poorly versatile, but may also cause serious performance losses. Trusted Execution Environment (TEE) is an effective solution that can take into account both privacy and performance. TEE can play the role of a black box in hardware. The operating system layer cannot peek at the code and data executed in TEE. Only the pre-defined interfaces in the code can operate on it. In terms of efficiency, due to the black box nature of TEE, the calculations in TEE are plaintext data, not the complex cryptographic operations in homomorphic encryption. There is no loss in the efficiency of the calculation process. Therefore, combining with TEE can greatly improve the security and privacy of blockchain with less performance loss. Currently, the industry is paying close attention to TEE solutions. Almost all mainstream chip and software alliances have their own TEE solutions, including TPM (Trusted Platform Module) in software and Intel SGX (Software Guard Extensions), ARM Trustzone and AMD PSP (Platform Security Processor) in hardware.

[0004] For the purpose of privacy protection, each blockchain node in the blockchain system will use a unified business key to encrypt and store private data and decrypt and restore it. In order to ensure the security of the business key, each blockchain node will only use the business key in its own TEE for encryption and decryption operations, and when the business key needs to be persistently stored, each blockchain node will encrypt it with the security key maintained in the TEE and persist the encrypted business key outside the TEE.

[0005] However, if the scale of the blockchain system is not large, for example, the number of participants and their corresponding blockchain nodes in the alliance chain scenario is often limited, and the extreme situation of failure of the physical hosts corresponding to all blockchain nodes cannot be ruled out. In particular, the trusted hardware that the TEE relies on in the physical host may also fail at the same time, resulting in the TEE being unable to start normally, and the encrypted business key cannot be decrypted through the aforementioned security key, which in turn makes it impossible to use the business key to decrypt the encrypted and stored private data. Summary of the invention

[0006] In view of this, this specification provides a distributed key generation and recovery method and system in a blockchain system to address the deficiencies in the related art.

[0007] Specifically, this specification is implemented through the following technical solutions:

[0008] According to a first aspect of an embodiment of this specification, a distributed key generation and recovery method in a blockchain system is provided, including:

[0009] The blockchain nodes in the blockchain system negotiate the key seed, and each blockchain node obtains at least one seed fragment; wherein the seed fragment is also backed up by the participant corresponding to the corresponding blockchain node, and the corresponding backup seed fragment is not encrypted using the security key maintained by the trusted execution environment in each blockchain node;

[0010] Each blockchain node injects the seed fragment maintained by itself into its own trusted execution environment, and shares the seed fragment based on its own trusted execution environment; and, in its own trusted execution environment, each blockchain node: based on the key recovery protocol, recovers the obtained seed fragment of not less than a preset threshold into the key seed, derives the business key based on the key seed, and encrypts and stores the business key using the security key maintained by the corresponding trusted execution environment; wherein the business key is used to encrypt the privacy data at the corresponding blockchain node;

[0011] The recovery end obtains backup seed fragments provided by at least some of the participants, and based on the key recovery protocol, recovers the obtained backup seed fragments that are not less than the preset threshold as the key seed, and the recovered key seed is used to further derive the business key.

[0012] According to a second aspect of an embodiment of this specification, a distributed key generation method in a blockchain system is provided, which is applied to a first blockchain node in the blockchain system; the method includes:

[0013] Negotiating the key seed with other blockchain nodes in the blockchain system, and each blockchain node obtains at least one seed fragment; wherein the seed fragment is also backed up by the participant corresponding to the corresponding blockchain node, and the corresponding backup seed fragment is not encrypted using the security key maintained by the trusted execution environment in each blockchain node;

[0014] Injecting the seed fragment maintained by itself into the first trusted execution environment in the first blockchain node, and sharing the seed fragment with other trusted execution environments at the other blockchain nodes based on the first trusted execution environment;

[0015] In the first trusted execution environment: based on the key recovery protocol, the obtained seed fragments that are not less than the preset threshold are restored to the key seed, the business key is derived based on the key seed, and the business key is encrypted and stored using the security key maintained by the corresponding trusted execution environment; wherein the business key is used to encrypt the private data at the corresponding blockchain node.

[0016] According to a third aspect of the embodiments of this specification, a system for implementing distributed key generation and recovery includes: a recovery end and each blockchain node in a blockchain system; wherein,

[0017] Each blockchain node is used to: negotiate the key seed with each other, and each blockchain node obtains at least one seed fragment; respectively injects the seed fragment maintained by itself into its own trusted execution environment, and shares the seed fragment based on its own trusted execution environment; and each blockchain node, in its own trusted execution environment: based on the key recovery protocol, recovers the obtained seed fragment of not less than a preset threshold into the key seed, derives the business key based on the key seed, and encrypts and stores the business key using the security key maintained by the corresponding trusted execution environment; wherein the business key is used to encrypt the privacy data at the corresponding blockchain node;

[0018] The recovery end is used to obtain backup seed fragments provided by at least some of the participants, and based on the key recovery protocol, restore the obtained backup seed fragments that are not less than the preset threshold into the key seed, and the restored key seed is used to further derive the business key.

[0019] According to a fourth aspect of an embodiment of this specification, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps of the method described in the first aspect and / or the second aspect are implemented.

[0020] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the steps of the method described in the first aspect and / or the second aspect are implemented.

[0021] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method described in the first aspect and / or the second aspect.

[0022] In the technical solution provided in this specification, since each blockchain node only obtains part of the seed fragment, a single (or a few) blockchain nodes or their participants cannot restore the complete key seed based on it, which can ensure the security of business keys and private data. At the same time, by sharing the seed fragments based on TEE by each blockchain node, it can ensure that each blockchain node can restore the complete key seed in its own TEE, and can also ensure the security of the shared seed fragments and the restored key seed.

[0023] Since the participants back up the seed fragments they have separately, and the backup seed fragments will not be encrypted with the security key in the TEE, even if all the physical hosts where the blockchain nodes are located fail, they can still use enough backup seed fragments to restore the complete key seed, and then derive the business key to decrypt and restore the encrypted and stored private data. Therefore, during normal operation, each blockchain node can still use the security key maintained by the TEE to encrypt the business key without worrying that the encrypted business key cannot be restored and affects the decryption of private data. It can be seen that the independent backup and recovery of seed fragments can ensure the high availability of business keys, and the encryption and persistence of business keys can take into account the security of the business keys. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 It is a flowchart of a distributed key generation and recovery method in a blockchain system shown in an exemplary embodiment of this specification;

[0025] Figure 2 is a schematic diagram of generating and storing a service key according to an exemplary embodiment of this specification;

[0026] Figure 3 is a schematic diagram of a secure recovery key seed shown in an exemplary embodiment of this specification;

[0027] Figure 4 is a schematic diagram of another secure recovery key seed shown in an exemplary embodiment of this specification;

[0028] Figure 5 It is a flowchart of a distributed key generation method in a blockchain system shown in an exemplary embodiment of this specification;

[0029] Figure 6 is a schematic diagram of the structure of an electronic device shown in an exemplary embodiment of this specification;

[0030] Figure 7 It is a structural schematic diagram of a distributed key generation device in a blockchain system shown in an exemplary embodiment of this specification. DETAILED DESCRIPTION

[0031] Distributed consistency is one of the core features of blockchain technology. It requires that operations and data be consistent between blockchain nodes within the blockchain system, so that even if a few nodes are malicious or fail, the overall security of the blockchain system can still be ensured, and the robustness of the blockchain system can be enhanced. Therefore, when it comes to the keys used by blockchain nodes, it is necessary to ensure that the same keys are used between blockchain nodes. For example, for privacy protection scenarios, each blockchain node can use a unified business key to encrypt the same private data to ensure that the encrypted private data obtained by each blockchain node is also consistent. At the same time, for the encrypted private data stored, it is also necessary to ensure that it can be successfully decrypted and restored when needed to maintain business continuity.

[0032] Based on this, this specification proposes a distributed key generation and recovery scheme suitable for blockchain systems, which is introduced in detail below with reference to the accompanying drawings.

[0033] Figure 1 This is a flowchart of a distributed key generation and recovery method in a blockchain system shown in an exemplary embodiment of this specification. Figure 1 As shown, the method may include the following steps:

[0034] In step 102, the blockchain nodes in the blockchain system negotiate the key seed, and each blockchain node obtains at least one seed fragment; wherein the seed fragment is also backed up by the participant corresponding to the corresponding blockchain node, and the corresponding backup seed fragment is not encrypted using the security key maintained by the trusted execution environment in each blockchain node.

[0035] For each blockchain node in the blockchain system, it can be understood that by running a blockchain client program on a physical host, it can be jointly implemented as a blockchain node based on the physical hardware of the physical host and the software logic of the blockchain client program.

[0036] The blockchain client program may include seed negotiation logic. In the blockchain system establishment phase, that is, when each physical host runs the blockchain client program to form each blockchain node and establish the blockchain system, each blockchain node can negotiate the key seed by executing the seed negotiation logic contained in the blockchain client program.

[0037] Of course, after the blockchain system has been established, for example, at any time when the blockchain system is running, the negotiation of the key seed can also be temporarily realized. For example, a smart contract containing seed negotiation logic in the blockchain system can be called to realize the negotiation of the key seed by running the seed negotiation logic. Among them, the smart contract can be a precompiled contract (Precompiled Contracts) pre-integrated in the blockchain client program, or it can be an ordinary smart contract deployed through blockchain transactions; similarly, the situations of other smart contracts mentioned in this specification are similar, and will not be repeated one by one in the following.

[0038] For the negotiation process of the key seed, any negotiation algorithm in the relevant technology can be used between the blockchain nodes, as long as it can ensure that the negotiation process can be carried out in secret and ultimately ensure that each blockchain node can and can only obtain part of the seed fragment. For example, the adopted negotiation algorithm may include the SSS (Shamir's Secret Sharing) algorithm, which is usually applicable to static scenarios where the set of participants is fixed. For example, in the alliance chain scenario, the participants of the blockchain system and their blockchain nodes are usually unchanged, and the SSS algorithm can be applied. For another example, the adopted negotiation algorithm may include the DKG (Distributed Key Generation) algorithm, which can be applicable to dynamic scenarios where the set of participants changes. For example, in the alliance chain scenario, sometimes some participants of the blockchain system may change, such as new members joining or old members leaving, and these changes can be dealt with by the DKG algorithm. In particular, if new participants need to be added, the DKG algorithm can allow the new participants to obtain sufficient information from the original participants through a secure interaction process to calculate their own seed fragments. If the original participants need to be removed, the DKG algorithm can realize the renegotiation of the key seed. Of course, even for the SSS algorithm, if there are changes in the participants, the seed fragments held by the participants can be updated through renegotiation.

[0039] For example Figure 2 As shown, it is assumed that there are a first blockchain node, a second blockchain node, a third blockchain node, and more blockchain nodes not shown in the blockchain system. Each blockchain node, such as the first blockchain node, the second blockchain node, and the third blockchain node, can jointly negotiate the key seed seed by running the above-mentioned seed negotiation logic. Assume that after the negotiation is completed, the first blockchain node obtains the seed fragment seed1, the second blockchain node obtains the seed fragment seed2, the third blockchain node obtains the seed fragment seed3, and other blockchain nodes also obtain corresponding seed fragments accordingly. Of course, the seed fragments that can be obtained by the same blockchain node can be one or more, and this specification does not limit this.

[0040] Based on the adopted seed negotiation logic, these seed fragments must satisfy: if the number of seed fragments obtained is not less than the preset threshold t, then the complete key seed seed can be restored based on these seed fragments; if the number of seed fragments obtained is less than the preset threshold t, it cannot be restored. Among them, assuming that the total number of seed fragments is n, the value of the preset threshold t satisfies 0<t<n, and t and n are both positive integers. Based on the determined value n, the seed negotiation logic can determine an appropriate value for the preset threshold t by itself; or, in some cases, the participants can also specify the required value for the preset threshold t by themselves, and this specification does not limit this. For example, assuming that the value of n is 8, the value of the preset threshold t can be, for example, 6. Combined with Figure 2 , which means that there are 8 blockchain nodes in the blockchain system. Assuming that each blockchain node maintains a seed fragment, the key seed can be fully recovered with the consent of at least 6 blockchain nodes.

[0041] The negotiated seed fragments are not only held by each blockchain node and used to restore the complete key seed and derive the business key, but are also backed up by the participants corresponding to the corresponding blockchain node. Figure 2 For example, assume that the first blockchain node corresponds to participant A. After the first blockchain node participates in the negotiation and obtains the seed fragment seed1, participant A can obtain the seed fragment seed1 from the first blockchain node and back up the seed fragment seed1 outside the first blockchain node. The backup seed fragment can be called a backup seed fragment. The backup seed fragment corresponding to the seed fragment seed1 can be stored by the participant in a storage space "backup-1". The backup-1 can be located in a non-volatile memory (such as a hard disk, etc.) in the physical host where the first blockchain node is located; or, in order to prevent a major accident in the physical host where the first blockchain node is located, causing its non-volatile memory to fail, the backup-1 can be outside the physical host where the first blockchain node is located to improve security, such as a mobile non-volatile memory (such as a mobile flash memory, a mobile hard disk, etc.) held by participant A, or a cloud storage space managed by participant A, etc. This specification does not limit this. Similarly, the seed fragment seed2 obtained by negotiation at the second blockchain node can be backed up by the corresponding participant B in a storage space "Backup-2", and the seed fragment seed3 obtained by negotiation at the third blockchain node can be backed up by the corresponding participant C in a storage space "Backup-3", and so on. They are not listed one by one here.

[0042] When storing backup seed fragments, in order to improve data security and reduce the probability of secret leakage, each participant can encrypt and store the corresponding backup seed fragments. However, it should be pointed out that the corresponding backup seed fragments are not encrypted using the security keys maintained by the trusted execution environment in each blockchain node. Then, even if all the physical hosts where the blockchain nodes are located fail, resulting in the TEEs in each blockchain node being unable to operate normally and unable to use the security keys maintained in each TEE normally, it will not affect the decryption and use of the corresponding backup seed fragments by each participant, ensuring that these backup seed fragments can restore the complete key seed. On this basis, the business key can be derived based on the key seed, so as to decrypt and restore the private data encrypted based on the business key. This process is no longer limited by whether the TEE in each blockchain node can operate normally. Therefore, there is no need to worry about the business data being unable to be decrypted and restored in extreme cases. You can safely use the business key to encrypt the business data, and encrypt the business key with the security key maintained in the TEE.

[0043] In step 104, each blockchain node injects the seed fragment maintained by itself into its own trusted execution environment, and shares the seed fragment based on its own trusted execution environment; and each blockchain node, in its own trusted execution environment: based on the key recovery protocol, recovers the obtained seed fragment that is not less than a preset threshold as the key seed, derives the business key based on the key seed, and encrypts and stores the business key using the security key maintained by the corresponding trusted execution environment; wherein the business key is used to encrypt the privacy data at the corresponding blockchain node.

[0044] In the technical solution of this specification, the TEE in each blockchain node can be implemented based on any type of TEE technology in the relevant technology, including but not limited to the various TEE technologies listed above, and this specification does not limit this. However, for ease of understanding, the following will take Intel SGX technology as an example to introduce the TEE involved in this specification.

[0045] Taking Intel SGX technology as an example, SGX provides an enclave (also called an enclave), which is an encrypted trusted execution area in memory, where the CPU protects data from being stolen. As mentioned above, by running a blockchain client program on a physical host, a blockchain node can be jointly implemented based on the physical hardware of the physical host and the software logic of the blockchain client program. In the technical solution of this specification, the physical host should use a CPU that supports Intel SGX technology, and use the newly added processor instructions to allocate a part of the area EPC (Enclave Page Cache, enclave page cache or enclave page cache) in the memory, and encrypt the data therein through the encryption engine MEE (Memory Encryption Engine) in the CPU. The encrypted content in EPC will only be decrypted into plaintext after entering the CPU. Therefore, in SGX, users can distrust the operating system, VMM (Virtual Machine Monitor), and even BIOS (Basic Input Output System), and only need to trust the CPU to ensure that private data will not be leaked.

[0046] The blockchain client program of a blockchain node can be divided into two parts at the code level: non-enclave code and enclave code. Among them, the non-enclave code runs outside the enclave and is not protected by the hardware level provided by SGX, while the enclave code runs in the enclave and is protected by the hardware level provided by SGX. Therefore, when this specification involves performing an operation or implementing a function in a TEE in a blockchain node, the TEE can be understood as the enclave where the enclave code in the blockchain client program of the blockchain node is located on the physical host where the blockchain node is located, and the operation performed in the TEE is to execute the enclave code in the enclave, and to implement a function in the TEE is to implement the function by executing the enclave code in the enclave.

[0047] For example Figure 2As shown, the first blockchain node needs to negotiate the key seed seed with the second blockchain node, the third blockchain node, etc. and obtain the seed fragment seed1. The seed fragment seed1 needs to be injected into the first TEE from the outside, and the seed fragment is shared with the second TEE in the second blockchain node, the third TEE in the third blockchain node, etc. in the first TEE, and then the complete key seed seed is restored in the first TEE based on the various sub-fragments obtained by sharing, and the business key is derived based on the key seed seed, and the business key is encrypted by the first security key. Among them, the first blockchain node specifically negotiates and obtains the seed fragment seed1 by executing the non-enclave code, and injects the seed fragment seed1 into the first TEE. And, the first blockchain node specifically shares the seed fragment, recovers the key seed seed, derives the business key, and encrypts the business key with the first security key by executing the enclave code. The situation of other blockchain nodes such as the second blockchain node and the third blockchain node is similar, and will not be repeated here.

[0048] A security key refers to a key maintained in the TEE. Since it is maintained in the TEE, the security of the key can be ensured as long as the TEE is not compromised, so it is called a security key. For example, Figure 2 The security key maintained in the first TEE is marked as the first security key, the security key maintained in the second TEE is marked as the second security key, and the security key maintained in the third TEE is marked as the third security key, so as to distinguish it from the security keys maintained in other TEEs (located in other blockchain nodes). Since the security key is extremely secure, any subject outside the TEE, or even the blockchain node to which the TEE belongs, cannot know the security key. Therefore, encrypting the business key with the security key and storing it can ensure the security of the business key itself and the security of the business data encrypted with the business key.

[0049] The security keys in this specification can be bound to the trusted hardware on which they rely to achieve sufficient security. For example, the security key maintained by any TEE can be: a trusted root key built into the trusted hardware on which any TEE relies. For example, based on SGX technology, the trusted root key can be an RSK (Root Seal Key or RootSealing Key) preset in the trusted hardware, which is securely burned in during the production process of the trusted hardware. For another example, the security key maintained by any TEE can be: a trusted derived key derived for any TEE based on the above-mentioned trusted root key. For example, based on SGX technology, a trusted derived key can be a key derived for any TEE based on RSK, for example, the trusted derived key can specifically be a Seal Key (or Sealing Key). In addition, the security key can also be other keys defined in SGX technology, or keys defined in other TEE technologies, and this specification does not limit this.

[0050] Each blockchain node can share seed fragments based on its own trusted execution environment. The sharing process involves each blockchain node sending its own seed fragments to other blockchain nodes, and receiving seed fragments from other blockchain nodes. Figure 2 For example, the first blockchain node sends the seed fragment seed1 from the first TEE to the second TEE, the third TEE, etc., and the first blockchain node receives the seed fragment seed2 from the second TEE, the seed fragment seed3 from the third TEE, etc. in the first TEE.

[0051] For the transmission of seed fragments between TEEs, various technical means in the relevant technology can be used to ensure the security of transmission, that is, to achieve secure transmission between TEEs. For example, each blockchain node can encrypt the seed fragments maintained by itself in its own TEE, and then transmit the encrypted seed fragments to each other. Specifically, each blockchain node outputs the encrypted seed fragments from its own TEE, and then transmits them to the TEEs in other blockchain nodes; and each blockchain node decrypts the encrypted seed fragments from other blockchain nodes in its own TEE. By encrypting the seed fragments, the TEE of each blockchain node only needs to maintain the corresponding decryption key to ensure that the encrypted seed fragment cannot be correctly decrypted even if it is leaked during the transmission process. Moreover, since the encryption and decryption processes are all implemented in the TEE, that is, the corresponding keys are maintained by the TEE, it can be further ensured that the keys will not be easily leaked. Among them, when encrypting and decrypting seed fragments, a symmetric encryption algorithm can be used, so that the key used by a blockchain node for encryption in its own TEE and the key used by other blockchain nodes for decryption in their own TEEs are the same; or, an asymmetric encryption algorithm can be used, so that a blockchain node uses a private key for encryption in its own TEE and other blockchain nodes use public keys for decryption in their own TEEs.

[0052] Take the interaction process between the first blockchain node and other blockchain nodes as an example:

[0053] In one embodiment, the first blockchain node executes a seed fragment (e.g. Figure 2 After the seed fragment seed1) shown is encrypted, it can be broadcast to all other blockchain nodes, so that each other blockchain node can decrypt the encrypted seed fragment in its own TEE respectively, and the decryption key used is the same.

[0054] In another embodiment, the first blockchain node and each other blockchain node use different encryption and decryption keys. Figure 2 As shown, taking symmetric encryption and decryption as an example, the first blockchain node can use the first secure transmission key C1 and the second secure transmission key C2 in the first TEE to encrypt the seed fragment seed1 respectively, and then send the seed fragment seed1 encrypted by the first secure transmission key C1 to the second blockchain node, and send the seed fragment seed1 encrypted by the second secure transmission key C2 to the third blockchain node. The second blockchain node decrypts the seed fragment seed1 with the first secure transmission key C1 in the second TEE, and the third blockchain node decrypts the seed fragment seed1 with the second secure transmission key C2 in the third TEE. The situation of using asymmetric encryption and decryption is similar and will not be repeated here.

[0055] Regarding the above-mentioned situation of using different encryption and decryption keys, the specific secure transmission key used can be obtained in combination with remote authentication. In SGX technology, TEEs on different hosts can verify each other through remote authentication to determine the identity and integrity of the other party's TEE, thereby determining whether the other party's TEE is trustworthy. For the process of remote authentication, please refer to the description in the relevant technology, which will not be repeated here. The first TEE of the first blockchain node can perform remote authentication with each other TEE in each other blockchain node respectively; wherein, after the first TEE and any TEE complete remote authentication with each other, the two can negotiate a secure transmission key for secure transmission between the first TEE and any TEE. The two TEEs can negotiate through, for example, a key exchange protocol to determine the above-mentioned secure transmission key. The key exchange protocol may include, for example, DH (Diffie-Hellman), ECDH (Elliptic Curve Diffie-Hellman), TLS (Transport Layer Security), etc., and this specification does not limit this.

[0056] Accordingly, the first blockchain node can determine the secure transmission key negotiated by the first TEE after successful remote authentication with the TEE in each other blockchain node; and use the determined secure transmission keys to encrypt the seed fragments maintained by itself. Figure 2 In the example, if the first blockchain node determines that the first TEE and the second TEE have negotiated a first secure transmission key C1, and the first TEE and the third TEE have negotiated a second secure transmission key C2, the first secure transmission key C1 and the second secure transmission key C2 can be used in the first TEE to encrypt the seed fragment seed1. Then, the first blockchain node can output each encrypted seed fragment from the first TEE, and transmit each encrypted seed fragment to the corresponding TEE in other blockchain nodes according to the secure transmission key used by each encrypted seed fragment and the corresponding relationship between each secure transmission key and TEE. Figure 2For example, the first blockchain node has learned the correspondence between the first secure transmission key C1 and the second TEE, and the correspondence between the second secure transmission key C2 and the third TEE, so it will use the first secure transmission key C1 to encrypt the seed fragment seed1 to generate the encrypted seed fragment seed1-C1 to send to the second TEE, and use the second secure transmission key C2 to encrypt the seed fragment seed1 to generate the encrypted seed fragment seed1-C2 to send to the third TEE. Of course, here the second blockchain node will specifically receive the encrypted seed fragment seed1-C1 and inject it into the second TEE, and then use the first secure transmission key C1 to decrypt in the second TEE to obtain the seed fragment seed1; similarly, the third blockchain node will receive the encrypted seed fragment seed1-C2 and inject it into the third TEE, and then use the second secure transmission key C2 to decrypt in the third TEE to obtain the seed fragment seed1.

[0057] Of course, the secure transmission key negotiated between TEEs may also be an asymmetric key. Then, taking the first TEE and the second TEE as an example, assuming that the two negotiate a set of public-private key pairs, in which the first TEE maintains the public key and the second TEE maintains the private key, then the first TEE will use the public key to encrypt the seed fragment seed1, and the second TEE will use the corresponding private key to decrypt to obtain the seed fragment seed1. The situation between other TEEs is similar and will not be repeated here.

[0058] The above actually describes the decryption to obtain the seed fragment seed1 shared by the first blockchain node from the perspective of the second blockchain node and the third blockchain node. Similarly, the first blockchain node can decrypt the encrypted seed fragment from the second blockchain node based on the secure transmission key negotiated between the first TEE and the second TEE in the second blockchain node when receiving the encrypted seed fragment from the second blockchain node. For example, the second blockchain node uses the first secure transmission key C1 negotiated between itself and the first blockchain node to encrypt the seed fragment seed2 to generate the encrypted seed fragment seed2-C1, and sends it to the first blockchain node; accordingly, the first blockchain node injects the encrypted seed fragment seed2-C1 into the first TEE, and decrypts it in the first TEE to obtain the seed fragment seed2. Then, the first blockchain node and the second blockchain node complete the mutual sharing of the seed fragment seed1 and the seed fragment seed2 based on the above process. Other blockchain nodes can also share the seed fragments they maintain through a similar process. Of course, even if some blockchain nodes do not participate in the sharing process, or a blockchain node holding multiple seed fragments only shares some of the seed fragments, or some seed fragments fail to be successfully shared due to network reasons, as long as the number of seed fragments obtained by each blockchain node is not less than the preset threshold, the complete key seed can be restored.

[0059] Based on the recovered key seed, each blockchain node can use the key seed to derive the business key in the TEE. The business key can be directly derived from the key seed through a key derivation algorithm (or key derivation function, i.e., KeyDerivation Function, KDF for short). As time goes by, the security of the same key will gradually decrease during use. Therefore, in order to ensure the security of private data and to avoid repeating the processes of negotiating key seeds and sharing seed fragments as described above, the business root key can be first derived from the key seed, and then the business key can be further derived based on the business root key. Since each blockchain node maintains a consistent business root key in its own TEE, the same business key can be obtained after derivation based on the same key derivation algorithm.

[0060] The above-mentioned business keys may include symmetric keys, asymmetric keys, or both. Symmetric keys use the same key for encryption and decryption, and have the characteristics of relatively simple algorithms and high encryption and decryption efficiency. Asymmetric keys use a pair of keys, namely a public key and a private key. The public key can be made public, while the private key must be kept confidential.

[0061] This specification does not limit the key derivation algorithm used when deriving the business key from the key seed, deriving the business root key from the key seed, and deriving the business key from the business root key. For example, the key derivation algorithm may include HKDF (HMAC-based Extract-and-Expand Key Derivation Function), PBKDF2 (Password-Based Key Derivation Function 2), bcrypt, scrypt, Argon2, SHA-based KDF (such as SHA-256KDF), etc., which are not listed here one by one. Among them, the key derivation algorithm used when deriving the business key from the key seed, deriving the business root key from the key seed, and deriving the business key from the business root key can be the same key derivation algorithm, or different key derivation algorithms can be used respectively, and this specification does not limit this.

[0062] The above-mentioned private data may include any data maintained at the blockchain node. For example, the block data maintained by the blockchain node (i.e., each block in the blockchain). Among them, the business key can be used to encrypt the entire block, and the business key can also be used to encrypt the private transactions contained in each block (i.e., blockchain transactions that require privacy protection) without encrypting ordinary transactions (i.e., blockchain transactions that do not require privacy protection). For another example, the state data and receipt data maintained by the blockchain node can also be encrypted to achieve privacy protection.

[0063] In one embodiment, the blockchain nodes participating in the technical solution of this specification, namely the aforementioned "blockchain nodes in the blockchain system", can be all blockchain nodes constituting the blockchain system. The above-mentioned privacy data needs to be maintained on all blockchain nodes in the blockchain system, so it is necessary to obtain the above-mentioned key seed based on the technical solution of this specification and derive a unified business key.

[0064] In another embodiment, the above-mentioned blockchain nodes may be only a part of the blockchain nodes in the blockchain system. The part of the blockchain nodes needs to maintain the above-mentioned privacy data, while the remaining part of the blockchain nodes does not need to maintain the above-mentioned privacy data, so only the part of the blockchain nodes needs to obtain the above-mentioned key seed and derive a unified business key based on the technical solution of this specification.

[0065] For example, some of the blockchain nodes may be full nodes in the blockchain system, and the privacy data may be data in the blockchain that the full nodes need to maintain, such as blocks or transactions, while another part of the blockchain nodes may be light nodes in the blockchain system, which only need to maintain the block header but not the complete block data, so they may not need to maintain privacy data.

[0066] For another example, there are multiple types of roles in the blockchain nodes in the blockchain system. Some of the blockchain nodes belong to a certain role in the blockchain system and need to maintain the above-mentioned private data, while the remaining blockchain nodes belong to other roles and do not need to maintain the private data. Specifically, for example, in the Hyperledger Fabric blockchain, there are roles such as PeerNode, Orderer Node, Membership Service Node, Client Node, and Endorser Node. If the private data is a blockchain transaction, then since the blockchain transaction is only maintained on the blockchain nodes of the Peer Node type, the above-mentioned blockchain nodes can only include blockchain nodes of the Peer Node type, and do not include blockchain nodes of other types.

[0067] Step 106, the recovery end obtains the backup seed fragments provided by at least some of the participants, and based on the key recovery protocol, recovers the backup seed fragments obtained that are not less than the preset threshold as the key seed, and the recovered key seed is used to further derive the business key.

[0068] As mentioned above, all blockchain nodes in the blockchain system may all become abnormal under extreme circumstances, causing the TEEs in all blockchain nodes to fail to operate normally. For example, the trusted hardware that the TEEs in each blockchain node rely on may be damaged. For another example, although no substantial damage has occurred, the physical hosts where the blockchain nodes are located may not work properly due to, for example, abnormal power supply, which also makes the corresponding TEEs unable to operate normally for at least a period of time. In response to the above situation, this specification can effectively recover the key seed through the recovery end, and the key seed can be further used to derive the business key, so that the private data encrypted with the business key can be decrypted and restored without the help of TEE, ensuring that the business that needs to use these private data can run smoothly.

[0069] It is understandable that, since the recovery end needs to obtain backup seed fragments of no less than a preset threshold when recovering the key seed, and these backup seed fragments are maintained by the corresponding participants, it is equivalent to the recovery end obtaining the approval of these participants before being able to recover the key seed, that is, the recovery operation of the key seed is based on the approval of multiple corresponding participants. Therefore, even if it is separated from the blockchain system, it still essentially meets the requirements of distributed consensus and does not undermine the security of the business keys originally maintained in the blockchain system.

[0070] The recovery end can be an end that is independent of the blockchain system and can be used to recover the key seed. The recovery end can be understood as a combination of hardware and software: the recovery end is formed by running the software logic based on the technical solution of this specification on the basis of hardware such as that provided by a physical host. More specifically, whether it is the recovery end here or the aforementioned blockchain node, in addition to being implemented by both software and hardware, if the hardware used is a programmable logic device such as FPGA (Field Programmable Gate Array), then the software logic can be burned into the hardware, thereby improving its operating efficiency.

[0071] The recovery end can be an independent end, which can obtain the backup seed fragments provided by each participant off-chain, and restore the obtained backup seed fragments in sufficient quantity into a complete key seed by running the key recovery protocol consistent with step 104. For example, each participant can go to the location of the recovery end, and manually import the backup seed fragments (such as those recorded in the mobile storage device used by the participant) into the recovery end. For another example, if a participant stores the backup seed fragments in the cloud, the participant can grant the recovery end access to the backup seed fragments, so that the recovery end can actively obtain the corresponding backup seed fragments from the cloud without the need for the participant to go to the location of the recovery end, and the recovery end can also obtain the backup seed fragments as soon as possible. Figure 3 As shown, Figure 2Taking the participants AC in as an example, the participant A can provide the seed fragment seed1 stored in the storage space "Backup-1" to the recovery end, the participant B can provide the seed fragment seed2 stored in the storage space "Backup-2" to the recovery end, and the participant C can provide the seed fragment seed3 stored in the storage space "Backup-3" to the recovery end. The seed fragments seed1-3 can be carried by the corresponding participants to the local recovery end and injected into the recovery end based on the method described above, or remotely transmitted to the recovery end from, for example, the cloud. The transmission methods of the corresponding backup seed fragments of each participant do not affect each other, and can be the same or different. After obtaining the seed fragments 1-3, the recovery end can restore them to the complete key seed seed based on the key recovery protocol.

[0072] In the event that an abnormality occurs in each blockchain node in the blockchain system, each participant can re-create a new blockchain node, and replace the original blockchain nodes that have failed in the blockchain system with each newly created blockchain node, thereby rebuilding its blockchain system. Of course, the direct participation of the participants is not required for the re-creation of blockchain nodes. For example, the corresponding backup host can be defined and configured in advance for the physical host where each original blockchain node is located, so that when each original blockchain node fails, the backup host automatically loads the blockchain client program to form a new blockchain node. Then, the recovery end can also belong to the above-mentioned newly created blockchain node. Among them, the recovery end can specifically be any one of all newly created blockchain nodes, or it can be each newly created blockchain node. For example Figure 4 As shown, participant A can create a new first blockchain node ' to replace Figure 2 Similarly, participant B can create a new second blockchain node 'to replace Figure 2 The second blockchain node shown in FIG. 1 is a node of the blockchain shown in FIG. 1 , and the participant C can create a third blockchain node ' to replace the node of the blockchain shown in FIG. Figure 2 The third blockchain node shown. Then, participant A can provide the seed fragment seed1 stored in the storage space "Backup-1" to the first blockchain node ', participant B can provide the seed fragment seed2 stored in the storage space "Backup-2" to the second blockchain node ', and participant C can provide the seed fragment seed3 stored in the storage space "Backup-3" to the third blockchain node '. The newly created blockchain nodes can share seed fragments with each other in the manner described above, so that each newly created blockchain node can obtain a sufficient number of seed fragments respectively, and then restore them to a complete key seed seed based on the key recovery protocol.

[0073] To improve security, the recovery end can include its own TEE. Accordingly, the recovery end can inject the encrypted backup seed fragments provided by at least some of the above-mentioned participants into its own TEE and decrypt them in the TEE; and the recovery end can restore the decrypted backup seed fragments to the key seed in the TEE based on the key recovery protocol. As mentioned above, by restoring the key seed in the TEE, it can be ensured that the key seed only exists in the TEE, avoiding leakage at the recovery end. For example, in Figure 3 and Figure 4 In the embodiments shown, the following examples are listed in the recovery end ( Figure 4 Specifically, the first blockchain node', the second blockchain node' and the third blockchain node') can contain TEE ( Figure 3 The middle is the recovery end TEE, Figure 4 In the example, the first TEE', the second TEE' and the third TEE' are configured, and operations such as key seed recovery are implemented within the TEE.

[0074] The recovery end can recover the key seed based only on the backup seed fragment, and then other entities can further derive the business key based on the key seed. Of course, in this process, it is necessary to ensure that the key seed is securely provided from the recovery end to other entities, and that other entities further derive the key seed into the business key securely, and decrypt the encrypted private data at any blockchain node based on the business key.

[0075] More simply but reliably, the recovery end can recover the key seed based on the backup seed fragment, and then derive the business key based on the key seed, and the recovery end can further use the business key to decrypt the encrypted private data at any blockchain node. In this way, it can be ensured that the key seed, business key, etc. only exist on the recovery end, reducing the risk of leakage. In particular, in combination with the above, if the recovery end includes a TEE, after the backup seed fragments are injected into the TEE, it can be ensured that a series of operations such as deriving the key seed based on the backup seed fragment, deriving the business key based on the key seed, and decrypting the encrypted private data based on the business key (the encrypted private data needs to be injected into the TEE) are all performed within the TEE, making the entire process safe and reliable.

[0076] Figure 5 This is a flow chart of a distributed key generation method in a blockchain system shown in an exemplary embodiment of this specification. Figure 5 As shown, the method is applied to the first blockchain node in the blockchain system; the method may include the following steps:

[0077] Step 502, negotiate the key seed with other blockchain nodes in the blockchain system, and each blockchain node obtains at least one seed fragment; wherein the seed fragment is also backed up by the participant corresponding to the corresponding blockchain node, and the corresponding backup seed fragment is not encrypted using the security key maintained by the trusted execution environment in each blockchain node.

[0078] Step 504: inject the seed fragment maintained by itself into the first trusted execution environment in the first blockchain node, and share the seed fragment with other trusted execution environments at the other blockchain nodes based on the first trusted execution environment.

[0079] Step 506, in the first trusted execution environment: based on the key recovery protocol, the obtained seed fragments that are not less than the preset threshold are restored as the key seed, the business key is derived based on the key seed, and the business key is encrypted and stored using the security key maintained by the corresponding trusted execution environment; wherein the business key is used to encrypt the privacy data at the corresponding blockchain node.

[0080] Optionally, security keys maintained by any trusted execution environment include:

[0081] A trusted root key built into the trusted hardware that any trusted execution environment relies on; or

[0082] A trusted derived key derived for any trusted execution environment based on the trusted root key.

[0083] Optionally, the sharing of the seed fragment based on the first trusted execution environment and other trusted execution environments at other blockchain nodes includes:

[0084] In the first trusted execution environment, encrypting the seed fragment maintained by the first blockchain node;

[0085] Outputting the encrypted seed fragment from the first trusted execution environment and transmitting it to the trusted execution environments in other blockchain nodes;

[0086] In the first trusted execution environment, the encrypted seed fragments from other blockchain nodes are decrypted.

[0087] Optionally, encrypting the seed fragments maintained by the first blockchain node in the first trusted execution environment includes: determining the secure transmission keys negotiated after the first trusted execution environment successfully performs remote authentication with the trusted execution environments in each other blockchain node; and encrypting the seed fragments maintained by itself using the determined secure transmission keys;

[0088] The step of outputting the encrypted seed fragments from the first trusted execution environment and then transmitting them to the trusted execution environments in other blockchain nodes comprises: outputting each encrypted seed fragment from the first trusted execution environment, and transmitting each encrypted seed fragment to the corresponding trusted execution environment in the other blockchain node according to the secure transmission key used by each encrypted seed fragment and the corresponding relationship between each secure transmission key and the trusted execution environment;

[0089] The method of decrypting the encrypted seed fragments from other blockchain nodes in the first trusted execution environment includes: upon receiving the encrypted seed fragments from the second blockchain node, decrypting the encrypted seed fragments from the second blockchain node based on the secure transmission key negotiated between the first trusted execution environment and the second trusted execution environment within the second blockchain node.

[0090] It should be noted that: Figure 1 The embodiment shown describes the technical solution of this specification based on the execution actions of each blockchain node and the recovery end. Figure 3 The embodiment shown describes the technical solution of this specification from the perspective of the first blockchain node, which can be any of the aforementioned blockchain nodes. Figure 3 The embodiment shown and Figure 1 The embodiments shown are closely related in terms of technical solutions, and their contents can all be referred to in the previous Figure 1 The description of the illustrated embodiment will not be repeated here.

[0091] This specification also provides a system for implementing distributed key generation and recovery, including: a recovery end and each blockchain node in a blockchain system; wherein,

[0092] Each blockchain node is used to: negotiate the key seed with each other, and each blockchain node obtains at least one seed fragment; respectively injects the seed fragment maintained by itself into its own trusted execution environment, and shares the seed fragment based on its own trusted execution environment; and each blockchain node, in its own trusted execution environment: based on the key recovery protocol, recovers the obtained seed fragment of not less than a preset threshold into the key seed, derives the business key based on the key seed, and encrypts and stores the business key using the security key maintained by the corresponding trusted execution environment; wherein the business key is used to encrypt the privacy data at the corresponding blockchain node;

[0093] The recovery end is used to obtain backup seed fragments provided by at least some of the participants, and based on the key recovery protocol, restore the obtained backup seed fragments that are not less than the preset threshold into the key seed, and the restored key seed is used to further derive the business key.

[0094] Optionally, security keys maintained by any trusted execution environment include:

[0095] A trusted root key built into the trusted hardware that any trusted execution environment relies on; or

[0096] A trusted derived key derived for any trusted execution environment based on the trusted root key.

[0097] Optionally, the sharing of seed fragments based on respective trusted execution environments includes:

[0098] Each blockchain node encrypts the seed fragments it maintains in its own trusted execution environment;

[0099] Each blockchain node outputs the encrypted seed fragment from its own trusted execution environment, and then transmits it to the trusted execution environment of other blockchain nodes; and each blockchain node decrypts the encrypted seed fragment from other blockchain nodes in its own trusted execution environment.

[0100] Optional,

[0101] The first blockchain node encrypts the seed fragment maintained by itself in its first trusted execution environment, including: determining the secure transmission key negotiated after the first trusted execution environment successfully performs remote authentication with the trusted execution environment in each other blockchain node; using each determined secure transmission key to encrypt the seed fragment maintained by itself;

[0102] The first blockchain node outputs the encrypted seed fragments from the first trusted execution environment, and then transmits them to the trusted execution environments in other blockchain nodes, including: outputting each encrypted seed fragment from the first trusted execution environment, and transmitting each encrypted seed fragment to the corresponding trusted execution environment in other blockchain nodes according to the secure transmission key used by each encrypted seed fragment and the corresponding relationship between each secure transmission key and the trusted execution environment;

[0103] The first blockchain node decrypts the encrypted seed fragments from other blockchain nodes in its own first trusted execution environment, including: upon receiving the encrypted seed fragments from the second blockchain node, decrypting the encrypted seed fragments from the second blockchain node based on the secure transmission key negotiated between the first trusted execution environment and the second trusted execution environment within the second blockchain node.

[0104] Optionally, the recovery end obtains backup seed fragments provided by at least some of the participants, and based on the key recovery protocol, recovers the obtained backup seed fragments that are not less than the preset threshold as the key seed, including:

[0105] The recovery end injects the encrypted backup seed fragments provided by at least a part of the participants into its own trusted execution environment, and decrypts them in the trusted execution environment;

[0106] In the trusted execution environment, the recovery end will restore the decrypted backup seed fragment into the key seed based on the key recovery protocol.

[0107] Optionally, the recovery end belongs to a newly created blockchain node in the blockchain system; wherein each newly created blockchain node is used to replace the original blockchain nodes that have failed in the blockchain system.

[0108] Optionally, the recovery end is further used for:

[0109] deriving a service key based on the key seed;

[0110] The business key is used to decrypt the encrypted private data at any blockchain node.

[0111] It should be noted that the embodiment of the blockchain system describes the system architecture including each blockchain node and the recovery end, as well as the execution actions of each blockchain node and the recovery end. Figure 1 The embodiments shown are closely related in terms of technical solutions, and their contents can all be referred to in the previous Figure 1 The description of the illustrated embodiment will not be repeated here.

[0112] In summary, in the technical solution provided in this specification, since each blockchain node only obtains part of the seed fragment, a single (or a few) blockchain nodes or their participants cannot restore the complete key seed based on it, which can ensure the security of business keys and private data. At the same time, by sharing the seed fragments based on TEE by each blockchain node, it can ensure that each blockchain node can restore the complete key seed in its own TEE, and can also ensure the security of the shared seed fragments and the restored key seed.

[0113] Since the participants back up the seed fragments they have separately, and the backup seed fragments will not be encrypted with the security key in the TEE, even if all the physical hosts where the blockchain nodes are located fail, they can still use enough backup seed fragments to restore the complete key seed, and then derive the business key to decrypt and restore the encrypted and stored private data. Therefore, during normal operation, each blockchain node can still use the security key maintained by the TEE to encrypt the business key without worrying that the encrypted business key cannot be restored and affects the decryption of private data. It can be seen that the independent backup and recovery of seed fragments can ensure the high availability of business keys, and the encryption and persistence of business keys can take into account the security of the business keys.

[0114] Figure 6 is a schematic diagram of the structure of an electronic device in an exemplary embodiment. Figure 6 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, and may also include other required hardware. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a device for hiding the recipient's address or a device for verifying the ownership of the transaction at the logical level. Of course, in addition to the software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0115] Corresponding to the embodiment of the distributed key generation method in the aforementioned blockchain system, this specification also provides an embodiment of a distributed key generation device in the blockchain system.

[0116] Please refer to Figure 7 , the device is applied to the first blockchain node in the blockchain system; the device may include:

[0117] The key seed negotiation unit 701 negotiates the key seed with other blockchain nodes in the blockchain system, and each blockchain node obtains at least one seed fragment; wherein the seed fragment is also backed up by the participant corresponding to the corresponding blockchain node, and the corresponding backup seed fragment is not encrypted using the security key maintained by the trusted execution environment in each blockchain node;

[0118] The seed fragment sharing unit 702 injects the seed fragment maintained by itself into the first trusted execution environment in the first blockchain node, and shares the seed fragment based on the first trusted execution environment and other trusted execution environments at the other blockchain nodes;

[0119] The key derivation and maintenance unit 703, in the first trusted execution environment: based on the key recovery protocol, recovers the obtained seed fragments that are not less than a preset threshold as the key seed, derives the business key based on the key seed, and uses the security key maintained by the corresponding trusted execution environment to encrypt the business key and then store it; wherein, the business key is used to encrypt the privacy data at the corresponding blockchain node.

[0120] Optionally, security keys maintained by any trusted execution environment include:

[0121] A trusted root key built into the trusted hardware that any trusted execution environment relies on; or

[0122] A trusted derived key derived for any trusted execution environment based on the trusted root key.

[0123] Optionally, the seed segment sharing unit 702 is specifically used for:

[0124] In the first trusted execution environment, encrypting the seed fragment maintained by the first blockchain node;

[0125] Outputting the encrypted seed fragment from the first trusted execution environment and transmitting it to the trusted execution environments in other blockchain nodes;

[0126] In the first trusted execution environment, the encrypted seed fragments from other blockchain nodes are decrypted.

[0127] Optional,

[0128] The step of encrypting the seed fragment maintained by the first blockchain node in the first trusted execution environment includes: determining the secure transmission key negotiated after the first trusted execution environment successfully performs remote authentication with the trusted execution environment in each other blockchain node; and encrypting the seed fragment maintained by itself using the determined secure transmission keys;

[0129] The step of outputting the encrypted seed fragments from the first trusted execution environment and then transmitting them to the trusted execution environments in other blockchain nodes comprises: outputting each encrypted seed fragment from the first trusted execution environment, and transmitting each encrypted seed fragment to the corresponding trusted execution environment in the other blockchain node according to the secure transmission key used by each encrypted seed fragment and the corresponding relationship between each secure transmission key and the trusted execution environment;

[0130] The method of decrypting the encrypted seed fragments from other blockchain nodes in the first trusted execution environment includes: upon receiving the encrypted seed fragments from the second blockchain node, decrypting the encrypted seed fragments from the second blockchain node based on the secure transmission key negotiated between the first trusted execution environment and the second trusted execution environment within the second blockchain node.

[0131] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0132] Based on the same concept as the above method, this specification also provides an electronic device, including: a processor; a memory for storing processor executable instructions; wherein the processor implements the steps of the method described in any of the above embodiments by running the executable instructions.

[0133] Based on the same concept as the above method, this specification also provides a computer-readable storage medium on which computer instructions are stored. When the instructions are executed by a processor, the steps of the method described in any of the above embodiments are implemented.

[0134] Based on the same concept as the above method, this specification also provides a computer program product, including a computer program / instruction, which implements the steps of the method described in any of the above embodiments when executed by a processor.

Claims

1. A distributed key generation and recovery method in a blockchain system, comprising: The blockchain nodes in the blockchain system negotiate the key seed, and each blockchain node obtains at least one seed fragment; wherein the seed fragment is also backed up by the participant corresponding to the corresponding blockchain node, and the corresponding backup seed fragment is not encrypted using the security key maintained by the trusted execution environment in each blockchain node; Each blockchain node injects the seed fragment maintained by itself into its own trusted execution environment, and shares the seed fragment based on its own trusted execution environment; and, in its own trusted execution environment, each blockchain node: based on the key recovery protocol, recovers the obtained seed fragment of not less than a preset threshold into the key seed, derives the business key based on the key seed, and encrypts and stores the business key using the security key maintained by the corresponding trusted execution environment; wherein the business key is used to encrypt the privacy data at the corresponding blockchain node; The recovery end obtains backup seed fragments provided by at least some of the participants, and based on the key recovery protocol, restores the obtained backup seed fragments that are not less than the preset threshold into the key seed, and the restored key seed is used to further derive the business key.

2. According to the method of claim 1, the security key maintained by any trusted execution environment includes: A trusted root key built into the trusted hardware that any trusted execution environment relies on; or, A trusted derived key derived for any trusted execution environment based on the trusted root key.

3. The method according to claim 1, wherein the sharing of seed fragments based on respective trusted execution environments comprises: Each blockchain node encrypts the seed fragments it maintains in its own trusted execution environment; Each blockchain node outputs the encrypted seed fragment from its own trusted execution environment, and then transmits it to the trusted execution environment of other blockchain nodes; and each blockchain node decrypts the encrypted seed fragment from other blockchain nodes in its own trusted execution environment.

4. The method according to claim 3, The first blockchain node encrypts the seed fragment maintained by itself in its own first trusted execution environment, including: Determine a secure transmission key negotiated after the first trusted execution environment successfully performs remote authentication with the trusted execution environment in each other blockchain node; Using the determined secure transmission keys, encrypt the seed fragments maintained by itself respectively; The first blockchain node outputs the encrypted seed fragments from the first trusted execution environment, and then transmits them to the trusted execution environments in other blockchain nodes, including: outputting each encrypted seed fragment from the first trusted execution environment, and transmitting each encrypted seed fragment to the corresponding trusted execution environment in other blockchain nodes according to the secure transmission key used by each encrypted seed fragment and the corresponding relationship between each secure transmission key and the trusted execution environment; The first blockchain node decrypts the encrypted seed fragments from other blockchain nodes in its own first trusted execution environment, including: upon receiving the encrypted seed fragments from the second blockchain node, decrypting the encrypted seed fragments from the second blockchain node based on the secure transmission key negotiated between the first trusted execution environment and the second trusted execution environment within the second blockchain node.

5. The method according to claim 1, wherein the recovery end obtains backup seed fragments provided by at least a portion of the participants, and based on the key recovery protocol, recovers the obtained backup seed fragments that are not less than the preset threshold as the key seed, comprising: The recovery end injects the encrypted backup seed fragments provided by at least a part of the participants into its own trusted execution environment, and decrypts them in the trusted execution environment; The recovery end, in a trusted execution environment, restores the decrypted backup seed fragments into the key seed based on the key recovery protocol.

6. According to the method of claim 1, the recovery end belongs to a newly created blockchain node in the blockchain system; wherein, Each newly created blockchain node is used to replace the original blockchain nodes that have failed in the blockchain system.

7. The method according to claim 1, further comprising: The recovery end derives a service key based on the key seed; The recovery end uses the business key to decrypt the encrypted private data at any blockchain node.

8. A distributed key generation method in a blockchain system, applied to a first blockchain node in the blockchain system; the method comprising: Negotiating the key seed with other blockchain nodes in the blockchain system, and each blockchain node obtains at least one seed fragment; wherein the seed fragment is also backed up by the participant corresponding to the corresponding blockchain node, and the corresponding backup seed fragment is not encrypted using the security key maintained by the trusted execution environment in each blockchain node; Injecting the seed fragment maintained by itself into the first trusted execution environment in the first blockchain node, and sharing the seed fragment with other trusted execution environments at the other blockchain nodes based on the first trusted execution environment; In the first trusted execution environment: based on the key recovery protocol, the obtained seed fragments that are not less than the preset threshold are restored to the key seed, the business key is derived based on the key seed, and the business key is encrypted and stored using the security key maintained by the corresponding trusted execution environment; wherein the business key is used to encrypt the private data at the corresponding blockchain node.

9. The method according to claim 8, wherein the security key maintained by any trusted execution environment comprises: A trusted root key built into the trusted hardware that any trusted execution environment relies on; or, A trusted derived key derived for any trusted execution environment based on the trusted root key.

10. The method according to claim 8, wherein the sharing of the seed fragment based on the first trusted execution environment and other trusted execution environments at the other blockchain nodes comprises: In the first trusted execution environment, encrypting the seed fragment maintained by the first blockchain node; Outputting the encrypted seed fragment from the first trusted execution environment and transmitting it to the trusted execution environments in other blockchain nodes; In the first trusted execution environment, the encrypted seed fragments from other blockchain nodes are decrypted.

11. The method according to claim 10, The step of encrypting the seed fragment maintained by the first blockchain node in the first trusted execution environment includes: Determine a secure transmission key negotiated after the first trusted execution environment successfully performs remote authentication with the trusted execution environment in each other blockchain node; Using the determined secure transmission keys, encrypt the seed fragments maintained by itself respectively; The step of outputting the encrypted seed fragments from the first trusted execution environment and then transmitting them to the trusted execution environments in other blockchain nodes comprises: outputting each encrypted seed fragment from the first trusted execution environment, and transmitting each encrypted seed fragment to the corresponding trusted execution environment in the other blockchain node according to the secure transmission key used by each encrypted seed fragment and the corresponding relationship between each secure transmission key and the trusted execution environment; The method of decrypting the encrypted seed fragments from other blockchain nodes in the first trusted execution environment includes: upon receiving the encrypted seed fragments from the second blockchain node, decrypting the encrypted seed fragments from the second blockchain node based on the secure transmission key negotiated between the first trusted execution environment and the second trusted execution environment within the second blockchain node.

12. A system for implementing distributed key generation and recovery, comprising: The recovery end and each blockchain node in the blockchain system; among them, Each blockchain node is used to: negotiate the key seed with each other, and each blockchain node obtains at least one seed fragment; respectively injects the seed fragment maintained by itself into its own trusted execution environment, and shares the seed fragment based on its own trusted execution environment; and each blockchain node, in its own trusted execution environment: based on the key recovery protocol, recovers the obtained seed fragment of not less than a preset threshold into the key seed, derives the business key based on the key seed, and encrypts and stores the business key using the security key maintained by the corresponding trusted execution environment; wherein the business key is used to encrypt the privacy data at the corresponding blockchain node; The recovery end is used to obtain backup seed fragments provided by at least some of the participants, and based on the key recovery protocol, restore the obtained backup seed fragments that are not less than the preset threshold into the key seed, and the restored key seed is used to further derive the business key.

13. The system according to claim 12, wherein the security key maintained by any trusted execution environment comprises: A trusted root key built into the trusted hardware that any trusted execution environment relies on; or, A trusted derived key derived for any trusted execution environment based on the trusted root key.

14. The system according to claim 12, wherein the sharing of seed fragments based on respective trusted execution environments comprises: Each blockchain node encrypts the seed fragments it maintains in its own trusted execution environment; Each blockchain node outputs the encrypted seed fragment from its own trusted execution environment, and then transmits it to the trusted execution environment of other blockchain nodes; and each blockchain node decrypts the encrypted seed fragment from other blockchain nodes in its own trusted execution environment.

15. The system according to claim 14, The first blockchain node encrypts the seed fragment maintained by itself in its own first trusted execution environment, including: Determine a secure transmission key negotiated after the first trusted execution environment successfully performs remote authentication with the trusted execution environment in each other blockchain node; Using the determined secure transmission keys, encrypt the seed fragments maintained by itself respectively; The first blockchain node outputs the encrypted seed fragments from the first trusted execution environment, and then transmits them to the trusted execution environments in other blockchain nodes, including: outputting each encrypted seed fragment from the first trusted execution environment, and transmitting each encrypted seed fragment to the corresponding trusted execution environment in other blockchain nodes according to the secure transmission key used by each encrypted seed fragment and the corresponding relationship between each secure transmission key and the trusted execution environment; The first blockchain node decrypts the encrypted seed fragments from other blockchain nodes in its own first trusted execution environment, including: upon receiving the encrypted seed fragments from the second blockchain node, decrypting the encrypted seed fragments from the second blockchain node based on the secure transmission key negotiated between the first trusted execution environment and the second trusted execution environment within the second blockchain node.

16. The system according to claim 12, wherein the recovery end obtains backup seed fragments provided by at least a portion of the participants, and based on the key recovery protocol, recovers the obtained backup seed fragments that are not less than the preset threshold as the key seed, comprising: The recovery end injects the encrypted backup seed fragments provided by at least a part of the participants into its own trusted execution environment, and decrypts them in the trusted execution environment; The recovery end, in a trusted execution environment, restores the decrypted backup seed fragments into the key seed based on the key recovery protocol.

17. The system according to claim 12, wherein the recovery end belongs to a newly created blockchain node in the blockchain system; wherein, Each newly created blockchain node is used to replace the original blockchain nodes that have failed in the blockchain system.

18. The system according to claim 12, wherein the recovery end is further configured to: deriving a service key based on the key seed; The business key is used to decrypt the encrypted private data at any blockchain node.

19. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method according to any one of claims 1 to 11 when executing the program.

20. A computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the steps of the method according to any one of claims 1 to 11.

21. A computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 11.

Images