A cross-domain multi-mode trusted authentication method for highly dynamic networks

Abstract

The present invention relates to the field of integrated network security technology for air, space, land and sea, and discloses a cross-domain multi-mode trusted authentication method for highly dynamic networks, in which a trusted institution and a key generation center jointly initialize elliptic curve parameters and master, public and private keys; the trusted institution generates a pseudonym with a validity period for the node based on a random number, the key generation center generates a partial key, and the node locally completes it to form a complete key pair without a certificate. The sender can complete the signature with only one point multiplication, and the receiver completes the verification with three point multiplications. The message hash is compared with the help of a blockchain smart contract, and a list of legitimate / malicious nodes is maintained in real time to achieve conditional privacy protection, unlinkability, traceability and immediate revocation. Experimental results show that the method of the present invention has a computational overhead of about 7ms and a communication opening of 184 bytes. Under 300TPS concurrency, the average contract delay is less than 0.35s, which has both high security and low resource consumption.

Description

Technical Field

[0001] The present invention relates to the field of integrated air-space-ground-sea network security technology, and specifically to a cross-domain multi-mode trusted authentication method for a highly dynamic network. Background Art

[0002] With the continuous advancement of integrated air, land, and sea networks, the number of nodes across space, air, land, and sea continues to increase. This network plays an increasingly important role in achieving global coverage, situational awareness, and multi-platform collaboration, but the security challenges involved are also becoming increasingly prominent. Nodes themselves may engage in malicious behavior driven by profit, such as intentionally broadcasting false situational information or resource status, leading to global network misjudgments or coordination failures. Therefore, ensuring the authenticity and trustworthiness of message transmission is crucial during communications within these integrated air, land, and sea networks.

[0003] Digital signature technology, as one of the primary means of ensuring trusted and secure communication between nodes, has been widely used in IoT security scenarios. However, signature schemes based on traditional public key infrastructure (PKI) suffer from high certificate maintenance costs, while identity-based signature schemes face key escrow issues. To overcome these issues, certificateless signature technology has been proposed. Unlike the aforementioned two schemes, certificateless signature technology does not require public key certificates. Instead, the user's private key is jointly generated by the user and a semi-trusted third-party entity, effectively addressing the key escrow and certificate overhead issues. Consequently, it has been widely used in various scenarios, including the IoT. This technology verifies signatures to ensure that messages have not been maliciously tampered with during transmission. However, this verification process cannot be directly linked to the node's own behavior. If a node intentionally sends an incorrect message and then transmits it to the recipient, the recipient cannot verify the authenticity of the message or verify the node's untrustworthy behavior. Summary of the Invention

[0004] (1) Technical Problems Solved: In response to the deficiencies of the existing technology, the present invention provides a cross-domain multi-mode trusted authentication method for a highly dynamic network, which solves the above-mentioned problems.

[0005] (2) Technical solution: To achieve the above-mentioned purpose, the present invention provides the following technical solution: A cross-domain multi-mode trusted authentication method for a highly dynamic network, providing a system including a trusted organization, a key generation center and a node, characterized in that the method includes the following steps: S1: The trusted organization and the key generation center generate their own private keys and public parameters, and publish the public parameters.

[0006] S2: The trusted organization selects a random number for each node and calculates a pseudonym, and then sends the pseudonym to the corresponding node and the key generation center; each node includes a sending node and a receiving node; the pseudonym includes a first component, a second component and a validity period.

[0007] S3: After receiving the pseudonym sent by the trusted organization, the key generation center checks whether the validity period of the pseudonym is still valid. If so, it generates the first part of the private key and the first part of the public key and sends them together with the pseudonym to the corresponding node. Otherwise, the pseudonym is discarded.

[0008] S4: After receiving the data packet containing the pseudonym, the first part of the private key and the first part of the public key, each node verifies the legitimacy of the first part of the private key. If the verification is successful, it generates the second part of the private key and the second part of the public key, and combines them with the first part of the private key and the first part of the public key to obtain the complete private key and the complete public key. Otherwise, the data packet is discarded.

[0009] S5: When the sending node needs to send a message, the sending node generates a digital signature and sends it together with the message, wherein the digital signature is calculated based on a random number, a pseudonym, a complete public key, the message to be sent and a timestamp.

[0010] S6: After receiving the data packet containing the pseudonym, complete public key, message, digital signature and timestamp, the receiving node performs a timeliness check on the timestamp; if the check passes, the digital signature is verified to confirm the message integrity and the identity of the sender, otherwise the data packet is discarded.

[0011] S7: The receiving node verifies the correctness of the content of the message by calling the smart contract deployed on the blockchain, and updates the list of legitimate nodes and malicious nodes on the blockchain in real time based on the verification results; when the verification fails, the sending node is marked as a malicious node and synchronized to the entire network.

[0012] Furthermore, the S1 is specifically as follows: S11: Select an elliptic curve , set group , the order of the group and generators .

[0013] S12: The trusted institution TA selects a random number As the system's master private key, and calculate the corresponding master public key as .

[0014] S13: The key generation center selects a random number As the private key, and calculate the corresponding public key as .

[0015] S14: Select the first, second and third collision-resistant secure hash functions: .

[0016] S15: Public Parameters .

[0017] Furthermore, the S2 specifically includes: S21: The trusted institution is each node Select random numbers respectively ,in, Indicates the node's sequence number.

[0018] S22: Generator-based , calculate the first component .

[0019] S23: Based on the system's master public key , calculate shared curve points .

[0020] S24: Set the validity period of the pseudonym , and calculate the second pseudonym component ;in, is the real identity of the node, is the system's master private key, is the first collision-resistant secure hash function, Represents a bitwise exclusive OR operation.

[0021] S25: Combine to get node pseudonym and sent to the corresponding nodes through secure channels and key generation center.

[0022] Furthermore, in S3, a partial private key is generated and sent to the corresponding node, specifically: S31: The key generation center is the node Pick a random number .

[0023] S32: Based on random numbers , calculate the first part of the public key .

[0024] S33: Node-based pseudonyms 、The first part of the public key , key generation center public key and the validity period of the pseudonym , calculate the hash coefficient ;in, It is the second most collision-resistant secure hash function.

[0025] S34: Compute the first part of the private key of the node ;in, The private key of the key generation center, S35: Send to the corresponding node .

[0026] Furthermore, the S4 specifically includes: S41: Node take over Then calculate the hash coefficient , and verify the equation If not, discard the data packet.

[0027] S42: Select a random number , and calculate the second part of the public key .

[0028] S43: Based on and , calculate the hash coefficient again .

[0029] S44: Calculate the combined public key components .

[0030] S45: Determine the node's complete private key and the complete public key .

[0031] Furthermore, the S5 specifically includes: S51: sender node Pick a random number , and calculate the temporary public key .

[0032] S52: Based on the sender node pseudonym , complete public key , temporary public key , messages to be sent and timestamp Calculating the hash coefficient ,in, It is the third collision-resistant secure hash function.

[0033] S53: Based on the hash coefficient Generate signed scalar ;in, For group level.

[0034] S54: Based on temporary public key and signed scalars Get a signature , and Sent to the receiving node .

[0035] Furthermore, the S6 specifically includes: S61: Receiving node Determine timestamp Whether it is within the valid time window, if not, the data packet is discarded.

[0036] S62: When the timestamp When valid, based on the pseudonym of the sender node 、The first part of the public key , key generation center public key and validity period , calculate the hash coefficient .

[0037] S63: Pseudonym based on the sender node , the second part of the public key , key generation center public key and the validity period of the pseudonym , calculate the hash coefficient .

[0038] S64: Pseudonym based on the sender node , complete public key , temporary public key ,information and timestamp , calculate the hash coefficient .

[0039] S65: Verifying Elliptic Curve Equality Is it true? If the equality is true, the digital signature is valid and the message is received, otherwise the data packet is discarded.

[0040] Furthermore, the S7 specifically includes: S71: the receiving node calls the verifyMessage function in the smart contract and sends the message to be verified and the pseudonym of the sending node Passed in as a parameter; calculated within the contract And the Compare with the real event hash value pre-stored in the contract state and output a Boolean value .

[0041] S72: The receiving node continues to call the smart contract Function, the sender node address and As input, when , the sender node is removed from the legal node list and added to the malicious node list; otherwise, if the sender node does not exist in the legal node list, it is added to the legal node list.

[0042] S73: The list update result and verification transaction are written into the blockchain ledger, and all nodes in the blockchain network synchronize the legitimate node list and the malicious node list to achieve a consistent node reputation status across the entire network.

[0043] (III) Beneficial effects: Compared with the prior art, the present invention provides a cross-domain multi-mode trusted authentication method for highly dynamic networks, which has the following beneficial effects: 1. The cross-domain multi-mode trusted authentication method for highly dynamic networks replaces the plaintext identity with a pseudonym mechanism driven by a random number, thereby realizing the design of "nodes communicating with pseudonyms and reversibly parsing by trusted institutions"; the pseudonyms are continuously updated with the validity period and random numbers, and attackers can neither associate different sessions nor infer the real identity. Only when the node is suspected of malicious behavior can the T trusted institution restore it once with the master private key, thereby achieving conditional privacy protection, unlinkability, traceability and non-repudiation.

[0044] 2. This cross-domain, multi-modal trusted authentication method for highly dynamic networks replaces bilinear pairings with certificateless elliptic curve signatures throughout the process. The sender only needs one point multiplication to issue a signature, while the receiver requires three point multiplications and five hashes in the "signature verification plus message verification" process. Compared with similar solutions, this method significantly reduces computational and communication overhead, and maintains its lightweight characteristics while ensuring identity authentication, content verification, and node reputation determination.

[0045] 3. This cross-domain, multi-modal trusted authentication method for highly dynamic networks avoids the risks of centralized failure and tampering by writing message hash comparisons and node blacklist and whitelist updates into blockchain smart contracts. In a 300-concurrency scenario, the average contract latency was less than 0.3 seconds and the throughput was approximately 200 TPS, verifying the efficiency and stability of the solution in an integrated air-space-land-sea distributed environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 The present invention provides an overall process diagram of the method.

[0047] Figure 2 A schematic diagram of the timing interaction provided by the method of the present invention.

[0048] Figure 3 Schematic diagram of pseudonym generation, partial key generation and key generation process provided by the method of the present invention.

[0049] Figure 4 Schematic diagram of the signature generation and signature verification process provided by the method of the present invention.

[0050] Figure 5 This is a graph showing the experimental results of the signature process overhead, verification process overhead, and total computational overhead provided by the method of the present invention.

[0051] Figure 6 This is a graph showing the experimental results of the communication overhead provided by the method of the present invention.

[0052] Figure 7 The experimental results of the maximum delay, minimum delay and average delay of the smart contract provided by the method of the present invention at different concurrency levels are shown.

[0053] Figure 8 This is a graph of the throughput and latency results of the smart contract provided by the method of the present invention at different concurrency levels. DETAILED DESCRIPTION

[0054] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0055] In order to enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0056] See also Figure 1-3 , Figure 1 The overall process diagram provided for the method of the present invention; Figure 2 A schematic diagram of the timing interaction provided by the method of the present invention; Figure 3 A schematic diagram of pseudonym generation, partial key generation and key generation process provided by the method of the present invention; the present invention provides a cross-domain multi-mode trusted authentication method for a highly dynamic network, providing a system including a trusted organization, a key generation center and nodes, and the method comprising the following steps: S1: The trusted organization and the key generation center generate their respective private keys and public parameters, and publish the public parameters.

[0057] S2: The trusted organization selects a random number for each node and calculates a pseudonym, and then sends the pseudonym to the corresponding node and the key generation center; each node includes a sending node and a receiving node; the pseudonym includes a first component, a second component and a validity period.

[0058] S3: After receiving the pseudonym sent by the trusted organization, the key generation center checks whether the validity period of the pseudonym is still valid. If so, it generates the first part of the private key and the first part of the public key and sends them together with the pseudonym to the corresponding node. Otherwise, the pseudonym is discarded.

[0059] S4: After receiving the data packet containing the pseudonym, the first part of the private key and the first part of the public key, each node verifies the legitimacy of the first part of the private key. If the verification is successful, it generates the second part of the private key and the second part of the public key, and combines them with the first part of the private key and the first part of the public key to obtain the complete private key and the complete public key. Otherwise, the data packet is discarded.

[0060] S5: When the sending node needs to send a message, the sending node generates a digital signature and sends it together with the message, wherein the digital signature is calculated based on a random number, a pseudonym, a complete public key, the message to be sent and a timestamp.

