A cross-domain information interaction method based on blockchain cross-chain communication structure

Abstract

The present invention relates to a cross-domain information interaction method based on a cross-chain communication structure of a blockchain, and belongs to the field of information interaction technology. The method realizes cross-domain identity authentication and message transmission by setting a messenger node on the alliance chain maintained by each of the two parties that need to interact, and combining it with a signature verification method based on the Fiat-Shamir transformation and the elliptic curve integrated encryption scheme. As a light node, the messenger node only participates in cross-chain communication to avoid affecting the efficiency of intra-chain communication. The elliptic curve integrated encryption scheme provides a shorter key length and faster computing speed, optimizes network resources, and improves transaction processing efficiency. The method is safe, efficient, and scalable, and is suitable for scenarios where different service providers use independent servers or blockchain platforms to maintain communications within their domains and want to conduct cross-domain communications, providing a new solution for cross-domain information interaction.

Description

Technical Field

[0001] The present invention belongs to the field of information interaction technology and relates to a cross-domain information interaction method based on a blockchain cross-chain communication structure. Background Art

[0002] More frequent interactions between information service sectors. The three mainstream cross-domain authentication schemes currently available each have their own advantages and disadvantages. Symmetric key-based authentication architectures offer fast encryption and decryption, are simple to implement, and require no complex infrastructure. However, they suffer from poor scalability and relatively low key security. PKI-based authentication architectures avoid the high difficulty of symmetric key management and offer good scalability, but are complex to implement and rely on certificate authorities for trust. Identity-based authentication frameworks simplify key management by entity identity, but rely on the security of the identity system and are complex to deploy initially. Overall, these schemes fail to strike a good balance between effectiveness, identity and key security, and cross-domain communication efficiency, and are unable to meet all user needs for cross-domain information interaction. Solutions combining cross-domain information interaction with blockchain are also evolving.

[0003] Blockchain integrates cryptography, peer-to-peer networks, and smart contracts. Featuring transparency, immutability, and traceability, it provides a solution for the secure and efficient exchange of information across diverse information service sectors. A consortium blockchain, comprised of a group of organizations, is a permissioned blockchain. Unlike public blockchains, which offer open and unrestricted participation, consortium blockchains are open only to members who have been granted network access. This feature of consortium chains provides enhanced security and confidentiality for businesses that need to conceal sensitive information and comply with privacy regulations.

[0004] However, user demand for cross-blockchain interaction is also increasing. Existing cross-domain solutions often replace nodes in different domains, transforming them into separate nodes within the same consortium chain. However, this approach is not practical and has two significant limitations. First, different service providers often use different servers, making it difficult to integrate them into a single consortium chain. Second, this approach leads to centralized data management, making it difficult to meet user demands for data autonomy and privacy. Furthermore, due to the multi-dimensional heterogeneity of blockchain platform technology, services and data are exclusive within their respective chains, making cross-platform collaboration difficult. Furthermore, the Cosmos relay chain solution, currently attracting widespread attention, has the limitation that information transmission and transactions require two cross-chain information exchanges, resulting in communication time losses.

[0005] The elliptic curve integrated cryptography scheme, based on the elliptic curve discrete logarithm problem, is extremely difficult to crack and provides strong cryptographic protection for cross-chain communications, preventing identity forgery and data tampering. Compared to traditional algorithms like RSA, the elliptic curve integrated cryptography scheme generates shorter keys and faster computations, making it suitable for cross-chain communication scenarios that require efficient processing of large amounts of data. Furthermore, the elliptic curve integrated cryptography scheme is highly compatible with existing blockchain systems and can be seamlessly integrated with various consensus mechanisms and protocols in cross-chain communication, enhancing the scalability of the cross-chain ecosystem. Summary of the Invention

[0006] In view of this, the purpose of this invention is to provide a cross-domain information interaction method based on the cross-chain communication structure of blockchain. It realizes cross-domain identity authentication and fast message communication; at the same time, it optimizes cross-chain communication, reduces the delay of cross-domain information transmission, ensures more efficient intra-chain and cross-chain communication, avoids the impact of cross-chain operations on intra-chain information interaction performance, and enhances the scalability and compatibility of the cross-chain platform; in addition, it ensures the security and authenticity of data in cross-domain information interaction, and prevents identity forgery and data tampering.

[0007] In order to achieve the above object, the present invention provides the following technical solutions:

[0008] The present invention combines the cross-chain and cross-domain scenarios of blockchain, sets users as nodes in the alliance chain, and different users in the same service domain form an alliance chain. They interact with users in other service domains across domains and are considered as nodes of different alliance chains for cross-chain interaction. A special light node, the messenger node, is set up, and the messenger node key is distributed using a secret sharing method. A signature verification method based on Fiat-Shamir transformation and elliptic curve integrated encryption is designed for identity authentication, and symmetric encryption is used for fast encrypted transmission. Combining the messenger node and the signature verification method, a cross-domain information interaction method based on the cross-chain communication structure of the blockchain is designed. The messenger node is used to transmit cross-domain messages, and the signature verification ensures the reliability of the message source and the efficiency of message communication.

[0009] The method specifically comprises the following steps:

[0010] S1: Design messenger node;

[0011] The two parties that need to exchange cross-domain information set up a messenger node on the other party's consortium chain, maintaining the identity-related information of the node on the chain for cross-chain information exchange. At the same time, through a secret sharing scheme, the private key of the messenger node is maintained to ensure the security of the messenger node identity, thereby ensuring the security of the entire cross-domain information exchange process.

[0012] S2: Design a signature verification method based on Fiat-Shamir transform and elliptic curve integrated encryption scheme;

[0013] Using an elliptic curve integrated encryption scheme, a temporary public-private key pair is generated at the sender. The temporary private key is used to encrypt the hash value of the plaintext to generate a digest signature. The temporary private key is then used with the recipient's public key for key negotiation to generate a negotiated key. A difficult function is selected using the Fiat-Shamir transform to map the fixed random number and key to a pseudo-random number, providing security for random numbers, messages to be transmitted, signature public keys, and other information during cross-chain information exchange.

