Block chain-based lightweight node-oriented data cross-domain secure transmission method

Abstract

The invention discloses a lightweight node-oriented data cross-domain secure transmission method based on a block chain, and relates to the technical field of communication security, and the method comprises the steps: S1, a system determines a public parameter, an identity authentication server creates a block chain account thereof, and a password server creates a public key and a private key thereof; s2, a user generates key information, and requests a password server for password enhancement to obtain an assistant word; s3, the user creates a key management block and registers in the identity authentication server; s4, the two communication parties execute key negotiation to establish secure communication connection; s5, initializing necessary communication parameters; s6, the sender executes symmetric ratchet to obtain a message key, encrypts the message and sends the encrypted message to the receiver; and S7, the receiver executes the symmetric ratchet to obtain the message key decryption message, and selects to execute the DH ratchet according to whether the receiving and transmitting states are converted or not. According to the invention, the decentralization, non-tampering and transparent characteristics of the block chain are utilized to replace a traditional centralized certificate issuing mechanism, and identity management and authentication of cross-domain nodes are realized.

Description

Technical Field

[0001] The present invention relates to the field of communication security technology, and particularly relates to a method for secure cross-domain data transmission for lightweight nodes based on blockchain. Background Art

[0002] In the context of the rapid development of the Internet of Things (IoT), mobile computing, and distributed systems, lightweight nodes are widely used in various scenarios. To coordinate and complete complex tasks, lightweight nodes belonging to different management domains usually need to cooperate with each other to perform reliable identity authentication and secure data interaction to support complex applications. In terms of identity authentication, the current certificate-based public key cryptosystem is widely used. The Certificate Authority (CA) binds the user identity and its public key and issues certificates to legitimate users. However, the traditional CA architecture is mainly applicable to security management within a single domain and is difficult to extend to the identity verification requirements in a multi-domain environment. In a cross-domain scenario, CAs in different management domains cannot securely share the identity information of nodes within their respective domains, and frequent interactions are required during user identity authentication, resulting in complex and inefficient cross-domain identity authentication. In addition, the CA system relies on a centralized trust model and is easily targeted by attacks. Once the CA is compromised or CAs in different management domains collude, the security of the entire authentication system will be seriously threatened. In terms of data interaction, due to resource constraints of lightweight nodes, it is usually difficult to deploy complex security technologies. Therefore, data interaction is often vulnerable to attacks by adversaries, leading to security threats such as privacy leakage and facing severe security challenges. Summary of the Invention

[0003] The purpose of the present invention is to overcome the deficiencies of the prior art and provide a method for secure cross-domain data transmission for lightweight nodes based on blockchain.

[0004] The purpose of the present invention is achieved by the following technical solutions:

[0005] The present invention discloses a method for secure cross-domain data transmission for lightweight nodes based on blockchain, including the following steps:

[0006] S1. The system determines public parameters according to security parameters. The identity authentication server creates a blockchain account, and the password server creates a pair of public and private keys for signature.

[0007] S2. The user generates key information and requests password strengthening from the password server using its identity and password to obtain a mnemonic phrase.

[0008] S3. The user creates its own key management block and registers with the identity authentication server, requests the identity authentication server to authenticate its identity, and publishes an authentication block. The identity authentication server registers the user's information list in the local maintenance.

[0009] S4. The two parties that need to establish communication perform key negotiation based on the public identity information on the blockchain, share the common key, and establish a secure communication connection;

[0010] S5. The two parties that need to establish communication initialize the necessary parameters for communication;

[0011] S6. The sender performs a symmetric ratchet operation to obtain the message key, encrypts the message, and sends it to the receiver;

[0012] S7. The receiver performs a symmetric ratchet operation to obtain the message key, decrypts the received message, and selects whether to perform a DH ratchet operation according to whether the sender and the receiver perform the conversion of the sending and receiving states.

[0013] Further, step S1 specifically includes the following steps:

[0014] S11. The system determines the system public parameters according to the security parameters where p is a prime number, G is a cyclic group of order p, P is a generator of G, and e: G×G→G T is a bilinear pairing, is a secure cryptographic hash function, Sig / Vrfy(·) represents a pair of secure digital signature / verification algorithms, E / D(·) represents a pair of secure symmetric encryption / decryption algorithms, DH(·) is a secure Diffie-Hellman key exchange technology, AEAD(·) represents a secure authenticated encryption algorithm with additional data, len is the bit length of the account address in the blockchain network, l is the security parameter, indicating the upper limit of the number of times of password authentication failure for the user to request the key strengthening service;

[0015] S12. The identity authentication server creates a blockchain account as

[0016] S13. The identity ID of the password server is represented as The password server The signature private key of is The signature public key of the password server is calculated through the formula

[0017] Preferably, step S2 specifically includes the following steps:

[0018] S21. The identity ID of the user is The user The long-term identity key private key of is Through the formula ​​Calculate the user The public key of the identity is user The mid-term pre-shared signing key is By formula Calculate the first signature user The blockchain account is The corresponding private key is

[0019] S22. User The first password is By blinding the value For the first password Password blinding Get the second password and will Send to password server

[0020] S23. Password Server Maintain a service request list locally Each user corresponds to a first service request record req=(ID, cre, ∈, l), where ID represents the user identity, cre represents the user authentication credential, and ∈ represents a random value used for verification; After the service request, query the user Identity Whether it exists in the service request list If it exists, terminate the subsequent operation; if it does not exist, calculate the blind signature The first random value is Create a second service request record in For users The safety parameters will Send to user

[0021] S24. User First check the blind signature Legality If they are not equal, the subsequent operation is terminated; if they are equal, the unblinding value r is used -1 Blind Signature Unblinding Calculate the mnemonic First authentication certificate Random value ciphertext and will Send to password server

[0022] S25, Password Server Decrypt the second random value According to the identity Extract the third service request record And check Whether they are equal. If the equation holds, update the third service request record to If the equation does not hold, check the user 's security parameters Whether it exceeds the authentication failure upper limit. If Then increment the security parameters of the user by 1, otherwise, terminate the subsequent operations.

[0023] Preferably, step S3 specifically includes the following steps:

[0024] S31. The user uses the private key in the mnemonic encryption key pair, including Create the first transaction as the user key management block T key , and the user key management block address is key Transfer 0 tokens from the first address to the second address , and the integrated content is as follows Let the data Calculate the second signature Send to the identity authentication server

[0025] S32. The identity authentication server locally maintains a registration record list where each user corresponds to a first registration record respectively where represents the identity credential block address provided by the identity authentication server for the user;

[0026] S33. The identity authentication server first extracts the user key management block address from the data to locate the user key management block T key , and verifies whether the sender of the user key management block T key is the first address and whether the receiver is the second address If the verification passes, the identity authentication server obtains the user 's identity public key from the user key management block T key ​​​Used to verify the legitimacy of the signature. If the above authentications are passed, the identity authentication server Receive user key management block T key And generate a second transaction as user The public key of the identity Authentication credentials Get the authentication server For users The provided identity credential block address The integration content is as follows And create a second registration record and save it to the local list On the contrary, if any of the above conditions fails to be verified, subsequent operations will be terminated.

[0027] Preferably, step S4 specifically includes the following steps:

[0028] S41. Sender If necessary, the recipient Communication, first the receiver Identity Send to sender Authentication server Make a communication request to it;

[0029] S42. Sender Authentication server Determine the receiver domain, and send the Authentication server Request Receiver Certified transaction address Sender Authentication server Locating the receiver User Credentials Block To obtain the recipient The key block address and forward it to the sender

[0030] S43. Sender extract Verify the first signature Is it legal? If so, a pair of temporary keys is generated. Sender Use the extracted recipient's public information and your own private key information to perform X3DH calculation: Get the shared key SK, where For sender The long-term identity key private key, For the receiver The mid-term pre-shared signing key, For the receiver The public key of the identity;

