Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Model Checking Invariants in Infinite State Systems - Prof. Jose Meseguer, Study notes of Computer Science

The automatic verification of invariants in infinite state systems using model checking through search. The concept of model checking, the process of checking invariants through search, and the limitations of this approach. It also provides an example of using this technique to find attacks in cryptographic protocols.

Typology: Study notes

Pre 2010

Uploaded on 03/16/2009

koofers-user-9d0
koofers-user-9d0 🇺🇸

10 documents

1 / 34

Toggle sidebar

Related documents


Partial preview of the text

Download Model Checking Invariants in Infinite State Systems - Prof. Jose Meseguer and more Study notes Computer Science in PDF only on Docsity! Program Verification: Lecture 22 José Meseguer Computer Science Department University of Illinois at Urbana-Champaign 1 Model Checking Invariants through Search Suppose that we have specified a rewrite theory R in Maude as a system module, and that, for k a chosen kind of states with, say, init the chosen initial state, R contains also a Boolean predicate I that we want to check it is an invariant, that is, TR, init |= 2I How can we do this in an automatic way? The key observaton is that I holds if and only if the search command search init =>* x:k such that I(x:k) =/= true . has no solutions. Indeed, having no solutions exactly means that on init, and on all states reachable from it, the predicate I evaluates to true, that is, that I is an invariant. 2 Model Checking Invariants through Search (IV) We call this process of automatically checking an invariant through search model checking, since we are cheching if our model, namely the initial model TR together with a chosen initial state satisfies a given invariant I. If, as in the clock example, the number of states reachable from the initial state is finite, then search provides a decision procedure for the satisfaction of invariants: in finite time Maude will either find no solutions to a search for states violating the invariant, or will find an invariant-violating state together with a sequence of rewrites from the initial state to it, that is, a counterexample. 5 Model Checking Invariants through Search (V) But what if the number of states reachable from the initial state is infinite? In such a case, if the invariant I is violated, the search command will terminate in finite time yielding a counterexample. Assuming that the rules in R have no rewrites in their conditions, termination is guaranteed by the breadth-first nature of the search. A state violating the invariant is a reachable state: there is a finite sequence of rewrites from the initial state to it. Since there is a finite number of rules R, and therefore a finite number of ways that each state can be rewritten, even though the number of reachable states is infinite, the number of states reachable from the initial state by a sequence of rewites of length less than a given bound is finite. 6 Model Checking Invariants through Search (VI) This bounded subset is always explored in finite time by the search command. This means that, for systems where the set of reachable states is infinite, search becomes a semi-decision procedure for detecting the violation of an invariant. That is, if the invariant is violated, we are guaranteed to get a counterexample; but, if it is not violated, we will search forever, never finding it. We can illustrate the semi-decision procedure nature of search for the verification of invariant failures with a simple infinite-state example of processes and resources. Processes and resources have no identities or topology; also, the number of processes and resources can grow dynamically in an unbounded manner. 7 Model Checking Invariants through Search (IX) One invariant we might like to verify about this system is deadlock freedom from an initial state res p(null). There are two ways to model check this property: one completely straightforward, and another requiring some extra work. The straightforward manner is to give the search command Maude> search in PROCS-RESOURCES : res p(null) =>! X:State . Solution 1 (state 1) states: 3 rewrites: 2 in 0ms cpu (0ms real) (~ rews/sec) X:State --> p(res) Solution 2 (state 5) states: 9 rewrites: 9 in 0ms cpu (1ms real) (~ rews/sec) X:State --> p(res) p(res) 10 Solution 3 (state 13) states: 19 rewrites: 26 in 0ms cpu (3ms real) (~ rews/sec) X:State --> p(res) p(res) p(res) Solution 4 (state 25) states: 34 rewrites: 56 in 0ms cpu (4ms real) (~ rews/sec) X:State --> p(res) p(res) p(res) p(res) Solution 5 (state 43) states: 55 rewrites: 104 in 0ms cpu (23ms real) (~ rews/sec) X:State --> p(res) p(res) p(res) p(res) p(res) ...... Solution 20 (state 1649) states: 1770 rewrites: 5640 in 20ms cpu (67ms real) (282000 rews/sec) X:State --> p(res) p(res) p(res) p(res) p(res) p(res) p(res) p(res) p(res) p(res) p(res) p(res) p(res) p(res) p(res) p(res) p(res) p(res) p(res) p(res) ...... 11 Model Checking Invariants through Search (X) Maude will indeed continue printing all the solutions it finds. But since there is an infinite number of deadlock states, it may be preferable to specify in advance a bound on the number of solutions, giving, for example, a command like the following, that looks for at most 5 solutions. Maude> search [5] in PROCS-RESOURCES : res p(null) =>! X:State . The nice thing about model checking deadlock freedom this way is that there is no need to explicitly specify the invariant as a Boolean predicate. This is because the negation of the invariant is by definition the set of deadlock states, which is what the search command with the =>! qualification precisely looks for. 12 states: 14 rewrites: 41 in 0ms cpu (0ms real) (~ rews/sec) X:State --> p(res) p(res) p(res) Solution 4 (state 25) states: 26 rewrites: 87 in 0ms cpu (1ms real) (~ rews/sec) X:State --> p(res) p(res) p(res) p(res) Solution 5 (state 43) states: 44 rewrites: 160 in 0ms cpu (1ms real) (~ rews/sec) X:State --> p(res) p(res) p(res) p(res) p(res) 15 A Cryptographic Protocol Example We can illustrate the power of this model checking technique for invariants of infinite state systems by showing how it can be used to find subtle attacks for cryptographic protocols, including some that have been used extensively and have been considered secure for a long time. One such protocol is the 1978 Needham-Schroeder authentication protocol (NSPK) for which a subtle “man-in-the-middle” attack was found by G. Lowe in 1996 using model checking. The goal of the NSPK Protocol is to provide authentication of two agents who want to be assured of each other’s identity before they exchange safety-critical data. 16 A Cryptographic Protocol Example (II) That is, an intruder should not be allowed to impersonate another agent. For this purpose, initiator and responder of a communication mutually authenticate each other. NSPK uses public key cryptography, i.e., each agent has a public key which can be accessed by all agents, and a secret key which is the inverse of the public key. Moreover, nonces are used in the protocol. Nonces are freshly generated, unguessable random numbers to be used in a single run of the protocol. 17 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) . 20 Maude Specification of NSPK (III) crl [Message2RecCorrect] : < A : Agent | sec key: SKA, role i: RI U (NI,P,mtfield), e com: C > from(B)to(A)send(ped(PKA,F)) => < A : Agent | role i: RI, ECom: C U (i,NI,B,rest(F)) > from(A)to(B)send(ped(pk(B),rest(F))) if keypair(SKA,PKA) and (B == P) and (NI == first(F)) . crl [Message2RecIncorrect] : < A : Agent | sec key: SKA, role i: RI U (NI,P,mtfield) > from(B)to(A)send(ped(PKA,F)) => < A : Agent | role i: RI > if keypair(SKA, PKA) and (NI == first(F)) and (B =/= P) . 21 Maude Specification of the Intruder class Intruder | e_com: EstabCom sec_key: Key ncs: FieldSet, msgs: FieldSet agents: FieldSet role_i: Run, role_r: Run d_com: Field cnt: Nat. crl [IntruderFakeMessage] : < I : Intruder | ncs: N U F, agents: S U A U B > => < I : Intruder | ncs: N U F > from(A)to(B)send(ped(pk(B),F)) if B =/= I . similar: IntruderInterceptMessage, IntruderOverhearMessage, IntruderReplayMessage 22 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)))) >) 25 Finding an Attack (III) We can find the actual sequence of rewrites leading to the “man-in-the-middle” attack by giving to Maude the command show path 37826 . A detailed trace is then shown, corresponding to the sequence of rewrite rule applications: [BeginRun];[IntruderAcceptEveryMessage1];[IntruderFakeMessage1]; [Message1Rec];[IntruderInterceptMessage2];[IntruderReplayMessage]; [Message2Rec];[IntruderAcceptEveryMessage3]; [IntruderFakeMessage3];[Message3Rec] 26 Bounded Model Checking of Invariants Although search can be a quite effective model checking technique for invariants, it has some limitations: • if the set of reachable states is infinite and the invariant is satisfied, the search process never terminates; • even if the number of reachable states is finite, it may be too large to be explored in reasonable time and space, due to time and memory limitations. In such cases we have several alternatives. The most obvious is to give up on completeness and settle for searching states only up to a bound on the depth of paths reaching them. A second alternative is to use an abstraction (this will be discussed in Lecture 23). 27 Bounded Model Checking of Invariants (IV) Taking < 0, 0 > as the initial state, we would like to verify two important invariants, namely: • mutual exclusion: readers and writers never access the resource simultaneously: only readers or only writers can do so at any given time. • one writer: at most one writer will be able to access the resource at any given time. We can try to model checking these two invariants. In this example the invariants themselves can be expressed in two different ways: (i) implicitly, by giving a pattern characterizing their negation; or (ii) explicitly by defining appropriate state predicates. 30 Bounded Model Checking of Invariants (V) The implicit method is the easiest: Maude> search < 0,0 > =>* < s(N:Nat), s(M:Nat) > . Maude> search < 0,0 > =>* < N:Nat, s(s(M:Nat)) > . In this case the state predicates corresponding to the negation of each of the two invariants do not need to be given explicitly as Boolean conditions: they can instead be described more simply by the patterns we are searching for. The negation of the first invariant corresponds to the simultaneous presence of readers and writers, which is exactly captured by the pattern < s(N:Nat), s(M:Nat) >; whereas the negation of the fact that zero or at most one writer should be present at any given time is exactly captured by the pattern < N:Nat, s(s(M:Nat)) >. 31 Bounded Model Checking of Invariants (V) Since the number or readers is unbounded, the set of reachable states is infinite and the search commands never terminate. We can instead perform bounded model checking of these two invariants by giving a depth bound, for example 106, with the commands: Maude> search [1, 1000000] in READERS-WRITERS : < 0,0 > =>* < s(N:Nat), s(M:Nat) > . No solution. states: 1000002 rewrites: 2000001 in 36480ms cpu (50317ms real) (54824 rews/sec) Maude> search [1, 1000000] in READERS-WRITERS : < 0,0 > =>* < N:Nat, s(s(M:Nat)) > . No solution. states: 1000002 rewrites: 2000001 in 38910ms cpu (41650ms real) (51400 rews/sec) 32
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved