Download Automating Compositional Analysis of Authentication Protocols and more Lecture notes Network Technologies and TCP/IP in PDF only on Docsity!
Automating Compositional Analysis of
Authentication Protocols
Zichao Zhang
Carnegie Mellon University
Arthur Azevedo de Amorim
Carnegie Mellon University
Limin Jia
Carnegie Mellon University
Corina S. P˘as˘areanu
Carnegie Mellon University and NASA Ames
Abstract—Modern verifiers for cryptographic protocols can analyze sophisticated designs automatically, but require the entire code of the protocol to operate. Compositional techniques, by contrast, allow us to verify each system component separately, against its own guarantees and assumptions about other com- ponents and the environment. Compositionality helps protocol design because it explains how the design can evolve and when it can run safely along other protocols and programs. For example, it might say that it is safe to add some functionality to a server without having to patch the client. Unfortunately, while compositional frameworks for protocol verification do exist, they require non-trivial human effort to identify specifications for the components of the system, thus hindering their adoption. To address these shortcomings, we investigate techniques for automated, compositional analysis of authentication protocols, using automata-learning techniques to synthesize assumptions for protocol components. We report preliminary results on the Needham-Schroeder-Lowe protocol, where our synthesized assumption was capable of lowering verification time while also allowing us to verify protocol variants compositionally.
I. INTRODUCTION
Cryptographic protocols are notoriously difficult to design, yet their correctness is crucial to ensure the security of software systems. Formal methods are thus valuable, as they can reveal critical bugs before these systems are deployed. Automated tools (ProVerif [8], CryptoVerif [9], Tamarin [33], etc.) are particularly interesting, as they allow us to focus on modeling the protocol rather than proving its correctness. Although these tools have been applied to ambitious case studies [7], [10], [34], [6], [20], they suffer from one important drawback: they offer little support for compositional reasoning. To verify a property, we must supply the entire protocol model at once, rather than verifying each component of the protocol against self-contained partial specifications. This is unsatisfactory, since a non-compositional analysis works under a closed-world assumption that provides few guarantees for when the protocol is itself a component of a larger system— for example, using a private key to sign and encrypt data si- multaneously can expose vulnerabilities that are absent if only one of the functionalities is used. Furthermore, decomposition can help speed up verification and guide protocol design when components are modified, or even perhaps removed, in case we want to de-bloat an existing protocol without breaking its security.
We envision a future where we can combine the power of compositional reasoning with the convenience of automation. As a first step in this direction, we consider how protocol analysis can benefit from off-the-shelf, automated composi- tional verification tools. To illustrate, suppose that we have a complex system M 1 || M 2 , obtained by composing simpler pieces M 1 and M 2. We would like to show that M 1 || M 2 satisfies a specification P : M 1 ||M 2 |= P. Rather than proving P directly, we can resort to the following assume-guarantee rule: 〈Q〉M 1 〈P 〉 〈true〉M 2 〈Q〉 M 1 || M 2 |= P
This rule says that we can prove P by finding an assumption Q such that (1) P holds on M 1 , assuming that Q holds on the rest of the system; and (2) the component M 2 guarantees that Q holds. Though it can be challenging to craft a suitable Q by hand, prior work [30], [16] shows that it can be inferred with L∗^ [3], an automaton learning algorithm, even for systems with multiple components. We report preliminary results on the analysis of the Needham-Schroeder protocol [29] and its subsequent correc- tion by Lowe [21] (dubbed NS and NSL, for short). We developed models of the protocols for a version of the LTSA model checker [24] extended with automaton learning [30], and used this infrastructure to synthesize assumptions to verify the protocol. Our focus is on agreement properties [35], [22], which say that when authentication is complete the participants are indeed talking to whom they think they are talking to. One obstacle for the formal analysis of security protocols is dealing with rich attacker behavior. A popular threat model is the symbolic (or Dolev-Yao [19]) paradigm, which says that the attacker has complete control over the network, but is constrained by standard cryptographic assumptions. Thus, the attacker might be able to shuffle, drop or replay messages, but cannot decrypt a message without the corresponding key. To ease the modeling of such threats, we developed Taglierino, a domain-specific language for describing protocols and attacker behavior as LTSA automata. Taglierino requires users to bound the possible attacker behaviors to ensure that its output is finite and it can be analyzed by LTSA. (Any attack can in principle be found with Taglierino if we make this bound large enough.) Though finite,
we observed that Dolev-Yao attackers produced in this way require a large number of states (>700k) to cover interesting behaviors. Synthesizing component assumptions directly using such attackers leads to bloated assumptions that are expensive to check and hard to interpret. To facilitate a compositional analysis of NSL, we carry a first decomposition step where we generate assumptions about the behavior of the attacker using alphabet refinement [30]. This decomposition shows that we can replace the attacker by a much simpler one (3 rather than 700k states). We use this refined attacker to generate assumptions for the initiator of the protocol. The assumptions are small (10–20 states), so they can be examined by decomposition and used for checking replaced components.
The rest of the document proceeds as follows. After a quick overview of the NS protocol and how it is modeled in Taglierino (Section II), we present our analysis of the protocol in Section III, explaining how we generated assumptions for the protocol initiator and used them to verify protocol variants and detect bugs. We discuss related work in Section IV and conclude in Section V.
II. AN OVERVIEW OF NS The Needham-Schroder public key protocol [29] is intended to provide mutual authentication of two agents, Alice (A) and Bob (B). The protocol can be summarized as follows:
(1) A −→ S : A, B (2) S −→ A : {B, pkB }skS (3) A −→ B : {nA, A}pkB (4) B −→ S : B, A (5) S −→ B : {A, pkA}skS (6*) B −→ A : {nA, nB }pkA (7) A −→ B : {nB }pkB
Alice starts by contacting the key server S asking for Bob’s public key pkB. The server returns this information to Alice signed with its own secret key skS , to prove that pkB is authentic. Then, Alice encrypts a fresh cryptographic nonce nA and sends it to Bob, along her own identity. Bob asks the key server for Alice’s public key pkA, and then sends nA back to Alice along another fresh nonce nB , all of this encrypted with Alice’s key. Finally, Alice acknowledges the end of the handshake to Bob by sending him nB back. (The protocol turns out to contain a vulnerability in message (6∗); we’ll come back to this shortly.) The intended specification for the protocol can be informally stated as follows:
- When Alice receives Message 6, she knows that Bob accepted her connection.
- When Bob receives Message 7, he knows that Alice has tried to contact him. To formalize this property, we model the behavior of the system as a series of finite automata running in parallel. Each automaton defines a language of traces over the following alphabet:
agent "Alice" $ do hostX <- receive begin "authAB" hostX send [alice, hostX] sig <- receive [pkX, host] <- checkSign spkS sig when (host == hostX) $ do send $ aenc pkX [na, alice] m <- receive [nx, ny] <- adec skA m if (nx == na) then send $ aenc pkX ny else fail "nonce mismatch"
Fig. 1: Implementation of Alice in NS.
- send (^) i(m): The agent i has sent the message m over the network.
- recv (^) i(m): The agent i has received the message m from the network.
- begini(e, m): The agent i claims that the event e has begun, using the data item m as an identifier.
- end (^) i(e, m): The agent i claims that the event e has ended, using the data item m as an identifier. Messages and data items are drawn from a set Term that contains an infinite supply of nonces, cryptographic keys, encrypted messages, etc. To keep the models finite, we restrict this set to a finite subset A ⊆ Term of allowed terms. Our goal is to prove agreement [35], [22]: if an event of the form end (^) i(e, m) occurs in an execution trace, than the trace has an earlier occurrence of the event beginj (e, m). For instance, Alice might emit beginA(authAB , B) at the beginning of the protocol to signal that she wishes to communicate with Bob, and Bob would emit end (^) B (authAB , B) after receiving {nB }pk (^) B to indicate that the connection was successful. Each protocol participant corresponds to a finite automaton. These automata are specified in Taglierino using a domain- specific language similar to process calculi used in pro- tocol verification [8], [1]. Figure 1 shows the model of Alice in Taglierino. A preamble, not shown in the figure, declares constants such as the nonce na, Alice’s identity alice, Alice’s private key skA, and Server’s public signa- ture key spkS. Alice communicates with the network using send and receive. The first received message (hostX <- receive) means that Alice is willing to run the protocol with any other agent chosen by the network. Upon sending or receiving from the network, Alice can manipulate mes- sages using cryptographic primitives; for example, aenc and adec stand for asymmetric encryption and decryption and checkSign is for checking the signature. The protocol implementation in Taglierino is compiled down to models for the LTSA model checker [24]. In ad- dition to the honest agents, our compiler generates another automaton that describes how messages are transmitted in
Attacker Alice send (^) i({nA, nB , M }pkA) send (^) A({nA, nB , M }pkA) send (^) i({nA, nB , B}pkM ) send (^) A({nA, nB , B}pkM ) send (^) i({nA, nB , M }pkM ) send (^) A({nA, nB , M }pkM ) send (^) i({nB , nB , B}pkM ) send (^) A({nB , nB , B}pkM ) send (^) i({nB , nB , M }pkM ) send (^) A({nB , nB , M }pkM ) send (^) i({nM , nB , B}pkM ) send (^) A({nM , nB , B}pkM ) send (^) i({nM , nB , M }pkM ) send (^) A({nM , nB , M }pkM ) send (^) i({nB }pkB ) send (^) A({nB }pkB ) send (^) i({nB }pkM ) send (^) A({nB }pkM ) send (^) i({B, pkB }skS ) send (^) A({B, pkB }skS )
recv (^) i({nA, nB , M }pkA) recv (^) A({nA, nB , M }pkA) recv (^) i({nA, nB , B}pkM ) recv (^) A({nA, nB , B}pkM ) recv (^) i({nA, nB , M }pkM ) recv (^) A({nA, nB , M }pkM ) recv (^) i({nB , nB , B}pkM ) recv (^) A({nB , nB , B}pkM ) recv (^) i({nB , nB , M }pkM ) recv (^) A({nB , nB , M }pkM ) recv (^) i({nM , nB , B}pkM ) recv (^) A({nM , nB , B}pkM ) recv (^) i({nM , nB , M }pkM ) recv (^) A({nM , nB , M }pkM ) recv (^) i({nB }pkB ) recv (^) A({nB }pkB ) recv (^) i({nB }pkM ) recv (^) A({nB }pkM ) recv (^) i({B, pkB }skS ) recv (^) A({B, pkB }skS )
beginA(authAB , B) beginA(authAB , M )
Fig. 4: Alphabets of generated assumptions. The identifier i ranges over A and B.
available to the attacker, while keeping all other private keys secret. We also bounded the attacker to learn at most 4 messages in addition to its initial knowledge.
When compiled, our model had a large attacker of more than 700k states. To obtain a more tractable model, we decomposed the system to generate an assumption for the attacker (i.e. let- ting M 1 = Alice || Bob || Server and M 2 = Attacker in rule (1)). To facilitate learning, we used alphabet refinement [30], a technique that generates more compact assumptions by limit- ing the possible interactions between components. Roughly speaking, alphabet refinement consists in gradually adding actions to the interface of M 1 and M 2 until we successfully generate a sound assumption for the attacker or manage to prove that the property did not hold. (Figure 2 describes this process in more detail.)
After refinement, we further decomposed the system using the assumption on the attacker to generate an assumption for Alice. Figure 3 shows the size of the original components with their generated assumption; Figure 4 shows the alphabets. The fact that we were able to generate an assumption for Alice means that the NSL protocol satisfies agreement. We will now see how this generated assumption facilitates the analysis of protocol variants.
B. Finding Lowe’s Flaw in NS We modified Alice in NSL such that the agent identity in message (6) is not checked. The behavior of the modified pro- tocol is equivalent to the original NS and allows Alice, while thinking she is contacting Mallory, to accept the message:
(6) B −→ A : {nA, nB , B}pkA
and continue with:
(7) A −→ M : {nB }pkM
This behavior enables Lowe’s attack on NS, which we redis- covered by checking the modified Alice against the assumption generated in the previous section. In principle, it is possible this method yields a spurious counterexample. The automaton learning technique generates the weakest assumption for Alice to validate agreement, but the assumption was computed using an abstraction that has more behaviors than the original attacker, and thus imposes more restrictions on Alice than would be necessary. To rule out the possibility that our counterexample is spurious, we double- check that it can be produced by this variant of NSL. Even when combined with the time to recheck the counterexample, the time spent to find this bug compositionally was much smaller than the time spent on monolithic bug finding, thus strengthening the case for compositional verification.
C. Serverless NSL A common simplification of NSL is to assume that Alice knows the keys of the agents she wants to contact from the start. This amounts to removing the communication between Alice and Server (messages (1) and (2)). We were capable of verifying this version of Alice against our previously generated assumption, thus confirming that this serverless variant of NSL is correct.
D. Interpreting the Assumptions Figure 3 shows that assumption learning with alphabet re- finement was capable of significantly abstracting the behavior of the attacker and of Alice, yielding automata that are much smaller in terms of number of states and number of transitions. The alphabets of the assumptions (Figure 4) list the actions that must be controlled for the property to hold; removing them from the alphabet has the effect of allowing the attacker to freely perform those actions, regardless of whether a send action was triggered by an honest agent or of whether the attacker had enough knowledge to deliver a message. The only difference between the alphabet for Alice and for the Attacker is that the Attacker alphabet includes actions for Bob, whereas Alice’s includes her begin events. Most of the controlled actions are variants of (6) encrypted with pk (^) M. If the attacker is free to forge such messages indiscriminately, he is capable of learning the nonce nB even before Bob is contacted by Alice or Mallory. When this is true, the attacker
Protocol Attack Compile time(ms) #States Attacker (^) #StatesMonolithic verification #Transitions Time(ms)^ #StatesCompositional verification #Transitions Time(ms) NSL public key [21] No 2851 775030 388 2738 8 18 163 1 * NS public key [29] Yes [21] 2674 775030 10880 102449 97 19 (3104) 164 (22979) 1 (22) ** NSL public key (variant) No 2182 775030 9792 86094 115 13 99 1
Fig. 5: Experimental results (cf. Section III-E)
has all the information needed to impersonate Alice and break agreement. (Note that we didn’t include nB in the allowed set of messages, so it is not possible for the attacker to learn this value directly.) Interestingly, the expected message (6) in a normal run of the protocol, {nA, nB , B}pk (^) A, is not in the alphabet. Intuitively, since the attacker does not control pk (^) A, the only thing he can do with this message is relaying it to Alice. If Alice meant to talk to Bob anyway, she will eventually trigger begin and send her response (7) to Bob, which does not pose any harm for agreement. Otherwise, if she meant to talk to Mallory, receiving this message will trigger a mismatch between Bob’s identity and Mallory’s; thus, she’ll stop running and never send (7) to Bob.
E. Results
Figure 5 summarizes the results of verifying the three variants of NSL above. Each row describes:
- whether the variant is vulnerable to an attack;
- how long it took to compile the various automata pro- duced by Taglierino;
- the number of states in the attacker component;
- results for monolithic verification: the number of states and transitions of the compiled automata, as well as the time spent to verify them;
- results for compositional verification: the number of states and transitions of the compiled automata used to check that Alice satisfies the generated assumption, as well as the time to perform this check. Note that the results of compositional verification for the first row () are somewhat redundant, since the system is automatically verified as a byproduct of generating the as- sumptions. We included those numbers for completeness. In each column under the results of compositional verification for the second row (*), the first number refers to the pro- cess of generating the counterexample, whereas the second number refers to the process of rechecking it, as explained in Section III-B. In all cases, we observe that compositional verification requires substantially fewer resources than mono- lithic verification. However, these numbers do not include the time spent to generate Alice’s assumption, which amounts to approximately 5 minutes, implying that the benefits of compositional verification mostly apply when we expect to reuse the generated assumptions for several protocol variants.
IV. RELATED WORK Compositional verification and assume-guarantee reason- ing [27], [32], [25], [26], [28] have been studied extensively, as a way to address the state-space explosion problem in
model checking [15]. Progress has been made in automat- ing compositional reasoning using learning and abstraction- refinement techniques for iterative building of the necessary assumptions [17], [31], [11]. Other learning-based approaches for automating assumption generation have been proposed as well, e.g. [12], [2], [13], [14], with many other research works to follow. All this work was done in the context of applying automated compositional verification to general-purpose software. While there have been many model checkers that target security protocols, for example [4] surveys a number of them and [23], [5] have been applied to Needham-Schroeder protocol, they all verify the entire protocol at once. In fact, there is relatively little research on compositional analysis of security protocols, which pose special challenges due to the com- plexity introduced by the attacker model. Among the most prominent works in this direction is Protocol Compositional Logic (PCL) [18], a logic and system for proving security properties of network protocols. PCL supports compositional reasoning about complex security protocols and has been applied to a number of industry standards including SSL/TLS, IEEE 802.11 i and Kerberos V5. Despite its success, PCL is limited by the large amount of manual effort that is involved in performing the proofs. Other tools can use the help of humans to guide the proving effort with intermediate lem- mas; examples include the Tamarin [33] and the CryptoVerif provers [9]; however, this functionality still requires the entire protocol code. It would be interesting to investigate how to integrate the properties discovered by our framework in such tools. Tamarin is a natural first candidate for experiments in this area, since it works under the symbolic model, just like Taglierion. CryptoVerif, by contrast, is used for proofs in the computational model of cryptography, which would represent a significant depart from our setting.
V. CONCLUSION AND FUTURE WORK We have carried out a first experiment towards automating the compositional verification of protocols, using the NS and NSL protocols as a case study. Our results show that synthesized assumptions can be used to verify variants of the original protocol and yield faster checks. We see several promising directions for future work. Besides trying out more case studies, we would like to improve the performance of our assumption generation, which right now takes a few minutes to complete (≈ 5 ). It would also be interesting to use the generated assumptions to guide the design and simplification of other protocols, or to incorporate those in manual proofs of correctness.
[34] Whitefield, J., Chen, L., Sasse, R., Schneider, S., Treharne, H., Wese- meyer, S.: A symbolic analysis of ecc-based direct anonymous at- testation. In: IEEE European Symposium on Security and Privacy, EuroS&P 2019, Stockholm, Sweden, June 17-19, 2019. pp. 127–
- IEEE (2019). https://doi.org/10.1109/EuroSP.2019.00019, https:// doi.org/10.1109/EuroSP.2019. [35] Woo, T.Y., Lam, S.S.: A semantic model for authentication protocols. In: Proceedings 1993 IEEE Computer Society Symposium on Research in Security and Privacy. pp. 178–194. IEEE (1993)