[0031] S44. After the calculation is completed, the sender Delete the temporary private key and the intermediate output of the DH protocol locally and send the first message To the receiver in For sender The key management block address, E(Sk,m) is the second message encrypted with the shared key SK;

[0032] S45. Receiver Receive the first message After that, first from the sender The key block address Get the key management block from and extract the sender from it The public key information of the receiver is obtained and the signature of the intermediate key is verified to be legitimate. Key Management Block Use mnemonics Decrypt the private key ciphertext to obtain the private key, and repeat the X3DH operation to calculate the shared key SK. At this time, the sender and the receiver Use a shared key SK.

[0033] Preferably, step S5 specifically includes the following steps:

[0034] S51. Sender and the receiver During the communication process, the key chain and data structure state (DH s ,DH r ,RK,CK s ,CK r ), the key chain includes a root key chain, a sending key chain and a receiving key chain, wherein DH s Indicates DH ratchet sends key pair, DH r Represents the DH ratchet receiving public key, RK represents the root key, CK s Indicates the chain key of the sending chain, CK r Represents the chain key of the receiving chain;

[0035] S52, sender and the receiver The key derivation function agreed upon by both parties is (RK new , C.K.KDF_RK ) ← KDF_RK(RK old , dh_out), (CK new , mk) ← KDF_CK(CK old ) where dh_out is the output of the DH key agreement function, mk represents the encryption / decryption message key, RK new represents the first root key, RK old represents the second root key, CK new represents the first chain key, CK old represents the second chain key, CK KDF_RK represents the seventh chain key;

[0036] S53. Calculate for the sender to obtain the output Result KDF = KDF_RK(SK, DH(DH s , DH r ))), and initialize its own state variable:

[0037] S54. The receiver waits for the sender to send the first message and initialize its own state variable:

[0038] Preferably, step S6 specifically includes the following steps:

[0039] S61. The sender performs a symmetric ratchet operation to update the sending chain. Through the formula state.CK s-new , mk = KDF_CK(state.CK s-old ), obtain the encryption key mk required for encrypting the message and the third chain key CK s-new ;

[0040] S62. Perform a two - party negotiated key derivation to generate the private key sk ss ← Z P required for the next - stage DH ratchet, and calculate the public key pk ss = sk ss ·P, and send the public key pk ss as additional data AD to the receiver Encrypt the message C = AEAD(mk, plointext, AD);

[0041] S63. After the calculation is completed, delete the encryption key mk and the fourth chain key CK s-old , and send the data (pk ss , C) to the receiver

[0042] Preferably, step S7 specifically includes:

[0043] S71. The receiving party extracts the public key pk ss from the data (pk ss , C), calculates (RK new , CK KDF RK ) = KDF_RK(RK old , DH(DH s , pk ss ))). If the receiving party receives the sender's message for the first time, then calculate (RK new , CK KDF_RK ) = KDF_RK(SK, DH(DH s , pk ss ));

[0044] S72. The receiving party performs a symmetric ratchet operation, updates the receiving chain, calculates state.CK r-new , mk = KDF_CK(state.CK r-old ), obtains the message key mk for decrypting the current message and the fifth chain key CK r-new , where the sixth chain key CK r-old is equal to the seventh chain key CK KDF_RK ;

[0045] S73. Executes the decryption algorithm of AEAD to decrypt the received ciphertext C to obtain the message plaintext plaintext;

[0046] S74. In subsequent communications, if the sending and receiving statuses of the sender and the receiving party are swapped, then update the DH ratchet key.

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

[0048] 1) By introducing the blockchain, the present invention makes full use of the immutable characteristic of the blockchain itself, enabling the efficient authentication of user identity-related information across trust domains, and users do not need to manage privacy information locally, realizing lightweight management of nodes.

[0049] 2) The use of a secure communication protocol simultaneously achieves forward security and backward security during the data transmission process. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 is a schematic flowchart of the steps of an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0051] The technical solution of the present invention will be clearly and completely described below in conjunction with embodiments. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts belong to the scope of protection of the present invention.

