model checking in protocol analysis · 2011-11-17 · model checking in protocol analysis alisa...

17
Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic pro- tocol analysis. One of the protocol analyzers that are based on model checking is SATMC. It reduces a protocol security problem to a boolean formula satisfiability problem, which can be in turn solved by means of modern SAT analyzers. Although SATMC can be used to test complex protocols, it does not support all possible cryptographic primitives. The main goal of this work is to give an overview of the theory that stands behind SATMC and check how Diffie-Hellman exponentiation and XOR operation could be implemented in in this analyzer. 1 Introduction Model checking is an automatic technique for verifying finite-state concurrent systems. Suppose that we are given a model of a system. We may want to check if this model meets some required specification. First of all, we need to describe the system as a finite state machine: a set of states and transitions between the states. Then we need to define some kind of restriction on the states. We check if it is possible that the machine gets into a state that is not valid according to the specification. It can be done for example by using directed graph search, where the nodes are states, and the arcs are transitions. The algorithm checks if it is possible to reach any invalid state from the initial state. This process of verification is called model checking. Model Checking can be used in many different situations, in testing both hardware and software issues. One of its possible implementation is verification of security protocols. Let us consider a simple authentication protocol NSPK (Needham-Schroeder Public Key). Let Alice and Bob be the two parties who want to authenticate themselves to each other. They do not have any pre-shared secret keys, but their public keys are published. These public keys are known not only to both Alice and Bob, but also to the possible attacker. 1. Alice generates a random number N a (called nonce). This random number is needed to identify the session. She encrypts it together with her identity A with Bob’s public key and sends it to Bob through a public channel. A B : {|A, N a |} pk(B) 2. Bob decrypts the message. He generates another random number N b that is also needed to identify the session. He encrypts it together with N a with Alice’s public key and sends it to Alice through a public channel. B A : {|N b ,N a |} pk(A)

Upload: others

Post on 30-Jan-2020

8 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

Model Checking in Protocol Analysis

Alisa Pankova

University of Tartu

Abstract. Model checking is being widely used in cryptograhic pro-tocol analysis. One of the protocol analyzers that are based on modelchecking is SATMC. It reduces a protocol security problem to a booleanformula satisfiability problem, which can be in turn solved by means ofmodern SAT analyzers. Although SATMC can be used to test complexprotocols, it does not support all possible cryptographic primitives. Themain goal of this work is to give an overview of the theory that standsbehind SATMC and check how Diffie-Hellman exponentiation and XORoperation could be implemented in in this analyzer.

1 Introduction

Model checking is an automatic technique for verifying finite-state concurrentsystems. Suppose that we are given a model of a system. We may want to checkif this model meets some required specification. First of all, we need to describethe system as a finite state machine: a set of states and transitions between thestates. Then we need to define some kind of restriction on the states. We checkif it is possible that the machine gets into a state that is not valid accordingto the specification. It can be done for example by using directed graph search,where the nodes are states, and the arcs are transitions. The algorithm checksif it is possible to reach any invalid state from the initial state. This process ofverification is called model checking.

Model Checking can be used in many different situations, in testing bothhardware and software issues. One of its possible implementation is verificationof security protocols.

Let us consider a simple authentication protocol NSPK (Needham-SchroederPublic Key). Let Alice and Bob be the two parties who want to authenticatethemselves to each other. They do not have any pre-shared secret keys, but theirpublic keys are published. These public keys are known not only to both Aliceand Bob, but also to the possible attacker.

1. Alice generates a random number Na (called nonce). This random numberis needed to identify the session. She encrypts it together with her identityA with Bob’s public key and sends it to Bob through a public channel.A→ B : {|A,Na|}pk(B)

2. Bob decrypts the message. He generates another random number Nb thatis also needed to identify the session. He encrypts it together with Na withAlice’s public key and sends it to Alice through a public channel.B → A : {|Nb, Na|}pk(A)

Page 2: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

3. Alice decrypts the message. Since no one except Bob could get her nonceand re-encrypt it, she assumes that it was indeed sent by Bob. Now Bobhas authenticated himself, but Alice also wants to authenticate herself. Shere-encrypts Nb with Bob’s public key and sends it back to Bob.A→ B : {|Nb|}pk(B)

When Bob decrypts the message, he assumes that it has been sent by Alicesince noone else knows the value of Nb.

This protocol is not secure. If Alice wants to communicate with the intruder andsends him {|A,Na|}pk(I), he may re-encrypt the nonce and send {|A,Na|}pk(B)

to Bob claiming that he is Alice. Bob will send him a message {|Na, Nb|}pk(A)