[0061] S6: After receiving the data packet containing the pseudonym, complete public key, message, digital signature and timestamp, the receiving node performs a timeliness check on the timestamp; if the check passes, the digital signature is verified to confirm the message integrity and the identity of the sender, otherwise the data packet is discarded.

[0062] S7: The receiving node verifies the correctness of the content of the message by calling the smart contract deployed on the blockchain, and updates the list of legitimate nodes and malicious nodes on the blockchain in real time based on the verification results; when the verification fails, the sending node is marked as a malicious node and synchronized to the entire network.

[0063] Furthermore, in order to establish a unified and secure cryptographic foundation in the integrated network of air, space, land and sea, the system initialization phase is completed by the trusted institution and the key generation center in collaboration: the two parties first select the elliptic curve , determine the order Cyclic group of and its generators , then the trusted organization independently generates the system master private key And calculate the master public key , and the key generation center independently generates its own private key And calculate the public key On this basis, we select three types of collision-resistant secure hash functions , and By making the master private key With private key The key information is kept by the trusted institution and the key generation center respectively, which not only forms the trust root relied on by subsequent pseudonym generation, certificateless signing and other operations, but also prevents any single entity from owning all key information. , set group , the order of the group and generators .

[0064] S12: The trusted institution TA selects a random number As the system's master private key, and calculate the corresponding master public key as .

[0065] S13: The key generation center selects a random number As the private key, and calculate the corresponding public key as .

[0066] S14: Select the first, second and third collision-resistant secure hash functions: .

[0067] S15: Publish public parameters .

[0068] Furthermore, in order to protect the true identity of nodes in the integrated air-space-ground-sea network, it is necessary to hide their true identity, that is, to generate corresponding pseudonyms through the true identity. The pseudonym is determined by a trusted authority based on the node's real identity Generate; The design of pseudonym can restore the true identity of malicious nodes while protecting the privacy of node identity, that is, to achieve conditional privacy protection; Since only the trusted institution has the master private key, no other node can calculate the true identity of the node. The S2 specifically includes: S21: The trusted institution is each node Select random numbers respectively ,in, Indicates the node's sequence number.

[0069] S22: Generator-based , calculate the first component .

[0070] S23: Based on the system's master public key , calculate shared curve points .

[0071] S24: Set the validity period of the pseudonym , and calculate the second pseudonym component ;in, is the real identity of the node, is the system's master private key, is the first collision-resistant secure hash function, Represents a bitwise exclusive OR operation.

[0072] S25: Combine to get node pseudonym and sent to the corresponding nodes through secure channels and key generation center.

[0073] Furthermore, in order to enable network nodes to obtain key materials strongly bound to their pseudonyms without holding certificates, the key generation center will first check the validity period of the pseudonym after receiving it from the trusted organization; if it is still valid, the corresponding node Pick a random number Calculate the first part of the public key and under a pseudonym 、 , key generation center public key and validity period of the pseudonym Obtain the hash coefficient for the input ; Then, the key generation center uses its own private key Generate the first part of the node's private key , and The private key is sent to the node via a secure channel, thereby ensuring that no third party can deduce the complete private key based on the pseudonym alone, and the key is tightly bound to the pseudonym and validity period. In S3, a partial private key is generated and sent to the corresponding node, specifically: S31: The key generation center is the node Pick a random number .

[0074] S32: Based on random numbers , calculate the first part of the public key .

[0075] S33: Node-based pseudonyms 、The first part of the public key , key generation center public key and the validity period of the pseudonym , calculate the hash coefficient ;in, It is the second most collision-resistant secure hash function.

[0076] S34: Compute the first part of the private key of the node ;in, The private key of the key generation center, For group level.

[0077] S35: Send to the corresponding node .

[0078] Furthermore, in order to completely eliminate the risk of key escrow and ensure the node’s exclusive control over its own private key, the node Upon receipt of the key generation center's After the data packet, first verify the equation with the same hash coefficient , confirm that the first part of the private key is legal; after verification, the node locally selects a random number to calculate the second part of the public key , and accordingly obtain , and then generate the combined public key component ; At this point, the node will and self-sustaining Combined into a complete private key and the corresponding complete public key ; Thus, the two parts of the complete private key are respectively in the hands of the key generation center and the node itself, which not only ensures the autonomy and non-repudiation of the node signature, but also effectively blocks the attack path of any single entity to forge or replace the key. The S4 specifically includes: S41: Node take over Then calculate the hash coefficient , and verify the equation If not, discard the data packet.