[0052] The present invention discloses a cross-domain secure data transmission method for lightweight nodes based on blockchain. By utilizing the decentralized, immutable, and transparent characteristics of blockchain, it replaces the traditional centralized certificate authority (CA) to achieve identity management and authentication of cross-domain nodes. Cryptography techniques are used to meet actual security requirements, and a mature end-to-end encryption technology is deployed to achieve efficient encrypted communication in a lightweight node environment with limited resources, solving the deficiencies of the prior art. The schematic diagram of its steps is as Figure 1 shown, and it includes the following steps:

[0053] S1. The system determines public parameters according to security parameters. The identity authentication server creates a blockchain account, and the password server creates a pair of public and private keys for signature.

[0054] S2. The user generates key information and requests password strengthening from the password server using their identity and password to obtain a mnemonic phrase.

[0055] S3. The user creates their own key management block and registers with the identity authentication server, requests the identity authentication server to authenticate their identity, and publishes an authentication block. The identity authentication server registers the user's information list in the local maintenance.

[0056] S4. The two parties that need to establish communication perform key negotiation based on the public identity information on the blockchain, share a common key, and establish a secure communication connection.

[0057] S5. The two parties that need to establish communication initialize the necessary parameters for communication.

[0058] S6. The sender performs a symmetric ratchet operation to obtain a message key, encrypts the message, and sends it to the receiver.

[0059] S7. The receiver performs a symmetric ratchet operation to obtain a message key, decrypts the received message, and selects whether to perform a DH ratchet operation according to whether the sending and receiving statuses of the sender and receiver are converted.

[0060] Specifically, step S1 specifically includes the following steps:

[0061] S11. The system determines system public parameters according to security parameters where p is a prime number, G is a cyclic group of order p, p is a generator of G, and e: G×G→G Tis a bilinear pairing, is a secure cryptographic hash function, Sig / Vrfy(·) represents a pair of secure digital signature / verification algorithms, E / D(·) represents a pair of secure symmetric encryption / decryption algorithms, DH(·) is a secure Diffie-Hellman key exchange technology, AEAD(·) represents a secure authenticated encryption algorithm with associated data, len is the bit length of the account address in the blockchain network, l is a security parameter, representing the upper limit of the number of times the user requests password strengthening service password authentication fails;

[0062] S12. Identity authentication server The created blockchain account is

[0063] S13. Password server The identity ID of is represented as Password server The signature private key of is Through the formula Calculate the signature public key of the password server

[0064] Exemplarily, the user uses the key generation function to determine two pairs of public and private keys for himself, one pair is the long-term identity key, and one pair is the medium-term key, which needs to be updated regularly. After the update, step S3 is re-executed. If the user changes the password, step S2 needs to be requested again. The password server performs a blind signature on the user's password and returns it to the user. The user performs the de-blinding operation and performs a hash calculation to obtain the mnemonic. Step S2 specifically includes the following steps:

[0065] S21. User The identity ID of is User The long-term identity key private key of is Through the formula Calculate the identity public key of the user User The medium-term pre-shared signature key of is Through the formula Calculate the first signature User The blockchain account of is The corresponding private key is

[0066] S22. User The first password of is Through the blinding value Blind the first password ​​​Obtain the second password and send to the password server

[0067] S23. The password server locally maintains a service request list where each user corresponds to a first service request record req = (ID, cre, ∈, l), where ID represents the user identity, cre represents the user authentication credential, and ∈ represents a random value for verification; after receiving the user's service request, query whether the user's identity exists in the service request list if it exists, terminate the subsequent operations; if it does not exist, calculate the blind signature The first random value is Create a second service request record where is the security parameter of the user and send to the user

[0068] S24. The user first checks the legality of the blind signature if they are not equal, abort the subsequent operations; if they are equal, use the de - blinding value r to de - blind the blind signature -1 and calculate the mnemonic de - blind to obtain the first authentication credential the first authentication credential the random value ciphertext and send to the password server