[0014] S3: Design a cross-domain information interaction method based on the blockchain cross-chain communication structure.

[0015] Combining the messenger node and signature verification method, the signature, signing key, and encrypted message are obtained to verify the authenticity of the message source. After verification, the symmetric key is calculated and the message is decrypted to obtain the plaintext message. The cross-chain interaction process is designed to complete secure and efficient cross-domain message interaction.

[0016] Furthermore, in S1, a method for generating a messenger node is designed, which specifically includes the following steps:

[0017] S1.1: Each service domain maintains a consortium chain within its own domain and a corresponding messenger node within the domains where cross-domain information exchange is required. Service domain A maintains consortium chain A, and service domain B maintains consortium chain B. The messenger node maintained by service domain A in service domain B belongs to service domain A and is located on consortium chain B. The messenger node maintained by service domain B in service domain A belongs to service domain B and is located on consortium chain A. Each consortium chain must select a non-zero point on the elliptic curve Curve25519 as its base point.

[0018] S1.2: Each node on the consortium chain generates its own identity random number according to the selected algorithm, multiplies this identity random number by the base point of the consortium chain to obtain the corresponding identity random point. This identity random point is then sent to the messenger node maintained by the consortium chain to which the domain belongs and which requires cross-domain communication.

[0019] S1.3: The messenger node needs to save its own public and private key pair, as well as the identity random points of all nodes on the consortium chain maintained by its service domain.

[0020] S1.4: The public key of the messenger node is made public in the alliance chain B, and the private key is distributed to multiple nodes in the alliance chain A for joint custody using a secret sharing algorithm. A certain number of nodes on the alliance chain A are required to work together to recover the private key.

[0021] Furthermore, in S2, a signature verification scheme based on Fiat-Shamir transform and elliptic curve integrated encryption is designed, which specifically includes the following steps:

[0022] S2.1: The sender node A in the alliance chain A generates its own one-time private key sk and sends it to the messenger node A in the service domain B in the alliance chain A. β Request the identity random point R of the receiving node B B and messenger node A β Current public key PK β , construct the message m to be sent.

[0023] S2.2: Generate a signature Sig based on the information obtained above, negotiate the key Key, and pass the obtained symmetric key K sym The message m to be sent is encrypted to generate ciphertext c. The generated triple (Sig, pk, c) containing the signature Sig, the signature public key pk and the ciphertext c is sent to the receiving node B.

[0024] S2.3: After the service domain B where the receiving node B is located receives the triplet (Sig, pk, c) containing the signature Sig, the signature public key pk and the ciphertext c, any node on the alliance chain B in the service domain B where the receiving node B is located performs signature verification.

[0025] S2.4: If the signature authentication passes, the subsequent message decryption process begins;

[0026] S2.5: If the signature authentication fails, the message is discarded.

[0027] S2.6: After the signature authentication is passed, the receiving node B parses the intermediate process according to the received triple (Sig, pk, c) containing the signature Sig, the signature public key pk and the ciphertext c to obtain the negotiated symmetric key K sym , decrypt the ciphertext c and get the plaintext message m.

[0028] Furthermore, S2.2 specifically includes the following steps:

[0029] S2.2.1: Input is the one-time private key sk and identity random number r of the sender node A on the consortium chain A in the service domain A that wants to conduct cross-domain communication with the receiver node B on the consortium chain B in the service domain B. A ; Messenger node A on consortium chain A belongs to service domain B β Public key PK β ; The identity random point R of the receiver node B on the alliance chain B in the service domain B B ; Message m to be sent.

[0030] S2.2.2: Calculate the hash function SHA512 on the one-time private key sk to obtain a 512-bit binary number e = SHA512(sk) = (e0, e1, ..., e 511). Divide the binary number e obtained by hashing into two parts. The first part is LE:e0,e1...e 255 , the second part is RE = e 256 ,e 257 ,...,e 511 , let s2=(e 256 ,e 257 ,...,e 511 ). The first part LE:e0,e1...e 255 Used to generate the public key, and the second part s2 is used to generate a pseudo-random number.

[0031] S2.2.3: For the first part LE:e0,e1...e 255 Perform bitwise operations and convert LE:e0,e1...e 255 Set e0, e1 and e2 in 0, and set e 254 Set to 1, e 255 Set to 0, calculate the private key scalar s1=(0,0,0,e3,...,e 253 ,1,0);

[0032] S2.2.4: Compare the private key s1 with the identity random number r of the sender node A A Add up to get sk A =s1+r A , where sk A It is the actual private key used for signing. Multiply the private key scalar s1 with the alliance chain A base point G1 to get pk= V , V = s1 × G1, where pk is the public key used by the message sender to sign. V Represents the ordinate of the intermediate variable V on the elliptic curve Curve25519 in the Cartesian coordinate system, and records the intermediate variable temp1 = Vx||(Vx·Vy) generated when the point verification operation is performed here, where Vx and Vy respectively represent the horizontal and vertical coordinate parameters of the Cartesian coordinate system corresponding to the intermediate variable V.

[0033] S2.2.5: Messenger Node A maintained by Service Domain B on Alliance Chain A β Public key PK β and the identity random point R of the receiving node B B After doing the point addition operation and the actual private key sk of the sender node A A Multiply, according to the ECDH key agreement method, Key = sk A ×(PK β +R B ) to obtain the negotiated key Key.

[0034] S2.2.6: Use the agreed symmetric key algorithm f to convert the negotiated key Key into the symmetric key K sym =f(Key).

[0035] S2.2.7: Using the symmetric key K sym To encrypt the message m, we get the ciphertext c = Enc(m,K sym ).

