A Formal Verification Method for Network Protocol Combinations

Abstract

This invention proposes a formal verification method for network protocol composition, belonging to the field of formal verification technology. During the network protocol design phase, the method effectively performs formal verification on the information security, functional security, and cryptographic reliability required by the network protocol, enabling potential security flaws to be detected in the network protocol code before implementation, and ensuring that no false counterexamples exist among these potential security flaws.

Description

Technical Field

[0001] This invention belongs to the field of formal verification technology, and in particular relates to a formal verification method for network protocol combinations. Background Technology

[0002] With the rapid development of information and network technologies, information and communication networks have become crucial national infrastructures, making their security increasingly important. In recent years, cyberattacks such as botnets, denial-of-service attacks, and high-persistence threats have occurred frequently, repeatedly sounding the alarm for cybersecurity researchers. As a key component of network systems, ensuring the security of network protocols is of great significance for achieving cyberspace security. However, with the increasing demand for network communication, emerging communication technologies such as 5G and new network architectures such as QUIC have emerged, making protocol design increasingly complex. This is reflected in the computational complexity (combination of multiple cryptographic operations), environmental complexity (the presence of malicious attackers), and concurrency complexity (multiple entities executing concurrently). Currently, the design of existing network protocols mainly considers providing better connectivity and compatibility for network services, often neglecting the insecurity factors existing in complex network environments. This leads to security flaws, causing protocols to fail to meet their claimed security properties during actual execution. Attackers can exploit these design flaws to launch attacks on users within the network, posing a serious security threat to the entire network system.

[0003] Since the late 1970s, researchers have proposed various formal analysis theories of network protocols based on symbolic representation. For example, they proposed the assumption of a "perfect" cryptographic model, allowing researchers to focus on the intrinsic security properties of protocols without discussing the security of cryptographic algorithms. They also proposed the Dolev-Yao model, an attacker capability model in which attackers possess greater operational capabilities than the actual participants in the protocol. Attackers can eavesdrop, intercept, tamper with, and replay information exchanged between real entities during protocol operation, and can encrypt, decrypt, split, and recombine original messages to forge message content. Based on the Dolev-Yao model, formal analysis methods for security protocols can generally be divided into three categories: modal logic-based methods, classical model testing-based methods, and theorem-proving methods.

[0004] Modal logic is intuitive, simple, and practical. It abstracts the objects, states, and relationships involved in network protocols into propositions and inference rules. Propositions represent the knowledge of the protocol subjects regarding protocol messages. These propositions are calculated according to inference rules, allowing new knowledge to be derived from known knowledge. Modal logic analysis of a protocol can be understood as follows: first, the security properties of the protocol are represented as the target knowledge of the subjects. Whether the protocol satisfies these declared security properties can be viewed as a deductive process of whether the subjects can deduce the target knowledge from the initial knowledge after the security protocol has been executed. The most representative method of modal logic is BAN logic theory, which was the first to verify knowledge-based modal logic for security protocols. However, BAN logic lacks a precise semantic foundation and cannot detect attackers' attacks on knowledge.

[0005] Classical model checking methods essentially involve state searching for the security attributes of a protocol. This method abstracts the protocol as a distributed state space, where the process executed by each protocol entity is considered a local state, and the combination of all local states constitutes the global state of the security protocol. When the information of a protocol entity changes, its local state space changes, and consequently, the global state space changes as well. The security properties of a protocol are represented as invariant relations and defined in the global state. Analyzing these security properties involves determining whether all global states of the security protocol satisfy these invariant relations. Because network protocols can involve a large number of state changes, manual analysis is impossible; therefore, classical model checking methods typically rely on automated tools. While classical model checking techniques have achieved remarkable success in computer hardware and control systems, in network protocol verification, network protocols generally possess complex cryptographic mechanisms that classical model checking techniques cannot analyze. For example, if a state in the model receives a symmetric encrypted ciphertext, classical model checking cannot analyze whether the current state can decrypt the ciphertext; the ciphertext result is randomly determined as true or false, serving as the transition condition for the current state. This randomly assigned state transition condition can characterize all possible situations during protocol execution, but it may not be truly feasible for actual network protocols, and there may be false counterexamples.

