Block chain system and distributed key sharing method

Abstract

The invention provides a block chain system and a distributed key sharing method, and the method comprises the steps: a first block chain node deduces a corresponding service root key in a first trusted execution environment based on a key seed and a first security key maintained by the first trusted execution environment in the first block chain node, safely transmitting the service root key from the first trusted execution environment to trusted execution environments in other block chain nodes in the block chain system; and the first block chain node and the other block chain nodes respectively derive a unified service key based on the service root key in own trusted execution environments, wherein the service key is used for encrypting private data at the corresponding block chain node.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a blockchain system and a distributed key sharing method. 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] Due to the requirement of distributed consistency between blockchain nodes, each blockchain node needs to ensure that the same key is used when performing certain operations involving keys. In related technologies, keys are usually generated uniformly by KMS (Key Management Service) and then distributed to each blockchain node.

[0004] However, the key generation and distribution based on KMS is a centralized solution, which is somewhat inconsistent with the decentralized idea of ​​blockchain itself and may also bring certain security risks. Summary of the invention

[0005] In view of this, this specification provides a blockchain system and a distributed key sharing method to solve the deficiencies in the related technology.

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

[0007] According to a first aspect of an embodiment of this specification, a distributed key sharing method in a blockchain system is provided, including:

[0008] The first blockchain node derives a corresponding business root key in the first trusted execution environment based on the key seed and the first security key maintained by the first trusted execution environment in the first blockchain node, and securely transmits the business root key from the first trusted execution environment to the trusted execution environments in other blockchain nodes in the blockchain system;

[0009] The first blockchain node and the other blockchain nodes respectively derive a unified business key based on the business root key in their own trusted execution environments, and the business key is used to encrypt the privacy data at the corresponding blockchain node.

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

[0011] Based on the key seed and the first security key maintained by the first trusted execution environment in the first blockchain node, deriving a corresponding key to be shared in the first trusted execution environment;

[0012] The key to be shared is securely transmitted from the first trusted execution environment to the trusted execution environments in other blockchain nodes in the blockchain system.

[0013] According to a third aspect of an embodiment of this specification, a blockchain system includes a first blockchain node and other blockchain nodes;

[0014] Among them, the first blockchain node is used for:

[0015] Based on the key seed and the first security key maintained by the first trusted execution environment in the first blockchain node, deriving a corresponding key to be shared in the first trusted execution environment;

[0016] The key to be shared is securely transmitted from the first trusted execution environment to the trusted execution environments in other blockchain nodes in the blockchain system.

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

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

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

[0020] In the technical solution provided in this specification, the key is derived through the first blockchain node in the blockchain system. Since the first blockchain node can be any node in the blockchain system, that is, the selection of the first blockchain node is random, it helps to improve the security of key sharing. At the same time, by performing key derivation in the first trusted execution environment in the first blockchain node, the secure and trusted execution environment provided by the first trusted execution environment helps to improve the security of the key generation process. In addition, by performing key derivation based on the key seed and the first security key, it can be ensured that even if the key seed is leaked, the derived key can still be ensured to be secure and reliable because the first security key maintained by the first trusted execution environment is secure and reliable. Furthermore, for the derived key, by securely transmitting it from the first trusted execution environment to the trusted execution environment in other blockchain nodes, the possibility of leakage of the key during the transmission process can be reduced or avoided, further improving the security of key sharing. In short, the key sharing solution of this specification does not require the help of other entities outside the blockchain system, and can achieve trusted generation and sharing of keys by relying solely on blockchain nodes. Compared with the centralized solutions adopted in related technologies, the distributed key sharing solution of this specification does not need to rely on centralized entities such as KMS, and can significantly improve the security of key sharing. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 It is a flowchart of a distributed key sharing method in a blockchain system shown in an exemplary embodiment of this specification;

[0022] Figure 2 It is a schematic diagram of generating and sharing a service root key as shown in an exemplary embodiment of this specification;