[0036] S2.2.8: Concatenate the second part s2 obtained after calculating the hash function on the one-time private key sk and the ciphertext c and calculate the hash function to obtain a pseudo-random number r = SHA512(s2||c).

[0037] S2.2.9: Multiply the generated pseudo-random number r by the base point G1 of the alliance chain A to calculate the pseudo-random point R = r × G1. Take the vertical coordinate of the pseudo-random point R in the Cartesian coordinate system to obtain part of the signature. R , and record the intermediate variable temp2 = Rx||(Rx·Ry) generated when the point verification operation is performed here, where Rx and Ry represent the horizontal coordinate parameters and vertical coordinate parameters on the Cartesian coordinate system corresponding to the pseudo-random point R, respectively.

[0038] S2.2.10: Replace part of the signature R , signature public key pk, and ciphertext c are concatenated and passed through the hash function to generate the scalar h = SHA512 ( R ||pk||c)(modp), where p is a chosen prime number.

[0039] S2.2.11: Combine the generated pseudo-random number r with the scalar h and the private key sk of the sender node A A The result of the dot product is added to calculate the other part of the signature q = r + h sk A (modp), where p is a chosen prime number.

[0040] S2.2.12: Use part of a signature R , based on the other part q of the calculated signature and the two intermediate variables temp1 and temp2 obtained by the point verification operation, the signature Sig is generated. R ||q||temp1||temp2, and transmit the triple (Sig, pk, c) containing the signature Sig, the signature public key pk and the message ciphertext c to the alliance chain B through the oracle or cross-link router.

[0041] Furthermore, S2.3 specifically includes the following steps:

[0042] S2.3.1: The input is a triple (Sig, pk, c) containing the signature Sig, the signature public key pk, and the message ciphertext c, which is claimed to come from the sender node A in the alliance chain A; the identity random point R of the sender node A A .

[0043] S2.3.2: According to the signature Sig in the triple R Restore the pseudo-random point R, and then restore the actual public key pk of the sender node A based on the signature public key pk A Part of V.

[0044] S2.3.3: Calculate and generate scalar h = SHA512( R ||pk||c)(modp), where R is the vertical coordinate of the pseudo-random point R in the Cartesian coordinate system, pk is the public key of the signature performed by the sender node, c is the message ciphertext, and p is the selected prime number.

[0045] S2.3.4: According to the actual public key pk of the sender node A A A part of V and the identity of the sender node A is a random point R A Recover the actual signature public key pk A .

[0046] S2.3.5: Verify -q×G1+h×pk A +R is equal to the zero point (infinity point). If they are equal, the verification is successful, confirming that the message is sent by the sender node A. Where q is the part of the signature recovered from the signature Sig, G1 is the base point selected by chain A, h is the calculated scalar, and pk A is the actual public key of the sender node A, and R is the pseudo-random point recovered from the signature Sig.

[0047] Furthermore, S2.6 specifically includes the following steps:

[0048] S2.6.1: The input is the other two parts of the triple (Sig, pk, c) in addition to the signature Sig, the signature public key pk and the encrypted ciphertext c.

[0049] S2.6.2: Recover the sender A’s actual public key pk based on the signature public key pk A Part of V.

[0050] S2.6.3: According to the actual public key pk A A part of V and the identity of the sender node A is a random point R A Recover the actual signature public key pk A .

[0051] S2.6.4: Restore the messenger node A maintained by service domain B in consortium chain A together with other nodes according to the secret sharing algorithm n-out-of-k β The private key sk β and the identity random number r of the receiving node B B Add. Using ECDH key negotiation principle Key = pk A ×(sk β +r B ), recover the negotiated key.

[0052] S2.6.5: Convert Key to a symmetric key K using a pre-agreed function f sym =f(Key).

[0053] S2.6.6: Using a symmetric key K sym Decrypt the ciphertext c and get the plaintext message m=Enc(c,K sym ).

