A CSP approach to the analysis

of security protocols

Thesis submitted for the degree of

Doctor of Philosophy

at the University of Leicester

M e i L i n H u i

Department of Mathematics

and Computer Science

University of Leicester

LEI7RH

May 2001

UMI Number: U157826

All rights reserved

INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted.

In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed,

a note will indicate the deletion.

Dissertation Publishing

UMI U157826Published by ProQuest LLC 2013. Copyright in the Dissertation held by the Author.

Microform Edition ProQuest LLC.All rights reserved. This work is protected against

unauthorized copying under Title 17, United States Code.

ProQuest LLC 789 East Eisenhower Parkway

P.O. Box 1346 Ann Arbor, Ml 48106-1346

Abstract

Security protocols involve an exchange of messages in order to achieve a goal

such as authentication of a user or secrecy of a session key. Many established

protocols have been found to be flawed using protocol analysis techniques. In this

thesis we will be extending current CSP-based protocol modelling techniques.

Recent techniques for analyzing security protocols have tended to concentrate

upon the small protocols that are typically found in the academic literature. How

ever, there is a huge gulf between these and most large commercial protocols. As

a result, existing techniques are difficult to apply directly to these large protocols.

In this thesis we develop the notion of safe simplifying transformations: trans

formations that have the property of preserving insecurities; the effect of such

transformations is that if we can verify the transformed protocol, then we will

have verified the original protocol. We identify a number of safe simplifying

transformations, and use them in the analysis of two commercial protocols, the

CyberCash Main Sequence protocol and SET.

We extend the CSP-based analysis technique to model the property of non

repudiation and give a formal generalized definition. Our definition of non

repudiation is tested against our two case studies.

Another property we model is that of key compromise: the reuse of a compro

mised session key that might lead to an authentication or secrecy attack. We look

at how to model the intruder learning the value of a key and then using it in an

attack. We apply this technique to our case studies, looking for key compromise

attacks using the session keys.

Acknowledgements

I would like to thank my supervisor, Gavin Lowe, for his advice and guidance

throughout the course of this thesis. He has provided many useful suggestions,

and pointed out errors when I was going astray.

Many thanks go to my office colleagues, especially Michael Hoffmann, Andy

White and Steve Hales, for making my time at Leicester University enjoyable and

for their friendship and support.

This work was supported by a grant from the Engineering and Physical Sci

ences Research Council without which this work could not have been carried

out.

Finally I must thank Troy Wilson for all his patience and support during the

last 4 years and throughout our lifetime together.

Contents

1 Introduction 1

2 Security protocols and the CSP approach 5

2.1 Security Protocols.................................................................................. 5

2.2 C S P ........................................................................................................ 15

2.3 Modelling security protocols using C S P ............................................ 20

2.4 D iscussion.............................................................................................. 26

3 A survey of other approaches 30

3.1 Model checking approaches................................................................... 31

3.1.1 Inatest - K em m erer................................................................... 32

3.1.2 NRL protocol analyzer - Meadows.......................................... 32

3.1.3 Interrogator - M il le n ................................................................ 34

3.1.4 Marrero, Clarke and J h a .......................................................... 34

3.1.5 Mur< Mitchell, Mitchell and S te rn ....................................... 37

3.2 Direct proof m ethods............................................................................ 38

3.2.1 BAN logic - Burrows, Abadi and N eedham ............................ 38

3.2.2 AAPA - Brackin ...................................................................... 39

3.2.3 Isabelle/HOL - Paulson .......................................................... 40

3.2.4 B o lignano ...................................................................... 41

ii

3.2.5 Spi calculus - Abadi and Gordon .......................................... 41

3.2.6 Strand spaces - Thayer, Herzog and G u t tm a n .................... 43

3.2.7 Rank functions - Schneider...................................................... 44

4 Simplifying transformations 47

4.1 Modelling security p ro toco ls................................................................ 51

4.1.1 Messages...................................................................................... 51

4.1.2 Honest a g en ts ............................................................................ 53

4.1.3 The in truder................................................................................ 54

4.1.4 Attacks ...................................................................................... 56

4.2 Renaming transformations on protocols.............................................. 58

4.2.1 Formalizing renaming transformations ................................. 58

4.2.2 A general re s u lt ......................................................................... 60

4.3 Examples of safe renaming transformations....................................... 66

4.3.1 Removing en cry p tio n s ............................................................ 66

4.3.2 Removing hash functions......................................................... 68

4.3.3 Removing some atomic or hashed fields.................................. 69

4.3.4 Renaming a t o m s ...................................................................... 71

4.3.5 Swapping p a i r s ........................................................................ 72

4.3.6 Coalescing a to m s ...................................................................... 73

4.3.7 Removing fields from the bodies of encryptions ................. 75

4.3.8 Simplifying S ig n a tu re s ......................... 76

4.3.9 Removing timestamps from bodies of encryption................. 78

4.4 Structural transform ations................................................................... 79

4.4.1 Splitting messages ................................................................... 80

4.4.2 Redirecting m essages................................................................ 84

iii

5 Commercial protocols 90

5.1 Case study: CyberCash protocol....................................................... 90

5.1.1 Tool S u p p o r t ............................................................................ 91

5.1.2 Simplifying the p ro to c o l.......................................................... 93

5.1.3 Analysis of the simplified protocol.......................................... 99

5.2 Case study: SET p ro to c o l.................................................................... 102

5.2.1 Simplifying the p ro to c o l............................................................. 105

5.2.2 Analysis of the simplified protocol............................................. 110

5.3 Related w o r k ................................................... 113

6 Non-repudiation protocols 116

6.1 Formalizing N on-R epudiation.............................................................. 120

6.1.1 Non-repudiation of origin............................................................. 120

6.1.2 Non-repudiation of re c e ip t.......................................................... 122

6.2 A fair non-repudiation p ro to c o l ........................................................... 123

6.2.1 Non-repudiation of origin (N R O ) ..............................................125

6.2.2 Non-repudiation of recipient (N R R )...........................................127

6.3 Non-repudiation in commercial p ro toco ls............................................130

6.3.1 Non-repudiation and simplifying transformations ................132

6.3.2 Non-repudiation in the CyberCash protocol ...........................135

6.3.3 Non-repudiation in the SET p ro to co l....................................... 137

6.4 Related w o r k .................................................... 139

7 Key compromise 141

7.1 Untimed CSP m o d e l .............................................................................. 143

7.2 Adding t im e ..............................................................................................150

7.3 Commercial protocols.............................................................................. 154

7.4 D iscussion................................................................................................. 155

iv

7.5 Related work 156

8 Conclusions 158

8.1 Future w o rk ..............................................................................................163

A An example Casper input file 166

B Some proofs of transformations 169

B.l Removing en c ry p tio n s .......................................................................... 169

B.2 Removing hash functions....................................................................... 171

B.3 Removing some atomic or hashed fie ld s...............................................171

B.4 Renaming atoms ....................................................................................173

B.5 Swapping p a i r s .......................................................................................173

B.6 Coalescing a to m s ..................................................................................... 175

B.7 Removing fields from the bodies of encryptions................................... 175

B.8 Simplifying signatures ............................................................................176

B.9 Splitting messages..................................................................................... 178

B.10 Redirecting m essages...............................................................................180

C The CyberCash M ain Sequence Protocol 188

D SET protocol description 194

v

Chapter 1

Introduction

Security protocols are used to maintain secure operations over the Internet or

through any communication using a computer. A protocol is a series of steps

involving different agents each sending messages to one another to establish a

goal. By following these steps in sequence the agents can agree, for example, on

a cryptographic key with which to send subsequent encrypted messages known

only to themselves, authenticate one agent to another or to agree on some data,

or simultaneously sign a contract.

Security protocols are made up of an exchange of typically 2-5 messages sent

in a particular sequence. These messages can be encrypted, or in plaintext con

sisting of details, nonces, keys and timestamps. Encryption can be in two forms,