that is encrypted by Alice’s public key. The intruder may now send it to Aliceand claim that it is his own challenge. Alice will decrypt it and send {|Nb|}pk(I)to the intruder. He may now send {|Nb|}pk(B) to Bob and impersonate Alice.

This vulnerability can be very dangerous in reality. If Alice logs to a maliciouswebpage that uses this protocol for verification, the owner of that webpage mayconnect to a bank that uses the same protocol and log in as Alice. Of course,it is quite unlikely that Alice would use the same authentication methods forthe bank and for an arbitrary webpage. But if some official organization wouldbe attacked by an intruder (a smaller Estonian bank), and after visiting theattacked bank Alice would like to check her bigger account in Swedbank usingthe same ID card and the same protocol, then the intruder would get access toher bigger account also.

In more complex protocols, such vulnerabilities can be difficult to detect.Therefore, we need to use various automatic cryptographic protocol analyzers.For example, we may analyze a protocol as a state machine. Each step of theprotocol can be represented as a state that describes the current situation. Thetransitions between the states can be defined by the set of possible operations.The state may change if one party send something into the network or the in-truder derives some new values from the values that he already has obtained. Wemay define a set of ”bad” states where the intruder succeeds in impersonatingsomeone or reveals a secret message. If it is possible to reach one of the ”bad”states from the initial state, it means that the protocol is not secure.

Page 3: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

In this work, all the protocols will be considered in formal model under perfectcryptography assumption. It means that all the messages are represented by termalgebra, and the set of possible operations on them is enumerated. The only wayfor the attacker to get the message is to obtain the secret key. The formal modelis less realistic, but it can be represented as a finite state machine and is easierto analyse.

2 Protocols as Models

A cryptographic protocol can be represented as a state transition system. Thestates are sets of facts that are true for the current step of the protocol execution.The transitions are rewrite rules over sets of facts that may add new facts anddelete old facts from the state. We need to define more formally how the statesand transition can be described.

2.1 Preliminaries

First of all, we need to define what information must be contained in the states:

1. In the previous example, the honest parties generated new random numbers(the nonces) for each session. In the process of protocol analysis, it is veryimportant to remember which nonces are fresh. When an honest party gen-erates a new nonce, we must assume that it has not been used in the systembefore, since in reality it should be completely random. We can denote itwith a term fresh(nonce). If Na is a fresh nonce, we denote this fact asfresh(Na).

Page 4: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

2. On each step of the protocol, the intruder may get the values of moreterms. If Alice has sent {|A,Na|}pk(B) to Bob, we must keep the informa-tion that the intruder also knows the value of this message. Therefore, eachstate must contain information about the values known by the intruder:iknows(information). If the intruder knows the value of a term t, we de-note it as iknows(t).

3. Now it is necessary to model the exchange of messages. The steps of aprotocol are enumerated. We need to record who has sent what values towhom at what step: message sent(step, sender, receiver,message). If onthe step i party A sent to party B a message t, we can denote it as thefact message sent(i, A,B, t). This fact will be included in the state even ifit was actually not A who sent the message, but it was the intruder who hassucceeded to impersonate A.

4. The most important thing is to describe the state of the protocol itself.For each party, we may define its ”state of execution”. In this state, wemay store certain operations that must be executed on certain steps of theprotocol. This can be expressed through a more complex fact state(step,sender, receiver, aquired knowledge, initial knowledge, session). For ex-ample, state(i, A,B, ak, ik, s) means that at step i of session s the party Bknows the terms stored in the list ik, and gains the knowledge about theterms from the list ak after the step i has been executed. A message fromA to B is awaited for step i to be executed. If i = 0, we do not wait for anyexecution.

This type of facts is extremely important since it gives the most informationabout the protocol itself: in which state we are now and what operations canbe performed according to the protocol.

Page 5: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

2.2 Protocol State Description

If we want to describe the particular state of protocol execution, we define it asa set of facts of the form above. For example, the initial state of the previouslydefined simple authentication protocol will be something like this:

– state(0,A,A,[],[A,B,pkB,pkA,skA],1): in the first session, the party A isthe initiator, and B is the responder. This is the view of A. Initially, A knowsthe identities of the both parties A and B, and it also knows the public keyof B, which is pkB. A knows its own secret key and its own public key.

– state(1,B,A,[],[B,A,pkA,pkB,skB],1): the same session from the view ofthe responder B. Initially, B knows the identities of the both parties A andB, its own keys, and it also knows the public key of A, which is pkA. On thefirst step of the protocol, B is waiting for a message that must come fromthe party A.