[0023] Figure 3 It is a flowchart of another distributed key sharing method in a blockchain system shown in an exemplary embodiment of this specification;

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

[0025] Figure 5 It is a structural diagram of a distributed key sharing device in a blockchain system shown in an exemplary embodiment of this specification. DETAILED DESCRIPTION

[0026] 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, each blockchain node uses the same key to encrypt the same private data to ensure that the encrypted data obtained by each blockchain node is also consistent. For another example, each blockchain node may sometimes need to use the same key to represent a unified digital identity, such as using the same key to generate a digital signature.

[0027] The keys shared between blockchain nodes can 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 secret. Asymmetric keys can be used for encryption and decryption, and can also be used to generate and verify the above-mentioned digital signatures.

[0028] Take encryption and decryption as an example. In the blockchain scenario, if there is a need for privacy protection, the key shared between blockchain nodes can be used to encrypt and decrypt related data. For example, the block data maintained by the blockchain node (i.e., each block in the blockchain) can be encrypted for each block as a whole, or only the private transactions contained in each block (i.e., blockchain transactions that require privacy protection) can be encrypted 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.

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

[0030] Figure 1 This is a flow chart of a distributed key sharing method in a blockchain system shown in an exemplary embodiment of this specification. Figure 1 As shown, the method may include the following steps:

[0031] Step 102: The first blockchain node derives a corresponding business root key in the first trusted execution environment based on the key seed and the first security key maintained by the first trusted execution environment in the first blockchain node, and securely transmits the business root key from the first trusted execution environment to the trusted execution environments in other blockchain nodes in the blockchain system.

[0032] The first blockchain node may be any blockchain node in the blockchain system. For example, a blockchain node may be randomly selected from the blockchain system as the first blockchain node. By randomly selecting the first blockchain node, the randomness of the process of generating the business root key may be increased to improve security. Of course, other methods may also be used to determine the first blockchain node, and this specification does not limit this; for example, in the alliance chain scenario, the first blockchain node may be the master node in the blockchain system.

[0033] The timing for determining the first blockchain node may be the blockchain establishment stage of the blockchain system, that is, the initial establishment of the blockchain system. For example, the first blockchain node may be determined online through the node selection logic defined in the blockchain client program. For another example, in a consortium chain scenario, the participants corresponding to each blockchain node may negotiate offline or run the node selection logic such as the aforementioned through an electronic device outside the blockchain system, and write the information of the determined first blockchain node into the genesis block, so that each blockchain node may determine the first blockchain node by loading the genesis block.

[0034] Of course, after the blockchain system has been established, for example, at any time when the blockchain system is running, the first blockchain node can also be temporarily determined. For example, a smart contract containing node selection logic in the blockchain system can be called to select the first blockchain node by running the node selection 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 later.

[0035] The key seed can be obtained by the first blockchain node in any way, and this specification does not limit this. For example, in the alliance chain scenario, the first blockchain node can obtain the key seed from the corresponding participant. For another example, the first blockchain node can temporarily generate the key seed or temporarily select the key seed from a pre-obtained seed set by running the seed generation logic or the seed screening logic; wherein the seed generation logic can be integrated in the blockchain client program run by the first blockchain node. For another example, the blockchain client program of the first blockchain node can run on the same physical host as the above-mentioned seed generation / screening logic (for example, two processes running on the physical host), and after the seed generation / screening logic determines the key seed, it can provide the key seed to the blockchain client program of the first blockchain node (for example, cross-process data transfer), so that the first blockchain node obtains the key seed.

[0036] Trusted Execution Environment (TEE) is an effective solution currently adopted by enterprise-level blockchain systems to solve the two challenges of privacy and performance at the same time. Other solutions, such as common encryption technologies for solving privacy problems, homomorphic encryption and zero-knowledge proof, are not only highly complex and have poor versatility, but may also cause serious performance losses. TEE can play the role of a black box in hardware. The operating system layer cannot peek at the code and data executed in the 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 the 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.

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

