WO2024001037A1 - 一种消息传输方法、装置、电子设备和存储介质 - Google Patents
一种消息传输方法、装置、电子设备和存储介质 Download PDFInfo
- Publication number
- WO2024001037A1 WO2024001037A1 PCT/CN2022/135607 CN2022135607W WO2024001037A1 WO 2024001037 A1 WO2024001037 A1 WO 2024001037A1 CN 2022135607 W CN2022135607 W CN 2022135607W WO 2024001037 A1 WO2024001037 A1 WO 2024001037A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- blockchain
- blockchain node
- node
- key
- encrypted
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
- H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
Definitions
- the embodiments of this specification belong to the field of blockchain technology, and in particular relate to a message transmission method, device, electronic device and storage medium.
- Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
- data blocks are combined into a chained data structure in a chronological manner and are cryptographically guaranteed to be an untamperable and unforgeable distributed ledger. Due to the characteristics of blockchain, such as decentralization, non-tamperable information, and autonomy, blockchain has also received more and more attention and applications.
- each blockchain node directly uses P2P (Peer to Peer, point-to-point) technology to communicate to transmit transactions, blocks, etc.
- P2P Peer to Peer, point-to-point
- blockchain nodes often An encrypted channel is established, thereby enabling encrypted communication. Since each encrypted channel is independent and its corresponding keys or encryption strategies are different, in the scenario of multicast or broadcast of messages, the source blockchain node needs to follow the instructions of multiple destination blockchains. Multiple keys corresponding to multiple encrypted channels connected by nodes encrypt the same plaintext message multiple times and then send it to other blockchain nodes respectively, which brings a huge computational burden to the source blockchain node. Affects the efficiency of encrypted communication between blockchain nodes.
- the purpose of this specification is to provide a message transmission method, device, electronic device and storage medium.
- a message transmission method is proposed, applied to a source blockchain node, each blockchain node in the blockchain node group to which the source blockchain node belongs All maintain the same shared key; the method includes:
- the plaintext is modified based on the shared key. Messages are encrypted to obtain encrypted messages;
- a message transmission device which is applied to a source blockchain node, and each blockchain node in the blockchain node group to which the source blockchain node belongs All maintain the same shared key; the device includes:
- An encryption unit configured to perform encryption based on the shared secret when the destination blockchain node corresponding to the plaintext message includes at least two blockchain nodes in the blockchain node group except the source blockchain node. Use the key to encrypt the plaintext message to obtain the encrypted message;
- a sending unit configured to send the encrypted message to the at least two blockchain nodes, and the at least two blockchain nodes are configured to decrypt the encrypted message based on the shared key maintained by each. Get the clear text message.
- an electronic device including:
- Memory used to store instructions executable by the processor
- the processor implements the method described in the first aspect by running the executable instructions.
- a computer-readable storage medium on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in the first aspect are implemented.
- the source blockchain node when the source blockchain node performs broadcast or multicast, since at least two blockchain nodes of the source blockchain node and the destination blockchain node jointly maintain the same shared key, therefore The source blockchain node can use the shared key to encrypt the plaintext message once and send it to the at least two blockchain nodes, thereby reducing the number of encryption times of the plaintext message in multicast or broadcast scenarios, while ensuring communication security. Reduce the computational burden of source blockchain nodes and improve the efficiency of encrypted communication between blockchain nodes.
- Figure 1 is a schematic diagram of a scenario of interaction between blockchain nodes provided by an exemplary embodiment.
- Figure 2 is a flow chart of a message transmission method provided by an exemplary embodiment.
- Figure 3 is a schematic diagram of a broadcast scenario provided by a source blockchain node according to an exemplary embodiment.
- Figure 4 is a schematic structural diagram of a device provided by an exemplary embodiment.
- Figure 5 is a block diagram of a message transmission device provided in an exemplary embodiment.
- SSL Secure Socket Layer
- TLS Transport Layer Security Protocol
- IPsec Internet Protocol Security (Internet Security Protocol), etc.
- end-to-end encryption protocols to achieve encrypted communication.
- the blockchain node Node A needs to send a blockchain message to the blockchain node Node B
- Node A and Node B can perform key negotiation based on the SSL protocol, so that the negotiated transmission key can be used in the An SSL link is established between Node A and Node B.
- the blockchain messages are in ciphertext state (encrypted by the above-mentioned transmission key) when transmitted within the SSL link, and only Node A and Node B holding the transmission key can decrypt the corresponding message plaintext. .
- each encrypted channel established between blockchain nodes is independent.
- the keys or encryption strategies of multiple encrypted channels established by the same blockchain node and other different blockchain nodes are different, which means For a source blockchain node that needs to broadcast or multicast the same plaintext message to multiple other destination blockchain nodes at the same time, it needs to send the plaintext message according to the multicast message established between multiple destination blockchain nodes.
- the keys and encryption strategies corresponding to each encrypted channel are encrypted independently multiple times to obtain multiple encrypted messages, and then these multiple encrypted messages are sent to the corresponding other multiple destination blockchain nodes through the corresponding encrypted channels.
- Figure 1 is a schematic diagram of an interaction scenario between blockchain nodes provided by an exemplary embodiment.
- this scenario contains a total of 4 blockchain nodes Node A, Node B, Node C and Node D. They all have encrypted channels established with each other to achieve encrypted communication.
- the encrypted channels established between blockchain nodes are independent of each other.
- Node A, Node B, Node C, and Node D each establish three unrelated encrypted channels, tunnel_AB, tunnel_AC, and tunnel_AD.
- Node A when Node A needs to broadcast messages to Node B, Node C, and Node D at the same time, Node A will encrypt the plaintext message to be broadcast based on the keys corresponding to tunnel_AB, tunnel_AC, and tunnel_AD respectively to obtain three different encrypted messages msg_AB, msg_AC, msg_AD, then send msg_AB to Node B through tunnel_AB, send msg_AC to Node C through tunnel_AC, and send msg_AD to Node D through tunnel_AD. It is not difficult to find that in order to broadcast the same plaintext message to the other three blockchain nodes, Node A needs to encrypt the plaintext message three times independently.
- Blockchain nodes will undertake a large number of message broadcast tasks, which means that as the scale of the blockchain network gradually increases and the number of blockchain nodes increases, its communication overhead will increase with a quadratic function.
- this specification proposes a message transmission scheme that reduces the number of times of encryption of plain text messages in multicast or broadcast scenarios by establishing a blockchain node group in the blockchain node and maintaining the same shared key. , while also ensuring communication security.
- Figure 2 is a flow chart of a message transmission method provided by an exemplary embodiment, wherein the method is applied to a source blockchain node, and each block in the blockchain node group to which the source blockchain node belongs All chain nodes maintain the same shared key; the method includes:
- the source blockchain node refers to the blockchain node that is the message sender in an interaction between blockchain nodes. Therefore, there is generally only one source blockchain node, and the destination area A blockchain node refers to a blockchain node that is the receiver of a message in an interaction between blockchain nodes. Obviously the receiver of a message is not unique, so the number of destination blockchain nodes is not unique either. It can be one or multiple.
- blockchain nodes that can communicate with each other can be managed according to the group management method of the blockchain node group, so that each blockchain node in the same blockchain node group maintains the same shared key.
- several blockchain nodes can maintain a common shared key through group key negotiation in advance, and thus be organized into a blockchain node group based on online negotiation; or, several blockchain nodes can be organized offline The same key is manually entered as a shared key, and is organized into a blockchain node group based on offline entry; or, the node devices where several blockchain nodes are located are bound to the same key.
- these several blockchain nodes will read the same key from the node device where they are located and use it as a shared key, and then they will be jointly organized into a blockchain node group based on device binding.
- they will first encrypt the plaintext message according to the jointly maintained shared key to obtain the encrypted message, and then transmit the encrypted message. From then on, Regardless of whether the encrypted message undergoes any processing during transmission or is stolen by an attacker, since the shared key is only maintained by blockchain nodes within the same blockchain node group, it is theoretically excluded that the plaintext message is transmitted during transmission. the possibility of being exposed.
- the shared key involved in the embodiments of this specification is a symmetric key. Therefore, when a blockchain node receives encrypted messages from other blockchain nodes belonging to the same blockchain node group, it can directly use the shared key based on the shared key. key to decrypt to obtain the plaintext message.
- each blockchain node in the blockchain node group is in the same blockchain network or a different blockchain network.
- the source blockchain node and the destination block Chain nodes can be on the same blockchain network or different blockchain networks.
- blockchain node groups and blockchain networks are not the same concept, which means that blockchain node members belonging to the same blockchain node group are not necessarily in the same blockchain network.
- Each blockchain node in the same blockchain network is not necessarily in the same blockchain node group.
- the original intention of the blockchain node group involved in the embodiments of this specification is to realize secure communication among members of the blockchain node group.
- the different blockchain networks are isomorphic or heterogeneous to each other. For example, between the source blockchain node and When the destination blockchain node is in a different blockchain network, the source blockchain network where the source blockchain node is located is the same as the destination blockchain network where the destination blockchain node is located.
- the blockchain nodes in the blockchain node group are not required to have the same blockchain architecture, that is, multiple blockchain networks involved in each blockchain node in a blockchain node group Isomorphism is not necessarily required. With the same blockchain protocol, consensus protocol, etc., multiple blockchain networks involved can also be heterogeneous.
- heterogeneous blockchains in a narrow sense usually refer to obvious differences in the values circulating on the blockchain; that is, between two blockchains with obvious differences in the values circulating, it is usually possible to Call it a heterogeneous blockchain.
- the Bitcoin network and Ethereum are heterogeneous blockchains in a narrow sense.
- Heterogeneous blockchain in a broad sense means that there are obvious differences in the types of blockchains and/or the blockchain protocols adopted; that is, there are obvious differences in the types of blockchains and/or the blockchain protocols adopted. Between two blockchains, it can usually be called a heterogeneous blockchain.
- ANT CHAIN and hyperledger fabric blockchain are heterogeneous blockchains in a broad sense.
- the same blockchain node can belong to multiple different blockchain node groups at the same time. Therefore, for any blockchain node, it can locally maintain multiple nodes that it belongs to. List of members of the blockchain node group and their corresponding shared keys.
- the source blockchain node first searches for at least one pre-maintained blockchain node group locally and determines the relationship between itself and the destination blockchain.
- the blockchain node group to which the nodes belong together (there may be multiple), and then encrypts the plain text message based on the shared key corresponding to the locally maintained blockchain node group to obtain the encrypted message, so that the destination blockchain node After receiving the encrypted message, the plaintext message can be decrypted based on the shared key of the blockchain node group.
- the destination blockchain node includes at least two blockchain nodes, it is necessary to locally find out the source blockchain node and the at least two blockchain nodes that are the destination blockchain node.
- the blockchain node group is then encrypted based on the corresponding shared key.
- the source blockchain node When the source blockchain node responds to a multicast or broadcast task, it may not necessarily be triggered to execute the message transmission method involved in the embodiments of this specification. This is because although the multicast and broadcast tasks both send the same message to at least two areas, The blockchain node meets the condition that the destination blockchain node corresponding to the plain text message includes at least two blockchain nodes. However, the triggering condition in this case is actually that the destination blockchain node corresponding to the plain text message includes the above-mentioned blockchain node group. At least two blockchain nodes other than the source blockchain node. In other words, the message transmission method involved in the implementation of this specification not only depends on the scenario of performing multicast or broadcast tasks, but also needs to ensure that it serves as the destination area.
- At least two blockchain nodes of the blockchain node belong to the same blockchain node group as the source blockchain node, and both are node members in the same blockchain node group. Therefore, for a multicast or broadcast task, the source blockchain node first determines the plaintext message to be sent and the destination blockchain node to be sent, and determines the result by looking up the member list of the locally maintained blockchain node group. After the destination blockchain node belongs to a blockchain node group, the plaintext message will be encrypted according to the shared key corresponding to the determined blockchain node group to obtain the encrypted message, and finally the encrypted message will be sent to the The destination blockchain node of at least two blockchain nodes.
- FIG. 3 is a schematic diagram of a broadcast scenario provided by a source blockchain node according to an exemplary embodiment, in which the source blockchain node is blockchain node A in the figure, and the destination blockchain node There are a total of 7 blockchain nodes including blockchain nodes B to H. It can be found that blockchain nodes B, C, and D in the destination blockchain node and blockchain node A belong to blockchain node group 1.
- blockchain nodes A, B, C, and D jointly maintain the shared key corresponding to blockchain node group 1, while blockchain node E in the destination blockchain does not belong to any blockchain node group.
- blockchain node group F belongs to blockchain node group 3
- the node members of blockchain node group 3 do not include at least two destination blockchain nodes, nor does it include blockchain node A, so this Some of them will not trigger the execution of the message transmission method involved in this manual, and the blockchain nodes G and H belong to the blockchain node group 2 together with the blockchain node A, and jointly maintain the shares corresponding to the blockchain node group 2. key.
- blockchain node A will first retrieve the member list of the blockchain node group maintained by itself based on the destination blockchain node, and then in the determination area After blockchain nodes B, C, D and blockchain node A belong to blockchain node group 1, and blockchain nodes G, H and blockchain node A belong to blockchain node group 2, the plaintext message They are encrypted based on the shared key corresponding to blockchain node group 1 and sent to blockchain nodes B, C, and D, and the plaintext message is encrypted based on the shared key corresponding to blockchain node group 2 and sent to Blockchain nodes G and H, as well as blockchain nodes E and F, need to use blockchain node A and their separately established encrypted channels to encrypt and transmit plaintext messages. Therefore, blockchain node A has a total of Four encryption calculations were performed, which is significantly lower than the traditional method of encrypting transmission separately based on the encrypted channel established with each destination blockchain node (requiring seven encryption calculations for the plaintext message). Calculate consumption.
- encrypting the plaintext message based on the shared key to obtain an encrypted message includes: based on a security parameter index contained in the plaintext message, determining a security association policy corresponding to the security parameter index; The plaintext message is encrypted based on the shared key included in the security association policy to obtain the encrypted message.
- the source blockchain node determines that the destination blockchain node corresponding to the plaintext message includes at least two blockchain nodes and the at least two blockchain nodes and the source blockchain node belong to the same Blockchain node group.
- the source blockchain node will encapsulate the plaintext message to be sent according to the preset protocol such as IPsec protocol, add the SPI (security parameters index, security parameter index) field to it and then deliver it to the source blockchain.
- the encryption computing module in the node performs further encryption processing.
- the encryption computing module After receiving the plaintext message carrying the SPI, the encryption computing module will retrieve the locally pre-maintained SA (security assist, security association policy) based on the SPI, and then obtain the The shared key contained in the SA (that is, the shared key corresponding to the determined blockchain node group) encrypts the plaintext message to obtain the encrypted message and sends the encrypted message carrying SPI to the destination blockchain node, destination area
- the block link After the block link receives the encrypted message carrying SPI, it can retrieve the locally pre-maintained SA through the SPI field carried in the encrypted message, and then use the shared key contained in the retrieved SA (that is, the determined blockchain node group corresponding shared key) to decrypt the ciphertext message to obtain the plaintext message.
- the embodiments of this specification are equivalent to establishing a new encrypted channel between the source blockchain node and the destination blockchain node to implement the message transmission method involved in the embodiments of this specification.
- the at least two private keys maintained by the source blockchain node and corresponding to the at least two point-to-point encrypted channels respectively established between the at least two blockchain nodes are the shared keys; Encrypting the plaintext message based on the shared key to obtain the encrypted message includes: encrypting the plaintext message based on any one of the at least two private keys to obtain the encrypted message; Sending the encrypted message to the at least two blockchain nodes includes: respectively determining a point-to-point encrypted channel established with the at least two blockchain nodes, and basing the encrypted message on the corresponding point-to-point encrypted channel. Sent to the at least two blockchain nodes respectively.
- point-to-point encrypted channels are independently established between the source blockchain node and the at least two blockchain nodes.
- these point-to-point encrypted channels are independent of each other and have different characteristics.
- the embodiment of this specification allows each blockchain node in the blockchain node group to which the source blockchain node belongs to perform key negotiation, so that after each blockchain node maintains the same shared key, Each blockchain node will replace the private key corresponding to the point-to-point encrypted channel established by other blockchain nodes in the same blockchain node group with a shared key, so that each block in the blockchain node group Communication between chain nodes will only use shared keys for encryption and decryption, thereby realizing key association of encrypted channels within the blockchain node group.
- the embodiment of this specification also provides a new encryption strategy , that is, when it is detected that at least two blockchain nodes serving as destination blockchain nodes belong to the same blockchain node group as the source blockchain node, although the plaintext message will be encrypted according to the original encrypted channel transmission, but the independent encryption processes corresponding to multiple encrypted channels will be merged.
- a new encryption strategy that is, when it is detected that at least two blockchain nodes serving as destination blockchain nodes belong to the same blockchain node group as the source blockchain node, although the plaintext message will be encrypted according to the original encrypted channel transmission, but the independent encryption processes corresponding to multiple encrypted channels will be merged.
- a new encryption strategy that is, when it is detected that at least two blockchain nodes serving as destination blockchain nodes belong to the same blockchain node group as the source blockchain node, although the plaintext message will be encrypted according to the original encrypted channel transmission, but the independent encryption processes corresponding to multiple encrypted channels will be merged.
- the traditional solution requires the plaintext
- the message first encrypts the plaintext message through the encrypted
- the keys corresponding to tunnel_AB and tunnel_AC have been associated, their corresponding keys are the same shared keys corresponding to the blockchain node groups to which Node A, Node B and Node C belong, so there is no need to re-encrypt twice. process, but merge the encryption process into one, and the obtained encrypted message is sent to Node B and Node C through tunnel_AB and tunnel_AC respectively.
- the embodiments of this specification realize the message transmission method involved in the embodiments of this specification based on the architecture of traditional encrypted channels by performing key association and merging of encryption processes on multiple encrypted channels that are originally independent of each other, without the need to re-establish new encryption. channel.
- the key storage addresses of the at least two private keys on the source blockchain node are both the key storage addresses of the shared key on the source blockchain node.
- the dedicated keys in different point-to-point encryption channels will occupy an exclusive storage space.
- the private keys in the point-to-point encrypted channel are all replaced by the same shared key. Therefore, for the source blockchain node, if the traditional high storage strategy is still used, information redundancy will occur.
- S204 Send the encrypted message to the at least two blockchain nodes, and the at least two blockchain nodes are used to decrypt the encrypted message based on the shared key maintained by each to obtain the Clear text message.
- any destination blockchain node will receive After the message is encrypted, the encrypted message will be decrypted based on the shared key to finally obtain the plaintext message. At this point, the entire process of the message transmission solution involved in the lock of the embodiment of this specification is realized.
- the source blockchain node when the source blockchain node performs broadcast or multicast, since at least two blockchain nodes of the source blockchain node and the destination blockchain node jointly maintain the same shared key, therefore The source blockchain node can use the shared key to encrypt the plaintext message once and send it to the at least two blockchain nodes, thereby reducing the number of encryption times of the plaintext message in multicast or broadcast scenarios, while ensuring communication security. Reduce the computational burden of source blockchain nodes and improve the efficiency of encrypted communication between blockchain nodes.
- the source blockchain node needs to determine whether there are at least two blockchain nodes in the destination blockchain node that belong to the same node as the source blockchain node by looking up the member list of the locally maintained blockchain node group.
- Blockchain node group however, the source blockchain node or the destination blockchain node may temporarily lack the member list of the blockchain node group, which makes although the source blockchain node or the destination blockchain node objectively Both belong to the same blockchain node group, but the source blockchain node and the destination blockchain node are unknown, resulting in the inability to apply the message transmission method involved in the embodiments of this specification. For this reason, it is necessary to design a message interaction method so that the source blockchain node can still confirm whether the destination blockchain node and the source blockchain node belong to the same block even when the blockchain node group is incomplete. Link node group.
- the source blockchain node only maintains multiple shared keys corresponding to multiple blockchain node groups to which it belongs, but does not maintain member lists of these blockchain node groups, or although it maintains members list, but these member lists do not contain the identity information of the destination blockchain node. It should be pointed out that the fact that a certain blockchain node is not included in the member list of the blockchain node group does not mean that the blockchain node must not belong to the
- the blockchain node group may be temporarily undetermined, which means that if the source blockchain node needs to send a plaintext message to the destination blockchain node, it cannot pass the node ID, node public key, network address, etc.
- the identity information of the destination blockchain node determines the blockchain node group to which it and the destination blockchain node belong.
- the source blockchain node can only determine the network address of the destination blockchain node. It is impossible to determine whether there is a blockchain node group that belongs to the destination blockchain node.
- the source blockchain node will encrypt the plaintext message with multiple shared keys corresponding to all the blockchain node groups it maintains. Obtain multiple encrypted messages, and then send these multiple encrypted messages to the destination blockchain node according to the network address of the destination blockchain node.
- the number of destination blockchain nodes can be multiple, for example, in order to cooperate with the aforementioned message transmission.
- the destination blockchain node here can be all destination blockchain nodes corresponding to the plaintext message.
- the destination blockchain node cannot determine the source blockchain node and the blockchain nodes to which it belongs, it can decrypt the received multiple messages one by one according to the shared key corresponding to at least one blockchain node group it maintains.
- An encrypted message For example, the destination blockchain node maintains a total of two blockchain node groups, and the corresponding shared keys are key_1 and key_2.
- the destination blockchain node received a total of 3 encrypted messages, respectively msg_1. , msg_2 and msg_3, then the destination blockchain node will use key_1 and key_2 to try to decrypt msg_1, msg_2 and msg_3 respectively, that is, up to six decryptions are required.
- the destination blockchain node will know that it and the source blockchain node belong to the blockchain node group corresponding to key_2, so it can maintain the area corresponding to key_2 locally.
- the identity information of the source blockchain node is written in the member list of the blockchain node group.
- the destination blockchain node when the destination blockchain node successfully identifies the blockchain node group to which the source blockchain node belongs, it will further notify the source blockchain node.
- This blockchain node group enables the source blockchain node to determine the destination blockchain node and the blockchain node group it belongs to, so that the source blockchain node subsequently needs to send a plaintext message to the destination blockchain node. , you can directly query the blockchain node group it belongs to and encrypt the plaintext message based on the shared key corresponding to the blockchain node group to obtain the encrypted message, without the need to perform multiple encryptions to generate multiple encrypted messages. Avoid wasting computing and network resources.
- the destination blockchain node can use various methods to inform the source blockchain node of the blockchain node group to which it belongs. For example, the destination blockchain node can directly return the group ID of the corresponding blockchain node group to the source blockchain node, where the group ID of any blockchain node group can include: any area agreed or disclosed in advance.
- the identification information of the blockchain node group, the shared key corresponding to the blockchain node group, or any key identifier in the key identification cluster generated based on the shared key, and each key in the key identification cluster The key identification is obtained by encrypting or decrypting the shared key a limited number of times through the shared key.
- this method may leak the group ID of the blockchain node group, so there are security risks;
- the destination blockchain node can return to the source blockchain node the group ID of the blockchain node group encrypted based on the shared key corresponding to the shared blockchain node group;
- the destination blockchain node can return to the source blockchain node an encrypted message that has been successfully decrypted from the multiple encrypted messages previously received from the source blockchain node.
- the destination blockchain node returns msg_2 to the source blockchain node
- the source blockchain node can determine the shared key key_2 used to encrypt msg_2, and at the same time determine the blockchain node group corresponding to key_2, thereby adding the identity information of the destination blockchain node to the area. List of members of the blockchain node group.
- this method will not leak the information plaintext at the transport layer, it is assumed that the attacker simultaneously captures multiple encrypted messages previously sent by the source blockchain node to the destination blockchain node and the destination blockchain.
- the encrypted message returned by the node can therefore determine that the source blockchain node and the destination blockchain node belong to at least the same blockchain node group;
- the destination blockchain node can first re-encrypt the successfully decrypted encrypted message among the multiple encrypted messages previously received from the source blockchain node according to the shared key corresponding to the blockchain node group to which the source blockchain node belongs. To obtain the double encrypted message, and then return the double encrypted message to the source blockchain node. If multiple encrypted messages received from the source blockchain node cannot be decrypted, the same as the above two are still returned to the source blockchain node.
- the re-encrypted message has the same data format but randomly generated garbled messages. In this way, for the source blockchain node, it can calculate in advance the corresponding values of the multiple encrypted messages it previously sent to the destination blockchain node.
- Double encrypted message (obtained by calculating the shared key of an encrypted message and then encrypting the encrypted message), thereby maintaining a "blockchain node group-shared key-encrypted message-double encryption"
- the correspondence between the four "messages” allows the source blockchain node to directly determine the corresponding blockchain node group based on the double-encrypted message received from the destination blockchain node, thereby identifying it as Blockchain node group to which they belong together, and when the source blockchain node cannot match the double-encrypted message sent by the destination blockchain node from the existing correspondence, the double-encrypted message can be identified In fact, it is a garbled message randomly generated by the destination blockchain node, so it can be concluded that the destination blockchain node and the source blockchain node do not belong to any blockchain node group.
- the double-encrypted message does not appear in the multiple encrypted messages sent by the source blockchain node, it is used to indicate that "the source blockchain node and the destination blockchain node at least belong to the same zone.”
- the double encryption of "blockchain node group” is indistinguishable from the garbled message used to indicate that "the source blockchain node and the destination blockchain node do not belong to any blockchain node group", so the attacker No conclusions can be inferred based on the intercepted message itself, thus protecting the theoretical security of the transmission process against side-channel attacks that target the analysis of the ciphertext structure.
- the source blockchain node when the source blockchain node cannot determine whether there is a blockchain node group that belongs to the destination blockchain node, the source blockchain node will correspond to all the blockchain node groups it maintains. Multiple shared keys are used to encrypt plaintext messages to obtain multiple encrypted messages, and then send multiple encrypted messages to the destination blockchain node.
- this method will still leak information: the attacker intercepts multiple For encrypted messages, although the attacker cannot deduce the plaintext message through multiple encrypted messages, he can deduce the number of blockchain node groups to which the source blockchain node belongs based on the number of multiple encrypted messages (equal to The number of encrypted messages), which constitutes the reference information for restoring the member list of the blockchain node group, objectively also brings security risks.
- the source blockchain node in addition to sending encrypted messages obtained by encrypting plaintext messages using all shared keys maintained by itself, the source blockchain node will also send additional randomly generated garbled messages.
- the source block All messages sent by the chain node to the destination blockchain node not only contain multiple encrypted messages normally obtained through shared key encryption, but also mixed with a random number of garbled messages, because it is impossible for the attacker to distinguish between garbled messages and Encrypted messages, so this practice can mask multiple encrypted message volumes from an attacker to combat side-channel attacks against encrypted message volumes.
- the destination blockchain node will further encrypt the updated member list of the blockchain node group maintained by itself through the shared key corresponding to the blockchain node group and return it to the source blockchain node. to instruct the source blockchain node to update the member list of the corresponding blockchain node group.
- the member list received by the source blockchain node is a ciphertext list encrypted by the shared key
- the source blockchain node can pass The aforementioned method obtains the blockchain node group to which the destination blockchain node belongs, which means that the source blockchain node does not need to pair the ciphertext one by one according to the shared keys corresponding to the multiple blockchain node groups it maintains.
- the ciphertext list can be decrypted directly based on the determined shared key corresponding to the blockchain node group that belongs to the same destination blockchain node, saving the consumption of computing resources.
- the destination blockchain node After the destination blockchain node obtains the encrypted message using shared key encryption, it will further encrypt based on the first key corresponding to the first encrypted channel established between the blockchain relay communication network system to obtain the first layer of encryption. Encrypt the message, and then send the first encrypted message to the blockchain relay communication network system through the first encrypted channel, so that the external attacker is not only restricted by the encryption strategy based on the shared key corresponding to the blockchain node group, It will be further restricted by the encryption strategy based on a specific encrypted channel between the source blockchain node and the blockchain network communication system (the relevant key corresponding to the first encryption channel is only relayed by the source blockchain node and the blockchain communication network system), therefore, even if the attacker obtains the shared key of the blockchain node group to which the source blockchain node and the destination blockchain node belong together through external means, as long as there is no further control of the source blockchain node or The key relay nodes in the blockchain relay communication network system are still unable to recover the plaintext message by intercepting the first encrypted message, thus ensuring the security
- the shared key is maintained at each blockchain node through group key negotiation by each blockchain node in the blockchain node group.
- each blockchain node belonging to the same blockchain node group realizes joint maintenance of a shared key by performing group key negotiation in advance.
- Group key agreement is different from the end-to-end key agreement between two peers, but refers to the key agreement between at least three peers.
- the purpose is to enable at least three peers to communicate through online interaction.
- the peers jointly maintain the same shared key, while preventing the shared key from being leaked to third parties other than the at least three peers.
- the protocols corresponding to the end-to-end key negotiation involved in the embodiments of this specification may include TLS protocol, IKE (Internet key exchange, network key exchange protocol) protocol, DH (Diffie-Hellman) key exchange protocol, etc. This specification will This is not a limitation.
- each blockchain node in the blockchain node group performs group key negotiation, including: the master node in the blockchain node group communicates with each node in the blockchain node group except the master node.
- Other blockchain nodes other than the node jointly maintain the shared key through key negotiation.
- a method for group key negotiation is provided. In this method, it is first necessary to determine a master node in the blockchain node group as the host of the group key negotiation. Then, the master node will Conduct end-to-end key negotiation with other blockchain nodes (slave nodes) in the blockchain node group except the master node.
- Node A serves as the master node and wants to form a blockchain node group including Node A, Node B and Node C
- Node A can interact with Node B and Node C respectively or simultaneously.
- Key negotiation, and the shared key maintained by Node B after key negotiation is the same as the shared key maintained by Node C after key negotiation.
- Node A itself will also maintain the shared key, so that ultimately This allows Node A, Node B and Node C to maintain the same shared key, thereby jointly participating in forming a new blockchain node group.
- the master node conducts group key negotiation with any blockchain node (slave node) among the other blockchain nodes, including: the master node and any blockchain node pass
- the DH key exchange protocol generates and maintains the shared key; or, the master node and any blockchain node jointly maintain the session key through the DH key exchange protocol, and all the keys generated by the master node are
- the shared key is encrypted based on the session key and sent to any blockchain node, and the any blockchain node is used to decrypt the encrypted shared key based on the session key. to obtain the shared key.
- the master node when the master node performs key negotiation with any slave node, it can jointly maintain the same shared key directly or indirectly based on the DH key exchange protocol.
- the DH key exchange protocol is a type of A scheme for generating symmetric keys in an insecure network, which mainly uses the method of two key negotiation parties to disclose generators and publicly computable values to each other, so that each key negotiation party can calculate only the key negotiation Only the other party can learn the same key seed, thereby further generating and maintaining the same symmetric key based on the same key seed.
- the master node and the slave node can use the keys directly generated by each other through the DH key exchange protocol as a shared key, so that the master node and the slave node maintain the same shared key.
- the shared key obtained through the DH key exchange protocol each time is uncertain, in order to ensure that the master node and all other slave nodes maintain the same shared key, this is done directly through the DH key agreement protocol.
- the method of directly generating a shared key is usually only used when the master node performs key negotiation with the first slave node during the group key negotiation process. Subsequently, other methods need to be used to ensure that all slave nodes can maintain the same key. Shared key.
- the master node and the slave node can first use the key directly generated by the DH key exchange protocol as the session key for subsequent encrypted communication. At this time, the master node can use the randomly generated key.
- the symmetric key is used as a shared key (or a shared key generated through key negotiation with the first slave node) and is encrypted by the session key and sent to the slave node, so that the slave node decrypts it according to the session key maintained by itself.
- Shared key and since the session key generated directly by the DH key exchange protocol is not directly used as a shared key, but as a basis for building encrypted communication, this allows each slave node in the blockchain node group to pass This method maintains the same shared key, ultimately achieving group key agreement.
- the shared key and/or the session key are recorded in the security association policy maintained by the master node and any blockchain node.
- the association policy specifically refers to the SA (security assist) in the IKE protocol. Different SAs can be indexed through the SPI (security parameters index) field on the message to be processed.
- messages used for key negotiation can be set to be encrypted with the session key, so the relevant index fields on the messages corresponding to such messages will point to the use of Security association policy for encryption and decryption with session keys; messages used for ordinary communication can be set to be encrypted by the shared key, so the relevant index fields on the messages corresponding to such messages will point to the use of the shared key Security association policy for encryption and decryption.
- the master node performs group key negotiation with any blockchain node (slave node) among the other blockchain nodes, including: the master node generates the shared key and transfers the shared key to the shared key.
- the ciphertext key obtained by encrypting the shared key based on the public key of any blockchain node is sent to the any blockchain node; the any blockchain node encrypts the ciphertext key based on The private key of any blockchain node is decrypted to obtain the shared key.
- the key negotiation between the master node and the slave node is realized through the asymmetric encryption feature, while avoiding leaking the shared key to other third parties during the key negotiation process, so as to further realize the group operation. Key agreement.
- any other blockchain node encrypts the shared key based on the public key of the master node and returns it to the master node; the master node encrypts the shared key based on the private key of the master node.
- the encrypted shared key obtained from any other blockchain node is decrypted to obtain the shared key, it is determined that the key negotiation with any other blockchain node has been completed. .
- the slave node decrypts and obtains the shared key, although objectively both the master node and the slave node have maintained the same shared key at this time, the master node cannot actually determine that the slave node has maintained the shared key without receiving the relevant certificate.
- the slave node can further use the master node's public key to encrypt and return after decrypting the shared key. to the master node, and after the master node decrypts and obtains the shared key, it can be determined that the slave node has successfully obtained the shared key, which facilitates the arrangement of subsequent key negotiation tasks, or determines that the group key negotiation has been completed (in the determination area When all slave nodes in the blockchain node group maintain shared keys).
- the master node generates a digital signature for the ciphertext key based on the private key of the master node, and sends the digital signature to any blockchain node;
- a blockchain node verifies the digital signature based on the public key of the master node, and determines that the ciphertext key originates from the master node if the signature verification is successful.
- digital signature technology can be used to enable the master node to digitally sign the ciphertext key , and then the slave node verifies the digital signature, and determines the legitimacy of the source of the ciphertext key if the verification is successful. It also ensures that the ciphertext key has not been tampered with during the transmission process.
- the message transmission method involved in the embodiments of this specification can be implemented based on a network layer protocol or an application layer protocol, and this specification does not place any restrictions on this.
- the network layer protocol can be IPsec (Internet Protocol Security, Internet Security Protocol).
- IPsec Internet Protocol Security, Internet Security Protocol
- the encryption and decryption process based on the shared key and the corresponding decryption process all occur at the network layer, which is very important for forwarding. Efficiency has a smaller performance loss. This is because the encrypted objects in the network layer are IP messages, while the encrypted objects in the application layer are data structures defined by the application. Therefore, network layer encryption is compared to application layer encryption.
- IP messages are lightweight information carriers
- the encryption task is smaller in granularity and does not need to consume a lot of computing resources.
- the encryption scheme based on the network layer protocol has fewer information transmission links and has a higher High execution efficiency.
- network layer encryption can adapt to different upper-layer architectures, such as being shared and utilized by different applications, thus reflecting a high adaptability.
- Figure 4 is a schematic structural diagram of a device provided by an exemplary embodiment.
- the device includes a processor 402, an internal bus 404, a network interface 406, a memory 408 and a non-volatile memory 410.
- the processor 402 reads the corresponding computer program from the non-volatile memory 410 into the memory 408 and then runs it.
- the execution subject of the following processing flow is not limited to each A logic unit can also be a hardware or logic device.
- Figure 5 is a block diagram of a message transmission device provided by an exemplary embodiment.
- the device can be applied to the equipment shown in Figure 4 to implement the technical solution of this specification; the device is applied For the source blockchain node, each blockchain node in the blockchain node group to which the source blockchain node belongs maintains the same shared key; the device includes:
- Encryption unit 501 configured to perform encryption based on the sharing when the destination blockchain node corresponding to the plaintext message includes at least two blockchain nodes in the blockchain node group except the source blockchain node.
- the key encrypts the plaintext message to obtain the encrypted message.
- Sending unit 502 configured to send the encrypted message to the at least two blockchain nodes, and the at least two blockchain nodes are configured to decrypt the encrypted message based on the shared key maintained by each. to obtain the clear text message.
- the encryption unit 501 is specifically used to:
- the plaintext message is encrypted based on the shared key included in the security association policy to obtain the encrypted message.
- the at least two private keys maintained by the source blockchain node and corresponding to the at least two point-to-point encrypted channels respectively established between the at least two blockchain nodes are the shared keys;
- the encryption unit 501 is specifically used for:
- the sending unit 502 is specifically used for:
- Point-to-point encrypted channels established with the at least two blockchain nodes are respectively determined, and the encrypted messages are respectively sent to the at least two blockchain nodes based on the corresponding point-to-point encrypted channels.
- the key storage addresses of the at least two private keys on the source blockchain node are both the key storage addresses of the shared key on the source blockchain node.
- the shared key is maintained at each blockchain node through group key negotiation by each blockchain node in the blockchain node group.
- each blockchain node in the blockchain node group conducts group key negotiation, including:
- the master node in the blockchain node group jointly maintains the shared key through key negotiation with other blockchain nodes in the blockchain node group except the master node.
- the master node conducts key negotiation with any of the other blockchain nodes, including:
- the master node and any blockchain node generate and maintain the shared key through a DH key exchange protocol; or,
- the master node and any blockchain node jointly maintain a session key through the DH key exchange protocol, and encrypt the shared key generated by the master node based on the session key and send it to the Any blockchain node, the any blockchain node is configured to decrypt the encrypted shared key based on the session key to obtain the shared key.
- the shared key and/or the session key are recorded in the security association policy maintained by the master node and any blockchain node.
- the master node conducts key negotiation with any of the other blockchain nodes, including:
- the master node generates the shared key and sends the ciphertext key obtained by encrypting the shared key based on the public key of any blockchain node to the any blockchain node;
- the any blockchain node decrypts the ciphertext key based on the private key of any blockchain node to obtain the shared key.
- Optional also includes:
- the master node generates a digital signature for the ciphertext key based on the private key of the master node, and sends the digital signature to any blockchain node;
- the any blockchain node verifies the digital signature based on the public key of the master node, and determines that the ciphertext key originates from the master node if the signature verification is successful.
- each blockchain node in the blockchain node group is in the same blockchain network or different blockchain networks.
- the different blockchain networks are homogeneous or heterogeneous to each other.
- the device is implemented based on a network layer protocol.
- PLD Programmable Logic Device
- FPGA Field Programmable Gate Array
- HDL Hardware Description Language
- the controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor. , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers and embedded microcontrollers.
- controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, For Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic.
- the controller in addition to implementing the controller in the form of pure computer-readable program code, the controller can be completely programmed with logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded logic by logically programming the method steps. Microcontroller, etc. to achieve the same function. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as structures within hardware components as well as software modules implementing the methods.
- the systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions.
- a typical implementation device is a server system.
- the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, or a personal digital assistant. , media player, navigation device, email device, game console, tablet, wearable device, or a combination of any of these devices.
- the functions are divided into various modules and described separately.
- the functions of each module can be implemented in the same or multiple software and/or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. .
- the device embodiments described above are only illustrative.
- the division of the units is only a logical function division. In actual implementation, there may be other division methods.
- multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented.
- the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.
- These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions
- the device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.
- These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device.
- Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.
- a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
- processors CPUs
- input/output interfaces network interfaces
- memory volatile and non-volatile memory
- Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
- RAM random access memory
- ROM read-only memory
- flash RAM flash random access memory
- Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information.
- Information may be computer-readable instructions, data structures, modules of programs, or other data.
- Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and read-only memory.
- PRAM phase change memory
- SRAM static random access memory
- DRAM dynamic random access memory
- RAM random access memory
- read-only memory read-only memory
- ROM read-only memory
- EEPROM electrically erasable programmable read-only memory
- flash memory or other memory technology
- compact disc read-only memory CD-ROM
- DVD digital versatile disc
- Magnetic tape magnetic tape storage, graphene storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device.
- computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
- one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. Product form.
- computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, etc.
- program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
- program modules may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network.
- program modules may be located in both local and remote computer storage media including storage devices.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
Claims (16)
- 一种消息传输方法,应用于源区块链节点,所述源区块链节点所属的区块链节点组中的各区块链节点均维护有相同的共享密钥;所述方法包括:在明文消息对应的目的区块链节点包括所述区块链节点组中除所述源区块链节点以外的至少两个区块链节点的情况下,基于所述共享密钥对所述明文消息进行加密以获取加密消息;将所述加密消息发送至所述至少两个区块链节点,所述至少两个区块链节点用于基于各自维护的所述共享密钥对所述加密消息进行解密以获取所述明文消息。
- 根据权利要求1所述的方法,所述基于所述共享密钥对所述明文消息进行加密以获取加密消息,包括:基于所述明文消息包含的安全参数索引,确定对应于所述安全参数索引的安全关联策略;基于所述安全关联策略中包含的所述共享密钥对所述明文消息进行加密以获取所述加密消息。
- 根据权利要求1所述的方法,所述源区块链节点维护的与所述至少两个区块链节点之间分别建立的至少两个点对点加密信道对应的至少两个专用密钥均为所述共享密钥;所述基于所述共享密钥对明文消息进行加密以获取加密消息,包括:基于所述至少两个专用密钥中的任一密钥,对明文消息进行加密以获取所述加密消息;所述将所述加密消息发送至所述至少两个区块链节点,包括:分别确定与所述至少两个区块链节点之间建立的点对点加密信道,将所述加密消息基于相应的点对点加密信道分别发送至所述至少两个区块链节点。
- 根据权利要求3所述的方法,所述至少两个专用密钥于所述源区块链节点的密钥存储地址均为所述共享密钥于所述源区块链节点的密钥存储地址。
- 根据权利要求1所述的方法,所述共享密钥通过所述区块链节点组中的各区块链节点进行组密钥协商以维护于所述各区块链节点。
- 根据权利要求5所述的方法,所述区块链节点组中的各区块链节点进行组密钥协商,包括:所述区块链节点组中的主节点分别与所述区块链节点组中除所述主节点以外的其他区块链节点通过密钥协商以共同维护所述共享密钥。
- 根据权利要求6所述的方法,所述主节点与所述其他区块链节点中的任一区块链节点进行密钥协商,包括:所述主节点与所述任一区块链节点通过DH密钥交换协议生成并维护所述共享密钥;或者,所述主节点与所述任一区块链节点通过DH密钥交换协议共同维护会话密钥,并将所述主节点生成的所述共享密钥基于所述会话密钥加密后发送至所述任一区块链节点,所述任一区块链节点用于将加密后的所述共享密钥基于所述会话密钥进行解密以获取所述共享密钥。
- 根据权利要求7所述的方法,所述共享密钥和/或所述会话密钥记录在所述主节点与所述任一区块链节点维护的安全关联策略中。
- 根据权利要求6所述的方法,所述主节点与所述其他区块链节点中的任一区块链节点进行密钥协商,包括:所述主节点生成所述共享密钥,并将所述共享密钥基于所述任一区块链节点的公钥加密得到的密文密钥发送至所述任一区块链节点;所述任一区块链节点将所述密文密钥基于所述任一区块链节点的私钥进行解密以获取所述共享密钥。
- 根据权利要求9所述的方法,还包括:所述主节点基于所述主节点的私钥为所述密文密钥生成数字签名,并将所述数字签名发送至所述任一区块链节点;所述任一区块链节点基于所述主节点的公钥对所述数字签名进行验签,在验签成功的情况下确定所述密文密钥来源于所述主节点。
- 根据权利要求1所述的方法,所述区块链节点组中的各区块链节点处于相同的区块链网络或不同的区块链网络。
- 根据权利要求10所述的方法,所述不同的区块链网络之间彼此同构或异构。
- 根据权利要求1所述的方法,所述方法基于网络层协议实现。
- 一种消息传输装置,应用于源区块链节点,所述源区块链节点所属的区块链节点组中的各区块链节点均维护有相同的共享密钥;所述装置包括:加密单元,用于在明文消息对应的目的区块链节点包括所述区块链节点组中除所述源区块链节点以外的至少两个区块链节点的情况下,基于所述共享密钥对所述明文消息进行加密以获取加密消息;发送单元,用于将所述加密消息发送至所述至少两个区块链节点,所述至少两个区块链节点用于基于各自维护的所述共享密钥对所述加密消息进行解密以获取所述明文消息。
- 一种电子设备,包括:处理器;用于存储处理器可执行指令的存储器;其中,所述处理器通过运行所述可执行指令以实现如权利要求1-13中任一项所述的方法。
- 一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如权利要求1-13中任一项所述方法的步骤。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210760927.XA CN115174188A (zh) | 2022-06-29 | 2022-06-29 | 一种消息传输方法、装置、电子设备和存储介质 |
| CN202210760927.X | 2022-06-29 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2024001037A1 true WO2024001037A1 (zh) | 2024-01-04 |
Family
ID=83489420
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2022/135607 Ceased WO2024001037A1 (zh) | 2022-06-29 | 2022-11-30 | 一种消息传输方法、装置、电子设备和存储介质 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN115174188A (zh) |
| WO (1) | WO2024001037A1 (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN119416231A (zh) * | 2024-09-06 | 2025-02-11 | 天冕信息技术(深圳)有限公司 | 数据加密方法、装置、服务器及存储介质 |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115174188A (zh) * | 2022-06-29 | 2022-10-11 | 蚂蚁区块链科技(上海)有限公司 | 一种消息传输方法、装置、电子设备和存储介质 |
| CN116319840A (zh) * | 2023-02-13 | 2023-06-23 | 远光软件股份有限公司 | 一种数据跨链共享方法、系统和电子设备 |
| CN119628823A (zh) * | 2023-09-13 | 2025-03-14 | 华为技术有限公司 | 密钥管理方法、装置、设备、存储介质及程序产品 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108712261A (zh) * | 2018-05-10 | 2018-10-26 | 杭州智块网络科技有限公司 | 一种基于区块链的密钥生成方法、装置及介质 |
| KR20200048722A (ko) * | 2018-10-30 | 2020-05-08 | 주식회사 머니브레인 | 블록체인에 기반한, 분산형 컴퓨팅 자원 공유 시스템 상에서의 워킹 그룹별 동일한 키를 사용하는 보안 통신 제공 방법 |
| CN113992418A (zh) * | 2021-10-29 | 2022-01-28 | 南京联了么信息技术有限公司 | 一种基于区块链技术的IoT设备管理方法 |
| CN114285555A (zh) * | 2021-12-15 | 2022-04-05 | 支付宝(杭州)信息技术有限公司 | 基于区块链的组播方法及装置 |
| CN115174188A (zh) * | 2022-06-29 | 2022-10-11 | 蚂蚁区块链科技(上海)有限公司 | 一种消息传输方法、装置、电子设备和存储介质 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR102034449B1 (ko) * | 2017-12-12 | 2019-10-21 | 주식회사 디지캡 | 콘텐츠 블록체인에서의 콘텐츠 암호키 관리 및 배포 방법 |
| CN111404950B (zh) * | 2020-03-23 | 2021-12-10 | 腾讯科技(深圳)有限公司 | 一种基于区块链网络的信息共享方法、装置和相关设备 |
| CN112131316B (zh) * | 2020-11-20 | 2021-02-12 | 腾讯科技(深圳)有限公司 | 应用于区块链系统的数据处理方法及装置 |
-
2022
- 2022-06-29 CN CN202210760927.XA patent/CN115174188A/zh active Pending
- 2022-11-30 WO PCT/CN2022/135607 patent/WO2024001037A1/zh not_active Ceased
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108712261A (zh) * | 2018-05-10 | 2018-10-26 | 杭州智块网络科技有限公司 | 一种基于区块链的密钥生成方法、装置及介质 |
| KR20200048722A (ko) * | 2018-10-30 | 2020-05-08 | 주식회사 머니브레인 | 블록체인에 기반한, 분산형 컴퓨팅 자원 공유 시스템 상에서의 워킹 그룹별 동일한 키를 사용하는 보안 통신 제공 방법 |
| CN113992418A (zh) * | 2021-10-29 | 2022-01-28 | 南京联了么信息技术有限公司 | 一种基于区块链技术的IoT设备管理方法 |
| CN114285555A (zh) * | 2021-12-15 | 2022-04-05 | 支付宝(杭州)信息技术有限公司 | 基于区块链的组播方法及装置 |
| CN115174188A (zh) * | 2022-06-29 | 2022-10-11 | 蚂蚁区块链科技(上海)有限公司 | 一种消息传输方法、装置、电子设备和存储介质 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN119416231A (zh) * | 2024-09-06 | 2025-02-11 | 天冕信息技术(深圳)有限公司 | 数据加密方法、装置、服务器及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115174188A (zh) | 2022-10-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11316677B2 (en) | Quantum key distribution node apparatus and method for quantum key distribution thereof | |
| CN104160674B (zh) | 内容中心网络 | |
| US11683160B2 (en) | Encrypted group communications | |
| TWI714270B (zh) | 在用戶和可信計算群集之間建立可信通道的方法及裝置 | |
| CN115174188A (zh) | 一种消息传输方法、装置、电子设备和存储介质 | |
| CN103036872B (zh) | 数据传输的加密和解密方法、设备及系统 | |
| US20170149748A1 (en) | Secure Group Messaging and Data Steaming | |
| CN106487749A (zh) | 密钥生成方法及装置 | |
| WO2024001035A1 (zh) | 基于区块链中继通信网络系统的消息传输方法及装置 | |
| WO2020252611A1 (zh) | 一种数据交互方法及相关设备 | |
| CN115174267A (zh) | 一种tls协议协商方法、设备及介质 | |
| US20140181508A1 (en) | Communication device and computer program product | |
| WO2020237880A1 (zh) | 基于非对称加密技术的数据交换方法、发送终端和计算机可读存储介质 | |
| CN115941278A (zh) | 数据传输方法、装置、电子设备和计算机可读介质 | |
| WO2024001022A1 (zh) | 跨子网调用 | |
| CN114142995B (zh) | 面向区块链中继通信网络的密钥安全分发方法及装置 | |
| US12015702B2 (en) | Key sharing for media frames using blockchain | |
| CN107425959A (zh) | 一种实现加密处理的方法、系统、客户端及服务端 | |
| WO2016134631A1 (zh) | 一种OpenFlow报文的处理方法及网元 | |
| CN109905310B (zh) | 数据传输方法、装置、电子设备 | |
| CN120582782B (zh) | 基于量子密钥的网关拓扑组网方法、装置、设备和介质 | |
| US20200177557A1 (en) | System and method for providing end-to-end security of data and metadata | |
| US20240356909A1 (en) | Signing messages using public key cryptography and certificate verification | |
| CN115567195A (zh) | 安全通信方法、客户端、服务器、终端和网络侧设备 | |
| WO2023024540A1 (zh) | 处理报文、获取sa信息的方法、装置、系统及介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 22949116 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 22949116 Country of ref document: EP Kind code of ref document: A1 |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 22949116 Country of ref document: EP Kind code of ref document: A1 |
|
| 32PN | Ep: public notification in the ep bulletin as address of the adressee cannot be established |
Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 25.06.2025) |