[0054] The above process can perform batch signing and encryption as well as signature verification and decryption, with the input being the one-time temporary private keys sk1, sk2, ...sk of n nodes. i ,...,sk m and identity random numbers r1, r2, ..., r i ,...,r n ; Messenger node A maintained by service domain B on alliance chain A β Public key PK β ; The identity of the receiving node B is a random point R B ; Messages to be sent m1, m2, ..., m i ,...,m n Repeat the above signature encryption process n times to generate n triples (Sig i ,pk i ,c i Repeat n times, use the verification signature and decryption algorithm to authenticate the sender's identity for each triple, and for each ciphertext c that passes the verification i Use ECDH to recover the negotiated key and decrypt the plaintext m i , where i represents the i-th triplet.

[0055] Furthermore, in S3, a cross-domain information interaction method based on the cross-chain communication structure of the blockchain is designed. Specifically, it includes the following steps:

[0056] S3.1: A consortium chain A is maintained in service domain A, and a consortium chain B is maintained in service domain B. Assuming that service domain A and service domain B need to interact across domains, service domain A needs to maintain a messenger node B on consortium chain B. α, service domain B needs to maintain a messenger node A on alliance chain A β The messenger node will distribute its private key to the nodes in its service domain based on the secret sharing algorithm.

[0057] S3.2: If the sender node A wants to conduct cross-domain communication, it sends a message to the messenger node A on the alliance chain A maintained by the service domain A, which corresponds to the service domain B where the receiver node B is located. β Initiate a request from messenger node A β Get the identity random point R of the receiving node B B and messenger node A β The current public key PK β , and pay a certain deposit to the messenger node.

[0058] S3.3: Use the signature verification method designed in S2 to sign and encrypt the message to generate transaction T sign +T Enc , generate a triple (Sig, pk, c) containing the signature Sig, the signature public key pk, and the message ciphertext c, and include it in the smart contract.

[0059] S3.4: The triplet generated after signing and encryption is consensus-based on the consortium chain where the sender node is located and recorded on the chain to generate record T Consenses ;

[0060] S3.5: Messenger Node A β Read the on-chain triplet to transfer information between the two domains.

[0061] S3.6: The service domain B where the receiver node B is located receives the messenger node A β The message T of the triple (Sig, pk, c) transmitted from service domain A Deliver , any node in service domain B verifies whether the message source is correct. If correct, it constructs record T verify , write to the buffer pool and wait until the consensus is on the chain.

[0062] S3.7: The nodes in service domain B will T verify Consensus on the chain.

[0063] S3.8: The receiving node B obtains the triplet in the message from the alliance chain B in the service domain B, decrypts it, and constructs the record T Dec , waiting for consensus to be uploaded to the chain. At the same time, after receiving the request, the receiving node B will notify the messenger node A β After a certain period of time, the deposit will be returned to the sender node A (if a handling fee is set, the deposit will not be returned). This completes the message exchange.

[0064] The beneficial effects of the present invention are:

[0065] (1) Compared with the common cross-domain solutions, the present invention combines cross-chain blockchain and cross-domain information interaction scenarios, which is more in line with the actual application scenarios in which different service providers use independent servers or blockchain platforms to maintain communications within the domain, and has compatibility and scalability. The present invention is based on the concept of light nodes on the blockchain, sets up messenger nodes, and uses messenger nodes as a medium for cross-chain interactive communications, so as to avoid cross-chain interactive communications affecting the efficiency of intra-chain communications as much as possible. The messenger node is only active during cross-chain communications. At the same time, the messenger node can host or store possible transaction fees (deposits), and as a bridge for cross-domain communications, it can more quickly complete the tasks of finding communication targets and verifying the identities of communication parties in cross-chain communications.

[0066] (2) The present invention ensures the security of the cross-chain communication process by designing a signature verification method based on Fiat-Shamir transformation and elliptic curve integrated encryption. Identity authentication and information transmission within the blockchain rely on the consensus protocol and the matching mechanism of public and private keys. The security of authentication and information transmission between chains is guaranteed by messenger nodes and elliptic curve integrated encryption. At the same time, the private key of the messenger node is frequently updated, which can effectively resist forgery attacks, SOV attacks, replay attacks and side channel attacks.

[0067] (3) This invention applies messenger nodes and signature verification methods to the fields of identity authentication and message transmission in cross-chain communication, ensuring the overall cross-chain communication performance. Compared with traditional encryption algorithms, the use of elliptic curve integrated encryption schemes provides shorter key lengths and faster computing speeds. While ensuring the integrity and credibility of cross-chain communication messages, it can optimize network resources, reduce the time and energy consumption of cross-chain operations, and improve transaction processing efficiency. It also combines cross-chain blockchains with cross-domain information interaction to ensure the security and efficiency of cross-domain information interaction.

[0068] Other advantages, objects, and features of the present invention will be described in part in the following description and, in part, will be apparent to those skilled in the art upon examination of the following description or may be learned from practice of the present invention. The objects and other advantages of the present invention may be realized and obtained through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] In order to make the purpose, technical solutions and advantages of the present invention more clear, the present invention will be described in detail below with reference to the accompanying drawings, in which:

[0070] Figure 1 This is a structural diagram of the cross-domain information interaction method based on the blockchain communication structure;

[0071] Figure 2Flowchart for signature and message encryption based on Fiat-Shamir and elliptic curve integrated encryption scheme;

[0072] Figure 3 Flowchart for signature verification and message decryption based on Fiat-Shamir and elliptic curve integrated encryption scheme;

[0073] Figure 4 This is a flow chart of a cross-domain information interaction method based on a blockchain cross-chain communication structure that combines messenger nodes and signature verification methods. DETAILED DESCRIPTION

[0074] The following describes the embodiments of the present invention by means of specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present invention, and the following embodiments and features in the embodiments can be combined with each other without conflict.

[0075] Among them, the accompanying drawings are only for illustrative purposes and represent only schematic diagrams rather than actual pictures, and should not be understood as limiting the present invention. In order to better illustrate the embodiments of the present invention, some parts of the accompanying drawings may be omitted, enlarged or reduced, and do not represent the dimensions of actual products. For those skilled in the art, it is understandable that some well-known structures and their descriptions may be omitted in the accompanying drawings.

[0076] The same or similar numbers in the drawings of the embodiments of the present invention correspond to the same or similar parts; in the description of the present invention, it should be understood that if there are terms such as "upper", "lower", "left", "right", "front", "back", etc. indicating directions or positional relationships, they are based on the directions or positional relationships shown in the drawings. They are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific direction, be constructed and operate in a specific direction. Therefore, the terms describing the positional relationship in the drawings are only used for illustrative purposes and cannot be understood as limiting the present invention. For ordinary technicians in this field, the specific meanings of the above terms can be understood according to specific circumstances.

[0077] like Figure 1 Figure 2 shows the structure of a cross-domain information exchange method based on blockchain communication architecture. It consists of two service domains that require cross-domain information exchange. Each service domain maintains a consortium chain within its own domain and a messenger node within the other domain. The private key of the messenger node is shared by all nodes within the service domain. The messenger node is responsible for storing information about nodes on the consortium chain within the service domain and transmitting cross-domain information.

[0078] This method first designs a method for generating a messenger node. Both parties requiring cross-domain communication set up a messenger node on the other party's consortium chain, maintaining the identity-related information of the node on the chain for cross-chain information exchange. Simultaneously, through a secret sharing scheme, the private key of the messenger node is maintained, ensuring the security of the messenger node information and, therefore, the security of the entire cross-domain information exchange process. Next, a signature verification method based on the Fiat-Shamir transform and elliptic curve integrated encryption scheme is designed. Finally, combining the messenger node and signature verification method, a cross-domain information exchange method based on the blockchain cross-chain communication structure is designed to achieve secure and efficient cross-domain information exchange.