[0038] Taking Intel SGX technology as an example, SGX provides an enclave (also called an enclave), which is an encrypted trusted execution area in memory, and the CPU protects data from being stolen. Take the first blockchain node as an example: by running a blockchain client program on a physical host, it can be implemented as a first blockchain node 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.

[0039] The blockchain client program of the first 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 executing a certain operation or realizing a certain function in the TEE in a certain 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 realize a certain function in the TEE by executing the enclave code in the enclave.

[0040] For example Figure 2As shown, the first blockchain node needs to inject the key seed from the outside into the first TEE, and derive the business root key in the first TEE by combining the key seed and the first security key maintained in the first TEE. The first blockchain node specifically injects the key seed into the first TEE by executing non-enclave code; if the key seed is obtained by the first blockchain node by running the seed generation / screening logic, the seed generation / screening logic also belongs to the non-enclave code. And, the first blockchain node specifically derives the business root key by executing the enclave code. In the following, the first blockchain node further derives the business key from the business root key in the first TEE, which is also achieved by executing the enclave code; the situation is similar for other blockchain nodes such as the second blockchain node and the third blockchain node.

[0041] The first security key refers to a key maintained in the first TEE. Since it is maintained in the first TEE, the security of the key can be ensured as long as the first TEE is not compromised, so it is called a security key; and in order to distinguish it from the security keys maintained in other TEEs (located in other blockchain nodes), the security key maintained in the first TEE is called the first security key. Due to the extremely high security of the first security key, any subject outside the first TEE, even the first blockchain node itself, cannot know the first security key. Therefore, when deriving the business root key, the first security key is used as one of the inputs (the key seed is another input), which can greatly improve the unpredictability of the key derivation process. Even if the key seed is leaked, since the first security key cannot be known, it can also ensure that the business root key is unpredictable.

[0042] For each blockchain node in the blockchain system, the security keys maintained by the TEEs in each blockchain node may be the same or different, which does not affect the technical solution of this specification. In other words, the first security key maintained by the first trusted execution environment may be the same as the security keys maintained by the trusted execution environments in other blockchain nodes, or the first security key maintained by the first trusted execution environment may be different from the security keys maintained by the trusted execution environments in other blockchain nodes.

[0043] If each TEE maintains the same security key, the security key can be, for example, a key distributed to each TEE by KMS. For example, remote authentication is required between each TEE. If KMS confirms that a certain TEE has passed the remote authentication, the security key can be distributed to the TEE. In this way, KMS can distribute the same security key to the TEE of each blockchain node, so that each TEE maintains the same security key. Of course, the security key can also be obtained based on other methods, and this specification does not limit this.

[0044] If each TEE maintains different security keys, these security keys can still be distributed by KMS based on the above logic, but the security keys distributed each time are different. Of course, security keys can also be obtained based on other methods, and this specification does not limit this. 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 (RootSeal Key or Root Sealing 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).

[0045] This specification does not limit the key derivation algorithm (or key derivation function, KDF for short) used when deriving the service root key from the key seed and the first security 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.

[0046] After the first blockchain node generates a service root key in the first TEE, it securely transmits the service root key to other blockchain nodes so that each blockchain node can obtain the same service root key. Figure 2 In the embodiment shown, the business root key is securely transmitted from the first TEE to the second TEE in the second blockchain node and the third TEE in the third blockchain node. Figure 2 Only the second blockchain node and the third blockchain node are taken as examples, and the "other blockchain nodes" in this specification may also include more blockchain nodes not shown.

[0047] There are many means to ensure transmission security in the relevant technology, which can be used in the technical solution of this specification to achieve secure transmission between the first TEE and other TEEs. For example, the first blockchain node can encrypt the business root key in the first TEE, output the encrypted business root key from the first TEE, and then transmit it to the TEE in other blockchain nodes. By encrypting the business root key, the TEE of each blockchain node only needs to maintain the corresponding key for decryption to ensure that the encrypted business root key cannot be correctly decrypted even if it is leaked during the transmission process. Moreover, since the encryption and decryption process is implemented in the TEE, that is, the corresponding keys are maintained by the TEE, it can be further ensured that the key will not be easily leaked. Among them, when encrypting and decrypting the business root key, a symmetric encryption algorithm can be used, then the first blockchain node encrypts in the first TEE and the other blockchain nodes decrypt in their own TEEs with the same key; or, an asymmetric encryption algorithm can be used, then the first blockchain node uses a private key for encryption in the first TEE, and other blockchain nodes use a public key for decryption in their own TEEs.

[0048] In one embodiment, after the first blockchain node encrypts the business root key in the first TEE, it can broadcast it to all other blockchain nodes, so that each other blockchain node decrypts the encrypted business root key in its own TEE respectively, and the decryption key used is the same.

[0049] 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 to encrypt the business root key in the first TEE, and then send the business root key encrypted by the first secure transmission key C1 to the second blockchain node, and send the business root key encrypted by the second secure transmission key C2 to the third blockchain node. The second blockchain node decrypts the business root key in the second TEE with the first secure transmission key C1, and the third blockchain node decrypts the business root key in the third TEE with the second secure transmission key C2. The situation of using asymmetric encryption and decryption is similar and will not be repeated here.

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

[0051] Accordingly, the first blockchain node can determine the secure transmission key negotiated after the first TEE successfully performs remote authentication with the TEE in each other blockchain node; and use the determined secure transmission keys to encrypt the business root key respectively. 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 business root key. Then, the first blockchain node can output each encrypted business root key from the first TEE, and transmit each encrypted business root key to the corresponding TEE in other blockchain nodes according to the secure transmission key used by each encrypted business root key 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 send the business root key encrypted by the first secure transmission key C1 to the second TEE, and the business root key encrypted by the second secure transmission key C2 to the third TEE. Of course, here the second blockchain node will receive the business root key encrypted by the first secure transmission key 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 business root key; similarly, the third blockchain node will receive the business root key encrypted by the second secure transmission key 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 business root key.

[0052] Of course, the secure transmission key negotiated between TEEs may also be an asymmetric key. So, 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 business root key, and the second TEE will use the corresponding private key to decrypt to obtain the business root key. The situation between other TEEs is similar and will not be repeated here.

[0053] In step 104, the first blockchain node and the other blockchain nodes respectively derive a unified business key based on the business root key in their own trusted execution environments, and the business key is used to encrypt the private data at the corresponding blockchain node.

[0054] As mentioned above, after the first blockchain node securely derives the business root key in the first TEE, it securely transmits the business root key to other blockchain nodes, so that other blockchain nodes also obtain the business root key in their own TEEs. So far, each blockchain node has maintained the business root key in its own TEE.

[0055] Furthermore, 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 key sharing process as described above, the business root key is usually not directly used to encrypt private data, but the business key is further derived based on the business root key, thereby encrypting the private data based on the business key. Since each blockchain node maintains a consistent business root key in its own TEE, the same business key, that is, the unified business key mentioned above, can be obtained after derivation based on the same key derivation algorithm. Among them, the key derivation algorithm used to generate the business root key can be the same as the key derivation algorithm used to generate the business key, or different key derivation algorithms can be used respectively, and this specification does not limit this.

[0056] In one embodiment, the first blockchain node and other blockchain nodes constitute all blockchain nodes in 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 business root key and derive a unified business key based on the technical solution of this specification.

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

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

[0059] For another example, there are multiple types of roles for blockchain nodes in a 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 node of the Peer Node type, the above-mentioned first blockchain node and other blockchain nodes may only include blockchain nodes of the Peer Node type, but not other types of blockchain nodes.

