Model Checking a Security Protocol by monkey6


More Info
									Model Checking a Security Protocol
Cornelia P. Inggs Telkom SA, Private Bag X74, Pretoria, 0001, South Africa Tel: +27 12 311 1609, Fax: +27 12 311 4335 Email: Howard Barringer, Aleksandra Nenadic, and Ning Zhang Dept. of Computer Science, Univ. of Manchester, Kilburn Building, Oxford Road, M13 9PL, UK Tel: +44 161 275 6154, Fax: +44 161 275 6204

Abstract—As communication systems become more complex and configurable, and the Internet becomes more popular with an increasing number of online transactions performed daily, it is more important than ever to validate the software that these systems rely on. Model checking is a technique that has been adopted by industry to check correctness properties of such systems. The main challenge in model checking is dealing with the state explosion problem. To alleviate the state explosion problem, we developed a parallel model checker that can make effective use of large multiprocessor computers with significantly more memory and computing power than conventional personal computers. In this article we report on the use of this model checker to analyse a security protocol that was developed to facilitate secure and fair exchange of digital signatures for the purpose of online contract signing in e-commerce. I. INTRODUCTION As communication systems become more complex and configurable they are relying more heavily on software. It is therefore increasingly important to validate the software these systems depend on. Furthermore, with the growth in popularity of the Internet, many transactions that require a high level of security and were previously performed in person are now performed online. For example, one of the major activities in e -commerce is the exchange of valuable electronic data between parties, and adequate security measures must be in place to ensure that such an exchange process is fair. An exchange is fair if either both parties receive their expected items or neither party receives anything that can be used to obtain the item of the other party without releasing its own. A formal technique that has become increasingly attractive for the verification of critical systems, such as these, is model checking [1]. Model checkers establish the correctness of a given property by checking all the possible behaviours of a system. Model checking is very effective in finding subtle bugs and works especially well for concurrent systems, which are also the most difficult to debug using traditional test methods. One of the main advantages of model checking is that it is automatic. The user provides a specification of the system and a correctness property, and the model checker returns

yes or no, depending on whether the property is satisfied or violated. When a property is violated, the model checker produces a counter example that can be studied to find the exact sequence of events that violate the property. The main challenge in model checking is dealing with the state explosion problem. The problem occurs, for example, in systems with many interacting components that can execute concurrently. Since there are typically many possible interleavings of the behaviours of each component, the number of global states in such a system can be very high. Because of the state explosion problem, two decades ago model checking could hardly be used for any system of realistic size or complexity. Over the past twenty years, tremendous advances have been made in developing specialised state encodings and algorithms to reduce the burden of the state explosion problem for serial computation. The memory that is required to model check a system is now much smaller than was the case for the same system before. Today, model checking is an established technology that has been taken up by industry to check correctness properties of many critical systems. For example, in 2000 researchers at Lucent Bell Labs checked the complete call processing code at implementation level for a commercial telephone switch [6]. Even so, the size and complexity of systems that can be verified in real-time is still constrained by time and memory and the development of techniques to alleviate the state explosion problem remains an active area of research. One technique that has gained interest recently is the parallelisation of model checking. We have developed a parallel model checker, PMC, for shared-memory multiprocessors such as the 512–processor SGI Origin 3800 at the University of Manchester [8]. As part of our work with the security team of the Mobile Systems Architecture (MSA) Group at the University of Manchester, a low overhead security protocol for the fair exchange of digital signatures has been developed [14]. The protocol uses a cryptographic primitive for the verification and offline recovery of an encrypted signature called Verifiable and Recoverable Encryption of a Signature (VRES). The recipient of the VRES can verify the correctness of the encrypted signature without obtaining the actual signature and, at the same time, is assured that an off-line SemiTrusted Third Party (STTP) can help to decrypt the signature from the VRES, should the VRES sender refuse to do so later