[0069] S25. The password server decrypts the second random value extracts the third service request record according to the identity and checks if they are equal, if the equation holds, update the third service request record to if the equation does not hold, check whether the security parameter of the user exceeds the authentication failure limit, if then increment the security parameter of the user by 1, otherwise, terminate the subsequent operations. then the security parameter of the user increases by 1, otherwise, terminate the subsequent operations.

[0070] Specifically, step S3 specifically includes the following steps:

[0071] S31. User Use mnemonics The private key of an encryption key pair, including Create the first transaction as user key management block T key , the user key management block address is From the first address To the second address Transfer 0 tokens, the integration content is as follows Order Data Calculate the second signature Will Sent to the authentication server

[0072] S32, identity authentication server Maintain a list of registration records locally Each user corresponds to a first registration record in Indicates the identity authentication server The identity credential block address provided to the user;

[0073] S33, Identity Authentication Server First, from the data Extract the user key management block address from Used to locate the user key management block T key , verify the user key management block T key Is the sender of the first address Is the recipient the second address? If the verification is successful, the identity authentication server From the user key management block T key Get the user Identity public key Used to verify the legitimacy of the signature. If the above authentications are passed, the identity authentication server Receive user key management block T key And generate a second transaction as user Identity public key Authentication certificate T cer , get the identity authentication server For users The provided identity credential block address The integration content is as follows And create a second registration record and save it to the local list On the contrary, if any of the above conditions fails to be verified, subsequent operations will be terminated.

[0074] Specifically, step S4 specifically includes the following steps:

[0075] S41. The sender If it is necessary to communicate with the receiver first sends the identity of the receiver to the identity authentication server of the sender to send a communication request thereto;

[0076] S42. The identity authentication server of the sender judges the domain where the receiver is located, and requests the authentication transaction address of the receiver from the identity authentication server of the receiver The identity authentication server of the sender locates the user identity credential block of the receiver to obtain the key block address of the receiver and forwards it to the sender

[0077] S43. The sender extracts and verifies whether the first signature is legal. If it is legal, a pair of temporary keys is generated by the sender using the extracted public information of the receiver and its own private key information for X3DH calculation: SK = KDF(DH1||DH2||DH3), obtaining the shared key SK, where is the long-term identity key private key of the sender is the medium-term pre-shared signature key of the receiver is the identity public key of the receiver

[0078] S44. After the calculation is completed, the sender deletes the temporary private key and the intermediate output of the DH protocol locally, and sends the first message to the receiver where is the key management block address of the sender, and E(SK, m) is the second message encrypted with the shared key SK;

[0079] S45, Receiver After receiving the first message firstly obtain the key management block from the sender's key block address and extract the public key information of the sender from it and verify the legality of the signature of the intermediate key. After that, locate the receiver's key management block Use the mnemonic phrase to decrypt the private key ciphertext to obtain the private key, and repeat the X3DH operation to calculate the shared key SK. At this time, the sender and the receiver use the shared key SK. and the receiver Use the shared key SK.

[0080] Specifically, step S5 specifically includes the following steps:

[0081] S51, Sender and Receiver both need to maintain the key chain and the data structure state(DH s , DH r , RK, CK s , CK r ) during the communication process. The key chain includes the root key chain, the sending key chain and the receiving key chain, where DH s represents the DH ratchet sending key pair (where the private key is used for calculation), DH r represents the DH ratchet receiving public key, RK represents the root key, CK s represents the chain key of the sending chain, CK r represents the chain key of the receiving chain;

[0082] S52, Sender and Receiver negotiate the key derivation function for both parties as (RK new , CK KDF_RK ) ← KDF_RK(RK old , dh_out),(CK new , mk) ← KDF_CK(CK old ) where dh_out is the output of the DH key agreement function, mk represents the encryption and decryption message key, RK new represents the first root key, PK old represents the second root key, CK new represents the first chain key, CK old represents the second chain key, CK KDF_RK represents the seventh chain key;

[0083] S53. Calculate the sender to obtain the output Result KDF =KDF_RK(SK,DH(DH s ,DH r )) and initialize its own state variable:

[0084] S54. The receiver waits for the sender to send the first message and initialize its own state variable:

[0085] Specifically, step S6 specifically includes the following steps:

[0086] S61. The sender performs a symmetric ratchet operation to update the sending chain. Through the formula state.CK s-new ,mk = KDF_CK(state.CK s-old ), obtain the encryption key mk and the third chain key CK required for encrypting the message s-new ;

[0087] S62. Perform a key derivation negotiation between the two parties to generate the private key sk required for the DH ratchet in the next stage ss ←Z P , and calculate the public key pk ss =sk ss ·P, and send the public key pk ss as additional data AD to the receiver Encrypt the message C = AEAD(mk,plaintext,AD);

[0088] S63. After the calculation is completed, delete the encryption key mk and the fourth chain key CK s-old , and send the data (pk ss , C) to the receiver

[0089] Specifically, step S7 specifically includes:

[0090] S71. The receiver extracts the public key pk from the data (pk ss , C), calculates (RK ss , CK new ) = KDF_RK(RK KDF RK , DH(DH old pk s ss ))), if the receiver receives the sender's message for the first time, then calculate (RK​new , CK KDF_RK ) = KDF_RK(SK, DH(DH s , pk ss ));

[0091] S72. The receiving party performs a symmetric ratchet operation, updates the receiving chain, and calculates state.CK r-new , mk = KDF_CK(state.CK r-old ), obtains the message key mk for decrypting the current message and the fifth chain key CK r-new , where the sixth chain key CK r-old is equal to the seventh chain key CK KDF_RK ;

[0092] S73. Executes the decryption algorithm of AEAD to decrypt the received ciphertext C to obtain the message plaintext plaintext;

[0093] S74. In subsequent communications, if the sending and receiving statuses of the sending party and the receiving party are swapped, then the DH ratchet key is updated.

[0094] The present invention provides a method for lightweight nodes in data transmission. By virtue of the immutable characteristic of the blockchain, users store key management information in the blockchain, which can not only ensure the public and immutable nature of the user identity public key information, but also meet the requirement that users do not need to locally store a large amount of private information. They only need to locate the key management block and obtain the private information for decryption when encrypting and decrypting messages, effectively reducing the computing pressure and storage pressure on the user side.

[0095] The present invention provides a highly secure cross - domain data transmission scheme, which uses a secure communication protocol to achieve forward security and backward security of data transmission. After one or both communication parties are compromised by an adversary, the adversary cannot recover the previous communication content, nor can it infer the subsequent communication keys.

[0096] The above are only the preferred embodiments of the present invention. It should be understood that the present invention is not limited to the form disclosed herein, should not be regarded as excluding other embodiments, but can be used in various other combinations, modifications and environments, and can be changed within the scope of the concept described herein through the above teachings or the technology or knowledge in related fields. And the changes and alterations made by those skilled in the art that do not depart from the spirit and scope of the present invention should all be within the protection scope of the appended claims of the present invention.

Claims

1. A blockchain-based method for cross-domain secure transmission of lightweight node data, characterized in that: The following steps are involved: S1. The system determines the public parameters based on the security parameters, the identity authentication server creates a blockchain account, and the password server creates a pair of public and private keys for signing; S2. The user generates key information and uses his / her identity and password to request password strengthening from the password server to obtain the mnemonic; S3. The user creates his own key management block and registers it with the identity authentication server, requests the identity authentication server to authenticate his identity, and publishes an authentication block. The identity authentication server maintains a list of registered users' information locally. S4. The two parties that need to establish communication perform key negotiation, share the public key, and establish a secure communication connection based on the public identity information on the blockchain; S5. The two parties that need to establish communication initialize the necessary communication parameters; S6. The sender performs a symmetric ratchet operation to obtain a message key, encrypts the message and sends it to the receiver; S7. The receiver performs a symmetric ratchet operation to obtain a message key, decrypts the obtained message, and chooses whether to perform a DH ratchet operation based on whether the sender and the receiver switch the sending and receiving states.

2. According to claim 1, a method for cross-domain secure transmission of lightweight node data based on blockchain, characterized in that: Step S1 specifically includes the following steps: S11. The system determines the system public parameters based on the security parameters Where p is a prime number, G is a p-order cyclic group, p is the generator of G, and e: G×G→G T is a bilinear pairing, h:{0,1} * →G,H:{0,1} * →Z p , is a secure cryptographic hash function, Sig / Vrfy(·) represents a pair of secure digital signature / verification algorithms, E / D(·) represents a pair of secure symmetric encryption / decryption algorithms, DH(·) is a secure Diffie-Hellman key exchange technology, AEAD(·) represents a secure authentication encryption algorithm with additional data, len is the bit length of the account address in the blockchain network, l is a security parameter, which represents the upper limit of the number of times the user requests the key strengthening service password authentication failure; S12. Identity Authentication Server The blockchain account created is S13. Password Server The identity ID is represented by Password Server The signature private key is By formula Calculate the password server The signature public key 3. According to claim 2, a method for cross-domain secure transmission of lightweight node data based on blockchain, characterized in that: Step S2 specifically includes the following steps: S21. User The identity ID is user The long-term identity key private key is By formula Calculate the user The public key of the identity is user The mid-term pre-shared signing key is By formula Calculate the first signature user The blockchain account is The corresponding private key is S22. User The first password is By blinding the value For the first password Password blinding Get the second password and will Send to password server S23. Password Server Maintain a service request list locally Each user corresponds to a first service request record req(ID, cre, ∈, l), where ID represents the user identity, cre represents the user authentication credential, and ∈ represents the random value used for verification; After the service request, query the user Identity Whether it exists in the service request list If it exists, terminate the subsequent operation; if it does not exist, calculate the blind signature The first random value is Create a second service request record in For users The safety parameters will Send to user S24. User First check the blind signature Legality If they are not equal, the subsequent operation is terminated; if they are equal, the unblinding value r is used -1 Blind Signature Unblinding Calculate the mnemonic First authentication certificate Random value ciphertext and will Send to password server S25, Password Server Decrypt the second random value According to identity Extract the third service request record And check If the equality holds, update the third service request record to If the equality does not hold, check the user Safety parameters Whether the authentication failure limit is exceeded, if Then let the user Safety parameters Increase by 1, otherwise, terminate the subsequent operation.

4. According to claim 3, a method for cross-domain secure transmission of lightweight node data based on blockchain, characterized in that: Step S3 specifically includes the following steps: S31. User Use mnemonics The private key of an encryption key pair, including Create the first transaction as user key management block T key , the user key management block address is From the first address To the second address Transfer 0 tokens, the integration content is as follows Order Data Calculate the second signature Will Sent to the authentication server S32, identity authentication server Maintain a list of registration records locally Each user corresponds to a first registration record in Indicates the identity authentication server The identity credential block address provided to the user; S33, Identity Authentication Server First, from the data Extract the user key management block address from Used to locate the user key management block T key , verify the user key management block T key Is the sender of the first address Is the recipient the second address? If the verification is successful, the identity authentication server From the user key management block T key Get the user The public key of the identity Used to verify the legitimacy of the signature. If the above authentications are passed, the identity authentication server Receive user key management block T key And generate a second transaction as user Identity public key Authentication certificate T cer , get the identity authentication server For users The provided identity credential block address The integration content is as follows And create a second registration record and save it to the local list On the contrary, if any of the above conditions fails to be verified, subsequent operations will be terminated.