[0060] Figure 3 FIG. 1 is a flow chart of another distributed key sharing method in a blockchain system shown in an exemplary embodiment of this specification. Figure 3 As shown, the method is applied to the first blockchain node in the blockchain system; the method may include the following steps:

[0061] Step 302: Based on the key seed and the first security key maintained by the first trusted execution environment in the first blockchain node, derive a corresponding key to be shared in the first trusted execution environment.

[0062] Step 304: securely transmit the key to be shared from the first trusted execution environment to the trusted execution environments in other blockchain nodes in the blockchain system.

[0063] Optionally, the first security key maintained by the first trusted execution environment is different from the security key maintained by the trusted execution environment in the other blockchain nodes.

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

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

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

[0067] Optionally, the method further includes:

[0068] In a case where the information of the first blockchain node is recorded in a genesis block of the blockchain system, loading the genesis block to read the information of the first blockchain node; and, in a case where it is determined that the read information matches itself, confirming itself as the first blockchain node; and / or,

[0069] Execute a blockchain transaction, wherein the blockchain transaction calls the node selection logic in the smart contract to select the first blockchain node.

[0070] Optional,

[0071] The first blockchain node and the other blockchain nodes constitute all blockchain nodes in the blockchain system; or,

[0072] The first blockchain node and the other blockchain nodes are part of the blockchain nodes in the blockchain system, wherein the part of the blockchain nodes needs to maintain the privacy data, and the remaining blockchain nodes do not need to maintain the privacy data.

[0073] Optionally, securely transmitting the to-be-shared key from the first trusted execution environment to a trusted execution environment in another blockchain node in the blockchain system includes:

[0074] Encrypting the to-be-shared key in a first trusted execution environment;

[0075] The encrypted key to be shared is output from the first trusted execution environment, and then transmitted to the trusted execution environment in the other blockchain node.

[0076] Optional,

[0077] The encrypting the key to be shared in the first trusted execution environment includes: determining the secure transmission key negotiated after the first trusted execution environment and the trusted execution environment in each other blockchain node are remotely authenticated successfully; and encrypting the key to be shared using the determined secure transmission keys;

[0078] The method of outputting the encrypted key to be shared from the first trusted execution environment and then transmitting it to the trusted execution environment in other blockchain nodes includes: outputting each encrypted key to be shared from the first trusted execution environment, and transmitting each encrypted key to be shared to the corresponding trusted execution environment in other blockchain nodes according to the secure transmission key used by each encrypted key to be shared and the correspondence between each secure transmission key and the trusted execution environment.

[0079] Optionally, also include:

[0080] deriving a service key based on the key to be shared;

[0081] The key to be shared is also used by other blockchain nodes that have obtained the key to be shared to: derive the business key in their own trusted execution environment;

[0082] The business key is used to encrypt the private data at the corresponding blockchain node.

[0083] It should be noted that: Figure 1 The embodiment shown describes the technical solution of this specification based on the execution actions of the first blockchain node and other blockchain nodes. Figure 3 The embodiment shown describes the technical solution of this specification from the perspective of the first blockchain node. Figure 3 The embodiment shown and Figure 1 The embodiments shown are closely related in technical solutions, except that the shared key is changed from the service root key to the key to be shared. Figure 3 For other contents of the illustrated embodiment, please refer to the above Figure 1 The description of the illustrated embodiment will not be repeated here.

[0084] The key to be shared refers to any key that needs to be shared by the first blockchain node to other blockchain nodes. The business root key can be a case of the key to be shared. However, the key to be shared can also be other keys besides the business root key, and this specification does not limit this.

[0085] This specification also provides a blockchain system, including a first blockchain node and other blockchain nodes;

[0086] Among them, the first blockchain node is used for:

[0087] Based on the key seed and the first security key maintained by the first trusted execution environment in the first blockchain node, deriving a corresponding key to be shared in the first trusted execution environment;

[0088] The key to be shared is securely transmitted from the first trusted execution environment to the trusted execution environments in other blockchain nodes in the blockchain system.