[0079] S42: Select a random number , and calculate the second part of the public key .

[0080] S43: Based on and , calculate the hash coefficient again .

[0081] S44: Calculate the combined public key components .

[0082] S45: Determine the node's complete private key and the complete public key .

[0083] For further information, see Figure 4 , Figure 4 Schematic diagram of the signature generation and signature verification process provided by the method of the present invention; in order to achieve lightweight and non-repudiation of identity and content binding before the sender node actually sends the service message, the sender node First, select a one-time random number And calculate the temporary public key ; Then get the hash coefficient , and generate a signature scalar based on it , which ultimately constitutes a digital signature , and The whole message is sent to the receiving node. This process only requires one elliptic curve multiplication to generate a signature, and the random number and timestamp are used to ensure that each message signature is unique and replay-proof. At the same time, the pseudonym is bound to the complete private key to ensure the coexistence of non-repudiation of the signature and privacy protection. The S5 specifically includes: S51: The sending node Pick a random number , and calculate the temporary public key .

[0084] S52: Based on the sender node pseudonym , complete public key , temporary public key , messages to be sent and timestamp Calculating the hash coefficient ,in, It is the third collision-resistant secure hash function.

[0085] S53: Based on the hash coefficient Generate signed scalar ;in, For group level.

[0086] S54: Based on temporary public key and signed scalars Get a signature , and Sent to the receiving node .

[0087] Furthermore, in order to achieve instant, low-cost and double-guaranteed identity and content verification of incoming messages at the receiving node, the node Upon receipt After that, first check the timestamp Perform window check to resist replay; after the check passes, calculate the binding coefficient using the sender's pseudonym and the first and second parts of the public key and , and then calculate the hash coefficient , then verify the core equation If the equation holds, it confirms the sender's sole control of the complete private key and the fact that the message content has not been tampered with. Otherwise, the data packet is immediately discarded and subsequent processing is blocked. This allows signature verification in a highly dynamic network environment to be completed with only three elliptic curve point multiplications and three hash operations. S6 specifically includes: S61: The receiving node Determine timestamp Whether it is within the valid time window, if not, the data packet is discarded.

[0088] S62: When the timestamp When valid, based on the pseudonym of the sender node 、The first part of the public key , key generation center public key and validity period , calculate the hash coefficient .

[0089] S63: Pseudonym based on the sender node , the second part of the public key , key generation center public key and the validity period of the pseudonym , calculate the hash coefficient .

[0090] S64: Pseudonym based on the sender node , complete public key , temporary public key ,information and timestamp , calculate the hash coefficient .

[0091] S65: Verifying Elliptic Curve Equality Is it true? If the equality is true, the digital signature is valid and the message is received, otherwise the data packet is discarded.

[0092] Furthermore, in order to eliminate the single point of failure of centralized verification and synchronize the authenticity of the message and the node reputation status across the entire network, the receiving node calls the blockchain smart contract after completing the signature verification: the verifyMessage function first calculates the message hash and compares it with the real event hash on the chain to generate , and then immediately call Function basis The results dynamically maintain the list of legitimate nodes and the list of malicious nodes; if the verification fails, the sending node is removed from the whitelist and added to the blacklist, otherwise it is registered or retained. All verification results and list changes are written to the blockchain along with the transaction and broadcast by consensus, achieving end-to-end decentralized message verification that is tamper-proof, publicly auditable, and less than 0.3 seconds. The S7 specifically includes: S71: The receiving node calls the verifyMessage function in the smart contract and sends the message to be verified to the blockchain. and the pseudonym of the sending node Passed in as a parameter; calculated within the contract And the Compare with the real event hash value pre-stored in the contract state and output a Boolean value .

[0093] S72: The receiving node continues to call the smart contract Function, the sender node address and As input, when , the sender node is removed from the legal node list and added to the malicious node list; otherwise, if the sender node does not exist in the legal node list, it is added to the legal node list.