on. In this way, it is secure for the VRES receiver to release his signature first, as he is guaranteed the reception of the sender’s signature afterwards – either from the sender or though the STTP. Thus, the protocol achieves fairness for all the parties involved. In this article we show how the protocol was validated using the parallel model checker PMC and discuss the applicability of model checking to the verification of security protocols. The paper is organized as follows. The next section contains a brief introduction to model checking and provides an overview of the parallel model checker PMC. This is followed by a description of the security protocol for fair exchange of digital signatures. The final section discusses the formal verification of the protocol using PMC.


typically specified using temporal logic, which is an excellent family of logics for expressing ordering properties of complex systems without explicit reference to time variables or time constants. Two well-known classes of temporal logics are branching time temporal logic, of which CTL (Computation Tree Logic) is an example, and linear time temporal logic, of which L (Linear Time Logic) is an example [11][13]. In TL linear time temporal logics the underlying model of time is linear: at each moment in time there is only one possible future moment. Linear time temporal logics therefore have temporal modalities to describe properties over a single execution path of a system. In branching time temporal logics the underlying model of time is a branching (tree) structure: at each moment in time there may be several possible future moments. Branching time temporal logics therefore have temporal modalities to describe properties that must hold over all or some of the paths from a specific state. The functionality of specifying the order in which events are allowed to appear on a path (sequence of states) is provided by modalities called temporal operators. Path quantifiers, on the other hand, are used to identify if a property should hold for all paths or some path from the current state and atomic propositions connected or preceded by Boolean operators are used to describe properties about states. For example, in the branching time temporal logic formula AGp, p is a proposition that will evaluate to either true or false at a particular state, G (globally) is a temporal operator which states that the property it applies to (p in this case) should hold at each state along the path, and A (for all) is a path quantifier which states that the property it applies to (Gp in this case) should hold for all paths from the current state. The properties that are expressible in temporal logic can be divided into two main categories, namely: safety properties and liveness properties. A safety property states that something bad will never happen, while a liveness property states that something good will eventually happen. Temporal logic formulas that represent properties of concurrent systems are interpreted over Kripke structures. Some properties, in particular all safety properties, can be evaluated over a Kripke structure by exe cuting a pure reachability analysis and simply checking the truth value of the property at each state. To evaluate liveness properties, on the other hand, the model checker must keep track of the states it visits and the order in which they were visited; this is for example needed to check the property that a system must receive an acknowledgement for each message that it sends. PMC currently takes as input designs specified in the high-level formalism ESML and properties specified in the branching time temporal logic CTL*.

A. Model Checking To verify that a system satisfies a set of requirements, a model checker must be provided with a formal specification of the system to be verified and a formal specification of each required property of that system. Given the specification of a system and the specification of a property, the model checker then establishes whether the system satisfies the property and returns a yes or no answer. B. Specifying System Behaviour The behaviours of systems are typically represented as labelled state-transition systems or Kripke structures [7]. A Kripke structure captures the basic concepts of the state of a system and the actions (transitions) that modify the state. Formally, a Kripke structure is a 5-tuple K = {S, s0, R, P, L}, where S is a set of states, s0 ∈ S is an initial state, P is a set of atomic propositions, L: S → 2P maps each state to the set of atomic propositions true in that state, and R ⊆ S × S is a transition relation that must be total, i.e., for every si ∈ S there exists an sj, such that (si, sj) ∈ R. To specify the behaviour of a large and complex system directly as a Kripke structure is, however, impractical and error-prone. Systems are therefore more often specified using a high-level formalism such as Promela [5], SMV [12], ESML [4], or Rainbow [2]. These formalisms provide the functionality to specify the variables of a system (such as communication channels), the actions of e ach component (such as data manipulations), and each component’s interactions with the other components in the system (such as sending and receiving messages). From these formalisms the corresponding Kripke structure can be constructed automatically, and even on-the-fly during the model checking process. C. Specifying Correctness Properties The system requirements or correctness properties are

D. Automata-theoretic Model Checking Several techniques have been developed to check that a design specification satisfies a given property. PMC follows an automata-theoretic approach. Automata-theoretic model checking is based on the principles (a) that an automaton Aϕ can be build such that L(Aϕ) (the language of Aϕ) is the set of computations that satisfy the temporal logic formula ϕ, and (b) a Kripke structure K can be viewed as an automaton, A K. The model checking problem can thus be defined as a language containment problem L(AK) ⊆ L(Aϕ), which can be rewritten as a nonemptiness problem L(AK) × L(¬Aϕ).
z,q0 x,q0

∧ ∧
y,q0 m,q0 n,q0 z,q1 y,q1 z,q1




In PMC, the kind of automata that are associated with CTL* formulas are called Hesitant Alternating Automata (HAA) [3]. The CTL* formula to be checked is therefore first translated into a Hesitant Alternating Automaton and then combined with the Kripke structure that represents the model to be checked; the resultant automaton is then checked for nonemptiness. As an example, Figure 1 depicts a small Kripke structure where each state is labelled with the propositions that are true at that state, Figure 2 depicts the Hesitant Alternating Automaton for the CTL* formula AGEFp, and Figure 3 depicts a subset of the product automaton of this HAA and Kripke structure.

Figure 3. A subset of the product automaton of the Kripke structure in Figure 1 and the HAA in Figure 2 E. PMC In PMC, the nonemptiness game is played in parallel over a number of processes where each process computes the result of a part of the and–or tree and the states that have not been vis ited are dynamically distributed across the processes. The structure of PMC is shown in Figure 4. The model checker has four main units: the program logic, the alternating automaton, the state generator, the stacks, and the storage. The line style of a unit indicates whether the unit is shared or private. The dashed line units are private and duplicated across the processes so that each process has its own copy. The solid line units are shared by all the processes, and there is only one copy of each of these. The main program logic unit is the controlling unit of the model checker. The serial (solid line) parts of the unit execute the startup and cleanup code that is executed before and after the parallel model checking algorithm executes, the parallel (dashed line) part of the unit drives the global nonemptiness game and each process participating in the model checking executes the nonemptiness game algorithm. The state generator unit contains the system specification and responds to requests for successor states of a given parent state. The alternating automaton unit keeps the alternating automaton and responds to requests for expanding an alternating automaton state. Given the current alternating automaton state and the truth values of the properties at the corresponding Kripke state, the next alternating automaton state is returned. The storage unit controls the storage of all the visited states to allow the detection of visited states and the detection of potential cycles. The stacks unit contains the shared and private stacks. These stacks are used for load balancing purposes. In model checking the work can’t be divided into large independent tasks; the tasks are small with a high synchronisation overhead. The novel technique

¬p x m ¬p y n z ¬p ¬p p

Figure 1. A Small Kripke structure

δ (q, {¬p}, l) q0 q0

δ (q, {p}, l)

∨(c, q ) ∧ ∧ (c, q )
1 0

∧(c, q )

∨(c, q )


Figure 2. The HAA for AGEFp; in each case c ranges from 0 to l − 1. The product automaton represented in Figure 3 is called an and–or tree and the algorithm that establishes the nonemptiness of this product automaton is formulated in terms of a game, called the nonemptiness game, where one player wins if the automaton is empty while the other player wins if the automaton is nonempty [15].

developed for efficient load balancing under these conditions is described in [8][10]. The modularised structure of the model checker allows for experimentation with different state generators and stack designs as long as these implementations implements the correct interfaces. A more detailed diagram and explanation of the algorithms are given in [10].

exchange sub-protocol executed between Pa and Pb, and the recovery sub-protocol invoked by Pa to seek the help of Pt for the recovery of Pb’s encrypted signature. The flows of the sub-protocols are depicted in Figures 5 and 6 respectively. (E1): Pa ? Pb: xa, ya (E2): Pb ? Pa: xb, xxb, yb, sb, Cbt (E3): Pa ? Pb: ra (E4): Pb ? Pa: rb Figure 5. The exchange sub-protocol Party Pa initiates the exchange sub-protocol by producing a verifiable encryption of his signature on C, denoted by (ya, xa) and transferring it to Pb in step (E1). Pb verifies the correctness of this encrypted signature (but cannot obtain the signature itself at this point). If the verification is successful, Pb produces a verifiable and recoverable encryption of his signature on C (VRES), denoted by (yb, xb, xxb), and a recovery authorization token (RAT), denoted by sb, and sends them to Pa together with his public-key certificate Cbt in step (E2). If both the VRES and RAT pass verification performed by Pa, Pa is assured that the VRES contains Pb’s correct signature, which can be recovered (i.e. decrypted) by Pt should it be necessary, and RAT contains the correct authorization for this recovery. Pa can then release his random number ra to Pb in step (E3), which can be used by Pb to decrypt Pa’s signature from xa received in step (E1). Pb in turn sends his random number rb to Pa so that Pa can decrypt Pb’s signature from xb received in step (E2). If for some reason Pa does not receive rb, (e.g. Pb does not sent the message (E4) or the message is lost), Pa initiates the recovery sub-protocol with Pt. (R1): Pa ? Pt: ra, yb, ya, sb, Cbt (R2): Pt ? Pa: rb (R3): Pt ? Pb: ra Figure 6. The recovery sub-protocol Pa sends ra, ya, yb, sb, and Cbt to Pt to ask for the recovery of Pb’s signature. Pt checks the correctness of RAT sb to ensure Pa is authorised for this recovery and the correctness of Pa’s random number ra. If both are correct Pt recovers Pb’s random number rb and sends it to Pa in step (R2), and Pt also forwards ra to Pb in step (R3), so that each party can compute the signature of the other party. It is assumed that the channels between Pt and the other parties are resilient, but any of the other messages sent may be lost. If a message (E4) is lost the recovery sub-protocol is initiated as described above. If messages are lost at any other time, the parties may choose to terminate the protocol execution, because at that point either both parties have received the signature of the other party or neither of the parties has received the signature of the other party nor anything useful.

Interface Shared & Private Stacks Shared Storage

Startup Main Program Logic

Interface State Generator


Alternating Automaton

Figure 4. The structure of the parallel model checker PMC F. PMC Performance The performance of PMC was evaluated through both a theoretical analysis of the algorithm and practical experiments on a variety of different models written in ESML and for different types of correctness properties. The performance evaluation showed the practicality and effective speedup of PMC and thus demonstrated that model checking can be efficiently implemented on shared-memory architectures. The speedups of the PMC model checker are good and the dynamic load balancing algorithm that have been developed for PMC works efficiently; there is practically no idle time due to unbalanced load. Performance graphs and more detail about the analysis of the results can be found in [9][10].

III. THE SECURITY PROTOCOL As an example of the use of this model checker, the security protocol developed by Nenadic et al. [14] was model checked. The protocol was developed to ensure the fair exchange of digital signatures and is applicable in ecommerce activities such as contract signing. An exchange of digital signatures is fair if either both parties receive the expected digital signature or neither party receives anything that can be used to obtain the digital signature of the other party. The protocol is designed to execute between two parties, Pa and Pb, which have agreed on a document C and plan to sign it over the Internet by exchanging their RSA digital signatures on C. The protocol requires the assistance of an off-line Semi-Trusted Third Party (STTP), Pt, which is involved in the protocol execution only in cases when a dispute arises and parties Pa and Pb cannot come to a successful completion of the exchange themselves. The protocol consists of two sub-protocols – the normal

IV. M ODEL CHECKING THE SECURITY PROTOCOL The aim of the verification is to establish that the protocol indeed ensures the fair exchange of signatures, i.e. that either both parties receive the s ignature of the other party or neither party receives the signature of the other party even when (a) the parties misbehave in an attempt to gain the signature of the other party without releasing its own signature, or (b) any of messages send between Pa and Pb are lost. The protocol was modeled in ESML by specifying the actions of each party and the interactions of each party with the other parties. The specification included message loss and misbehaving parties that try to gain the signature of the other party without revealing their own signatures. The fairness of the exchange process can be specified either as a safety or a liveness property. To specify a fair exchange as a liveness property, two propositions are needed: p 0: Pa knows the signature of Pb and p 1: Pb knows the signature of Pa. The property is then specified with CTL* formula AG(p 0 ⇒ AFp 1), which in words is: Always Globally p 0 implies Always Finally p 1. This property states that if, at any point during the exchange process, the protocol reaches a state where p 0 is true, it will always eventually reach a state where p 1 is true. Similarly the property AG(p 1 ⇒ AFp 0) can be specified to complete the fairness check. Both properties can also be combined with an and (∧) to check the fairness property in one run. To specify a fair exchange as a safety property, four propositions are needed: p 0: Pa knows the signature of Pb, p 1: Pb knows the signature of Pa, p 2: Pa has terminated (it therefore either has the signature of Pb or the protocol was terminated before the exchange could finish), p 3: Pb has terminated (it therefore either has the signature of Pa or the protocol was terminated before the exchange could finish). The property is then specified with CTL* formula AG ¬(p 2 ∧ p 3 ∧ ((p 0 ∧ ¬p 1) ∨ (¬p 0 ∧ p 1))). The protocol was also checked for deadlock, which is a state where none of the parties can continue with the next action, for example, if all the parties are waiting for messages before they send any more messages. All these properties were satisfied, but it was also found that party Pa can request a recovery from Pt before sending ra. However, when it requests a recovery from Pt, it has to send the correct ra to Pt and Pt will then forward ra to Pb in step (R3). If Pa attempts to cheat by sending the wrong ra, Pt’s correction check of ra will fail and it will reject Pa’s recovery request. It was also clear that the model checking of security protocols differ from the model checking of communication protocols or other systems that are typically model checked. First, security related properties often require explicit modelling of the behaviour of parties that do not form part of

the protocol. For example, in this protocol xa is encrypted before it is sent (although this was not shown in Figure 5 for the sake of simplicity), so that if a party other than Pt or Pb intercepts both xa and the message (E3) with ra it still cannot compute Pa’s signature. To check that other parties cannot intercept enough useful information to obtain Pa or Pb’s signature, the model must include other parties that intercept messages and use different variables to distinguish encrypted messages from unencrypted messages. This differs from the typical use of model checking where the specification of the system to be model checked includes all the processes involved in the interactions of the system. Second, security protocols tend to be very small compared to communication protocols such as TCP/IP, SIP, etc. The memory requirements for mo del checking security protocols is therefore low, and the time needed to complete the verification is short. Where the model checking of large and complex system can take hours or days, the model checking of this security protocol, which has only 13 thousand states, completes in a few seconds. Even though the model checker achieved a speedup for this small protocol, the model checker establishes correctness of the properties so fast that 1 processor is adequate.

V. CONCLUSION In this article we showed how the parallel model checker PMC was used to verify correctness properties of a security protocol for the online exchange of digital signatures. The appropriateness and shortcomings of using model checking to validate the correctness of a security protocol can be summarized as follows. First, the verification process confirmed the fact that the model checking of a protocol increases the understanding of the protocol, because the specification had to be fixed several times before all the properties were satisfied. Second, not all the correctness properties of a security protocol can be checked by modeling the behaviour of only the protocol, such as the interception of messages by other parties or the effectiveness of an encryption technique on which the protocol depends. Third, in model checking terms a model with 13 thousand unique states is small, but to manually check through 13 thousand states will be a long an error-prone process. It is rarely possible to test all the possible behaviours of a system manually; model checking does this automatically. This is the main benefit of using a model checker to verify security protocols, because they can branch and have several different courses of execution, such as the protocol described in this paper. Model checking a security effective, but the designer correctness criteria that cannot modeling and clearly state the made. protocol is therefore very should be aware of the be checked without explicit assumptions that have been