symmetric and asymmetric using shared keys or private and public key pairs.

One of the first papers to describe such protocols is [43].

Researchers have found flaws in security protocols, most notably [30] where

the Needham-Schroeder public key protocol was broken 17 years after it was first

published. The method used by Lowe is a process algebra that analyses protocols

by describing a set of agents and their communications together with an intruder.

This thesis will extend this method in order to analyse commercial protocols and

1

model a number of different properties.

The process algebra CSP (Communicating Sequential Processes) [25, 48, 54,

50] describes a protocol by modelling each of the participating agents as a CSP

process together with the most general intruder who can interact with the sub

sequent system made up of all the agents. The intruder is always present and is

described to have the ability to modify, overhear and intercept messages (subject

to the intruders capabilities within the system). The system is checked against

different specifications testing for secrecy and authentication by using a model

checker, FDR [20], to search the state space for possible attacks. A trace detailing

the sequence of events that form an attack is found if the specification fails. We

go into more details of the CSP method in the following chapter.

The analysis of security protocols with this method has been extremely suc

cessful, and has been used to discover a number of attacks [30, 31, 36]. In order

to make this analysis even simpler, Lowe has produced a CSP compiler, Casper

[34]. This takes as input a short description file of the protocol using standard

notation for describing protocols and automatically produces a CSP file of the

corresponding protocol. This file can then be loaded into FDR and analysed.

There are a number of different methods for analysing security protocols; these

are reviewed in chapter 3, but in this thesis we concentrate on the CSP approach.

The formal analysis of security protocols has been an area of research lead

ing to several new discoveries and attacks. Flaws have been found in security

protocols that have been assumed to be secure, only to be broken later on. The

emphasis on finding tools that can be applied to this analysis has increased with

so many methods now available, some successful some not. It is the ideal to have

a tool that can automatically determine whether a protocol is secure or not, in

a short amount of time without the arduous task of hand proofs. To have an

automated tool that is reliable would make the task of designing and verifying a

2

protocol much easier.

The remainder of this thesis is organized as follows. In chapter 2 we look at

security protocols in general and then go on to describe the CSP approach to

analysing protocols. We briefly describe the CSP notation and look at one way

of using CSP to model a protocol for analysis. This process can be automated

using Casper which generates the CSP from a simple protocol description.

In chapter 3 we look at other approaches to analysing protocols, including

more model-checking approaches and belief logics. As mentioned earlier there

have been several techniques created for the analysis of protocols, each with their

own advantages and disadvantages.

In chapter 4 we describe a technique of simplifying protocols prior to analy

sis. These have stemmed from trying to analyse commercial protocols that are

considerably larger with more fields and much higher levels of nested encryption.

As a result, existing techniques are difficult to apply directly to these protocols,

most notably leading to a state space explosion. We develop the notion of safe

simplifying transformations; transformations that have the property of preserving

insecurities; the effect of such transformations is that if we can verify the trans

formed protocol, then we will have verified the original protocol. We identify a

number of such simplifying transformations and prove that they are safe with

respect to secrecy and authentication specifications.

In chapter 5 we apply the transformations we have described in the previous

chapter to two commercial protocols, CyberCash and SET. This enables us to

analyse the transformed protocols, which is equivalent to analysing the complete

protocol.

Iii chapter 6 we look at formalizing non-repudiation in CSP. We look at both

non-repudiation of origin and receipt and give a general definition that covers

both cases. We apply our techniques to our case studies, the CyberCash and

3

SET protocols, looking at the simplified protocols and proving that by analysing

the simplified protocols with respect to non-repudiation any attacks that we find

can be mapped onto the original protocols.

Finally, in chapter 7 we address key compromise. We look at the Needham

Schroeder Symmetric Key protocol, which is known to suffer from a key compro

mise attack. We formalize two methods of modelling key compromise, the first

using a CSP model of time and another method that does not use time. We

compare and discuss these two methods and apply them to our case studies.

4

Chapter 2

Security protocols and the CSP

approach

2.1 Security Protocols

Security protocols are designed to provide users with services such as confiden

tiality and authenticity in applications such as electronic banking and Internet

security. The use of cryptography addresses many security issues and provides

us with a means of achieving confidentiality and authenticity. However when

designing a protocol, there may be a clear aim but does the protocol actually

achieve this? The protocol may achieve its aim but it may also be vulnerable to

other flaws that have not been considered.

Communicating over any network is always at risk to an intruder overhearing

or intercepting any messages. By using a security protocol we hope to prevent

this. A security protocol is a set of rules that the participants are expected to

follow in order to achieve authenticity of their identities or confidentiality of some

details.

Protocols can be used to achieve confidentiality, authenticity, integrity, non

5

repudiation, anonymity and fairness.

Confidentiality : Also known as secrecy. No other agents should be able

to read a sent message other than the intended recipient. For a set of data

items that is to remain secret, no message of this set should be obtainable

by the intruder.

A uthenticity : The receiver of a message should be able to ascertain the

origin. Each participant must be sure of the identity of the agent with

which they are communicating.

Integrity : The receiver of a message should be able to verify that it has

not been tampered with.

Non-repudiation : A sender should not be able to falsely deny that he

sent a message; this is non-repudiation of origin. Non-repudiation of receipt

concerns the receiver who should not be able to falsely deny having received

a message.

Anonym ity : A system is anonymous over some set of events E if it has

the property that when an event from E occurs then an observer can deduce

that an event has occurred but not which particular event.

Fairness : A protocol is fair if at no point during the run an agent is able

to gain an advantage over another agent by ending the protocol before it

has completed.

We can never assume a system is secure for communication. It is open to an

attack from an intruder who is present with the capability of intercepting and

faking messages. Even if a message is encrypted with a key which the intruder

does not possess it can still be intercepted and replayed in a different run of

6

the protocol. By intercepting messages the intruder can learn the values of keys

and nonces (a random number that is used only once) and thus generate his

own messages to introduce into the system. The intruder could participate in a

protocol either as himself or masquerading as another agent. By impersonating

another agent, say A, the intruder can fool the participant of the protocol into

believing that he has completed a run with A when in reality he has not.

With the assumption that no network is secure, it is therefore necessary to use

cryptographical methods to disguise the data transmitted. Through the use of

encryption, important data can be transformed into something illegible, providing

the decryption keys are remained secret. So a message m encrypted with key K

is decrypted with key K~ x to retrieve the original message.

m = { { m}K}K-1

Symmetric encryption uses the same key for encryption and decryption so it is

imperative to keep this key secret. If the encryption key is K, then the decryption

key K~x is exactly the same: K = K~x. Asymmetric encryption uses different

keys to encrypt and decrypt a message: K ^ K~l . The encryption key is known

as the public key as this can be made public knowledge. However the inverse

of this key, the decryption key must remain private. It is not computationally

possible to deduce the private key from the public key. Digital signatures can be

used for proof of origin as well. The idea is for an agent A, to use a private key,

SK(A), to sign a document; this document is then sent to agent B who uses A s

public key, P K ( A ), to verify the signature. The signature must have come from

agent A as only agent A holds the private key with which it was signed.

A B : {Message}sk(A)

The public key of A is used for both decrypting and checking the signature of

7

the message. If the decryption gives a message which does not make sense then

it can be assumed that A did not sign the message with SK(A).

In a symmetric system, for an agent A to send a message to B , both agents

need to know the value of the key used. So this key is a shared key between A

and B, denoted by K ab If we have the following message:

A -> B : {Message}Kab

B will know that this message has come from A as it has been signed with the

key that is a shared secret between the two of them. Assuming this key has been

kept secret, not leaked to anyone else and that B did not send it himself, no one

else but A must have sent this message.

Using just encryption is not enough to secure a message as it is possible to

replay previous messages. By secure, we mean that no one is able to read or

manipulate a message. It is difficult to detect whether a message is recent just

by looking at it. A message is deemed to be current if it has been sent recently

and is not a replay of an old one. In order to preserve this temporal integrity,

nonces can be applied. A nonce is a random number generated and used for only

one run of the protocol.

Alternatively, a system with a universal clock can use a timestamp [18, 22] to

guarantee the timeliness of a message and avoid the risk of replayed messages.

Each message is sent with a timestamp that is checked against each agents local

clock. If the timestamp is within a certain time period then it can be assumed to

be recent. All clocks must be synchronized or differ by only a small timeframe.

By looking at a well-known protocol and its corresponding attack we will illus

trate how protocols are described. The Needham-Schroeder Public-Key protocol

is a good example of this. It has been widely used to illustrate new protocol

analysis techniques.

We will be looking at the simplified three-message version, where the key

server has been omitted. The protocol is described as follows:

1. A B : A , B , { N cl,A } p k (b)

2. B -* A : B, A, {Na, Nb}pK(A)

3. A > B : A,B , {Nb}pK(B)

Each message is described as follows:

1. The initiator A sets up a session with B by sending a randomly selected

nonce N a , and its identity encrypted with B s public key, PK(B) . Only B

can decrypt this message using his own private key.

2. B responds by sending back the nonce Na together with his own nonce Nb ,

encrypted this time with A s public key. When A receives this message, the

value of the returned nonce is checked against the one sent in message 1. If

the two nonces match, A is assured to be talking to B as this nonce is only

sent to B.

3. A completes the protocol by returning s nonce again encrypted with

PK(B). When B receives this message and checks the value of the nonce,

it would appear that B can be assured to be talking to A. A subsequent ses

sion can now begin with each principal sure of the identity of their partner

in the communication.

However there is a flaw in this protocol that involves two runs, a and /?, inter

leaved as described in [30]. In run a, A begins by establishing a session with the

intruder, I, and in run /?, the intruder impersonates A (denoted by 1(A)) to fool

9

B into thinking he has completed a run of the protocol with A.

a l . A > I : A,I ,{Na,A}pK(i)

01. 1 ( A ) B : A,B,{Na,A}pK(B)

02. B > 1(A) : B ,A ,{ N a ,N b } PK{A)

olI . I y A : I, A, {Na, Nb}pK(A)

a3. A > I : A, I, {Nb}pjc(i)

03. 1 ( A ) - ^ B : A ,B ,{ N b } PK(I)

The weakness in this protocol is in message a2 which is replayed as 02. The

encrypted component of this message consists of the nonce from the first message

with a new nonce, Nb. The intruder reuses Na from a l in run 0. B replies in 02

with this nonce and a Nb. Now the intruder simply replays this message as he

is playing the responder role in run a with A, who then returns the value of Nb

this time encrypted with / s public key. So the intruder has learned the value of

Nb and fooled B into thinking he has completed the protocol run with A.

This attack can be easily rectified by adding the identity of the responder in

the encrypted part of the message so message 2 now becomes:

2. B > A : B, A, {Na, Nb, B } p k (a)

This can no longer be replayed by the intruder as message a2 as it would contain

Ts identity and would not be accepted by A.

Many security protocols have the aim of achieving authentication. There are

several different types of authentication, but informally it is the process of reliably

verifying the identity of an agent. Abadi gives Two facets of authentication

in [1], where authentication can be used for assigning responsibility and giving

credit. If a message is sent from A to B, responsibility is defined as being when

B believes that the message is supported by A s authority. B gives credit to A

10

for the message. The paper [1] illustrates these facets through examples using

existing protocols.

Example: encrypting a session key.

1. A > B : {A, K } PK(b)

2. A ^ B : { M } k

