An Efficient Cryptographic Protocol Verifier Based on

Prolog Rules

by Bruno Blanchet

Presented by Hai Lin

04/12/2005

The idea of verifying protocols formally

The design of protocols is a particularly error-prone process, many protocols have been shown to have flaws.

We need methods that can verify protocols formally.

Where should we start?

Is your bank account secure? (an analogy)

Assume that we decide whether or not a policy is secure by whether or not an unauthorized person can get PIN. Suppose a bank has the following (unrealistic) policy:

You can change your mail address by simply providing your name and your email address(Notice that these are both publicly known.).You can request your PIN reminder again by simply providing your name and your email address. And then the PIN will be sent to your mail address.

……

Is your bank account secure? (cont.)

Of course this policy is not secure, in the sense that the attacker can easily get your PIN:

The attacker requests that your mail address is changed to an address that he has access to. (Notice that he can do this by simply providing your name and email address.)

The attacker requests your PIN reminder.

Is the policy of a bank secure?This depends …

The policy of the bank(obviously)The attacker’s computational ability

reasonable computational ability: attacker(a) attacker(b)->attacker(P(a,b))∧ unreasonable computational ability: attacker(name)->attacker(PIN)

The attacker’s initial knowledge If the attacker knows PIN, then this problem is trivial.

Moreover, it is unreasonable.

Similarly, whether or not a protocol has flaw depends on

The protocolThe attacker’s computational abilityThe attacker’s initial knowledge

So the first step that we should start with is to formalize them.

Formalize the protocol

A protocol is represented by a set of Prolog rules.

Important terminologies: terms, facts, rules. To give an intuition:

Terms

Formalize the protocol

A protocol is represented by a set of Prolog rules.

Important terminologies: terms, facts, rules. To give an intuition:

facts: predicte(terms)

Formalize the protocol

A protocol is represented by a set of Prolog rules.

Important terminologies: terms, facts, rules. To give an intuition:

rules: fact1, fact2,…,factn->fact

More on termsTerms represent messages that are exchanged between participants of the protocol.Terms can be constants or variables, or functions that applied to terms recursively.Functions are used to represent protocol primitives. Generally, there are two kinds of functions: constructors(e.g. encryption) and destructors(e.g. decryption).

Examples of terms: A, encrypt(x,K)

More on facts

They represent facts about messages.

Facts are built by applying predicates to terms.

Examples of facts:

attacker(A)

attacker(encrypt(x,K))

More on rules

Rules are of the following form:

fact1, fact2,…,factn->fact

-means if fact1,fact2,…,factn are all true, then fact is also true.

Formalize the protocolThere is one set of rules for each message in the protocol. In the set corresponding to the ith message, sent by principle X, the rules are of the form:

attacker(Mj1) … attacker(M∧ ∧ jn)->attacker(Mi)

where Mj1,…,Mjn are the patterns of the message received by X before sending the ith message, and Mi is the pattern of the ith message.

A simple example on how to formalize a protocol

Suppose the first two messages of a protocol are:

1. A->S: A,B

2. S->A: Kab,A,B

The corresponding rules should be:

attacker((A,B))

attacker((A,B))->attacker((Kab,A,B))

Formalize the attacker’s computational ability

For each constructor f, there is a rule of the following form.

attacker(x1) … attacker(x∧ ∧ n)->attacker(f(x1,…xn)) example: attacker(m) attacker(K)->attacker(encrypt(m,K))∧

For each destructor g(M1,…,Mn)=M, there is a rule of the following form:

attacker(M1) … attacker(M∧ ∧ n)->attacker(M) example: attacker(encrypt(m,K)) attacker(K)->attacker(m)∧

Formalize the attacker’s initial knowledge

We always assume that the attacker knows something at the beginning. For example, it is reasonable to believe that the attacker knows the names and public keys of participants of the protocol.

What we have done so far?What we have done so far?

We have formalized the protocol, the attacker’s computational ability and the attacker’s initial knowledge.What is our goal? What’s left?

Determine some secrecy properties: for instance, can the attacker get Kab? In other words, can Kab be inferred from the rules?One possible method

Use Prolog to solve the problem directly.

How does prolog work?

Prolog rules are of the form:

F1,F2,…Fn->F

A fact is a rule with no hypothesis.

A goal is a rule with no conclusion.

Prolog uses depth-first, backward chaining to prove a goal.

How does Prolog work? (example)

Rules: A1->A2 (1)

A2,A3->A4 (2)

Facts: ->A1 (3)

->A3 (4)

Goal: A4-> (5)

The steps of the proof:

(2),(5): A2,A3-> (6)

(1),(6): A1,A3-> (7)

(3),(7): A3-> (8) (4),(8): □ (9)

What is the problem?

Consider the following rule:

attacker(encrypt(m,K) attack(K)∧ ->attacker(m)

The above rule leads to considering more and more complex terms, with an unbounded number of encryptions.

The method

Overview of the method The problematic rule: attacker(pencrypt(m,pk(sk)) attack(sk)->attacker(m)∧

The problem(intuition): the above rule is not “good” enough: the premises are bigger than the conclusion. So when performing backward search, one can get bigger terms, thus termination is not guaranteed.The idea: combine pairs of rules by unification and get the “desired” rules.The solving algorithm works in two phases. The first phase transforms the rule base into a new one, that implies the same facts. The second one uses a depth-first search to determine whether a fact can be inferred or not from the rules.

Overview of the first phase The first phase is actually another kind of forward

search:In the typical forward search, a fact is unified with a hypothesis of a rule to create a new rule. Or equivalently we can say:

Two rules R and R’ can be combined when: (a)The hypothesis of R belong to Φ. (b)The hypothesis F of R’ that we unify does not

satisfy F belongs to Φ.

Overview of the first phase(cont.)

Here in the first phase, two rule R and R’ can be combined when:

(a)The hypothesis of R are of the form attacker(x).

(b)The hypothesis F of R’ that we unify are not of the form attacker(x).

The first phase (detail)More generally…

We can define F∈rS by: there exist a renaming σ such that Fσ S. By default, S={attacker(x)}∈

Two rule R and R’ can be combined when: (a)The hypothesis of R contain only facts F which

satisfy F∈rS. (b)The hypothesis F of R’ that we unify does not

satisfy F∈rS.

The first phase (detail) The first phase contains three steps:

Insert in B the initial rule representing the protocol and the attacker. And perform the normal process of simplification.Combine all rules R and R’ which satisfy the previous two conditions. And add the new rules to B.Extract from B the new rule base B’, by taking only the rules whose all hypotheses are of the form attacker(x).

Some resultsGood news:

Lemma1 (Correctness of phase 1) Let F be a closed fact. F is derivable from the rules in B0 iff F is derivable from B’.

Bad news:The first phase does not always terminates, that means sometimes it will run forever! We will deal with this problem later on.

Overview of the second phase

The second phase searches the fact that can be inferred from B’. The is done by a typical backward depth-first search with loop detection.

The second phase (detail)

We define derivablerec(R,B’’) byderivablerec(R,B’’)=Φ if R’ B’’,∈

R’->R.derivablerec(Φ->C,B’’)={C} otherwise.derivablerec(R,B’’)=∪{derivablerec(elimdup(R’*F0R),{R}∪B’’)|R’ B’, F∈ 0 such that R’*F0R is defined} otherwise.

derivable(F) = derivablerec({F}->F,Φ)

derivablerec(R,B’’)=Φ if R’ B’’,∈ R’->R.

Note: To give an intuition, consider the case in which R B’’. That means R has been ∈used in the search. So it is redundant to call the function derivablerec(R,B’’) again.

derivablerec(Φ->C,B’’)={C} otherwise.

Note: It says if a rule that we want to prove has no hypothesis, then the conclusion of the rule is proved. (In other words, if we want to a fact, then the fact is trivially proved.)

derivablerec(R,B’’)=∪{derivablerec(elimd-up(R’*F0R),{R}∪B’’)|R’ B’, F∈ 0 such that R’*F0R is defined} otherwise.

Note: What happens here is that we try to use R’ to prove one of the hypothesis of R, F0. We change the parameters of the function and call it recursively.

Termination

Termination of the first phase

The first phase does not always terminate. Consider the following rule:

attacker(f(x)->attacker(f(g(x)))

Enforce termination of the first phase

Termination can be enforced by limiting the depth of terms.

Each term that starts at a depth greater than a limit is replaced by a new variable.

Note that this limit is on the depth of terms that appear in the rules, NOT the depth of terms that can be built by the attacker.

Enforce termination of the first phase (cont.)

Notice that if a fact can be generated by the system without depth limitation, it can also be generated with depth limitation because we are using more “powerful” rules. The converse is not correct.The system remains correct, but some precision is lost: If the verifier does not find a flaw in a protocol, then there is no flaw. In contrast, it may give a false attack against the protocol.In practice, the algorithm terminates for many protocols without limiting the depth of terms.

Termination of the second phaseThe second phase can guarantee to terminate under certain restrictions.

Proposition If F is closed and S={attacker(x)}, then derivable(F) terminates. (Otherwise, the termination of derivable(F) is not guaranteed.Proof sketch The hypotheses of the rules in B’ are smaller than the conclusions. Hence the depth-first search considers smaller and smaller terms, and thus terminates.

Optimizations and extensions

Tuples

The system can handle tuples with the following built-in rules:

attacker(M1) attacker(M∧ 2) … ∧ ∧attacker(Mn)->attacker((M1,M2,…,Mn))

attacker((M1,M2,…,Mn))->attacker(Mi)

i=1,2,…,n

Removing useless rules and useless hypotheses

If a rule has a conclusion which is already in the hypotheses, this rule does not generate new facts. Such rules are therefore removed as soon as they are encountered by the verifier.

If a rule contains in its hypotheses attacker(x), where x is a variable that does not appear elsewhere in the rule, the hypothesis attacker(x) can be removed.

Secrecy assumptions

We assume some facts will not be derived by the attacker. For example, we assume attacker(skA),attacker(skB),…are underivable.

The verifier can remove all rules which have underivable facts in their hypotheses.

Experimental resultsThey have implemented the verifier, and have performed tests on a Pentium MMX 223 MHz, under Linux 2.0.32 (RedHat 5.0).

The algorithm terminates for most protocols without limiting the depth of terms.

False attacks are rare. They have been able to prove the secrecy properties of all the protocols they have considered.

Experimental results (cont.)

The point revisited

They separate the search into two phases. The first phase is similar to knowledge compilation. But the purpose is different: the purpose of knowledge compilation is to facilitate the reasoning process later on; The purpose of the first phase here is to guarantee the termination of the second phase.

Thank you!

any questions, comments?