[0006] The basic idea of ​​theorem proving is proof based on mathematical theory. It describes the behavior of a security protocol as an axiomatic system and the security properties of the protocol as theorems that need to be proven. It views the security analysis of a security protocol as a theorem proving process within an axiomatic system. Theorem proving differs from model checking; theorem proving that the security of a protocol is satisfied, while model checking searches for attacks on the protocol—one addresses the positive aspects of the problem, the other the negative. Theorem proving can analyze the properties of a security protocol without limiting the number of concurrent executions. However, theorem proving requires significant human intervention for proof, making automated verification difficult. Summary of the Invention

[0007] To address the aforementioned technical problems, this invention proposes a formal verification method for network protocol composition. This method performs effective formal verification of the information security, functional security, and cryptographic reliability required by the protocol during the network protocol design phase, ensuring design guarantees for the required properties of the protocol before the protocol code is implemented.

[0008] The method performs effective formal verification of the information security, functional security and cryptographic reliability required by the network protocol during the network protocol design phase, so that potential security defects are detected in the network protocol code before implementation, and there are no false counterexamples among the potential security defects.

[0009] The method includes:

[0010] Step S1: Obtain the network protocol design document Doc, apply PI calculus to the network protocol design document Doc to perform formal modeling, thereby obtaining the first formal model. Perform automated verification for information security on the first formal model through the automated verifier ProVerif, and obtain the network protocol design document DocS with information security guarantee.

[0011] Step S2: Perform classic model detection and modeling on the network protocol design document DocS based on the Promela language to obtain a second formal model. Then, perform automated verification for functional safety on the second formal model through the automated verifier SPIN to obtain a set of counterexamples π, which includes real counterexamples and false counterexamples.

[0012] Step S3: Classify each counterexample in the counterexample set π, and use different verification methods to perform false counterexample screening for different categories of counterexamples to obtain a set of real counterexamples π' that only includes violations of network protocol functional security. Then, use the set of real counterexamples π' to revise the network protocol design document DocS, thereby obtaining a network protocol design document DocSS with information security and functional security guarantees.

[0013] Step S4: Apply Blanchet calculus to formally model the network protocol design document DocSS to obtain a third formal model. Then, use the automated verifier CryptoVerif to perform automated verification of the third formal model for cryptographic reliability, resulting in a network protocol design document DocSSS with information security, functional security, and cryptographic reliability guarantees.

[0014] According to the above method, in step S1, the network protocol design document Doc is formally modeled using PI calculus, including: application PI calculus modeling of the protocol channel, protocol cryptography suite, and protocol interaction process subject, as well as constructing a formal specification model for confidentiality and consistency for information security.

[0015] According to the above method, in step S1, the first formal model is automatically verified for information security by the automated verifier ProVerif, including: automatically verifying the first formal model by the automated verifier ProVerif, outputting counterexamples that violate network protocol information security, and correcting the network protocol design document Doc based on the counterexamples that violate network protocol information security, and continuously repeating the automated verification process for information security until the automated verifier ProVerif outputs no more counterexamples, thereby obtaining a network protocol design document DocS with information security protection.

[0016] According to the above method, in step S2, the network protocol design document DocS is subjected to classic model detection and modeling based on the Promela language, including: constructing an interaction flow state machine model of the network protocol based on the network protocol design document DocS, and performing formal modeling of the interaction flow state machine model using the Promela language to obtain a second formal model. The second formal model includes a protocol process model, an attacker model, and a temporal model of functional security.

[0017] According to the above method, in step S3, each counterexample in the counterexample set π is classified, and the classification results include: counterexamples that cannot be determined whether the attacker can construct; counterexamples that the attacker can construct, which are regarded as real counterexamples; and counterexamples that the attacker cannot construct, which are regarded as false counterexamples.

[0018] According to the above method, in step S3, different verification methods are used to screen out false negatives for different categories of negatives, including:

[0019] For counterexamples that cannot be determined whether an attacker can construct, they are converted into verifications based on ProVerif confidentiality.

[0020] Based on query attacker(m), where m is the plaintext message sent by the honest participant, if the attacker can obtain the plaintext message m, then the attacker can forge the plaintext message m; to determine whether the attacker can obtain the plaintext message m, that is, whether the plaintext message m passes the confidentiality verification.

[0021] In this scenario, honest participant A sends plaintext message m to honest participant B on a private channel. The attacker cannot obtain plaintext message m from the private channel, but instead intercepts plaintext message m from the public channel between honest participant B and other participants.

[0022] According to the above method, in step S3, different verification methods are used to screen out false negatives for different categories of negatives, including:

[0023] For counterexamples that attackers can construct and those that attackers cannot construct, convert them into confidentiality and consistency verification based on ProVerif.