3. B > A : {M '}k

It is assumed the principals can recognise their own messages and ignore them.

If A receives {M } k that is replayed to be a message 3, this would be ignored as

A would recognise this as being one of their previous messages.

Only B can extract K from message 1, so B takes responsibility for the use

of K. When A receives {M '} k , A knows this has come from B or from someone

who has got the key K from B. A holds B responsible for this message. This

is similar to secrecy in that A believes that only B or whoever has received the

key can produce the message. So by keeping the key secret we can attribute

responsibility.

Message 1 could have been sent from anyone as it does not provide any ev

idence that it has been produced by A. Therefore, B cannot hold anyone else

responsible for messages encrypted under K. A can claim credit for messages

encrypted under K as A s identity has been included in message 1.

If A says transfer 100 to j 4 s account and this message is encrypted with a

banks public key so that only the bank can carry out this transaction, then A

can claim credit for this message even though anybody could have created this

message. If, on the other hand, A says transfer 100 from As account and this

message is signed by A so that the bank can authenticate this has been authorised

by A, A then claims responsibility for the message. It is hard to link credit and

responsibility with our definitions of authentication and secrecy. Credit can be

11

claimed for a message that could be created by anyone but contains your identity.

Responsibility is similar to both our authentication and secrecy definitions, if a

key is meant to be kept secret between two agents then any message encrypted

with this key is held responsible by an agent, if a message is signed then it can

also be held responsible as our two examples illustrate.

Other definitions of authentication are given in [32] where a hierarchy is

presented. In some circumstances weak specifications are all that is needed,

and in others a stronger specification would be required. In increasing order of

strength, the specifications are listed as :

Aliveness Weak Agreement > Non-injective agreement > Agree

ment.

Aliveness : If an initiator A completes a protocol run apparently with a respon

der B , then B has previously been running the protocol. B , however, may

neither have been running the protocol with A nor running the protocol

recently.

W eak A greem ent : If an initiator A completes a protocol run, apparently with

responder B , then B has previously been running the protocol, apparently

with A. B may not necessarily have taken the responder role.

N on-injective A greem ent : If an initiator A completes a protocol run, appar

ently with a responder B then B has previously been running the protocol,

apparently with A where B has been taking the responder role and both

agents agree on the set of data items ds.

A greem ent : If an initiator A completes a protocol run with a responder B,

then B has previously been running the protocol, apparently with A where

12

B has been taking the responder role and both agents agree on the set of

data items ds. Each run of A corresponds with a unique run of B.

Some protocols even fail to achieve aliveness due to an intruder launching a mirror

attack and replaying an agents messages back to himself. Those that guarantee

aliveness sometimes dont guarantee weak agreement as there can be an attack

where the intruder imitates another agent in one run of the protocol and plays

himself in a parallel run. If A has been running the protocol with the intruder

playing himself, the intruder can use A as an oracle to fool B into thinking he

has completed a run with A when in fact it has been the intruder as we have

illustrated with the Needham Schroeder Public Key protocol. Failure to achieve

non-injective agreement can occur when the agents dont agree on the values of

the data items. An example of this attack can be seen in [14] on the original

Andrew protocol where the intruder fools A to accept a different key from the

one used by B. The final definition of authentication, agreement, can be difficult

to achieve as one agent could believe they have performed two runs of a protocol

with the same agent when in fact this agent has only participated in one run.

In order to design a protocol well, a number of principles [3] have now been

adopted as good practice.

Each protocol message should be distinctly different in terms of the en

crypted components so that a receiver will know to which message it be

longs. This reduces the risk of replaying a message from a previous step in

the protocol.

Every message should say what it means so that the recipient can clearly

understand the meaning. The appropriate action to be taken and the con

ditions for such an action should be clearly defined in a message.

13

Secrets should not be held longer than necessary and protected to maintain

their secrecy.

Encryption can be used in a number ways, to preserve confidentiality or

guarantee authenticity or both. Confidentiality is preserved when a message

encrypted with a key K is only understood by the holder of the inverse key,

K ~ l . To guarantee authenticity, it is assumed the sender is the only one

who knows the encryption key so when decrypted with the correct inverse

key the message can be authenticated.

Use temporal information to prove the timeliness of a message. This is

achieved through the use of timestamps, sequence numbers or nonces.

The identities of all the agents taking part in a protocol should be easily

recognised from an encrypted component of a message. This can either be

in the form of encrypting the identities or by inferring the identities through

encryption with a public, secret or shared key.

Anderson and Needham have put forward a number of principles to help

protocol designers avoid pitfalls and attackers to find errors, [5]. This paper

focuses on public key protocols whereas [3] is more general. Principles such as

the following are suggested:

Signing before encrypting;

Avoiding using the same key for more than one purpose, such as signing

and decryption, as it should be possible to distinguish different runs of the

same protocol

In essence when designing anything it is best to adopt the KISS principle

(Keep It Simple Stupid) which people often ignore. Commercial protocols such as

14

those for digital cash are immensely complicated and even with all this complexity

can be found to be insecure.

2.2 CSP

The abstract language of CSP is often used in the description and analysis of

systems which consist of interacting components. In particular, CSP is used to

describe communication patterns of concurrent system components that interact

through message passing, therefore protocols can be described using CSP.

This approach has been successful over the years for analysing security proto

cols and finding new and existing attacks. A number of papers have been written

detailing this research see [21, 30, 31, 36, 46, 51]. The method of analysing a

protocol using the process algebra CSP, has been successfully implemented and

the model checker FDR has found several attacks on a number of protocols.

FDR searches the state space of a small system running the protocol to discover

whether there exists an attack on this protocol. The agents participating in the

protocol are modelled as CSP processes along with the most general intruder who

can intercept and fake messages. The system is made up of all the agents and

the intruder processes acting concurrently. This system is then checked against a

specification to test for properties such as secrecy of data items or authentication.

B rief overview o f C SP notation

Events

A system is modelled in terms of events which can be performed within it. The

set of events which can occur in a system is denoted by . Events are actions

where no timeliness is involved, but whose occurrence might require simultaneous

15

participation by more than one independently described process. The events in

a system describing a protocol are communications which can consist of several

distinct components. In its simplest form, a communication can be described as

a pair c.m where c is the channel on which a message m is sent.

Processes

The components of a system are the processes which are described in terms of

possible events in which they may engage. The simplest process is Stop, which

will engage in no events at all and is equivalent to deadlock.

When a message is sent on a channel, e.g. c.m, the direction of the message is

unknown. Direction can be specified either as c?m or dm, representing input and

output, respectively. The input c?m : T -* P(m) accepts as input any m of type

T along channel c, and then acts like the process P(m). The output d m > P

first outputs m along channel c, and then behaves like P.

The choice between two process is shown by P Q (pronounced P choice

Q), so the process can behave either as P or Q. This is an external choice which

is deterministic, whose choices are made externally by the environment of the

process. A general form of choice is Pi, an indexed form where I is a finite

indexing set and a process Pi has been defined for each i.

Another form of choice is internal choice, which is nondeterministic. The

choice is made internally by the system in an arbitrary fashion. P n Q behaves

nondeterministically either as P or Q. The environment cannot control the choice

made. There is an indexed form for this as above, FI. Pi-i l

Some events of a system are best kept hidden, invisible to and beyond the

control of the environment. This is achieved with the concealment operator i\ \

and results in removing the events following \ from the interface, e.g. P \ A,

pronounced P hide A, behaves like P, except that each occurrence of any event

16

in A is concealed.

Pfla/6] is a process that acts like P , except the event b is renamed to a.

CHAOS (A) is the most nondeterministic, non-divergent process with alpha

bet A and can perform any sequence of events from A.

Processes may be placed in parallel so that they run concurrently, synchro

nising on common events. The processes will synchronize with each other on

events which appear in both processes. P [|S|] Q represents two processes which

run concurrently and synchronise on the events specified in the set S. All other

events not in this set are performed independently.

Two processes when placed in parallel are described as : P \\ Q. A general

form is: I * : Pi where I is a finite set of indices such that Pi and A{ are definedI I

for i E I. A system with this definition describes a combination of components

where each process Pi interacts with alphabet Ai.

Two processes which run concurrently and do not synchronise on any events

are written as P ||| Q (P interleaves Q) and is the same as P[\ {} |]Q, P in

parallel with Q synchronising on the empty set. This has the effect of both

processes running completely independently of each other with no interaction.

Trace Sem antics and R efinem ent

The semantics of a process P is defined to be the set of sequences of events

which it may perform; this is known as the traces of P , written as traces(P).

Traces are useful when defining specifications, that is a particular condition we

want a process to satisfy. We can define a behavioural specification such that

each s G traces(P) meets some condition R(s). To verify a specification, we state

what we want to achieve, e.g. P sa t R(tr) which means Vtr G traces(P) R(tr).

So for all traces of P , we expect them to satisfy the property R(tr). In order

to satisfy sa t P ( tr ) a processs traces must be a subset of the traces which R

17

allows.

If the behaviour of process Q is contained in the behaviour of another process

P , then we say that Q is a traces refinement of P or P is refined by Q, P Q Q.

We could consider P to be a specification which determines possible safe states of

a system, then we can think of P C.T Q as saying that Q is a safe implementation.

P Q = traces (Q) C traces(P)

A finer distinction between processes can be made by constraining the events

which an implementation is permitted to block as well as those it performs. A

process can be represented by its failures. A failure is a pair (s,X ), where s is a

finite trace of a process and A is a set of events it can refuse to perform after s.

This will lead to a stable state (i.e. no internal events are possible) where it can

do no action from the set X . Failures refinement is defined by insisting that the

failures of a refinement process are included in those of the refined process.

P Q = failures(Q) C failures(P)

A traces(Q) C traces(P)

A process can be represented by its divergences; the finite traces during or after

which the process can perform an infinite sequence of consecutive internal (r)

actions (livelock). Failures-divergence refinement is defined as:

P E fd Q = failures(Q) C failures(P)

A divergences(Q) C divergences(P)

The tool FDR (Failures-Divergence Refinement) [20], is a model-checking tool

for state machines, with its foundations in the theory of concurrency based around

CSR It allows the analysis of CSP with regard to particular properties. The

primary function of FDR is to investigate relationships between different CSP

properties, but also to check determinism of individual processes.

18

FDR directly supports three models:

The traces model: Traces refinement is used for proving safety properties

and can be used to check that a process is a safe implementation.

The stables failures model: Failures refinement is used to prove failures-

divergence refinement for processes that are already known to be divergence-

free.

The failures/divergence model: Failures-divergences refinement is used for

proving safety (via traces), liveness and combination properties and also

establishing refinement and equality between systems. This can be used to

assert that a process must eventually accept some event from a set that is

offered to it.

When a CSP file describing a protocol is loaded into FDR, assertions appear

that are to checked. Assertions usually take the form:

assert Abstract [X= Concrete

where Abstract and Concrete are processes, and X indicates the type of comparison. There are three types of comparison: T for traces, F for failures and FD for

failure-divergence. Assertions can be used to test that a specification is refined

by an implementation, spec C impl.

These assertions can be tested for traces refinement, failures refinement or

failure-divergences refinement as well as deadlock- and livelock- freedom. If they

are found to be false, the FDR process debugger displays a trace which fails the

refinement. FDR reports the first error it finds in a breadth first search and

continues to find more errors if required.

A system to be analyzed using FDR is written using machine readable CSP,

CSPm , which is a slight variant from the blackboard CSP. The table of

19

differences is listed in the following table.

Operator Name Syntax ASCII form

External choice P O Q P Q

General external choice D . , p ' [ ] i : I Pi

Internal choice P n Q p n Q

General internal choice n . e, pi*i l~l i : I Pi

Parallel

General parallel

P \ \Q

1 1 1 *

P 1 1 Q

1 1 i : I [Ai]Pi

Interleaving ^ III Q P III Q

General interleaving \ \ L P* 111i :I Pi

Common event parallel P [|A|] Q P [ 1AI ] Q

Renaming P lb / 4 P [[ a

message Public Key Protocol:

1. A - + B : A ,B ,{ N a ,A } p K(B)

2. B A : B, A ,{N a, Nb, B }pK(A)

3. A B : A ,B , {Nb)pK(B)

The datatype representing messages defines a message either as an atom, a

sequence of messages, an encryption of a message or a function applied to a mes

sage. Communication is carried out on different channels, normal communication

on the channels send and receive. The environment sends messages to agents

via the channel env to tell them with whom to open a session.

To define the initiator of the protocol as a CSP process, we shall call this

agent Initiator (A, na), having the identity A, with the nonce na in its initial

knowledge. The initiator process is described in terms of the message it sends

and receives during a run of the protocol.

Initiator (A, na) =

envlB : Agent > send.A.B.{na, A}p k (b) >

Once the steps of the protocol have been completed a session has been estab

lished with another agent B using the nonces na and nb.

We can describe the responder in a similar way with the process

Responder (B , nb).

Responder (B,nb) =

nb Nonce

receive.B.A.{na,nb}px(A)

send.A.B.{nb}pK(B) Session(A, B ,na,nb)

receive.A.B.{na, A }pk (b)

A Agent,naGNonce send.B.A.{na,nb}PK(A) ~>

receive.A.B.{nb}pK(B) Session(B, A,na,nb)

21

The system running the protocol with the honest agents can be described

simply as the interleaving of the initiator and responder.

SystemJd = Initiator(A,na) ||| Responder(B,nb)

We now include the possibility of an intruder joining in the communications

by either intercepting messages sent by an honest agent or faking those that have

been received.

M odelling the intruder

We have described the honest agents in the protocol, so now we go on to describe

the intruder.

The intruder definition uses the channels /earn, say and leak. The channel

leak is used to signal that a possible secret has been learnt, learn and say are

used to represent hearing or saying a message. When overhearing a message

the intruder increases his knowledge base and can replay this message or deduce

further messages.

The intruder uses a set of deductions which allow him to produce new facts

from ones he has already learnt. If the intruder knows a set of facts he can

produce the sequence of facts by concatenation or by knowing a sequence of facts

he can produce each fact singly. There are deductions for producing encryptions,

decryptions, Vernam encryption and decryption and hash deductions.

Sq ( . .. , , . . . ) h x

(a?!,. . . , xn) h Sq(xi , . . . , xn)

{m}k A A;-1 h m

k ,m b {m }k

We can describe an intruder with an initial knowledge, I I K , as a single process

22

in the following way:

IN T R U D E R (IIK ) =

,, learn!M -> I N T R U D E R ^ I K U {M})M E M essa ge J '

saylM -> I N TRU D E R (IIK )

M M e ssa g e , I IK \~ M ' '

leak.M -> IN T R U D E R ! I IK ) .

M M essa g e ,I IK \~ M

The intruder may:

see messages sent by honest agents, and so learn the contents;

send messages with contents that can be derived from his current knowl

edge, such messages being received by an honest agent;

signal that he knows any message that can be derived from his current

knowledge.

The complete system is then described as the parallel combination of processes

representing each participant. Each process runs independently but its range and

possibilities will be influenced by the other processes. The processes are brought

together to interact with each other simultaneously executing on common events.

In this system we have just three processes, the honest agents, Alice and Bob and

the intruder, Ivor.

The system is connected together with renamings to match the send and

receive events of the honest agents with the learn and say events of the intruder.

The send and learn events are renamed to an intercept channel, and the receive

and say events are renamed to a fake channel.

23

System =

Agent{Alice)\intercept, fake/send, receiveJ

inAgent(Bob)\intercept, fake/send, receive]]

11 {{intercept,fake\}

Ivor\intercept.x.y, fake.x.y/learn, say \ x, y G Agents]

The CSP model of the network can be described pictorially as:

send/rec

send sendrec rec

fakeintercept fake intercept

Intruder

Specifications

Now that we have described the whole system running the protocol we go on to

define the specifications against which the protocol will be tested. The specifica

tions make use of signals that the agents can perform during the protocol. These

signals describe the beliefs of the agents at a particular point in the protocol. The

signal channel is used as a flag to show each principals belief during the protocol.

This channel can take either of the following fields,claimSecret, runningAnit,

running-resp or finished-init, finished-resp. The claimSecret signal takes

the form of signal.daimSecret.A.B .na to represent A believing that the nonce

24

na is a secret between himself and B. A and B are taken from the set of honest

agents and na from the set of secrets. The signals running_* and finished

take the same format. For example, signal.running-init.A.B.na.nb represents

an agent A in a run of the protocol with agent B using the nonces na and nb.

We can test for secrecy of a data item with the following trace specification:

Secrecy(tr) = V A A gen t ; B Honest

signal.claimSecret.A.B.M in tr => leak.M in tr.

In the above specification, if we have a signal.claimSecret event performed by

any honest agent, then the intruder is should not perform a leak event in the

same trace for the data item M. If the intruder has performed a leak event in

the same trace as the claimSecret signal then we have a breach of secrecy.

To link the claimSecret signals with the system running the protocol the

corresponding messages in the system are renamed to the correct signal events.

The last message in which each agent is involved in the protocol is renamed

to the signal.claimSecret event. That is, only when they have completed their

participation within the protocol can they perform this event. So for the initiator

the third message sent is renamed to signal.claimSecret.A.B.na and the last

message which involves the responder is receiving the third message so the receive

event in the responder process is renamed to signal.claimSecret.B.A.nb.

S y s te m S e c =

System^signal.claimSecret. A.B.na, signal.claimSecret.B.A.nb

/ send. A.B. {nb} p k { b) > receive. A.B. {nb} p k { b )

| A 4 Agent, B 4 - Agent, na 4 Nonce, nb Nonce\

The secrecy specification is tested to see if it is refined by the renamed system.

Authentication is tested by ensuring the signal events occur in the correct

order. To authenticate the initiator to the responder, the initiator must signal a

25

running event before the responder has signalled to finish.

InitAuthToResp(A) =

signal.running-init. A? B?na?nb >

signal. finished-resp.B .A.na.nb -* Stop

The signals are renamed to their corresponding events, the initiator A sending

message 3 is renamed to signal.running-init and the responder receiving this

message is renamed to signal.finishedresp. We check this specification for

traces refinement. The specification is only in terms of signal events, so we hide

all the other events. System l is the renamed system running the protocol.

System A =

System l (Events \ {| signal.running-init, signal, finished-resp |})

We can test whether the protocol achieves authentication of the initiator by

checking for the refinement:

InitAuthToResp(A) ET System A

2.4 D iscussion

The CSP definition of the intruder is parameterized by the set of facts that he

might learn, these include atomic datatypes, encrypted keys and Vernam encryp

tions. For n facts, the intruder process will have 2" states which is too large to

be run on FDR. Therefore by using the lazy spy technique [21, 48] an equiv

alent process definition is used to cut down the amount of computation. The

intruder is no longer represented as a single process which can learn n facts but

as n processes, one for every fact. These are all run in parallel. Each fact is

either one that is not known by the intruder or one that could be learnt during

26

a run. These processes synchronize on events representing overhearing or inter

cepting messages, deducing or faking new messages. This allows us to optimize

the intruder definition when running the system on FDR.

CSP is appropriate for modelling multi-agent systems which communicate

via messages. It is also a good model to formulate security properties such as

secrecy, authentication and non-interference. It is possible to build time into

CSP modelling. The use of time and timestamping is apparent in some security

protocols so we can see why CSP has become an ideal framework for analyzing

security protocols.

With FDR the process of analyzing a protocol is made automatic. CSP pro

cesses representing the agents and intruder can be quickly checked to see if they

satisfy security specifications concerning secrecy and authentication. Testing such

specifications through FDR takes a few seconds. The state space is searched to

see if the refinements hold and if not a trace representing an attack is produced.

Lowe has devised a compiler for security protocols [34] to aid the coding of

a system running a protocol. Modelling a security protocol in CSP is a long

task which could be prone to errors. By using Casper, the CSP file describing

the protocol can be produced and then checked with FDR in a few minutes.

Casper accepts input in the form of an abstract description of a protocol and the

resulting output is a CSP file ready to be loaded into FDR. The protocol can

then be analysed.

A Casper file is essentially made up of two sections:

1. the definition of the protocol

2. the definition of the system to be checked.

Going back to the Needham-Schroeder Public-Key protocol once more, we see

the Casper notation for the protocol description is very similar:

27

#Protocol description

0. -> A : B

1. A -> B : {na, AMPK(B)}2. B -> A : {na, nb>{PK(A)>

3. A -> B : {nb}{PK(B)>

A message ra, encrypted with key &, is normally written as {m}k, but is repre

sented here as {m}{k}.

Casper adds extra fields to each message representing the sender and receiver

so they have been omitted from the above definition. The first line, although it

is not part of the protocol, is used to start the protocol off. A message is sent to

A from the environment to tell A to initiate a run with B.

The rest of the protocol description consists of a declaration of the free vari

ables that appear in the message list, with their types; a declaration of the agents

taking part in the protocol together with their initial knowledge and finally a

specification of what the protocol is supposed to achieve.

Specifications take the form:

#Specification

Secret(A, na, [B])

Secret(B, nb, [A])Agreement(A, B, [na, nb])

Agreement(B, A, [na, nb])

The first two lines specify the data items that are expected to remain secret. The

first line is read as: A believes the nonce na is to remain a secret between only A

and B. Similarly for the second line. The authentication specifications are given

28

in the last two lines. Agreement (A, B, [na, nb]),tells us that if B thinks he

has been running the protocol with A, then A has been running the protocol

with B, they agree upon which roles they take and the values of the nones of the

nonces na and nb.

The second half of the Casper file consists of the system definitions. This is

made up of four parts: the actual types used, including the intruder, a definition

of any functions used, the agents taking part in the protocol and the initial

knowledge of the intruder.

Once the Casper file has been compiled the CSP file describing the system is

then checked against the specifications with FDR to see if the system satisfies

them. If not, a trace is produced. FDR checks the protocol when it is adopted in

a specific system hence the need to describe the system. The system is usually

quite small.

An example input file can be found in Appendix A

29

Chapter 3

Other approaches to analyzing

security protocols

There are several different approaches to analysing protocols. The majority of

this research has been aimed at authentication and key exchange protocols. Sev

eral frameworks for modelling authentication protocols and associated correctness

properties have been presented. The techniques can be split into two categories:

M odel checking techniques where a model checker is used to search the state

space of a small system running the protocol, looking for attacks; see, for

example, [41, 27, 39, 30, 36, 34, 42, 38]

Direct proofs where the protocol is proved correct directly (possibly with the

help of machine assistance), typically using some form of induction; see, for

example, [52, 24, 45, 65].

The use of logic to describe the requirements of a protocol and analysing

knowledge and belief is a popular method. BAN logic [14] is a well known example

of this method although it is now widely discredited. There are a number of

general purpose formal methods using specification languages such as LOTOS,

30

HOL [45] and InaJo [27]. Formal methods based on algebraic term-rewriting

properties of a system are another example. This method expresses the state

of the agents knowledge and analyses if certain states can be reached. The

Naval Research Laboratory (NRL) Protocol Analyzer has been successful in this

method, finding both new and known flaws, [27, 39] . Finally there is the use of

process algebras, such as CSP and Spi calculus [2] which has been built on top

of the 7r calculus.

3.1 M odel checking approaches

There are several other model-checking methods that have been tried by others.

This approach is to model the protocol by defining a set of states and transitions.

An intruder is included who can participate in a run of the protocol either as

an honest agent or masquerading as another. This model only works for a small

system running the protocol. Messages are sent and received by agents and the

knowledge that they have at each stage of the protocol monitored. A protocol is

deemed secure if by searching the state space a particular insecure state cannot

be reached, if an attack exists, a trace leading to this state is generated.

If a model checker fails to find an attack this does not mean that the protocol

is free from attacks. All this means is that there is no attack on the small system

analysed. An attack may exist on a larger system running the protocol.

Formal methods are used to verify the correctness of systems, be it for security

protocols or safety critical systems. The system is specified using a formal speci

fication language such as a process algebra that has a mathematical background.

Different aspects of the specification are then proved either by hand, which is

slow and time-consuming, or with the aid of an automatic theorem-prover.

The algebraic approach, first devised by Dolev and Yao [19], models a protocol

31

with a collection of rules for transforming and reducing algebraic expressions

representing messages as well as an intruder. The state transition approach tests

whether insecure states are reachable. The next three systems to be described,

are all different but each combines algebraic and state-transition methods.

3.1.1 Inatest - Kem m erer

The Inatest system, as described in [27] was not developed exclusively for the

analysis of protocols. It is a specification execution tool designed to support gen

eral purpose software specification and verification using FDM (Formal Develop

ment Methodology). The properties that the protocol is expected to preserve are

described as state invariants and the theorems that must be proved to guarantee

that the invariants are preserved by the system are automatically generated. By

using InaJo, a formal specification language, the protocol and the way in which an

intruder can launch an attack are described. Inatest, a symbolic execution tool,

is then used to walkthrough the protocol and demonstrate its vulnerabilities.

The states of the protocol are searched in order to find an insecure state. This

is carried out using a forward search. By using a forward search, the protocol

can be searched to uncover insecure states that may not be obvious to the user.

This system has successfully found Simmons attack on the TMN protocol [63].

However, when using Inatest, the user determines the intruder actions and flaw

scenarios, so not all possible intruder actions are considered.

3.1.2 NRL protocol analyzer - M eadows

A Prolog based model-checker has been devised by Meadows, the NRL (Naval

Research Laboratory) Protocol Analyzer [39]. This uses a backwards search un

like the previous system which was forward searching. However the search is less

32

automated. This system aids the user by proving a protocol is secure but can be

used to uncover vulnerabilities. The specification language is Prolog-based and

the analysis tool based on term-rewriting. The action of sending and receiving

messages is represented as a set of state transition rules. The words used in a

message obey a set of reduction rules for example:

encrypt(X , decrypt(X , Y)) -+ Y

decrypt(X , encrypt(X , Y)) - * Y

In order to use this tool, the user specifies an insecure state and the tool

gives a complete description of all states preceding this state. Queries can be

made to find the trace leading to this state as well as proving that certain states

are unreachable. By limiting the search space and eliminating those areas which

are unreachable, infinite loops can be detected and avoided, making the search

process more efficient. This system provides a high degree of assurance that a

protocol is secure.

This model uses a protocol to produce words, beliefs and events. Each agent

of the protocol possesses a set of beliefs which may be modified and created

depending on which message has been received. A message is sent depending

on what beliefs and messages have been received before hand. An NRL Protocol

Analyzer specification is made up of four parts, the transition rules, the operations

available to the participants, the atoms that are used as the basic building blocks

of the words and the rewrite rules obeyed by the operations.

When a user queries the Analyzer about a particular state, the Analyzer

searches for the set of states that immediately precede it. The output is a large

amount of data describing the different paths which the protocol can take. This

can be difficult to manage and interpret to a novice. Searching through the state

space which can be large, can take a long time. This analysis is not entirely

33

automated; lemmas for the tool to prove must be generated by the user.

3.1.3 Interrogator - M illen

Another model checker that also uses backward searching and Prolog is Millens

Interrogator [41]. The protocol is specified in Prolog, using predicates to describe

the state transitions. An exhaustive backwards search is performed on a single

run of the protocol to determine if an insecure state is reachable from the initial

state. The intruders knowledge can be varied in terms of what information is

available to him. Each agent in the protocol has a list of memory items which

increases as the protocol is run with each message sent or received. The main

idea is to define a predicate, pKnow(D , H , B, S). This holds details of when the

intruder is able to obtain a knowledge of specified data D , via a message history

H , which goes from the initial state B , to an insecure state S. The user specifies

a goal state and the analyser returns a set of states instantiated to H that gives

a trace representing an attack.

The amount of time it takes to find an attack can vary depending on the

amount of detail in the specification and assumptions of the protocol. It takes

more time if less information is specified about the goal state. There is no guar

antee that a protocol is secure when a search fails, as with most protocol analysis

techniques.

3.1.4 M arrero, Clarke and Jha

Another model checking approach has been carried out by Marrero, Clarke and

Jha, [38]. The model checker used by the authors is called Brutus. This method

turns a protocol description into a sequence of commands such as SEND, r e c e iv e

and NEWNONCE. W ith each sequence of actions representing each participant in

34

the protocol, the full model is obtained by taking their asynchronous composition.

An intruder is also modelled with all the capabilities we have described earlier.

This method can be used to test for secrecy as well as authentication of one agent

to another. A trace here is represented as an alternating sequence of global states

and actions. The global state consists of the local states of each agent with some

global information such as the set of secret information and which principals have

been involved with which runs. A depth first search can be performed to check

the state space so that no reachable state violates the security specifications.

As well as testing secrecy specifications, a correspondence property is also

verified: if an event X occurs then an event Y must have occurred in the past.

This is a 1:1 mapping. A counter is used to keep track of the difference between

the number of Y and X events. If this counter becomes negative, i.e. there have

been more X events than Y, then the correspondence property has been violated

as there is no longer a 1:1 mapping from X events to Y events.

Each participant in the protocol is modelled as a 4-tuple (N,p, / , B) where,

N 6 names is the name of the principal

p is a process somewhat like a CSP process, detailing the actions to be

performed

/ C M , the set of all messages known by the participant.

B : vars(p) > / , where vars(p) is the set of variables appearing in the

process

The global state is also made up of a 5-tuple:

(II, Ci, Cr, S s , St) where

II is the product of the individual principals and the intruder process.

35

Ci : names x names N the difference between the number of times an

initiator A has begun a protocol with B and vice versa. If this number

is negative then B has finished a run of the protocol without A having

participated.

Cr : names x names N the difference between the number of times A

has responded to B and B has finished with an initiator A. If this number

is negative then B has finished without A.

Ss C M the set of messages which are safe secrets. This consists of data

items which the intruder should never know including secret keys.

St C M the set of messages which are temporary secrets, which are gener

ated during a run of the protocol.

The model of the protocol is made up of the asynchronous composition of a

set of named, communicating processes. This is updated with a local store with

the information known at each stage of the protocol. Each principal is modelled

as one of these processes along with a sequence of actions it is to perform and

its initial knowledge. The intruder is only described by its initial knowledge and

any actions it can realistically perform.

Communications are carried out by unifying a SEND action with a r e c e iv e

action.

This method does not make use of interpreting beliefs that each message is

meant to convey nor does it require a set of rewrite rules to model how the

intruder uses other agents to generate new messages. The intruder in this model

is never described as the intruders knowledge is kept separate from the state

exploration algorithms and is built into the tool. However coding up the protocol

with this method is a tedious task and prone to error.

36

3.1.5 Mur

3.2 D irect proof m ethods

3.2.1 B A N logic - Burrows, Abadi and N eedham

A well known modal logic is BAN logic, by Burrows, Abadi and Needham [14].

A protocol is converted into BAN logic notation using a series of statements and

assumptions about the initial state, and the logic determines what the final belief

state is. BAN logic doesnt prove that a protocol is secure; it can only reason

about authentication. It is popular for its simple straight forward logic and high

level abstraction that is easy to apply and detect flaws.

The beliefs of the principals involved are stated and this set of beliefs changes

as the principals receive messages. A set of inference rules define how the set of

beliefs changes. Some statements that are used in BAN logic include:

P believes X

P sees X i.e. in a message

P once said X , either a long time before or in the current run

P has jurisdiction over X . P is an authority on X .

P and Q may properly use the shared key K.

The proof rules to reason about the beliefs can be applied to the above statements

to prove or answer questions about the protocol. Here is an example of a rule,

the nonce-verification rule:

If A believes that X could have been uttered only recently and

that B once said X .

Then A believes that B believes X .

The limitations of this method include the fact that there are no complete

semantics for the logic although this has been updated since. The concept of

38

freshness is hard to model, as it is not possible to distinguish between freshness

of creation and receipt. Despite having been widely criticised and debated, this

approach has found flaws in protocols, but is now becoming dated.

3.2.2 A A P A - Brackin

The Automatic Authentication Protocol Analyser (AAPA) by Brackin takes a se

curity protocol together with its intended security properties described in a simple

Interface Specification Language [11] and translates them into Higher Order Logic

(HOL) theories based on a HOL implementation of the BGNY (Brackins exten

sion to the GNY logic [23]) belief logic. Proofs are automatically constructed over

the BGNY logic to show whether the protocols satisfy their security properties.

This tool has been applied to a library of protocols [15] and the results re

ported in [13]. This method does not seem to be too successful at present although

changes are being made to this tool. At present AAPA is unable to analyse cer

tain algebraic properties such as the commutativity of RSA encryption, a problem

which protocol analysis tools find hard to model. Attacks where the intruder re

plays messages from the initiator in order to fool the responder into multiple

sessions are undetected as AAPA only considers single sessions.

Some protocols have been analysed and not found to have flaws whereas Clark

and Jacobs [15] have identified ones. Protocols such as the Otway-Rees, Wide

Mouthed Frog, Needham-Schroeder Public-Key and Woo and Lam Authentica

tion Protocols have been analysed and found to be falsely secure.

In total, the AAPA analyses 52 of the 53 protocols in Clark and Jacobs library

of which it identifies 9 as failed, including 3 which have not been identified and

misses at least some failures in 19 others. Many of these are due to AAPAs

failure to perform type checking as it makes overly optimistic type checking

39

assumptions. The ongoing work should correct at least 18 of them so it is hoped

these problems will be resolved in the near future.

3.2.3 Isabelle/H O L - Paulson

Paulsons method of proving properties of security protocols with induction uses

the proof tool Isabelle/HOL. This method [45] does not have the restriction of

finite state systems, as in the CSP/FDR approach, nor is it based on belief logics.

A protocol is described as a set of traces, which may involve many interleaved

runs. Security properties are proved by induction on traces. This would be too

long to carry out by hand so we are aided by Isabelle for partial automation. The

laws and proof techniques for one protocol can be used again for another.

The inductive definition lists the possible actions that an agent or system can

perform. The corresponding induction rules allows reasoning about the conse

quences of an arbitrary finite sequence of actions. There are several inductively-

defined operators:

p a rts - enumerates all components of the set of messages,

analz - models the decryption of past traffic using available keys,

syn th - models the generation of fake messages.

Each message in a protocol is modelled as an event in a trace with the form

Says A B X , describing a message where A sends message X to B. The specifi

cation defines the set of possible traces inductively.

The intruder is modelled separately in terms of analyz and synth. Algebraic

laws governing parts , analz and synth are proved by induction and are invaluable

for reasoning about a protocol. Safety properties are proved by induction over

40

the protocol. Each case considers a state of the system that might be reached by

the corresponding protocol step.

3.2.4 B olignano

Another approach by Bolignano, [8] is different from formal methods based ap

proaches as it focuses more on proof conciseness and readability than on proof

automation. This approach has already been applied in industry for the design

or verification of a few real protocols. Bolignanos work is based on making a

clear separation between modelling reliable principals and unreliable ones. This

uses action/transition systems to model the behaviour of protocols and supports

modal logic reasoning. The intruders knowledge at any time during the proto

col is based on the set of messages that has been collected so far. Secrecy and

authentication can be tested and are specified and reasoned about as invariants

of the protocol. Authentication properties are described using basic temporal

features (i.e. ordering and coherence of events).

3.2.5 Spi calculus - Abadi and Gordon

The spi calculus is an extension to the process algebra, pi calculus. It has been

designed for the description and analysis of cryptographic protocols and therefore

includes cryptographic primitives. Cryptographic operations and communication

through channels are the main ingredients of the spi calculus. Channels can be

created and passed. The scoping rules of the pi calculus guarantee that the in

truder of a protocol cannot access a channel that is not explicitly given, which

is the basis for modelling security. However, cryptographic operations that are

commonly used for implementing channels in distributed systems are not sup

ported by the pi calculus. Operations such as encryption and decryption are not

41

easy to represent. This has led to the spi calculus constructs for cryptography in

protocols. Security guarantees are expressed as equivalences between spi calculus

processes.

The paper [2], details the pi calculus along with the primitives for defining

shared-key cryptography thus becoming the spi calculus. Authenticity and se

crecy properties are specified as equivalence equations.

Pi calculus programs are systems of independent, parallel processes that syn

chronise via message-passing handshakes on named channels. The channels a

process knows determine the communication possibilities of the process.

A protocol step such as,

1. A B : {M}Kab on cab

represents a message between two agents who share a key Kab and communicate

along a public channel cab

This is written in spi calculus as:

A(M) = cab ( {M} Kab)

B = cab(rr).case x of {y}Kab in F(y)

A sends {M}Kab on channel cab to B while B listens for a message on this

channel. B then attem pts to decrypt the message using Kab; if this succeeds,

F(y) is executed. Authenticity is written as an equivalence that compares the

protocol with another protocol.

It can be seen that writing a protocol in spi calculus is a little harder than

using the informal notations common in literature. The spi calculus definitions

are more detailed, stating the messages that are sent and how the messages are

generated and checked. By being more complex in their description, the protocols

can have a finer analysis.

42

3.2.6 Strand spaces - Thayer, Herzog and G uttm an

Strand space [64, 65] analysis is a method for stating and proving correctness

properties for cryptographic protocols. A strand is a sequence of events (sends

and receives) that represent the abilities of the intruder and honest agents in a

particular protocol. A send event is represented as -fa and a receive event by a,

so a strand can be represented as (ai, a 2, . . . , a n). A node is a particular

send or receive event of a particular strand, (s, 1) for the first node on strand s,

(s, 2) for the second and so on.

A strand space is a set of strands consisting of strands for the various honest

agents together with the intruder. A bundle consists of a number of strands

hooked together where one strand sends a message and another strand receives

that same message. The strands that form a bundle represent both the intruder

and honest agents.

The intruder strands represent the possible actions that the intruder can per

form that correspond to the Dolev-Yao model. Here are a selection showing

possible intruder traces with a set of keys initially known to him.

Concatenation: {g, h, +gh), if the intruder receives a message g and h, he can

concatenate these together and send out the result.

Separation: (gh, +g, +/i), conversely if he has received a message made up of

two or more components he can split up the components and send them individ

ually.

Encryption: (~K, h, +{H}k )? by knowing a key and a message the intruder can

encrypt the message and send out the result.

Decryption: {H}k , +/*), with an encrypted message and the decrypting

key the intruder can deduce the message and sent it out in plaintext.

Strands may interact or intertwine with one another through the exchange of

43

messages. The intruder strands may intertwine with other strands and honest

agents strands may intertwine through the sending and receiving of messages.

The causal relationships between nodes of a bundle are denoted by arrows,

> and = > . The single arrow means, n i > n- n2 means that n \ , n2

occur on the same strand successively. This corresponds to the causal ordering

of actions under the control of an agent, for example following the rules of a

protocol.

Properties that the protocol are expected to uphold are reasoned about with

the set of bundles representing the protocol. The bundles form finite well-founded

sets under the causal (partial) ordering and so the standard proof techniques for

such structures can be applied. Proofs of these properties are similar to those

used in set and number theory. The proofs are quite intricate and not easy to

follow. To aid this verification, the tool Athena [60] has been developed. This

tool is a model checker and theorem prover based on the strand spaces theory.

This tool does not suffer from state-space explosion problems like other tools as

it does not give a full representation of the traces of the system.

3.2.7 Rank functions - Schneider

Schneider has formed the notion of rank functions [52] based on CSP traces.

Secrecy and authentication properties can be defined in terms of CSP traces with

a set of conditions under which particular facts become known to an intruder.

The aim is to establish that a set of facts is not available to the intruder. By

modelling the protocol with the honest agents and the intruder, the facts that

can be generated must have a particular property such that the facts that the

44

intruder should not be able to obtain do not have that property. This particular

property needs to be identified in order for the proof to hold.

The idea of rank functions is to assign a rank to each fact that can be deduced.

A rank function is defined as a function p : Fact Z which maps facts to

integers. Ideally only facts of positive rank should be found in the system and

the honest agents cannot introduce any facts of non-positive rank. The intruder

is modelled with a set of facts representing the initial knowledge (these must have

positive rank) and a set of deductions based on the b relation. This relation must

respect positive rank, that is only facts of positive rank can be generated from

sets of facts of positive rank.

The description of the intruder is independent of the protocol, so all that

is required is a check on the initial state of the intruder and a check on the

deductions made under the b relation.

The aim of this method is to show that the steps of the protocol followed by a

particular agent cannot introduce any non-positive rank facts, that is if an agent

has only accepted messages of positive rank on the receive channel, then only

messages of positive rank can be sent out on the send channel. This is defined

by the trace property, maintains positive rank.

m ain tains p o s it iv e p(tr)

3 receive.a'.b'.m! Q tr p(m) < 0

A suitable rank function will depend on the protocol being verified, since whether

a particular agent satisfies the maintains positive rank property depends on the

match between the CSP description of the agent and the rank function p.

So to summarise, no fact of non-positive rank can ever be introduced into the

system, either by the intruder or honest agents. The intruders initial knowledge

45

and those messages that can be obtained by the intruder must have positive rank.

Vra I I K p(m) > 0

((V s S * p(s) > 0) A S m) => p(m) > 0

Va 6 Agent Agenta sat maintains positive p

46

Chapter 4

Simplifying transformations

Many security protocols have been suggested, with various goals, such as estab

lishing a cryptographic key, or achieving authentication (where an agent becomes

sure of the identity of the other agent taking part in the protocol). These pro

tocols are supposed to succeed even in the presence of a malicious agent, called

an intruder; this intruder is assumed to have complete control over the commu

nications network, and so can intercept messages, and introduce new messages

into the system using information from messages that have previously been seen.

Unfortunately, a large proportion of the protocols that have been suggested do

not succeed in their stated goals!

These techniques have proved successful at analysing the protocols that have

appeared in the academic literature. Such protocols are normally small, typically

having between two and seven messages, each message having between two and

ten fields. However, most commercial protocols are considerably more compli

cated, typically containing several layers of nested encryptions, and significant

amounts of redundancy. For example, the CyberCash Main Sequence Protocol

a protocol for carrying out commercial transactions over the Internetis given

in Appendix C; this protocol contains dozens of fields, and in one place, six levels

47

of nested cryptography.

There are a number of reasons why commercial protocols are more complicated

than ones in the academic literature:

Commercial protocols contain many fields that are included for function

ality rather than security; for example, the CyberCash Protocol includes a

field representing the customers postal code.

Often messages are hashed before being signed; this hashing reduces the

amount of text transferred by the protocol, but increases the complexity of

the protocol from the point of view of analysis.

Sometimes protocols are simply over-engineered; common techniques are

to include a copy of all previous fields in each message, or to include more

encryptions than are necessary.

This extra complexity of such protocols makes analysis much more difficult:

for the model checkers, it leads to an explosion in the state space and the message

space; for those doing direct proofs, the complexity just makes the protocol harder

to understand, let alone verify it.

However, we will often have a strong feeling that much of the complexity of

such a protocol could be removed without altering its security: for example, some

of the fields and some of the nested encryption might appear to be irrelevant t