– state(0,B,B,[],[B,A,pkA,pkB,skB],2),state(1,A,B,[],[A,B,pkB,pkA,skA],2): analogical facts for the second ses-sion, where B is the initiator and A is the responder.

– fresh(nonce(NA,1)), fresh(nonce(NA,2)), fresh(nonce(NB,1)),fresh(nonce(NB,2)): these facts state that the nonces for both parties arefresh in both sessions. Here nonce(NX ,Y) is the constructor of nonce for theparty X in the session Y .

– iknows(A), iknows(B), iknows(pkA), iknows(pkB): initially, the in-truder knows only the names of the parties and their public keys.

All these facts compose the initial state of the protocol.

We also need to write the corresponding transition rules that will change thecurrent state of the protocol. For example, the first step of the protocol can bedescribed by the rule step1(X,Y, SID,PKY, PKX,SKX):

{state(0, X,X, [], [X,Y, PKY, PKX,SKX], SID), fresh(nonce(NA, SID))}step1(X,Y,SID,PKY,PKX,SKX)−→{message sent(1, X, Y, enc(PKY, (A,nonce(NA, SID)))),state(2, Y,X, [nonce(NA, SID)], [X,Y, PKY, PKX,SKX], SID)}.

This rule describes how the state of the protocol changes after the initiatorsends the first message to the receiver. Here X,Y, SID,PKY are variables. Itmeans that this rule can be applied to different sessions and different commu-nicating parties. Here SID denotes the session, and this rule can be applied torewrite both the first and the second sessions that are defined in our initial state.As the result, we check if all the left-side facts are present in the current state.If they are there, we delete them and put the right-side facts instead of them.

Page 6: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

For example, if we apply this rewrite rule to our initial state and set X =B, Y = A,SID = 2, PKY = pkA, we get the following state:

– state(0, A,A, [], [A,B, pkB, pkA, skA], 1)– state(1, B,A, [], [B,A, pkA, pkB, skB], 1)– state(0, B,B, [], [B,A, pkA, pkB, skB], 2)– state(2, A,B, [nonce(NA, 2)], [A,B, pkB, pkA, skA], 2) this has been added– message sent(1, B,A, enc(pkA, (A,nonce(NA, 2))) this has been added– fresh(nonce(NA, 1))– fresh(nonce(NA, 2))– fresh(nonce(NB , 1))– iknows(A)– iknows(B)– iknows(pkB)– iknows(pkB)

The facts state(1, A,B, [], [A,B, pkB, pkA, skA], 2) and fresh(nonce(NB , 2)) havebeen removed. The nonce is no longer fresh, and the state of party B in the sec-ond session of the protocol has changed.

Page 7: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

Additionally, we need to define the intruder rules. For example, we may write

a transition rule for symmetric encryption as iknows(K), iknows(M)enc(K,M)−→

iknows(enc(K,M)), where K is the key and M is the message. When applyingthe transition rule, we need to specify which message we want to encrypt withwhich key (we do not just make all the possible encryptions at once). Thereare also rules that allow the intruder to decrypt data, read the messages, andimpersonate the honest parties (send the messages from their names).

2.3 Protocol Insecurity Problem

We may define protocol insecurity problem as a tuple 〈S,L,R, I,B〉, where:

– S is a set of facts (as defined above).– L is a set of function symbols for rules (not the rules themselves, but just

the symbols).– R is a set of rewrite rules assigned to each functional symbol (the descriptions

of the rules).– I is the initial state.– B is the set of ”bad” states that denote an attack.

The solution to a protocol insecurity problem (the description of the attack) isthe sequence of states that leads from the initial state I to one of the ”bad”states B by applying the rewrite rules.

We have defined the protocol insecurity problem and each of its components.Now we need to define the most important thing: how this problem can besolved?

3 Reducing Protocol Insecurity Problem to SAT

3.1 What is SATMC

Page 8: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

A protocol analysis tool SATMC has been developed based on the previoustheory [1]. It is a part of AVISPA tool set, that contains in total four analyz-ers. These analyzers are based on different theories. Each analyzer is good atparticular protocols, while some other protocol problems may turn out to beunsolvable.

First of all, the description of a protocol is being written in a special languageHLPSL (High Level Protocol Specification Language), that is the same for allAVISPA tools. It can be converted to a lower-level ”intermediate format” IF,which is also the same for all the four analyzers, but where more specificationscan be added manually. Afterwards, the protocol description can be convertedto the other formats that are more specific to the analyzers.

For example, SATMC accepts the protocols written in the format SATE,which is already a lower-level language and is closer to the theory. After beingprocessed by SATMC, the protocol description is finally converted to a protocolinsecurity problem which is in turn reduced to a planning problem and solved bya SAT solver. The current version of SATMC supports two different SAT solvers.They do not belong to the analyzer, but are totally independent programs.

Formally, SAT is a language that consists of all the satisfiable boolean formu-las. A boolean formula is satisfiable iff there exists at least one evaluation of itsfree variables such that the formula itself evaluates to true. Solving SAT problemis equivalent to deciding whether the given boolean formula is satisfiable or not(belongs to the language SAT or not).

Suppose that we are given a tuple 〈S,L,R, I,B〉. We need to find a sequenceof states that lead from the initiial state I ∈ I to some bad state B ∈ B. We wantto reduce this problem to SAT. It means that we need to transform the protocolinsecurity problem to a corresponding boolean formula. Afterwards, this formulashould be given to a SAT solver. The formula should be constructed in such away that it is satisfiable iff the protocol is insecure.

The first step is to reduce the protocol insecurity problem to a planningproblem. A planning problem is again a tuple of 〈F ,A, Ops, I,B〉, where:

– F is a set of variable-free atomic formulas that represent current facts (calledfluents).

– A is a set of variable-free atomic formulas that represent actions (the rules).– Ops is a set the possible operations on the facts and their effects on the

state. Each operation has the form op(Act, Pre,Add,Del), where:• Act ∈ A is the action that corresponds to the operation.• Pre ⊆ F is the set of facts that have to be present in the state before

we can apply this operation (the preconditions).• Add ⊆ F is the set of facts that are added to the state after performing

the operations.• Del ⊆ F is the set of facts that are deleted from the state after perform-

ing the operations.– I is the boolean combination of the facts representing the initial state.– B is the set of boolean combinations of the facts representing all the final

states (the ”bad” states).

Page 9: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

A solution to a planning problem is a sequence of actions whose execution leadsfrom the initial state to any final state and the precondition of each actionappears in the state to which it applies.

A planning problem 〈F ,A, Ops, I,B〉 is just another description for the pro-tocol insecurity problem 〈S,L,R, I,B〉. For example, the rewrite rule that de-scribes the first step of the protocol can be written down as an operation:

op(step1(X,Y, SID, pkY ), the name of the action[state(0, X,X, [], [X,Y, pkY ], SID), the first preconditionfresh(nonce(NA, SID))], the second precondition[message sent(1, X, Y, nonce(NA, SID)), added factstate(2, Y,X, nonce(NA, SID), [X,Y, pkY ], SID)], added fact[state(0, X,X, [], [X,Y, pkY ], SID), deleted factfresh(nonce(NA, SID))]) deleted fact

This kind of conversion is being done automatically by SATMC. There aresome optimizations that make this process faster. For exapmle, it uses stepcompression that merges protocol rules with intruder rules. It also splits somelonger facts into conjunction of smaller predicates. These optimizations do notchange the problem itself, but they allow to finish the reduction in feasible time.

Now we need to show how a planning problem can be reduced to SAT. Firstof all, we need to show how the problem can be represented by a propositionallogic formula.

3.2 Reduction to Propositional Logic

Before the planning problem can be reduced to a SAT problem, it needs somesimplifications. First of all, all the existential quantifiers need to be eliminated(if there are any). In the previous examples, the formulas are without quantifiers,and therefore this process is not described here in details. The main idea is tobind the nonces to some other variables (similar to bringing a formula to Skolemform). The universal quantifiers are not being used explicitly.

Another optimisation is called linearisation. For some rewrite rules there isno difference whether we apply them in parallel or sequentially. We can avoidextra permutations if we find out these sets of rules and assume that they are

Page 10: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

running in parallel. The solutions given by rules running in parallel are calledpartial order solutions, and one partial order solution represents a set of normalsolutions. This makes the analysis more efficient.

3.3 Reducing Quantifier-Free Protocol Insecurity Problem to SAT

First of all, we linearize all the rules that can be run in parallel. Then supposethat the number of steps of the state machine is bounded by some integer k. Oth-erwise, we do not get a finite boolean formula. We will construct a propositionalformula for the bounded partial order solution.

The basic idea is to add an additional time-index to the actions and factsto indicate the state at which the action begins or the fact holds. The planningproblem 〈F ,A, Ops, I,B〉 can be written out as 〈Γ,B〉, where B is still the setof bad (final) states, and Γ contains all the information about behaviour of thesystem (it contains F , A, Ops, and I). Let [[X]] denote the boolean formulathat corresponds to some set X (later, we will show how this formula can beconstructed). We can write down the formula that corresponds to partial orderproblem as [[Γ ]]k ∧ [[B]]k, where:

– [[B]]k encodes the bad states that are reachable in k steps. The constructionof this formula is trivial: each bad state is a conjuction of correspondingfacts, and the entire formula is their disjunction.

– [[Γ ]]k encodes the behaviour of the system that uses not only the rules thathave been defined for the initial protocol, but also the compound rules (thatconsist of several rules running in parallel).

We may write out [[Γ ]]k as I(f0)∧k−1i=0 Ti(f

i, ρi, f i+1):

– All the upper indices are the time indices that indicate the state at whichthe action begins or the fact holds.

– I(f0) is the initial state, and f0 denotes the facts that are true for the initialstate (on the step 0).

– Ti(fi, ρi, f i+1) encodes all the possible evolutions of the system from the

step i to the step i+ 1 (all the possible states that we may get by applyingall the available transition rules).

• f i is the set of facts on the step i.

• ρi is the set of rules that can be applied in parallel on the step i.

• f i+1 is the set of facts on the step i+ 1 after applying ρi.

If we get an evaluation for each Ti in the big conjunction, it means that startingfrom the initial state we can reach the final state that is denoted as fk.

Now we have to do the most important thing: consruct I(f0) and Ti. Thereare two ways of doing this in SATMC.

Page 11: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

3.4 Linear Encoding

In order to make this encoding possible, we assume that the set of facts F andthe set of rules L are finite. Otherwise, it would be impossible to compose afinite boolean formula.

The encoding will be the following:

– I(f0) =∧{f0|f ∈ I} ∧

∧{¬f0|f ∈ (F \ I)}

A fact in the initial state is true iff it belongs to the set I in the protocolinsecurity problem. The facts that do not belong to I (that belong to F \I)must be false.

– The rules of the form Ti(fi, ρi, f i+1) are encoded by axioms. For each rule

ρ ∈ L, the following must hold:• ρi ⇒

∧{f i|f ∈ pre(ρ)}: all the facts that are necessary for the precon-

dition of applying the rule ρ must be true on the step i.• ρi ⇒

∧{f i+1|f ∈ add(ρ)}: all the facts that must be added after applying

the rule ρ must be true on the step i+ 1.• ρi ⇒

∧{¬f i+1|f ∈ del(ρ)}: all the facts that must be removed after

applying the rule ρ must be false on the step i+ 1.On the other hand, if something has happened to a fact after the step i (itwas either added or deleted), there must be a rule that has caused that. Thefollowing must hold for each fact f ∈ F :• {f i ∧ ¬f i+1} ⇒

∨{ρi|ρ ∈ L, f ∈ del(ρ)}: if the fact f has been deleted

after the step i, it must have been caused by at least one rule ρ ∈ R.• {¬f i ∧ f i+1} ⇒

∨{ρi|ρ ∈ L, f ∈ add(ρ)}: if the fact f has been added

after the step i, it must have been caused by at least one rule ρ ∈ R.Finally, we need to be sure that exactly one rule has been executed on thestep i. For each pair of rules ρ1, ρ2 ∈ L(ρ1 6= ρ2), we write ¬(ρi1 ∧ ρi2).

Now we may join all these formulas into a single conjunction (construct [[Γ ]]k ∧[[B]]k) and give it to a SAT solver. The obtained formulas are very intuitive,and it has been proved in [1] that satisfiability of the conjunction of all theformulas defined above is equivalent to proving that the corresponding protocolis insecure. There are also optimizations that make the encoding and the furtheranalysis faster.

3.5 Graph-Based Encoding

Another idea is to construct a data structure called a planning graph. Thisencoding is equivalent to linear encoding, and for some protocols the analysison graph is faster. In general, a planning graph is a directed acyclic graph. Thesource nodes denote the first layer. All the neigbours of the source nodes composethe second layer. All the nodes reachable in one step from the second layer definethe third layer etc. In this way, each vertex of the graph belongs to exactly onelayer.

In the solution, we will limit the number of steps (layers) by some constant kin the same way as we did it for the linear encoding. Although formally a planning

Page 12: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

graph is directed, in [2] the relations between nodes are represented as edges.Our graph will be even more interesting since each layer contains two sublayers:one for the facts and the other one for rules. We can define a k-planning graph

as ([Γ ])k = 〈Nf , Nρ,pre→ ,

add→ ,del→,⊕f ,⊕ρ〉, where:

– Nf is a time-indexed family of sets of fact nodes, such that N if ⊂ F is the

set of fact nodes of layer i.– Nρ is a time-indexed family of sets of rule nodes, such that N i

ρ ⊂ L is theset of rule nodes of layer i.

–pre→

i⊆ N i

ρ × N if : time-indexed binary relations between the rule nodes and

the fact nodes.

–add→

i

⊆ N iρ ×N i+1

f .

–del→i

⊆ N iρ ×N i+1

f .– ⊕f are mutual exclusions between facts (that cannot be true at once).– ⊕ρ are mutual exclusions between rules.

Two nodes of the same type can be connected only with mutual exclusion edges,and the nodes of different types can be connected only with rule applicationedges. In [2], the relations add, pre, del are considered as edges, and the directionsof the relations are not important. The mutual exclusion edges are definitity notdirected, since otherwise, there would be cycles.

If we want to consider this graph as a directed acyclic graph (use it as a

normal planning graph), then arcs that denote addition and deletion (add→

i

anddel→i

) would point from the rule layer i to the fact layer i + 1 (according to thedefinition, there are no edges between more distant layers). The arcs that denote

preconditions (pre→

i) would always point from the fact layer i to the rule layer i,

although from the definition it may seem that the arc points from the rule tothe fact. In practice, SATMC passes the graph layer by layer, and he does notreturn to the previous layers.

This kind of graph can be constucted from the protocol insecurity problemby induction. We take the set of facts F and the set of rules R as a basis. First ofall, we extend the set of rules with no operation rule, which is defined as nop(f)for each f ∈ F . It will be need to define transitions from one level to another inthe cases where no rules have been applied. For example, if we have some factX on the step i, and we still have the same X on the step i + 1, we write is aswe have applied no operation to it.

Page 13: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

We define the following nodes and relations for the graph:

1. Fact Nodes:– N0

f = I: we may have more than one source node, and each of themcorresponds to an initial state.

– f ∈ N if iff there exists a rule ρ ∈ N i−1

ρ s.t either ρadd→

i−1f or ρ

del→i−1

f :we put a fact node into the layer i only if it is needed there (it is eitheradded to or deleted from the set of facts on the step i− 1).

2. Rule Nodes:– ρ ∈ N i

ρ iff pre(ρ) ⊆ N if and (∀f, f ′ ∈ pre(ρ))¬f ⊕if f ′: we add a rule

node into the layer i iff its preconditions are satisfiend on the step i andthese preconditions are not in contradiction with each other.

3. Edges: for each ρ ∈ N iρ:

– ρpre→

if iff f ∈ pre(ρ).

– ρadd→

i

f iff f ∈ add(ρ).

– ρdel→i

f iff f ∈ del(ρ).It means that there is an edge between a rule node and a fact node iff therule performs that operation on the fact node.

4. Rule Conflicts: ρ⊕iρ ρ′ iff ρ 6= ρ′ and at least one of the following holds:

– There exists f ∈ F such that ρdel→i

f and either ρ′add→

i

f or ρ′pre→

if :

the rules are in conflict iff one of them tries to delete f , and the otherone either needs it as a precondition or tries to add it.

– There exist f, f ′ ∈ F such that ρpre→

if , ρ′

pre→if ′, and f ⊕if f ′: the rules

are in conflict iff any of their preconditions are in conflict.5. Fact Conflicts:

– f ⊕if f ′ iff f 6= f ′ and for all ρ, ρ′ ∈ N i−1ρ such that ρ 6= ρ′, ρ

add→i−1

f ,

ρ′add→

i−1f ′, we have ρ⊕i−1ρ ρ′: the facts are in conflict iff they have been

produced by two different rules that are in conflict on the step i− 1.

Here is an example of the first 1,5 layers for the NSPK protocol:

Page 14: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

According to [2], such a graph can be constructed from a protocol insecurityproblem in polynomial time. It is also important that the sets of facts of rulesdo not have to be finite since the graph can be gradually being constructed inthe process of its analysis.

The only thing that has remained is reduction of graph planning problem tothe SAT problem. We need to show how to construct the corresponding booleanformula [[Γ ]]k = I(f0)

∧k−1i=0 Ti(f

i, ρi, f i+1) from the graph.

– I(f0) =∧{f0|f ∈ N0

f }: the initial state encodes the nodes of the first layer(the source nodes).

– Like in the case of linear encoding, the rules of the form Ti(fi, ρi, f i+1) are

encoded by axioms. For each rule ρ ∈ N iρ, the following must hold:

• ρi ⇒∧{f i|ρ pre→

if}.

• ρi ⇒∧{f i+1|ρ add→

i

f}.

• ρi ⇒∧{¬f i+1|ρ del→

i

f}.If something has happened to a fact after the step i, there must be a rulethat has caused that. The following must hold for each fact f ∈ N i

f :

• {f i ∧ ¬f i+1} ⇒∨{ρi|ρ del→

i

f}.

• {¬f i ∧ f i+1} ⇒∨{ρi|ρ add→

i

f}.• There is an additional rule that we did not have in the case of linear

encoding. For all f ∈ (N i+1f \ N i

f ) we have f i+1 ⇒∨{ρi|ρ add→

i

f}. Itmeans that if the fact f does exist on the step i+ 1, but it did not existon the step i, there must be some rule ρ that has added this fact.

– For each pair of rules x1, x2 ∈ (N iρ∪N i

f ), we write ¬(xi1∧xi2). This holds notonly for the rules (as in the case of linear encoding), but also for the facts.

In the worst case, the number of the atoms and the clauses generated bythe graphplan-based encoding is equal to that generated by the linear encoding.Still, in many cases the formulas are considerably smaller for the graphplan-basedencoding, and the SAT solvers can therefore deal with them much faster.

One reason why the graphplan-based encoding is more efficient is that we donot construct the nodes for unnecessary facts and unnecessary rules. We do notcreate a node for a fact on the layer i if this fact cannot be true on the step iand it has neither been added nor deleted. In the same way, we do not create anode for a rule on the layer i if we cannot apply this rule at the step i.

4 Diffie-Hellman Problem in SATMC

Suppose that we are given a group G = 〈g〉 of order n, in which the discretelogarithm problem is hard (there is no algorithm that, given gx ∈ G, findsx ∈ Zn in polynomial time). The Diffie-Hellman problem is defined as follows:given g ∈ G,gx ∈ G and gy ∈ G, find gxy ∈ G. This problem cannot be solvedin polynomial time if the discrete logarithm problem is hard in G.

Page 15: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

This problem can be efficiently used in some cryptographic protocols. In thesimple Diffie-Hellman key exchange, Alice and Bob agree on a group G = 〈g〉with public g. Alice generates a random number x ∈ Zn, computes gx and sendsit to Bob. Bob generates a random number y ∈ Zn, computes gy and sends it toAlice. Both parties may compute gxy = (gx)y = (gy)x and use it as the secretkey. The intruder cannot derive this key since he knows only g, gx, gy, and theDiffie-Hellman problem is hard in G.

The Diffie-Hellman exponentiation is not so easy to implement in SATMC.We need to take into account the equational theory that defines relations betweendifferent terms. For example, SATMC has to understand that (gx)y = (gy)x. Asmentioned in [3], it is possible to implement a solution for DH exponentiationthat uses only two exponents. In the case of SATMC it can be done by meansof axioms:

iknows((gX)Y ) ⊂ iknows((gY )X)

iknows((gX)Y ) ⊃ iknows((gY )X)

This solution is not very good because it requires non-trivial extensions to SATsolvers, but SATMC does support this. Some simpler protocols using DH expo-nentiation have already been tested in [3]. We may try to write a more complexset of axioms that would allow to test protocols that use more than two dif-ferent exponents. Describing only the intruder rules is not sufficient, since theequations are needed also for the ordinary protocol rules. If a rewrite rule con-tains state(...., (gx)y, ...) in its preconditions, we must take into account thatstate(...., (gy)x, ...) would also be a suitable precondition for this rule.

It is difficult to describe the whole theory, but it is possible that not all theaspects need to be included into analyzis. We may try to use some simplificationssuggested in [8].

One big problem concerns the syntax that must be used in writing axiomsfor SATMC. There is nothing about the axioms in the user manual, and theauthors of [3] did not publish their relults.

It would be good to suppot both addition and multiplication operations forDH exponentiation. We may try to use limited amount of variables so that theanalysis would be feasible. The ideas for multiplication can be taken from [7],where DH exponentiation has been implemented for another protocol analyzer

Page 16: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

called ProVerif. That solution is not perfect since it works only for finite numberof exponents and supports only their multiplication. The addition seems morecomlpex, and it has not been implemented in [7]. However, the rules for additioncan be similar to the rules for XOR.

5 How XOR Can be Modeled in SATMC

AVISPA toolset supports XOR operation in the protocols. This is however notthe property of SATMC. The protocol containing XOR can be tested with OFMC[4], which is another analyzer in the AVISPA toolset that is based on lazy anal-ysis. Its actions are generated in a demand-driven way. It allows to avoid unnec-essary operations that the real attacker would not apply.

The ways of implementing XOR operation in formal cryptography have beenproposed in some articles. In [5], the authors have proved that analysis of theprotocols that use XOR is in NP, but their solution is rather theoretical. Theseideas have been implemented in OFMC.

In [6], a solution has been proposed for Horn theory-based approach. It al-lows to check some protocols that use XOR with analyzer ProVerif, but theimplementation has turned out to be inefficient.

6 Conclusions and Future Work

Currently, SATMC does not support neither Diffie-Hellman exponentiation norXOR by default. It is however possible to define user axioms on the lower level,the SATE format, where the protocol insecurity problem has already been trans-formed to a planning problem.

In general, the work process can be the following:

1. Take some protocol that uses xor or exp operations. Write it down (or findan existing version) in HLPSL (the universal high-level language for AVISPAtoolset).

2. Convert the protocol to intermediate format IF.3. The SATMC will not agree to convert IF to SATE if he sees there xor or exp

operations. They should be replaced with some other functional symbols.For example, if we replace xor with xor2, the protocol will be successfulyconverted to SATE.

4. The SATE file can even be analysed, but it is senseless since nothing specialwill be done to the xor2 operation. Even if we change xor2 back to xor,SATMC will not apply any equations to it.The properties of xor2 need to be described manually, and this can be doneat least in three different places:– Rewrite rules: some rules for DH exponentiation have been tried here.

With the basic rules (without taking into account the inverses), the rulesare working. The process does not last for infinity even if associativityis used, since the size of the planning graph is bounded. However, this

Page 17: Model Checking in Protocol Analysis · 2011-11-17 · Model Checking in Protocol Analysis Alisa Pankova University of Tartu Abstract. Model checking is being widely used in cryptograhic

solution may turn out to be too inefficient for more complex protocols,and we would be able to describe only the intruder rules, but not theequations necessary for the set of preconditions.

– Equations: it is possible to use equations in SATMC, and there is evenan automatically generated record %EQUATIONS under which the gen-erated equations must be placed. A term equal(A,B) is being used insome places in the IF format, and it can be used to check if A == B.However, this term has no use in SATE format. In general, the equa-tions for IF are contained in the special prelude file, where exp and xorequations have been described. SATMC does not want to refer to thisfile, and he says that he does not support such equations.

– Axioms: it seems that the axioms can be expressed through facts, butit is not clear what use can be made of them. The solution in [3] assumesthat we have to define the axioms for subset, but it is unclear how the setrelations can be described in SATE. When SATMC converts IF format toSATE, it generates the record %USER AXIOMS that is also left empty.

Although the attempt to implement Diffie-Hellman exponentiation (and evenXOR operation) has failed, there are some ideas that have not yet been tried.The future work will most probably be concentrated on implementing axioms,and it would be good to somehow aquire the solution used in [3].

References

1. Alessandro Armando and Luca Compagna. Automatic sat-compilation of protocolinsecurity problems via reduction to planning. In FORTE, pages 210–225, 2002.http://dx.doi.org/10.1007/3-540-36135-9 14.

2. Alessandro Armando and Luca Compagna. Sat-based model-checkingfor security protocols analysis. Int. J. Inf. Sec., 7(1):3–32, 2008.http://dx.doi.org/10.1007/s10207-007-0041-y.

3. Alessandro Armando, Luca Compagna, and Yuliya Lierler. Automatic compilationof protocol insecurity problems into logic programming. In JELIA, pages 617–627,2004. http://dx.doi.org/10.1007/978-3-540-30227-8 51.

4. David Basin, Sebastian Modersheim, and Luca Vigano. Ofmc: A symbolic modelchecker for security protocols, 2004. Digital Object Identifier (DOI) 10.1007/s10207-004-0055-7.

5. Yannick Chevalier, Ralf Kusters, Michael Rusinowitch, and Mathieu Turuani. An npdecision procedure for protocol insecurity with xor. Theor. Comput. Sci., 338:247–274, June 2005. http://dl.acm.org/citation.cfm?id=1085260.1085269.

6. Ralf Kusters and Tomasz Truderung. Reducing protocol analysis with xor to thexor-free case in the horn theory based approach. ACM Conference on Computerand Communications Security, pages 129–138, 2008.

7. Ralf Kusters and Tomasz Truderung. Using proverif to analyze protocols with diffie-hellman exponentiation. IEEE Computer Society, pages 157–171, 2009.

8. Sebastian Modersheim. Diffie-Hellman without Difficulty. In Proceedings of the 8thInternational Workshop on Formal Aspects of Security & Trust (FAST2011), 2011.