[0024] Based on query attacker(key), inj-event(e(key)) ==> inj-event(e(key)), where key is the key to construct plaintext message m, the confidentiality of key is verified to prevent the attacker from forging message m when the attacker obtains key;

[0025] Verify the consistency of the key to prevent attackers from impersonating honest participants and exchanging keys with other honest participants in the key exchange protocol. This also prevents attackers from impersonating honest participants and sending forged erroneous ciphertext to other honest participants, which would cause the protocol to fail to execute properly.

[0026] After verifying the confidentiality and consistency of the key, false counterexamples are filtered out from the counterexample set π to obtain the true counterexample set π'. The network protocol design document DocS is then revised using the true counterexample set π', thus obtaining the network protocol design document DocSS with information security and functional security guarantees.

[0027] According to the above method, in step S4, the network protocol design document DocSS is formally modeled using Blanchet calculus, including: Blanchet calculus modeling of the protocol channel, protocol cryptography suite, protocol interaction process body, and specification model constructed for cryptographic reliability.

[0028] According to the above method, in step S4, the third formal model is subjected to automated verification for cryptographic reliability by the automated verifier CryptoVerif. This includes: automatically verifying the third formal model by the automated verifier CryptoVerif, outputting counterexamples that violate the cryptographic reliability of the network protocol, and correcting the network protocol design document DocSS based on the counterexamples that violate the cryptographic reliability of the network protocol. The automated verification process for cryptographic reliability is repeated until the automated verifier CryptoVerif outputs no counterexamples, thus obtaining the network protocol design document DocSS that has information security, functional security, and cryptographic reliability guarantees.

[0029] In summary, this invention addresses the limitation of existing technologies that only verify a single security aspect of a network protocol, proposing a formal verification method for network protocol combinations. This method effectively and automatically verifies the three key dimensions of network protocols: information security, functional security, and cryptographic reliability. It uncovers potential security flaws in network protocol design, and the verification results are free of false counterexamples. Furthermore, it provides network protocol designers with guidance on protocol security design, ensuring pre-implementation security safeguards for protocol code implementation. Attached Figure Description

[0030] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0031] Figure 1 This is a schematic diagram of the formal verification process for network protocol combinations according to an embodiment of the present invention. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] This invention proposes a formal verification method for network protocols. This method automates verification across three key dimensions of network protocols: information security, functional security, and cryptographic reliability. It addresses the problem of false counterexamples in classical model detection through a combined formal verification algorithm. Specifically, during the network protocol design phase, the method effectively performs formal verification of the required information security, functional security, and cryptographic reliability, enabling the detection of potential security flaws in the network protocol code before implementation, and ensuring that no false counterexamples exist among these potential security flaws.

[0034] The method includes:

[0035] Step S1: Obtain the network protocol design document Doc, apply PI calculus to the network protocol design document Doc to perform formal modeling, thereby obtaining the first formal model. Perform automated verification for information security on the first formal model through the automated verifier ProVerif, and obtain the network protocol design document DocS with information security guarantee.

[0036] Step S2: Perform classic model detection and modeling on the network protocol design document DocS based on the Promela language to obtain a second formal model. Then, perform automated verification for functional safety on the second formal model through the automated verifier SPIN to obtain a set of counterexamples π, which includes real counterexamples and false counterexamples.

[0037] Step S3: Classify each counterexample in the counterexample set π, and use different verification methods to perform false counterexample screening for different categories of counterexamples to obtain a set of real counterexamples π' that only includes violations of network protocol functional security. Then, use the set of real counterexamples π' to revise the network protocol design document DocS, thereby obtaining a network protocol design document DocSS with information security and functional security guarantees.

[0038] Step S4: Apply Blanchet calculus to formally model the network protocol design document DocSS to obtain a third formal model. Then, use the automated verifier CryptoVerif to perform automated verification of the third formal model for cryptographic reliability, resulting in a network protocol design document DocSSS with information security, functional security, and cryptographic reliability guarantees.

[0039] According to the above method, in step S1, the network protocol design document Doc is formally modeled using PI calculus, including: application PI calculus modeling of the protocol channel, protocol cryptography suite, and protocol interaction process subject, as well as constructing a formal specification model for confidentiality and consistency for information security.

[0040] According to the above method, in step S1, the first formal model is automatically verified for information security by the automated verifier ProVerif, including: automatically verifying the first formal model by the automated verifier ProVerif, outputting counterexamples that violate network protocol information security, and correcting the network protocol design document Doc based on the counterexamples that violate network protocol information security, and continuously repeating the automated verification process for information security until the automated verifier ProVerif outputs no more counterexamples, thereby obtaining a network protocol design document DocS with information security protection.