[0094] S73: The list update result and verification transaction are written into the blockchain ledger, and all nodes in the blockchain network synchronize the legitimate node list and the malicious node list to achieve a consistent node reputation status across the entire network.

[0095] To further verify the effect of the solution of the present invention, please refer to Figure 5-8 , Figure 5The experimental results of the signature process overhead, verification process overhead and total computational overhead provided by the method of the present invention are shown in the figure; Figure 6 The experimental results of the communication overhead provided by the method of the present invention are shown in FIG. Figure 7 The experimental results of the maximum delay, minimum delay and average delay of the smart contract under different concurrency levels provided by the method of the present invention; Figure 8 This is a graph of the throughput and latency results of the smart contract provided by the method of the present invention at different concurrency levels.

[0096] exist Figure 5 Experimental results show that the signature phase of this method is ≈2ms, the verification phase is ≈5ms, and the total is ≈7ms, which is 83% lower than the 41ms total time consumption of the ECA framework, and about 20%-25% lower than lightweight solutions such as AEP and REL. This verifies that the proposed certificateless ECC process significantly improves end-to-end execution efficiency while ensuring security properties.

[0097] exist Figure 6 In terms of message interaction size, the data packet sent by the solution of the present invention is only 184 bytes, which is on par with the optimal baseline AEP, saving 35% compared with the mainstream BBAS framework and 66% compared with the ECA solution that introduces certificates. This shows that the message structure of one-time encapsulation of pseudonym + complete public key can compress the link load without sacrificing verification information, which is particularly in line with the strict bandwidth constraints of air-space-ground-sea heterogeneous links.

[0098] exist Figure 7 In a simulated on-chain environment with 50-300 TPS concurrent transactions, the average latency of the smart contract in this solution remained below 0.35s, with the minimum latency approaching 0s and the maximum latency not exceeding 1.1s despite increasing linearly with the load. These results demonstrate that the message hash comparison and list update logic, implemented in Solidity, can maintain sub-second response times within the existing consortium chain's underlying consensus mechanism.

[0099] exist Figure 8 In the experiment, as concurrency increased from 50 TPS to approximately 230 TPS, contract throughput climbed linearly and stabilized at around 200 TPS, while the corresponding latency only increased smoothly to approximately 0.35 seconds. As the load continued to increase, the throughput and latency curves approached saturation without noticeable jitter, verifying the contract's stability and scalability under high load. The combined throughput-latency performance further demonstrates that the design of incorporating message verification and node reputation maintenance into the chain not only eliminates the bottleneck of central servers, but also meets the dual requirements of high concurrency and low latency for the integrated air-space-land-sea network.

[0100] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0101] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A cross-domain multi-mode trusted authentication method for a highly dynamic network, providing a system including a trusted institution, a key generation center, and nodes, characterized in that: The method The following steps are involved: S1: The trusted institution and the key generation center generate their own private keys and public parameters, and publish the public parameters; S2: The trusted institution selects a random number for each node and calculates a pseudonym, which is then sent to the corresponding node and the key generation center. Each node includes a sending node and a receiving node. The pseudonym includes a first component, a second component, and an expiration date. S3: After receiving the pseudonym from the trusted institution, the key generation center checks whether the pseudonym is still valid. If so, it generates a first part private key and a first part public key, and sends them along with the pseudonym to the corresponding node. Otherwise, the pseudonym is discarded. S4: After receiving the data packet containing the pseudonym, the first part of the private key and the first part of the public key, each node verifies the legitimacy of the first part of the private key. If the verification is successful, the second part of the private key and the second part of the public key are generated, and combined with the first part of the private key and the first part of the public key to obtain the complete private key and the complete public key. Otherwise, the data packet is discarded; S5: When the sending node needs to send a message, the sending node generates a digital signature and sends it together with the message, wherein the digital signature is calculated based on the random number, the pseudonym, the complete public key, the message to be sent and the timestamp; S6: After receiving the data packet containing the pseudonym, the complete public key, the message, the digital signature and the timestamp, the receiving node performs a timeliness check on the timestamp; if the check is successful, the digital signature is verified to confirm the message integrity and the identity of the sender, otherwise the data packet is discarded; S7: The receiving node verifies the correctness of the content of the message by calling the smart contract deployed on the blockchain, and updates the list of legitimate nodes and malicious nodes on the blockchain in real time based on the verification results; when the verification fails, the sending node is marked as a malicious node and synchronized to the entire network.