5. According to claim 4, a method for cross-domain secure transmission of lightweight node data based on blockchain, characterized in that: Step S4 specifically includes the following steps: S41. Sender If necessary, the recipient Communication, first send the receiver Identity Send to sender Authentication server Make a communication request to it; S42. Sender Authentication server Determine the receiver domain, and send the Authentication server Request Receiver Certified transaction address Sender Authentication server Locating the receiver User Credentials Block To obtain the recipient The key block address and forward it to the sender S43. Sender extract Verify the first signature Is it legal? If so, a pair of temporary keys is generated. Sender Use the extracted recipient's public information and your own private key information to perform X3DH calculation: SK=KDF(DH1||DH2||DH3), get the shared key SK, where For sender The long-term identity key private key, For the receiver The mid-term pre-shared signing key, For the receiver The public key of the identity; S44. After the calculation is completed, the sender Delete the temporary private key and the intermediate output of the DH protocol locally and send the first message To the receiver in For sender The key management block address of , E(SK, m) is the second message encrypted with the shared key SK; S45. Receiver Receive the first message After that, first from the sender The key block address Get the key management block from and extract the sender from it The public key information of the receiver is obtained and the signature of the intermediate key is verified to be legitimate. Key Management Block Use mnemonics Decrypt the private key ciphertext to obtain the private key, and repeat the X3DH operation to calculate the shared key SK. At this time, the sender and the receiver Use a shared key SK.

6. According to claim 5, a method for cross-domain secure transmission of lightweight node data based on blockchain, characterized in that: Step S5 specifically includes the following steps: S51. Sender and the receiver During the communication process, the key chain and data structure state (DH s , DH r , RK, CK s , C.K. r ), the key chain includes a root key chain, a sending key chain and a receiving key chain, wherein DH s Indicates DH ratchet sends key pair, DH r Represents the DH ratchet receiving public key, RK represents the root key, CK s Indicates the chain key of the sending chain, CK r Represents the chain key of the receiving chain; S52, sender and the receiver The key derivation function agreed upon by both parties is (RK new , C.K. KFD_RK )←KDF_RK(RK old , dh_out), (CK new ,mk)←KDF_CK(CK old ), where dh_out is the output of the DH key negotiation function, mk represents the encryption and decryption message key, RK new Represents the first root key, RK old Indicates the second root key, CK new Represents the first chain key, CK old Indicates the second chain key, CX KDF_RK Indicates the seventh chain key; S53. To the sender Calculate and get the output Result KDF =KDF_RK(SK,DH(DH s , DH r )) and initialize its own state variables: S54. Receiver Waiting for sender Send the first message and initialize its own state variables:

7. According to claim 6, a method for cross-domain secure transmission of lightweight node data based on blockchain, characterized in that: Step S6 specifically includes the following steps: S61. Sender Perform symmetric ratchet operation, update the sending chain, and pass the formula state.CK s-new ,mk=KDF_CK(state.CK s-old ), obtain the encryption key mk and the third chain key CK required to encrypt the message s-new ; S62: Execute the key derivation agreed upon by both parties to generate the private key sk required for the next stage of DH ratchet ss ←Z P , and calculate the public key pk ss =sk ss P, and the public key pk ss Sent to the receiver as additional data AD Encrypted message C = AEAD(mk, plaintext, AD); S63. After the calculation is completed, the encryption key mk and the fourth chain key CK are deleted. s-old , the data (pk ss , C) sent to the receiver 8. According to claim 7, a method for cross-domain secure transmission of lightweight node data based on blockchain, characterized in that: Step S7 specifically includes: S71. Receiver From the data (pk ss , C) Extract the public key pk ss , calculate (RK new , C.K. KDF RK )=KDF_RK(RK old , DH(DH s , pk ss )), if the receiver receives the sender's message for the first time, then calculate (RK new , C.K. KDF_RK )=KDF_RK(SK,DH(DH s , pk ss )); S72. Receiving Party Perform symmetric ratchet operation, update receiving chain, calculate state.CK r-new ,mk=KDF_Ck(state.CK r-old ), obtain the message key mk and the fifth chain key CK for decrypting the current message r-new , where the sixth chain key CK r-old Equal to the seventh chain key CK KDF_RK ; S73, execute the AEAD decryption algorithm to decrypt the received ciphertext C and obtain the message plaintext; S74. In subsequent communications, if the sender and the receiver The sending and receiving status are swapped, and the DH ratchet key is updated.

Images