[0079] Design of a method for generating a messenger node so that service domain A maintains messenger node B in service domain B α For example, the specific process is as follows:

[0080] The first step is to maintain a consortium chain A in service domain A and a consortium chain B in service domain B. Consortium chain A needs to maintain a messenger node B on consortium chain B. α Select G1 as the base point of chain A and G2 as the base point of chain B. G1 and G2 are different non-zero points on the selected elliptic curve, such as Curve25519.

[0081] In the second step, each node in the alliance chain A maintains and generates an identity random number r i , used to calculate the identity random point R i =r i ×G1, and randomly point the identity R i Sent to the messenger node B maintained by alliance chain A in alliance chain B α Messenger Node B α The computing power is jointly maintained by alliance chain A.

[0082] Step 3: Messenger Node B α Maintain two keys: Messenger Node B α The public-private key pair (PK α ,SK α ) and the identity random number r of all nodes in the alliance chain A i , where i represents the node numbered i in the alliance chain A. In order to ensure the security of the system, the messenger node B α The key needs to be updated from time to time. When a node on alliance chain B needs to exchange information with a node on alliance chain A, it will send a message to the messenger node B maintained by service domain A in alliance chain B. α Request the current public key PK α The identity random point R corresponding to the node with interaction target number i i .

[0083] Step 4: Messenger Node B α Public key PK α Public in alliance chain B, messenger node B α The private key SK α It is jointly kept by all nodes in the alliance chain A, and SK can be converted to α The fragment is sent to each node of the alliance chain A. Only more than k nodes can recover the private key together.

[0084] like Figure 2 As shown in the figure, the signature and encryption flow chart based on the Fiat-shamir and elliptic curve integrated encryption scheme is as follows:

[0085] The first step is to input the one-time private key sk and identity random number r of the sender node A on the alliance chain A maintained by the service domain A that wants to conduct cross-domain communication. A ; Messenger node A on consortium chain A belongs to service domain B β Public key PK β ; The identity random point R of the receiver node B on the alliance chain B maintained by the service domain B B ; Message m to be sent.