[0041] Specifically, the information security verification of the network protocol involves applying PI calculus to the network protocol design document (Doc) for formal modeling. This modeling includes applying PI calculus to model the protocol channel, protocol cryptographic suite, and the main body of the protocol interaction process, as well as constructing a formal specification model for confidentiality and consistency to ensure information security. The automated verifier ProVerif automatically verifies the above formal model, outputting counterexamples that violate the network protocol's information security. Based on these counterexamples, the network protocol design document is improved, and the information security verification process in the first step is repeated until ProVerif outputs no more counterexamples, resulting in the network protocol design document (DocS) with guaranteed information security.

[0042] According to the above method, in step S2, the network protocol design document DocS is subjected to classic model detection and modeling based on the Promela language, including: constructing an interaction flow state machine model of the network protocol based on the network protocol design document DocS, and performing formal modeling of the interaction flow state machine model using the Promela language to obtain a second formal model. The second formal model includes a protocol process model, an attacker model, and a temporal model of functional security.

[0043] Specifically, the functional security verification of the network protocol involves performing classic model testing and modeling on the protocol design document DocSec obtained from the first step. First, a state machine model of the network protocol's interaction flow is constructed based on DocS. This state machine model is then formally modeled using the Promela language. This formal model includes a protocol process model, an attacker model, and a temporal model of functional security. The automated validator SPIN is then used to verify the Promela model, outputting a set π of counterexamples that violate the network protocol's functional security.

[0044] According to the above method, in step S3, each counterexample in the counterexample set π is classified, and the classification results include: counterexamples that cannot be determined whether the attacker can construct; counterexamples that the attacker can construct, which are regarded as real counterexamples; and counterexamples that the attacker cannot construct, which are regarded as false counterexamples.

[0045] According to the above method, in step S3, different verification methods are used to screen out false negatives for different categories of negatives, including:

[0046] For counterexamples that cannot be determined whether an attacker can construct, they are converted into verifications based on ProVerif confidentiality.

[0047] Based on query attacker(m), where m is the plaintext message sent by the honest participant, if the attacker can obtain the plaintext message m, then the attacker can forge the plaintext message m; to determine whether the attacker can obtain the plaintext message m, that is, whether the plaintext message m passes the confidentiality verification.

[0048] In this scenario, honest participant A sends plaintext message m to honest participant B on a private channel. The attacker cannot obtain plaintext message m from the private channel, but instead intercepts plaintext message m from the public channel between honest participant B and other participants.

[0049] According to the above method, in step S3, different verification methods are used to screen out false negatives for different categories of negatives, including:

[0050] For counterexamples that attackers can construct and those that attackers cannot construct, convert them into confidentiality and consistency verification based on ProVerif.

[0051] Based on query attacker(key), inj-event(e(key)) ==> inj-event(e(key)), where key is the key to construct plaintext message m, the confidentiality of key is verified to prevent the attacker from forging message m when the attacker obtains key;

[0052] Verify the consistency of the key to prevent attackers from impersonating honest participants and exchanging keys with other honest participants in the key exchange protocol. This also prevents attackers from impersonating honest participants and sending forged erroneous ciphertext to other honest participants, which would cause the protocol to fail to execute properly.

[0053] After verifying the confidentiality and consistency of the key, false counterexamples are filtered out from the counterexample set π to obtain the true counterexample set π'. The network protocol design document DocS is then revised using the true counterexample set π', thus obtaining the network protocol design document DocSS with information security and functional security guarantees.

[0054] Specifically, the second step involves filtering out false counterexamples regarding network protocol functional security. The functional security counterexamples π are categorized into three types: 1. Counterexamples π that cannot be determined whether an attacker could construct; 2. True counterexamples π that an attacker could construct; and 3. False counterexamples π that an attacker could not construct.

[0055] Specifically, the Type 1 counterexamples are converted into verification based on ProVerif confidentiality.

[0056] query attacker(m)

[0057] Here, message m is the plaintext information sent by an honest participant. If an attacker can obtain message m, they can forge it. Therefore, it is necessary to determine whether an attacker can obtain message m, i.e., whether message m satisfies confidentiality. Verifying the confidentiality of plaintext information is meaningful. For example, honest participant A sends plaintext message m to honest participant B on a private channel. An attacker cannot obtain message m from the private channel, but might intercept message m from the public channel between participant B and other participants.