[0089] Optionally, the first security key maintained by the first trusted execution environment is different from the security key maintained by the trusted execution environment in the other blockchain nodes.

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

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

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

[0093] Optionally, the method further includes:

[0094] In a case where the information of the first blockchain node is recorded in the genesis block of the blockchain system, each blockchain node in the blockchain system loads the genesis block respectively to read the information of the first blockchain node; wherein any blockchain node confirms itself as the first blockchain node when determining that the read information matches itself; and / or,

[0095] Each blockchain node in the blockchain system executes a blockchain transaction respectively, and the blockchain transaction calls the node selection logic in the smart contract to select the first blockchain node.

[0096] Optional,

[0097] The first blockchain node and the other blockchain nodes constitute all blockchain nodes in the blockchain system; or,

[0098] The first blockchain node and the other blockchain nodes are part of the blockchain nodes in the blockchain system, wherein the part of the blockchain nodes needs to maintain the privacy data, and the remaining blockchain nodes do not need to maintain the privacy data.

[0099] Optionally, securely transmitting the to-be-shared key from the first trusted execution environment to a trusted execution environment in another blockchain node in the blockchain system includes:

[0100] Encrypting the to-be-shared key in a first trusted execution environment;

[0101] The encrypted key to be shared is output from the first trusted execution environment, and then transmitted to the trusted execution environment in the other blockchain node.

[0102] Optional,

[0103] The encrypting the key to be shared in the first trusted execution environment includes: determining the secure transmission key negotiated after the first trusted execution environment and the trusted execution environment in each other blockchain node are remotely authenticated successfully; and encrypting the key to be shared using the determined secure transmission keys;

[0104] The method of outputting the encrypted key to be shared from the first trusted execution environment and then transmitting it to the trusted execution environment in other blockchain nodes includes: outputting each encrypted key to be shared from the first trusted execution environment, and transmitting each encrypted key to be shared to the corresponding trusted execution environment in other blockchain nodes according to the secure transmission key used by each encrypted key to be shared and the correspondence between each secure transmission key and the trusted execution environment.

[0105] Optionally, also include:

[0106] deriving a service key based on the key to be shared;

[0107] The key to be shared is also used by other blockchain nodes that have obtained the key to be shared to: derive the business key in their own trusted execution environment;

[0108] The business key is used to encrypt the private data at the corresponding blockchain node.

[0109] It should be noted that the embodiment of the blockchain system describes the system architecture of the first blockchain node and other blockchain nodes, as well as the execution actions of the first blockchain node and other blockchain nodes. Figure 1 The embodiments shown are closely related in technical solutions. Except that the shared key is changed from the service root key to the shared key, the other contents can refer to the above description of Figure 1 The description of the illustrated embodiment will not be repeated here.

[0110] In summary, in the technical solution provided in this specification, the key is derived through the first blockchain node in the blockchain system. Since the first blockchain node can be any node in the blockchain system, that is, the selection of the first blockchain node is random, it helps to improve the security of key sharing. At the same time, by performing key derivation in the first trusted execution environment in the first blockchain node, the secure and trusted execution environment provided by the first trusted execution environment helps to improve the security of the key generation process. In addition, by performing key derivation based on the key seed and the first security key, it can be ensured that even if the key seed is leaked, the derived key can still be ensured to be secure and reliable because the first security key maintained by the first trusted execution environment is secure and reliable. Furthermore, for the derived key, by securely transmitting it from the first trusted execution environment to the trusted execution environment in other blockchain nodes, the possibility of leakage of the key during the transmission process can be reduced or avoided, further improving the security of key sharing. In short, the key sharing solution of this specification does not require the help of other entities outside the blockchain system, and can achieve trusted generation and sharing of keys by relying solely on blockchain nodes. Compared with the centralized solutions adopted in related technologies, the distributed key sharing solution of this specification does not need to rely on centralized entities such as KMS, and can significantly improve the security of key sharing.