[0086] Step 2. Calculate the hash function SHA512 on the one-time key sk to obtain a 512-bit binary number e=SHA512(sk=(e0,e1,...,e 511 ). Divide the binary number e obtained by hashing into two parts. The first part is LE:e0,e1...e 255 , the second part is RE = e 256 ,e 257 ,...,e 511 , let s2=(e 256 ,e 257 ,...,e 511 ). The first part LE:e0,e1...e 255 Used to generate the public key, and the second part s2 is used to generate a pseudo-random number.

[0087] The third step is to calculate the first part LE:e0,e1...e 255 Perform bitwise operations and convert LE:e0,e1...e 255 Set e0, e1 and e2 in 0, and set e 254 Set to 1, e 255 Set to 0, calculate the private key scalar s1=(0,0,0,e3,...,e 253 ,1,0).

[0088] The fourth step is to compare the private key scalar s1 with the identity random number r of the sender node A. A Add up to get sk A =s1+r A ,sk A The actual private key used for signing. Multiply the private key s1 by the chain A base point G1 to get pk= V , V = s1 × G1, where pk is the public key used by the message sender to sign. V Represents the ordinate of the intermediate variable V on the elliptic curve Curve25519 in the Cartesian coordinate system, and records the intermediate variable temp1 = Vx||(Vx·Vy) generated when the point verification operation is performed here, where Vx and Vy respectively represent the horizontal and vertical coordinate parameters of V in the Cartesian coordinate system.

[0089] Step 5: Send the messenger node A maintained by service domain B on alliance chain A β Public key PK β and the identity random point R of the receiving node B B After doing the point addition operation and the actual private key sk of the sender node A A Multiply, according to the ECDH key agreement method, Key = sk A ×(PK β +R B ) to obtain the negotiated key Key.

[0090] Step 6: Use the agreed symmetric key algorithm f to convert the negotiated key Key into a symmetric key K sym =f(Key).

[0091] Step 7: Use the symmetric key K sym To encrypt the message m, we get the ciphertext c = Enc(m,K sym ).

[0092] In the eighth step, the second part s2 obtained after calculating the hash function of the one-time key and the ciphertext c are concatenated and the hash function is calculated to obtain a pseudo-random number r=SHA512(s2||c).

[0093] In the ninth step, multiply the generated pseudo-random number r by the base point G1 of the alliance chain A to calculate the pseudo-random point R = r × G1. Take the vertical coordinate of the pseudo-random point R in the Cartesian coordinate system to obtain part of the signature. R , and record the intermediate variable temp2 = Rx||(Rx·Ry) generated when the point verification operation is performed here, where Rx and Ry represent the horizontal coordinate parameters and vertical coordinate parameters on the Cartesian coordinate system corresponding to the pseudo-random point R, respectively.

[0094] Step 10: Sign part of R, signature public key pk, and ciphertext c are concatenated and passed through the hash function to generate the scalar h = SHA512 ( R ||pk||c)(modp), where p is a chosen prime number.

[0095] Step 11: Combine the generated pseudo-random number r and scalar h with the private key sk of the sender node A. A The result of the dot product is added to calculate the other part of the signature q = r + h sk A (modp), where p is a chosen prime number.

[0096] Step 12: Use part of the signature R , based on the other part q of the calculated signature and the two intermediate variables temp1 and temp2 obtained by the point verification operation, the signature Sig is generated. R ||q||temp1||temp2, and transmit the triple (Sig, pk, c) containing the signature Sig, the signature public key pk and the message ciphertext c to the alliance chain B through the oracle or cross-link router.

[0097] like Figure 3 As shown in the figure, the signature verification and message decryption flow chart based on the Fiat-Shamir and elliptic curve integrated encryption scheme is as follows:

[0098] In the first step, the input is a triple (Sig, pk, c) containing the signature Sig, public key pk and message ciphertext c of the sender node A in the alliance chain A claiming to be from the service domain A; the identity random point R of the sender node A A .

[0099] The second step is to calculate the signature Sig in the triplet. R Restore the pseudo-random point R, and then restore the actual public key pk of the sender node A based on the signature public key pk A Part of V.

[0100] The third step is to calculate and generate the scalar h = SHA512 ( R ||pk||c)(modp), where R is the vertical coordinate of the pseudo-random point R in the Cartesian coordinate system, pk is the public key of the signature performed by the sender node, c is the message ciphertext, and p is the selected prime number.

[0101] The fourth step is to use the actual public key pk of the sender node A A A part of V and the identity of the sender node A is a random point R A Recover the actual signature public key pk A .

[0102] Step 5: Verify -q×G1+h×pk A Is +R equal to the zero point (infinity)? If not, do not process the message.

[0103] Step 6: If they are equal, the cross-domain authentication is passed, confirming that the message is sent by the sender node A. Where q is the part of the signature recovered from the signature Sig, G1 is the base point selected by the alliance chain A, h is the calculated scalar, and pk A is the actual public key of the sender node A, and R is the pseudo-random point recovered from the signature Sig.

[0104] Step 7: Recover the sender A’s actual public key pk based on the signature public key pk A A portion V, according to the identity of the sender node A random point R A Recover the actual signature public key pk A .

[0105] Step 8: Use the secret sharing algorithm n-out-of-k to jointly restore the messenger node A maintained by service domain B in alliance chain A with other nodes. β The private key sk β and the identity random number r of the receiving node B B Add. Using ECDH key negotiation principle Key = pk A ×(sk β +r B ), recover the negotiated key.

[0106] Step 9: Use the pre-agreed function f to convert the Key into a symmetric key K sym =f(Key).

[0107] Step 10: Use the symmetric key K sym Decrypt the ciphertext c and get the plaintext message m=Enc(c,K sym ).

[0108] like Figure 4 As shown in the figure, the cross-domain information interaction method based on the blockchain cross-chain communication structure, combined with the messenger node and signature verification method, is as follows:

[0109] First, a consortium chain A is maintained in service domain A, and a consortium chain B is maintained in service domain B. Assuming that service domain A and service domain B need to interact across domains, service domain A needs to maintain a messenger node B on consortium chain B. α , service domain B needs to maintain a messenger node A on alliance chain A β The messenger node will distribute its private key to the nodes in its domain based on the secret sharing algorithm. Then cross-domain information exchange will be carried out.

[0110] In the first step, the sender node A wants to interact across domains, so it sends a message to the messenger node A in the service domain A corresponding to the service domain B where the receiver node B is located. β Initiate a request from messenger node A β Get the identity random point R of the receiving node B B and messenger node A β The current public key PK β , and pay a certain deposit to the messenger node.

[0111] Step 2: Messenger Node A β Reply to sender node A with the information that sender node A wants.

[0112] The third step is to sign and encrypt the message according to the designed signature verification method to generate transaction T sign +T Enc , generate a triple (Sig, pk, c) containing the signature Sig, the signature public key pk, and the message ciphertext c, and include it in the smart contract.

[0113] The fourth step is to generate a triple (Sig, pk, c) containing the signature Sig, the signature public key pk, and the message ciphertext c after signing and encryption, and record it on the alliance chain A where the sender node A is located, generating a record T Consenses .

[0114] Step 5: Messenger Node A β Read the on-chain triplet (Sig, pk, c).

[0115] Step 6, Messenger Node A β The cross-domain information triple (Sig, pk, c) containing the signature Sig, signature public key pk, and message ciphertext c on the alliance chain A is transmitted to the alliance chain B.

[0116] Step 6: The service domain B where the receiver node B is located receives the messenger node A β The message T transmitted from service domain A contains the triple (Sig, pk, c) of signature Sig, signature public key pk, and message ciphertext c. Deliver , any node in service domain B verifies whether the message source is correct. If correct, it constructs record T verify , write to the buffer pool and wait until the consensus is on the chain.

[0117] Step 7: The nodes in service domain B will verify Consensus on the chain.

[0118] In the eighth step, the receiving node B obtains the triple (Sig, pk, c) in the message from the alliance chain B in the service domain B, decrypts it, and constructs the record TDec , waiting for consensus to be put on the chain.

[0119] In the ninth step, the receiving node B reads the cross-domain message triple (Sig, pk, c) containing the signature Sig, the signature public key pk, and the message ciphertext c from the alliance chain B, and notifies the messenger node A at the same time. β After a certain period of time, the deposit will be returned to the sender node A (if a handling fee is set, the deposit will not be returned), and the message exchange is completed.

[0120] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not limiting. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present invention can be modified or replaced by equivalents without departing from the purpose and scope of the technical solutions, which should all be included in the scope of the claims of the present invention.

Claims

1. A cross-domain information interaction method based on a blockchain cross-chain communication structure, characterized by: The method comprises the following steps: S1: Design messenger node; The two parties that need to exchange cross-domain information set up a messenger node on the alliance chain maintained by the other party, maintain the identity-related information of the node on the chain, and use it for cross-chain information exchange; at the same time, through the secret sharing scheme, maintain the private key of the messenger node to ensure the security of the messenger node identity and the security of the entire cross-domain information exchange process; In S1, the messenger node is designed, which specifically includes the following steps: S1.1: Each service domain maintains a consortium chain within its own domain and a corresponding messenger node in the domain where cross-domain information exchange is required. Service domain A maintains consortium chain A, and service domain B maintains consortium chain B. The messenger node maintained by service domain A in service domain B belongs to service domain A and is located on consortium chain B. The messenger node maintained by service domain B in service domain A belongs to service domain B and is located on consortium chain A. Each consortium chain needs to select a non-zero point on the elliptic curve Curve25519 as its base point. S1.2: Each node on the consortium chain will generate its own identity random number according to the selected algorithm, multiply this identity random number by the base point of the consortium chain to obtain the corresponding identity random point; and send this identity random point to the messenger node maintained by the domain on the consortium chain that requires cross-domain communication; S1.3: The messenger node needs to save its own public and private key pair, as well as the identity random points of all nodes on the consortium chain maintained by its service domain; S1.4: The public key of the messenger node is made public in consortium chain B, and the private key is distributed to multiple nodes in consortium chain A for joint custody using a secret sharing algorithm. A certain number of nodes in consortium chain A are required to jointly recover the private key. S2: Design a signature verification method based on Fiat-Shamir transform and elliptic curve integrated encryption scheme; Using an elliptic curve integrated encryption scheme, a temporary public-private key pair is generated at the sender. The temporary private key is used to encrypt the hash value of the plaintext to generate a digest signature. The temporary private key is then used with the receiver's public key for key negotiation to generate a negotiated key. The Fiat-Shamir transform is used to select a difficult function to map the fixed random number and key to a pseudo-random number, providing security for the random number, the message to be transmitted, and the signature public key during cross-chain information interaction. In S2, a signature verification method based on the Fiat-Shamir transform and elliptic curve integrated encryption scheme is designed, which specifically includes the following steps: S2.1: The sender node A in the alliance chain A generates its own one-time private key sk and sends it to the messenger node A in the service domain B in the alliance chain A. β Request the identity random point R of the receiving node B B and messenger node A β Current public key PK β , construct the message m to be sent; S2.2: Generate signature Sig, negotiate key Key, and pass the obtained symmetric key K sym Encrypt the message m to be sent and generate the ciphertext c; send the generated triple (Sig, pk, c) containing the signature Sig, the signature public key pk and the ciphertext c to the receiving node B; S2.3: After receiving node B’s service domain B receives the triple (Sig, pk, c) containing the signature Sig, the signature public key pk, and the ciphertext c, any node on consortium chain B in service domain B performs signature verification. S2.4: If the signature authentication passes, the subsequent message decryption process begins; S2.5: If the signature authentication fails, the message is discarded; S2.6: After the signature authentication is passed, the receiving node B parses the intermediate process according to the received triple (Sig, pk, c) containing the signature Sig, the signature public key pk and the ciphertext c to obtain the negotiated symmetric key K sym , decrypt the ciphertext c and obtain the plaintext message m; S3: Design a cross-domain information interaction method based on the cross-chain communication structure of blockchain; Combining the messenger node and signature verification method, the signature, signing key and encrypted message are obtained to verify the reliability of the message source. After verification, the symmetric key is calculated and the message is decrypted to obtain the plaintext. The cross-chain interaction process is designed to complete the cross-domain message interaction. In S3, a cross-domain information interaction method based on the cross-chain communication structure of blockchain is designed; specifically, the following steps are included: S3.1: A consortium chain A is maintained in service domain A, and a consortium chain B is maintained in service domain B. Assuming that service domain A and service domain B need to interact across domains, service domain A needs to maintain a messenger node B on consortium chain B. α , service domain B needs to maintain a messenger node A on alliance chain A β The messenger node will distribute its private key to the nodes in its service domain based on the secret sharing algorithm; S3.2: If the sender node A wants to conduct cross-domain communication, it sends a message to the messenger node A on the alliance chain A maintained by the service domain A, which corresponds to the service domain B where the receiver node B is located. β Initiate a request from messenger node A β Get the identity random point R of the receiving node B B and messenger node A β The current public key PK β and pay a certain deposit to the messenger node; S3.3: Use the signature verification method designed in S2 to sign and encrypt the message to generate transaction T sign +T Enc , generate a triple (Sig, pk, c) containing the signature Sig, the signature public key pk, and the message ciphertext c, and include it in the smart contract; S3.4: The triplet generated after signing and encryption is consensus-based on the consortium chain where the sender node is located and recorded on the chain to generate record T Consenses ; S3.5: Messenger Node A β Read the on-chain triplet and transfer information between the two domains; S3.6: The service domain B where the receiver node B is located receives the messenger node A β The message T of the triple (Sig, pk, c) transmitted from service domain A Deliver , any node in service domain B verifies whether the message source is correct. If correct, it constructs record T verify , write to the buffer pool and wait until consensus is on the chain; S3.7: The nodes in service domain B will T verify Consensus on the chain; S3.8: The receiving node B obtains the triplet in the message from the alliance chain B in the service domain B, decrypts it, and constructs the record T Dec , waiting for consensus to be uploaded to the chain; at the same time, after the receiving node B receives the request, it will notify the messenger node A β The deposit will be returned to the sender node A after a certain period of time. If a handling fee is set, the deposit will not be refunded. The message exchange is now completed.

2. A cross-domain information interaction method based on a blockchain cross-chain communication structure according to claim 1, characterized in that: The S2.2 specifically includes the following steps: S2.2.1: Input is the one-time private key sk and identity random number r of the sender node A on the consortium chain A in the service domain A that wants to conduct cross-domain communication with the receiver node B on the consortium chain A in the service domain B. A ; Messenger node A on consortium chain A belongs to service domain B β Public key PK β ; The identity random point R of the receiver node B on the alliance chain B in the service domain B B ; Message m to be sent; S2.2.2: Calculate the hash function SHA512 on the one-time private key sk to obtain a 512-bit binary number e = SHA512(sk) = (e0, e1, ..., e 511 ); Divide the binary number e obtained by hashing into two parts, the first part is LE:e0,e1...e 255 , the second part is RE = e 256 ,e 257 ,...,e 511 , let s2=(e 256 ,e 257 ,...,e 511 ); the first part LE:e0,e1...e 255 Used to generate the public key, the second part s2 is used to generate a pseudo-random number; S2.2.3: For the first part LE:e0,e1...e 255 Perform bitwise operations and convert LE:e0,e1...e 255 Set e0, e1 and e2 in 0, and set e 254 Set to 1, e 255 Set to 0, calculate the private key scalar s1=(0,0,0,e3,...,e 253 ,1,0); S2.2.4: Compare the private key s1 with the identity random number r of the sender node A A Add up to get sk A =s1+r A , where sk A It is the actual private key used for signing; multiply the private key scalar s1 by the alliance chain A base point G1 to get pk= V , V = s1 × G1, where pk is the public key used by the message sender to sign. V Represents the ordinate of the intermediate variable V on the elliptic curve Curve25519 in the Cartesian coordinate system, and records the intermediate variable temp1 = Vx||(Vx·Vy) generated when the point verification operation is performed here, where Vx and Vy represent the horizontal and vertical coordinate parameters of the Cartesian coordinate system corresponding to the intermediate variable V, respectively; S2.2.5: Messenger Node A maintained by Service Domain B on Alliance Chain A β Public key PK β and the identity random point R of the receiving node B B After doing the point addition operation and the actual private key sk of the sender node A A Multiply, according to the ECDH key agreement method, Key = sk A ×(PK β +R B ) to obtain the negotiated key Key; S2.2.6: Use the agreed symmetric key algorithm f to convert the negotiated key Key into the symmetric key K sym =f(Key); S2.2.7: Using the symmetric key K sym To encrypt the message m, we get the ciphertext c = Enc(m,K sym ); S2.2.8: Concatenate the second portion s2 obtained by computing the hash function on the one-time private key sk and the ciphertext c and compute the hash function to obtain the pseudo-random number r = SHA512(s2||c); S2.2.9: Multiply the generated pseudo-random number r by the base point G1 of the alliance chain A to calculate the pseudo-random point R = r × G1. Take the vertical coordinate of the pseudo-random point R in the Cartesian coordinate system to obtain part of the signature. R , and record the intermediate variable temp2 = Rx||(Rx·Ry) generated when performing the point verification operation here, where Rx and Ry represent the horizontal and vertical coordinate parameters on the Cartesian coordinate system corresponding to the pseudo-random point R respectively; S2.2.10: Replace part of the signature R , signature public key pk, and ciphertext c are concatenated and passed through the hash function to generate the scalar h = SHA512 ( R ||pk||c)(modp), where p is a selected prime number; S2.2.11: Combine the generated pseudo-random number r with the scalar h and the private key sk of the sender node A A The result of the dot product is added to calculate the other part of the signature q = r + h sk A (modp), where p is a chosen prime number; S2.2.12: Use part of a signature R , based on the other part q of the calculated signature and the two intermediate variables temp1 and temp2 obtained by the point verification operation, the signature Sig is generated. R ||q||temp1||temp2, and transmit the triple (Sig, pk, c) containing the signature Sig, the signature public key pk and the message ciphertext c to the alliance chain B through the oracle or cross-link router.

3. A cross-domain information interaction method based on a blockchain cross-chain communication structure according to claim 1, characterized in that: The S2.3 specifically includes the following steps: S2.3.1: The input is a triple (Sig, pk, c) containing the signature Sig, the signature public key pk, and the message ciphertext c, which is claimed to come from the sender node A in the alliance chain A; the identity random point R of the sender node A A ; S2.3.2: According to the signature Sig in the triple R Restore the pseudo-random point R, and then restore the actual public key pk of the sender node A based on the signature public key pk A Part of V; S2.3.3: Calculate and generate scalar h = SHA512( R ||pk||c)(modp), where R is the ordinate of the pseudo-random point R in the Cartesian coordinate system, pk is the public key of the signature performed by the sender node, c is the message ciphertext, and p is the selected prime number; S2.3.4: According to the actual public key pk of the sender node A A A part of V and the identity of the sender node A is a random point R A Recover the actual signature public key pk A ; S2.3.5: Verify -q×G1+h×pk A +R is equal to zero. If so, the verification is successful, confirming that the message is sent by the sender node A. Where q is the part of the signature recovered from the signature Sig, G1 is the base point selected by chain A, h is the calculated scalar, and pk A is the actual public key of the sender node A, and R is the pseudo-random point recovered from the signature Sig.

4. A cross-domain information interaction method based on a blockchain cross-chain communication structure according to claim 1, characterized in that: The S2.6 specifically includes the following steps: S2.6.1: The input is the other two parts of the triple (Sig, pk, c) besides the signature Sig: the signature public key pk and the encrypted ciphertext c. S2.6.2: Recover the sender A’s actual public key pk based on the signature public key pk A Part of V; S2.6.3: According to the actual public key pk A A part of V and the identity of the sender node A is a random point R A Recover the actual signature public key pk A ; S2.6.4: Restore the messenger node A maintained by service domain B in consortium chain A together with other nodes according to the secret sharing algorithm n-out-of-k β The private key sk β and the identity random number r of the receiving node B B Add; using ECDH key agreement principle Key = pk A ×(sk β +r B ), recover the negotiated key Key; S2.6.5: Convert Key to a symmetric key K using a pre-agreed function f sym =f(Key); S2.6.6: Using a symmetric key K sym Decrypt the ciphertext c and get the plaintext message m=Enc(c,K sym ); Perform batch signing and encryption as well as signature verification and decryption. The input is the one-time temporary private key sk1, sk2, ...sk of n nodes. i ,...,sk m and identity random numbers r1, r2, ..., r i ,...,r n ; Messenger node A maintained by service domain B on alliance chain A β Public key PK β ; The identity of the receiving node B is a random point R B ; Messages to be sent m1, m2, ..., m i ,...,m n Repeat the above signature encryption process n times to generate n triples (Sig i ,pk i ,c i ); Repeat n times, use the verification signature and decryption algorithm to authenticate the sender's identity for each triple, and for each ciphertext c that passes the verification i Use ECDH to recover the negotiated key and decrypt the plaintext m i , where i represents the i-th triplet.

Images