REFERENCES [1] E. M. Clarke, O. Grumberg and D. A. Peled, Model Checking, MIT Press, 1999. [2] H. Barringer, D. Fellows, G. Gough, and A. Williams, “Rainbow: Development, Simulation and analysis tools for asynchronous micropipeline hardware design,” The Computer Journal, vol. 45, no. 1, 2002. [3] O. Bernholtz, “Model checking for branching time temporal logics,” The Technion, Haifa, 1995. [4] P. J. A. de Villiers and W. Visser, “ESML—A validation language for concurrent systems,” Proceedings of the 7th Southern African Computer Symposium, pp. 59–64, 1992. [5] G. J. Holzmann, The SPIN Model Checker: Primer and Reference Manual, Addison–Wesley, 2003. [6] G. J. Holzmann and M. H. Smith, “Automating software feature verification,” Bell Labs Technical Journal, vol. 5, no. 2, pp. 72–87, 2000. [7] G. E. Hughes and M. J. Cresswell, Introduction to Modal Logic, 2nd ed., Methuen & Co. Ltd, London, 1974. [8] C. P. Inggs and H. Barringer, “Effective state exploration for model checking on a shared memory architecture,” Workshop on Parallel and Distributed Model Checking, Electronic Notes in Theoretical Computer Science (ENTCS), vol. 68, no. 4, Czech Republic, 2002. [9] C. P. Inggs and H. Barringer, “CTL* Model Checking on a Shared-Memory Architecture”, 3rd International Workshop on Parallel and Distributed Methods in verifiCation, To appear in a volume of Electronic Notes in Theoretical Computer Science (ENTCS), London, England, 2004. [10] C. P. Inggs, “Parallel model checking on shared-memory multiprocessors,” Ph.D. dissertation, Dept. Comp. Sci., Manchester Univ., England, 2004. [11] L. Lamport, “Sometime is sometimes not never—On the temporal logic of programs,” Proceedings of the 7th ACM Symposium on Principles of Programming Languages, pp. 174–185, 1980. [12] K. L. McMillan, Symbolic Model Checking: An Approach to the State Explosion Problem, Kluwer Academic Publishers, 1993. [13] Z. Manna and A. Pnueli, The Temporal Logic of Reactive and Concurrent Systems, Springer–Verlag, 1992. [14] A. Nenadic, N. Zhang, and S. Barton, “A protocol enabling efficient verifiable and recoverable encryption and fair exchange of RSA-based signatures,” submitted for publication. [15] W. Visser and H. Barringer, “Practical CTL* model checking, Should SPIN be extended?,” Software Tools for Technology Transfer, vol. 2, no. 4, Springer–Verlag, pp. 350–365, 2000.
Cornelia P. Inggs recently received the Ph.D. in Computer Science from the University of Manchester, England. She is currently employed by Telkom SA in the Technology Strategy and Integration division at their corporate offices in Pretoria. Howard Barringer is Professor of Computer Science at the University of Manchester where he leads the Formal Methods research group. His current research activities include executable

temporal and modal logics and the development of application specific formal methods for digital systems design. Aleksandra Nenadic is reading for her Ph.D. at the University of Manchester where she is also working as a Research Associate in the Mobile Systems Architecture Group at the Department of Computer Science. Ning Zhang received the Ph.D. in Computer Science from the University of Kent and is currently a lecturer at the Department of Computer Science, University of Manchester. Her research interests include the design of security solutions for networked and e-commerce applications.

To top