[0111] Figure 4 is a schematic diagram of the structure of an electronic device in an exemplary embodiment. Figure 4 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.

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

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

[0114] The key derivation unit 501 derives a corresponding key to be shared in the first trusted execution environment based on the key seed and the first security key maintained by the first trusted execution environment in the first blockchain node;

[0115] The key transmission unit 502 securely transmits the key to be shared from the first trusted execution environment to the trusted execution environments in other blockchain nodes in the blockchain system.

[0116] Optionally, the first security key maintained by the first trusted execution environment is different from the security key maintained by the trusted execution environment in the other blockchain nodes.

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

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

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

[0120] Optionally, the device further includes a node confirmation unit, configured to:

[0121] In a case where the information of the first blockchain node is recorded in a genesis block of the blockchain system, loading the genesis block to read the information of the first blockchain node; and, in a case where it is determined that the read information matches itself, confirming itself as the first blockchain node; and / or,

[0122] Execute a blockchain transaction, wherein the blockchain transaction calls the node selection logic in the smart contract to select the first blockchain node.

[0123] Optional,

[0124] The first blockchain node and the other blockchain nodes constitute all blockchain nodes in the blockchain system; or,

[0125] The first blockchain node and the other blockchain nodes are part of the blockchain nodes in the blockchain system, wherein the part of the blockchain nodes needs to maintain the privacy data, and the remaining blockchain nodes do not need to maintain the privacy data.

[0126] Optionally, the key transmission unit 502 is specifically used for:

[0127] Encrypting the key to be shared in the first trusted execution environment;

[0128] The encrypted key to be shared is output from the first trusted execution environment, and then transmitted to the trusted execution environment in the other blockchain node.

[0129] Optional,

[0130] The encrypting the key to be shared in the first trusted execution environment includes: determining the secure transmission key negotiated after the first trusted execution environment and the trusted execution environment in each other blockchain node are remotely authenticated successfully; and encrypting the key to be shared using the determined secure transmission keys;

[0131] The method of outputting the encrypted key to be shared from the first trusted execution environment and then transmitting it to the trusted execution environment in other blockchain nodes includes: outputting each encrypted key to be shared from the first trusted execution environment, and transmitting each encrypted key to be shared to the corresponding trusted execution environment in other blockchain nodes according to the secure transmission key used by each encrypted key to be shared and the correspondence between each secure transmission key and the trusted execution environment.

[0132] Optional,

[0133] The key derivation unit 501 is further used to: derive a service key based on the key to be shared;

[0134] The key to be shared is also used by other blockchain nodes that have obtained the key to be shared to: derive the business key in their own trusted execution environment;

[0135] The business key is used to encrypt the private data at the corresponding blockchain node.

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

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

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

[0139] 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 sharing method in a blockchain system, include: The first blockchain node derives a corresponding business root key in the first trusted execution environment based on the key seed and the first security key maintained by the first trusted execution environment in the first blockchain node, and securely transmits the business root key from the first trusted execution environment to the trusted execution environments in other blockchain nodes in the blockchain system; The first blockchain node and the other blockchain nodes respectively derive a unified business key based on the business root key in their own trusted execution environments, and the business key is used to encrypt the privacy data at the corresponding blockchain node.

2. According to the method of claim 1, the first security key maintained by the first trusted execution environment is different from the security keys maintained by the trusted execution environments in the other blockchain nodes.

3. The method according to claim 2, wherein any security key maintained by a trusted execution environment include: 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.

4. The method according to claim 1, further comprising: include: In a case where the information of the first blockchain node is recorded in the genesis block of the blockchain system, each blockchain node in the blockchain system loads the genesis block respectively to read the information of the first blockchain node; wherein any blockchain node confirms itself as the first blockchain node when determining that the read information matches itself; and / or, Each blockchain node in the blockchain system executes a blockchain transaction respectively, and the blockchain transaction calls the node selection logic in the smart contract to select the first blockchain node.