[0058] Specifically, the second and third types of counterexamples are converted into verification based on the confidentiality and consistency of ProVerif.

[0059] query attacker(key),inj-event(e(key))==>inj-event(e(key))

[0060] Here, `key` is the key used to construct message `m`. When an attacker obtains `key`, they can forge message `m`, therefore the confidentiality of `key` needs to be verified. Furthermore, in the key exchange protocol, an attacker could impersonate a legitimate participant to complete the key exchange. This would allow the attacker to send forged, incorrect ciphertext to other legitimate participants, rendering the protocol unusable. Therefore, verifying the consistency of `key` is also necessary.

[0061] Specifically, the counterexamples π obtained in the second step are screened out as false counterexamples using the above method to obtain true counterexamples π' of network protocol functional security. The network protocol design document is improved based on the counterexamples, and the functional security verification process in the second and third steps is repeated to obtain the network protocol design document DocSS that ensures information security and functional security.

[0062] According to the above method, in step S4, the network protocol design document DocSS is formally modeled using Blanchet calculus, including: Blanchet calculus modeling of the protocol channel, protocol cryptography suite, protocol interaction process body, and specification model constructed for cryptographic reliability.

[0063] According to the above method, in step S4, the third formal model is subjected to automated verification for cryptographic reliability by the automated verifier CryptoVerif. This includes: automatically verifying the third formal model by the automated verifier CryptoVerif, outputting counterexamples that violate the cryptographic reliability of the network protocol, and correcting the network protocol design document DocSS based on the counterexamples that violate the cryptographic reliability of the network protocol. The automated verification process for cryptographic reliability is repeated until the automated verifier CryptoVerif outputs no counterexamples, thus obtaining the network protocol design document DocSS that has information security, functional security, and cryptographic reliability guarantees.

[0064] Specifically, the cryptographic reliability of the network protocol is verified. The network protocol design document DocSS obtained in step three is formally modeled using Blanchett calculus. This modeling includes Blanchett calculus modeling of the protocol channel, protocol cryptographic suite, and protocol interaction process body, as well as a reduction model constructed for cryptographic reliability. The formal model is automatically verified using the automated verifier CryptoVerif, which outputs counterexamples that violate the cryptographic reliability of the network protocol. Based on these counterexamples, the network protocol design document is improved, and the cryptographic reliability verification process in step four is repeated until CryptoVerif outputs no more counterexamples, resulting in the network protocol design document DocSSS, which guarantees information security, functional security, and cryptographic reliability.

[0065] In summary, this invention addresses the limitation of existing technologies that only verify a single security aspect of a network protocol, proposing a formal verification method for network protocol composition. The technical features and significant effects of this invention are as follows: First, it proposes a formal verification method for network protocol composition. Current methods and systems only verify a specific security aspect of a network protocol, while this invention can effectively and automatically verify the three key dimensions of network protocol security: information security, functional security, and cryptographic reliability. This allows for the discovery of potential security flaws in network protocol design, and the verification results are free of false counterexamples. It also provides network protocol designers with guidance on protocol security design, ensuring pre-implementation security safeguards for protocol code.

[0066] Please note that the technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. The above embodiments only illustrate several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be pointed out that for those skilled in the art, several modifications and improvements can be made without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A formal verification method for network protocol composition, characterized in that: The method performs effective formal verification of the information security, functional security and cryptographic reliability required by the network protocol during the network protocol design phase, so that potential security defects are detected in the network protocol code before implementation, and there are no false counterexamples among the potential security defects. The method includes: Step S1: Obtain the network protocol design document Doc, apply PI calculus to the network protocol design document Doc to perform formal modeling, thereby obtaining the first formal model. Perform automated verification for information security on the first formal model through the automated verifier ProVerif, and obtain the network protocol design document DocS with information security guarantee. Step S2: Perform classic model detection and modeling on the network protocol design document DocS based on the Promela language to obtain a second formal model. Then, perform automated verification for functional safety on the second formal model through the automated verifier SPIN to obtain a set of counterexamples π, which includes real counterexamples and false counterexamples. Step S3: Classify each counterexample in the counterexample set π, and use different verification methods to perform false counterexample screening for different categories of counterexamples to obtain a set of real counterexamples π' that only includes violations of network protocol functional security. Then, use the set of real counterexamples π' to revise the network protocol design document DocS, thereby obtaining a network protocol design document DocSS with information security and functional security guarantees. Step S4: Apply Blanchet calculus to formally model the network protocol design document DocSS to obtain a third formal model. Then, use the automated verifier CryptoVerif to perform automated verification of the third formal model for cryptographic reliability, resulting in a network protocol design document DocSSS with information security, functional security, and cryptographic reliability guarantees.

