Model Checking Safety Properties of Infinite-State Systems using Maude LTL Model Checker -, Study notes of Computer Science

Download Model Checking Safety Properties of Infinite-State Systems using Maude LTL Model Checker - and more Study notes Computer Science in PDF only on Docsity! Program Verification: Lecture 25 José Meseguer Computer Science Department University of Illinois at Urbana-Champaign 1 Model Checking Safety Properties of Infinite-State Systems As usual for model checkers, the Maude LTL model checker relies quite essentially on the assumption that the set of states reachable from an initial state is finite. Yet, many concurrent systems of interest fail to have this property. For example, just adding some simple fault-tolerant features to a simple asynchronous communication protocol can easily bring us into an infinity of reachable states. Likewise, cypto protocols with powerful enough intruder models easily have infinite sets of reachable states. What can we do in such cases? Is some kind of model checking still applicable? 2 Infinite-State Model Checking in Practice (II) • we can effectively determine that the set of states satisfying P is finite, and we can enumerate those states, say, {init1, . . . , initn} • Q can be assumed to be an arbitrary Boolean combination of unparameterized state predicates p1, . . . , pm, each of which is defined by the general method already explained, that is, by extending R with equations, ceq pi(exp1) = true if C1 . ... ceq pi(expk) = true if Ck . 5 Infinite-State Model Checking in Practice (III) By De Morgan’s laws the negation ¬Q is also a Boolean combination of the form ¬Q(S) = bexp(p1(S), . . . , pm(S)), which we can assume in negative normal form. In Maude we can express each basic predicate appearing in negated form in the negative normal form Boolean expression ¬Q(S) = bexp(p1(S), . . . , pm(S)), say ¬pj(S), by pj(S)=/= true. 6 Infinite-State Model Checking in Practice (IV) Under the above assumptions about R, P , and Q, our desired semidecision procedure for the failure of the safety property P → 2Q can be implemented in Maude by running in parallel, or in a fair scheduling of n processes, the n (breadth-first) search commands, 1 ≤ j ≤ n, search [1] initj =>* S s.t. bexp(p1(S), . . . , pm(S)) . Of course, this is not the only method of reasoning about infinite-state systems. Two other alternative methods are: (1) deductive proof; and (2) model checking an abstraction, that is, associating to R a more abstract version A whose sets of reachable states are finite and such that TReach(A) |=LTL ϕ ⇒ TReach(R) |=LTL ϕ. 7 A Cryptographic Protocol Example (III) Here is a textbook-style simplified description of NSPK: Message 1 A→ B : A.B.{Na, A}PK(B) Message 2 B → A : B.A.{Na.Nb}PK(A) Message 3 A→ B : A.B.{Nb}PK(B) This level of description is ambiguous, in that a fair amount of implicit assumptions are left unspecified. An object-oriented rewriting logic specification of the protocol (developed in joint work with G. Denker and C. Talcott) makes these assumptions explicit, and allows model checking. 10 Maude Specification of NSPK We first specify key algebraic properties of the cryptographic infrastructure in a functional module. fmod DATATYPES is sorts Key Field Nonce Principal Run Role EstabComm . subsort Nonce Principal Key < Field . op keypair : Key Key -> Bool [comm] . op ped : Key Field -> Field . *** encryption function op n : Principal Nat -> Nonce . ceq ped(sk,ped(pk,f)) = f if keypair(sk,pk) . ... endfm The protocol itself, as well as the actions of an attacker, are specified as follows (fragment): 11 Maude Specification of NSPK (II) class Agent | e com: EstabCom, sec key: Key, role i: Run, role r: Run, d com: FieldSet cnt: Nat . msg from to send : Principal Principal Field -> Message . vars A B P : Principal . vars RI RR : Run . vars NI : Nonce . ... rl [BeginRun] : < A : Agent | role i: RI, d com: B U S, cnt: J > => < A : Agent | role i: RI U (n(A,J),B,mtfield), d com: S, cnt: J + 1 > from(A)to(B)send(ped(pk(B),n(A,J),A)) . crl [Message1Rec] : < B : Agent | sec key: SKB, role i: RI, role r: RR, cnt: J > from(A)to(B)send(ped(PKB,F,A)) => < B : Agent | role r: RR U (n(B,J),A,F), cnt: J + 1 > from(B)to(A)send(ped(pk(A),F.n(B,J))) if keypair(SKB,PKB) and not(F in RR) . 12 The State Predicate of an Attack In a topmost version of the specification, the situation where authentication information has been compromised is specified by the following state predicate: op attack? : Configuration -> Prop . ceq attack?(boundary( < INTR : Intruder | ecom : EC, rolei : RI, roler : RR, ncs : fset+(fset+(FSET1, N1), N2) > < A : NSPKAgent | ecom : ecom+(EC2, ecom(ROLE,N1,B,N2)) > Conf)) = true if (not(inEstabCom(ecom(r,N2,A,N1),EC)) and not(inEstabCom(ecom(i,N2,A,N1), EC)) and not(in(N1,RI)) and not(in(N1,RR)) and not(in(N2,RI)) and not(in(N2,RR)) and B =/= INTR) == true . 15 Finding an Attack The relevant safety property is that no such attack is possible under reasonable initial conditions. For example, we can consider a simple scenario with two agents and an attacker given by an initial state cf2Agents1Intruder equationally defined in the obvious manner. Then the desired safety property is P → 2Q with: P = (S = cf2Agents1Intruder) Q = ¬(attack?(S) = true). Maude’s search command finds Lowe’s countarexample to such a property: 16 Finding an Attack (II) Maude> search [1] cf2Agents1Intruder =>+ C:Configuration s.t. attack?(C:Configuration) = true . search [1] in NSPK : cf2Agents1Intruder =>+ C:Configuration such that attack?(C:Configuration) = true . Solution 1 (state 37826) states: 37827 in 25350ms cpu (44300ms real) C:Configuration --> boundary(< alice : NSPKAgent | cnt : 2,dcom : mtfset,roler : mtrun,rolei : mtrun,seckey : skalice,ecom : ecom(i, n(alice, 1), mrx, n( bob, 1)) > < bob : NSPKAgent | cnt : 2,dcom : mtfield,roler : mtrun,rolei : mtrun,seckey : skbob,ecom : ecom(r, n(bob, 1), alice, n(alice, 1)) > < mrx : Intruder | cnt : 1,dcom : mtfield,roler : mtrun,rolei : mtrun,seckey : skmrx,ecom : mtecom,agents : fset+(alice, bob, mrx),ncs : fset+(mtfset, n( alice, 1), n(bob, 1)),msgs : fset+(mtfset, ped(pkalice, cat(n(alice, 1), n( bob, 1)))) >) 17 Simulations (II) Note that (exercise) AP -simulations (resp. AP -simulation maps, resp. AP -bisimulations) compose. That is, if we have AP -simulations (resp. AP -simulation maps, resp. AP -bisimulations) H : A −→ B G : B −→ C then H;G : A −→ C is also an AP -simulation (resp. AP -simulation map, resp. AP -bisimulation). Note also that the identity function 1A is trivially an AP -simulation 1A : A −→ A, and also an AP -simulation map and an AP -bisimulation. 20 LTL−(AP ) It is sometimes useful to restict ourselves to a negation-free fragment LTL−(AP ) of LTL(AP ), defined as follows: • Atomic Propositions. If p ∈ AP , then p ∈ LTL−(AP ). • Next Operator. If ϕ ∈ LTL(AP ), then ©ϕ ∈ LTL(AP ). • Until and Release Operators. If ϕ, ψ ∈ LTL−(AP ), then ϕ U ψ ∈ LTL−(AP ), and ϕ R ψ ∈ LTL−(AP ). • Boolean Connectives. ⊤,⊥ ∈ LTL−(AP ). If ϕ, ψ ∈ LTL−(AP ), then ϕ ∨ ψ ∈ LTL−(AP ), and ϕ ∧ ψ ∈ LTL−(AP ). 21 LTL−(AP ) (II) Since LTL−(AP ) is a sublogic of LTL(AP ), its semantics is the same. Furthermore, in a very practical sense there is no real loss of generality by resticting ourselves to formulas in LTL−(AP ), because we can always transform any LTL formula ϕ into a semantically equivalent LTL− formula ϕ̂. The idea is as follows. Consider a Kripke structure A = (A,→A, LA) on AP , and any formula ϕ ∈ LTL(AP ), and let nnf(ϕ) be its negative normal form (Cf. Lecture 23) in which all negations have been pushed next to the atoms. Of course we have, A |= ϕ ⇔ A |= nnf(ϕ). 22 Simulations Reflect Satisfaction of LTL− Formulae We say that an AP -simulation H : A −→ B reflects the satisfaction of an LTL formula ϕ iff B, b |= ϕ and aHb imply A, a |= ϕ. A fundamental result, allowing us to prove the satisfaction of an LTL formula ϕ in an infinite-state system A by proving the same satisfaction in a finite-state system B that simulates it is the following, Theorem: AP -simulations always reflect satisfaction of LTL−(AP ) formulae. 25 Simulations Reflect Satisfaction of LTL− Formulae (II) bf Proof: First of all, note that we can extend H to a binary relation Ĥ : Path(A) −→ Path(B), where, πĤρ ⇔ ∀ n ∈ IN π(n)Hρ(n). Lemma1: If aHb, than for each π ∈ Path(A) such that π(0) = a there is a ρ ∈ Path(B) such that ρ(0) = b and πĤρ. Proof of Lemma1: The proof amounts to an inductive argument that, if we have built the first n stages of ρ, then we can always build the n+ 1 stage. So, assume that we have ρ defined for 0 ≤ i ≤ n with ρ(0) = b, and with: 26 Simulations Reflect Satisfaction of LTL− Formulae (III) • π(i)Hρ(i), 0 ≤ i ≤ n, and • ρ(i) →B ρ(i+ 1), 0 ≤ i < n. Then, since H is a simulation, and since π(n) →A π(n+ 1), we can find a b′ ∈ B such that ρ(n) →B b ′, and π(n+ 1)Hb′. Therefore, we can define ρ(n+ 1) = b′ and extend ρ to n+ 1 steps. q.e.d. We will be essentially done if we prove the following, Lemma2: For each aHb, π ∈ Path(A) such that π(0) = a, ρ ∈ Path(B) such that ρ(0) = b and πĤρ; and for each ϕ ∈ LTL−(AP ) we have, B, b, ρ |= ϕ ⇒ A, a, π |= ϕ. 27