5. The method according to claim 1, The first blockchain node and the other blockchain nodes constitute all blockchain nodes in the blockchain system; or, The first blockchain node and the other blockchain nodes are part of the blockchain nodes in the blockchain system, wherein the part of the blockchain nodes needs to maintain the privacy data, and the remaining blockchain nodes do not need to maintain the privacy data.

6. The method according to claim 1, wherein the business root key is securely transmitted from the first trusted execution environment to the trusted execution environment in other blockchain nodes in the blockchain system, include: Encrypting the service root key in a first trusted execution environment; The encrypted business root key is exported from the first trusted execution environment and then transmitted to the trusted execution environment in the other blockchain nodes.

7. The method according to claim 6, The service root key is encrypted in the first trusted execution environment, include: 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 service root keys respectively; The method of outputting the encrypted business root key from the first trusted execution environment and then transmitting it to the trusted execution environment in other blockchain nodes includes: outputting each encrypted business root key from the first trusted execution environment, and transmitting each encrypted business root key to the corresponding trusted execution environment in other blockchain nodes according to the secure transmission key used by each encrypted business root key and the correspondence between each secure transmission key and the trusted execution environment.

8. A distributed key sharing method in a blockchain system, applied to a first blockchain node in the blockchain system; the method include: Based on the key seed and the first security key maintained by the first trusted execution environment in the first blockchain node, deriving a corresponding key to be shared in the first trusted execution environment; The key to be shared is securely transmitted from the first trusted execution environment to the trusted execution environments in other blockchain nodes in the blockchain system.

9. According to the method of claim 8, the first security key maintained by the first trusted execution environment is different from the security keys maintained by the trusted execution environments in the other blockchain nodes.

10. The method according to claim 9, wherein any security key maintained by a trusted execution environment include: 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.

11. The method according to claim 8, further comprising: include: In a case where the information of the first blockchain node is recorded in a genesis block of the blockchain system, loading the genesis block to read the information of the first blockchain node; and, if it is determined that the read information matches itself, confirming itself as the first blockchain node; and / or, Execute a blockchain transaction, wherein the blockchain transaction calls the node selection logic in the smart contract to select the first blockchain node.

12. The method according to claim 8, wherein the key to be shared is securely transmitted from the first trusted execution environment to the trusted execution environment in other blockchain nodes in the blockchain system, include: Encrypting the to-be-shared key in a first trusted execution environment; The encrypted key to be shared is output from the first trusted execution environment, and then transmitted to the trusted execution environment in the other blockchain node.

13. The method according to claim 12, encrypting the key to be shared in the first trusted execution environment, include: 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 keys to be shared respectively; The method of outputting the encrypted key to be shared from the first trusted execution environment and then transmitting it to the trusted execution environment in other blockchain nodes includes: outputting each encrypted key to be shared from the first trusted execution environment, and transmitting each encrypted key to be shared to the corresponding trusted execution environment in other blockchain nodes according to the secure transmission key used by each encrypted key to be shared and the correspondence between each secure transmission key and the trusted execution environment.

14. The method according to claim 8, further comprising: include: deriving a service key based on the key to be shared; The key to be shared is also used by other blockchain nodes that have obtained the key to be shared to: derive the business key in their own trusted execution environment; The business key is used to encrypt the private data at the corresponding blockchain node.

15. A blockchain system, comprising a first blockchain node and other blockchain nodes; in, The first blockchain node is used for: Based on the key seed and the first security key maintained by the first trusted execution environment in the first blockchain node, deriving a corresponding key to be shared in the first trusted execution environment; The key to be shared is securely transmitted from the first trusted execution environment to the trusted execution environments in other blockchain nodes in the blockchain system.

16. 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 any one of the methods of claims 1 to 14 when executing the program.

17. 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 14.

18. 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 14.

Images