2. The formal verification method for network protocol composition according to claim 1, characterized in that, In step S1, the network protocol design document Doc is formally modeled using PI calculus, including: The application of PI calculus modeling for protocol channels, protocol cryptography suites, and protocol interaction processes, as well as the construction of formal specification models for confidentiality and consistency in order to ensure information security.

3. The formal verification method for network protocol composition according to claim 2, characterized in that, In step S1, the first formal model is subjected to automated verification for information security using the automated verifier ProVerif, including: The first formal model is automatically verified by the automated verifier ProVerif, which outputs counterexamples that violate network protocol information security. Based on these counterexamples, the network protocol design document Doc is revised. This automated verification process is repeated until the automated verifier ProVerif outputs no more counterexamples, resulting in a network protocol design document DocS with information security guarantees.

4. The formal verification method for network protocol composition according to claim 3, characterized in that, In step S2, the network protocol design document DocS is modeled using the classic model detection method based on the Promela language, including: Based on the network protocol design document DocS, an interaction flow state machine model of the network protocol is constructed. The interaction flow state machine model is formally modeled using the Promela language to obtain a second formal model, which includes a protocol process model, an attacker model, and a temporal model of functional security.

5. The formal verification method for network protocol composition according to claim 4, characterized in that, In step S3, each counterexample in the counterexample set π is classified. The classification results include: counterexamples that cannot be determined whether an attacker can construct; counterexamples that an attacker can construct, which are considered real counterexamples; and counterexamples that an attacker cannot construct, which are considered false counterexamples.

6. The formal verification method for network protocol composition according to claim 5, characterized in that, In step S3, different verification methods are used to screen out false negatives for different categories of negatives, including: For counterexamples that cannot be determined whether an attacker can construct, they are converted into verifications based on ProVerif confidentiality. Based on query attacker(m), where m is the plaintext message sent by the honest participant, if the attacker can obtain the plaintext message m, then the attacker can forge the plaintext message m; to determine whether the attacker can obtain the plaintext message m, that is, whether the plaintext message m passes the confidentiality verification. In this scenario, honest participant A sends plaintext message m to honest participant B on a private channel. The attacker cannot obtain plaintext message m from the private channel, but instead intercepts plaintext message m from the public channel between honest participant B and other participants.

7. The formal verification method for network protocol composition according to claim 6, characterized in that, In step S3, different verification methods are used to screen out false negatives for different categories of negatives, including: For counterexamples that attackers can construct and those that attackers cannot construct, convert them into confidentiality and consistency verification based on ProVerif. Based on query attacker(key), inj-event(e(key)) ==> inj-event(e(key)), where key is the key to construct plaintext message m, the confidentiality of key is verified to prevent the attacker from forging message m when the attacker obtains key; Verify the consistency of the key to prevent attackers from impersonating honest participants and exchanging keys with other honest participants in the key exchange protocol. This also prevents attackers from impersonating honest participants and sending forged erroneous ciphertext to other honest participants, which would cause the protocol to fail to execute properly. After verifying the confidentiality and consistency of the key, false counterexamples are filtered out from the counterexample set π to obtain the true counterexample set π'. The network protocol design document DocS is then revised using the true counterexample set π', thus obtaining the network protocol design document DocSS with information security and functional security guarantees.

8. The formal verification method for network protocol composition according to claim 7, characterized in that, In step S4, the network protocol design document DocSS is formally modeled using Blanchett calculus, including: Blanchet calculus modeling of protocol channels, protocol cryptography suites, protocol interaction processes, and specification models for cryptographic reliability.

9. The formal verification method for network protocol composition according to claim 8, characterized in that, In step S4, the third formal model is subjected to automated verification for cryptographic reliability using the automated verifier CryptoVerif, including: The third formal model is automatically verified by the CryptoVerif automated verifier, which outputs counterexamples that violate the cryptographic reliability of the network protocol. Based on these counterexamples, the network protocol design document DocSS is revised. The automated verification process of cryptographic reliability is repeated until the CryptoVerif automated verifier outputs no more counterexamples, resulting in a network protocol design document DocSSS that has guarantees of information security, functional security, and cryptographic reliability.

Images