2. A cross-domain multi-mode trusted authentication method for a highly dynamic network according to claim 1, characterized in that: The S1 is specifically as follows: S11: Select an elliptic curve , set group , the order of the group and generators ; S12: Trusted institution TA selects random number As the system's master private key, and calculate the corresponding master public key as ; S13: The key generation center selects a random number As the private key, and calculate the corresponding public key as ; S14: Select the first, second and third collision-resistant secure hash functions: ; S15: Publish public parameters .

3. The cross-domain multi-mode trusted authentication method for a highly dynamic network according to claim 2, characterized in that: The S2 specifically includes: S21: The trusted institution is each node Select random numbers respectively ,in, Indicates the sequence number of the node; S22: based on the generator , calculate the first component ; S23: Based on the system's master public key , calculate shared curve points ; S24: Set the validity period of the pseudonym , and calculate the second pseudonym component ;in, is the real identity of the node, is the system's master private key, is the first collision-resistant secure hash function, Indicates bitwise XOR operation; S25: Combine to get the node pseudonym and sent to the corresponding nodes through secure channels and key generation center.

4. A cross-domain multi-mode trusted authentication method for a highly dynamic network according to claim 3, characterized in that: In S3, a partial private key is generated and sent to the corresponding node, specifically: S31: The key generation center is the node Pick a random number ; S32: Based on random number , calculate the first part of the public key ; S33: Based on node pseudonym 、The first part of the public key , key generation center public key and the validity period of the pseudonym , calculate the hash coefficient ;in, The second collision-resistant secure hash function; S34: Calculate the first part of the node private key ;in, The private key of the key generation center, For group level; S35: Send to the corresponding node .

5. A cross-domain multi-mode trusted authentication method for a highly dynamic network according to claim 4, characterized in that: The S4 specifically includes: S41: Node take over Then calculate the hash coefficient , and verify the equation Is it true? If not, discard the data packet; S42: Select a random number , and calculate the second part of the public key ; S43: Based on and , calculate the hash coefficient again ; S44: Calculate the combined public key component ; S45: Determine the node's complete private key and the complete public key .

6. A cross-domain multi-mode trusted authentication method for a highly dynamic network according to claim 5, characterized in that: The S5 specifically includes: S51: sender node Pick a random number , and calculate the temporary public key ; S52: Based on the sender node pseudonym , complete public key , temporary public key , messages to be sent and timestamp Calculating the hash coefficient ,in, is a third collision-resistant secure hash function; S53: according to the hash coefficient Generate signed scalar ;in, is the group order; S54: based on temporary public key and signed scalars Get a signature , and Sent to the receiving node .

7. A cross-domain multi-mode trusted authentication method for a highly dynamic network according to claim 6, characterized in that: The S6 specifically includes: S61: Receiving node Determine timestamp Is it within the valid time window? If not, the data packet is discarded. S62: When the timestamp When valid, based on the pseudonym of the sender node 、The first part of the public key , key generation center public key and validity period , calculate the hash coefficient ; S63: Pseudonym based on the sender node , the second part of the public key , key generation center public key and the validity period of the pseudonym , calculate the hash coefficient ; S64: Pseudonym based on the sender node , complete public key , temporary public key ,information and timestamp , calculate the hash coefficient ; S65: Verify elliptic curve equality Is it true? If the equality is true, the digital signature is valid and the message is received, otherwise the data packet is discarded.

8. A cross-domain multi-mode trusted authentication method for a highly dynamic network according to claim 7, characterized in that: The S7 specifically includes: S71: The receiving node calls the verifyMessage function in the smart contract and sends the message to be verified and the pseudonym of the sending node Passed in as a parameter; calculated within the contract And the Compare with the real event hash value pre-stored in the contract state and output a Boolean value ; S72: The receiving node continues to call the smart contract Function, the sender node address and As input, when When the sender node is detected, the sender node is removed from the legal node list and added to the malicious node list; otherwise, if the sender node does not exist in the legal node list, it is added to the legal node list; S73: the list update result and verification transaction are written into the blockchain ledger, and all nodes in the blockchain network synchronize the legal node list and the malicious node list to achieve a consistent node reputation status across the entire network.

Images