Analysing the Woo-Lam protocol using CSP and rank
functions
Siraj Shaikh and Vicky Bush
Department of Multimedia and Computing,
University of Gloucestershire Business School,
Park Campus, Cheltenham Spa, GL52 2RH, UK
Abstract. Designing security protocols is a challenging and deceptive exercise.
Even small protocols providing straightforward security goals, such as authenti-
cation, have been hard to design correctly, leading to the presence of many sub-
tle attacks. Over the years various formal approaches have emerged to analyse
security protocols making use of different formalisms. Schneider has developed
a formal approach to modeling security protocols using the process algebra
CSP. He introduces the notion of rank functions to analyse the protocols. We
demonstrate an application of this approach to the Woo-Lam protocol. We de-
scribe the protocol in detail along with an established attack on its goals. We
then describe Schneider’s rank function theorem and use it to analyse the proto-
col.
1 Introduction
Over the years various formal approaches have emerged to analyse security protocols
[8], making use of different formalisms including logic [3,11] strand spaces [12], type
theory [4], model-checking [5,7] and some hybrid techniques [6]. A main aspect of
this research is the perfect-encryption assumption that allows cryptography to be
treated as a black-box and therefore flawless; this is formalised by Dolev and Yao [1].
Schneider [10] has developed a formal approach to modeling security protocols using
CSP [2]. Schneider then proceeds to introduce the notion of rank functions to analyse
the protocols.
The purpose of this paper is to demonstrate an application of this approach to the
Woo-Lam protocol [13]. The protocol is an example of an authentication protocol
with a history of established attacks. We describe the Woo-Lam protocol in Section 2,
along with an attack in Section 2.1. We then describe Schneider’s CSP approach and
model the Woo-Lam protocol in CSP in Section 3. We introduce the rank functions
approach in relevant detail and apply the approach to the Woo-Lam protocol in Sec-
tion 4. We finally discuss our experiences of this effort to conclude the paper in Sec-
tion 5.
Shaikh S. and Bush V. (2005).
Analysing the Woo-Lam protocol using CSP and rank functions.
In Proceedings of the 3rd International Workshop on Security in Information Systems, pages 3-12
DOI: 10.5220/0002557000030012
Copyright
c
SciTePress
2 Woo-Lam protocol
Woo and Lam [13] introduce a protocol that provides one-way authentication of the
initiator of the protocol, A, to a responder, B. The protocol uses symmetric-key cryp-
tography and a trusted third-party server, with whom A and B share long-term sym-
metric keys.
(1) A B : A
(2) B A : N
B
(3) A B : {N
B
}
KAS
(4) B S : {A,{N
B
}
KAS
}
KBS
(5) S B : {N
B
}
KBS
Fig. 1. Woo-Lam protocol
The protocol is shown in Fig. 1 above where {m}
k
represents message m encrypted
under key k and “,” represents the concatenation operator. The keys K
AS
and K
BS
rep-
resent the long-term keys that A and B share with the trusted server S. The protocol
goal is to authenticate A to B by using a fresh and unpredictable nonce, N
B
, produced
by B.
A starts the protocol by sending it’s identity to B. B replies by sending a freshly
generated nonce N
B
. A encrypts N
B
with key K
AS
and sends it back to B. B concatenates
A’s reply with the identity of A, encrypts it with key K
BS
and sends it to the server S. S
sends out N
B
back to B encrypted under K
BS
. B compares the nonce it receives from S
with the one it sent out to A. If they match, then B is guaranteed that the initiator of the
protocol is in fact the principal claimed in the first step of the protocol.
2.1 An attack on the Woo-Lam protocol
The Woo-Lam protocol has been to shown to be susceptible to a few attacks [14], one
of which is shown in Fig. 2 below.
(1.1) I(A) B : A
(1.2) B I(A) : N
B
(1.3) I(A) B : X
(2.1) I B : I
(2.2) B I : N
B
(2.3) I B : {N
B
}
KIS
(1.4) B S : {A,X}
KBS
(2.4) B S : {I,{N
B
}
KIS
}
KBS
(1.5) S B : {N
B
}
KBS
Fig. 2. An attack on the Woo-Lam protocol
The attack shows two simultaneous inbound authentication attempts initiated by an
intruder I, where I is also considered as any other regular participant. I pretends to be
A in one (1.x) and retains its own identity I for the other (2.x). I obtains nonces from B
4
for both runs and encrypts the nonce N
B
intended for A with its own server key and
returns it to B, retaining its original identity. When the nonce is returned by the server,
it leads B to believe that it has authenticated A, whereas A has not even participated in
either of the runs. The attack is complete.
The attack shown in Fig. 2 demonstrates the difficulty in designing such protocols
and emphasises the need for a formal and rigorous analysis of these protocols.
3 Schneider’s CSP approach
In order to deal with the problem highlighted in the previous section, Schneider pre-
sents a formal framework that uses the process algebra CSP to model protocols. We
present Schneider’s CSP approach in detail, describing the relevant syntax for CSP
and its trace semantics in Section 3.1. In Section 3.2 we model the participants in the
Woo-Lam protocol as CSP processes and specify a network composed of these proc-
esses. We then present a trace specification that the network needs to satisfy for the
protocol to hold correct. Finally we adopt a proof strategy to verify this network.
While we discuss this notation in detail relevant to our usage in this paper, we take
for granted the reader’s basic knowledge of CSP and its use by Schneider [10] to
model security protocols; in-depth treatments of CSP are provided by Hoare [2] and,
more relevantly, Ryan, et al [8].
3.1 CSP Events and Processes
A CSP system is modelled in terms of processes and events that these processes can
perform, which are essentially instances of communication, usually involving a chan-
nel and some data value. Events may be atomic in structure or may consist of distinct
components. The CSP expression a P describes a process P with event a in the
interface of P. The process is initially able to perform a and then behaves as P. The
process STOP is the simplest CSP process that can be described; it has no event tran-
sitions and does not engage in any events. A choice operator
provides the option for
running either of the two processes, P and Q for example, when put together as P
Q
whereas P and Q running in parallel would be written as P
A
||
Q where both P and Q
have to synchronise on events in a set of events A. If P or Q were to perform any
events that are not in A then they can do so independently without the need for any
synchronisation. Another form of a parallel composition could be P Æ Æ Æ Q where P and
Q do not need to interact with each other at all, known as interleaving. A process
could be restricted on certain events, such as P
A
||
STOP where all of P’s occurrences
of events from A are restricted; P would not be able to perform any events in A.
For the purpose of communication, a process may have channels using which it
communicates, accepts inputs on or produces output on. The expression c!v P
describes a process that will output the value of v on the channel c and then behave as
5
P. A process P accepting an input x on the channel c is described as c?x P(x) where
the behaviour of P after the input is described as P(x), determined by the input. To
express message transmission and reception, Schneider [10] introduces two new chan-
nels, send and receive, which are public channels that all processes use to send and
receive messages on. The events are structured as send.i.j.m where a message m is sent
by source i to destination j on the channel send while receive.j.i.m represents a mes-
sage m being received by j from a source i on the channel receive.
3.1.1 Trace Semantics
The trace semantics in CSP allows us to capture the sequence of events performed by
a communicating process as a trace and then use the trace to model the behaviour of
the process. A trace tr of all events possibly performed by a process P could be ex-
pressed as tr = traces(P). An example of a trace could be a, bÒ where event a is per-
formed followed by event b, whereas „Ò is an empty trace.
A concatenation of two traces tr
1
and tr
2
would be written as tr
1
^ tr
2
, which is the
sequence of evens in tr
1
followed by the sequence of events in tr
2
. A trace tr could be
of the form aÒ ^ tr where event a is followed by tr, the remainder of the trace. A
subsequence of tr could be expressed as tr ¯ tr where tr is the prefix of tr. Traces
also provide a projection operation where the tr á A is the maximal subsequence of tr,
all of whose events are drawn from a set of events A.
Trace semantics are used by Schneider [9] to specify security properties for proto-
cols as trace specifications. These are essentially defined as predicates on a trace of a
process. This is done by defining a predicate on traces and checking whether a process
satisfies the trace specification for its every trace. For a process P and a predicate
S(tr) on a trace tr
P sat S(tr) tr traces(P) S(tr)
signifies that P satisfies S(tr) if S(tr) holds for every trace of P.
3.2 Modelling the network
We now model the Woo-Lam protocol in CSP as a network and specify the authenti-
cation property for this network as a trace specification. We then describe the proof
strategy to verify this network for the given trace specification.
While modelling the different processes of a protocol, Schneider [8] takes advan-
tage of the extensibility of CSP to introduce additional control events known as sig-
nals. These signal events are then used in trace specifications to express the authenti-
cation goals of a protocol. We model the three participant roles in the Woo-Lam pro-
tocol in CSP below
Initiator
A
=
b
send.A.b.A
receive.A.b.n
Running.A.b.n
send.A.b.{n}
KAS
Stop
Server = receive.S.b.{a,{n}
Kas
}
Kbs
send.S.b.{n}
Kbs
Stop
Responder
B
(n
b
) = receive.B.a.a
send.B.a.n
b
receive.B.a.{n
b
}
Kas
send.B.s.{a,{n
b
}
Kas
}
KBS
receive.B.s.{n
b
}
KBS
Commit.B.a.n
b
Stop
6
In the model above, we specify a Running.A.b.n signal and introduce it in A’s run,
indicating that A is aware of its involvement in a run with b and the nonce n being
used as part of this run. We specify a corresponding Commit.B.a.n
b
signal on B’s
behalf indicating that B has completed the protocol run and authenticated a using
nonce n
b
. The Commit.B.a.n
b
signal is placed at the end of Bs run as it is only when B
receives the final message from S it can be assured of A’s involvement in the run. The
entire network is composed of the above processes along with an Intruder process that
is assumed to be in complete control of the network. In order to model it as such, we
specify our NET as where Initiator
A
, Responder
B
and Server all communicate with
each other only through an Intruder process and consider a specific run of the protocol
between Initiator
A
and Responder
B
using the nonce N
B
NET = (Initiator
A
Æ Æ Æ Responder
B
(N
B
) Æ Æ Æ Server) Æ Æ Intruder
We show this specific run of the protocol with appropriate signals in Fig. 3 below.
Fig. 3. A specific run of the Woo-Lam protocol involving A and B using nonce N
B
Proof strategy. We now specify a trace specification that expresses the authentication
property needed to be satisfied by this NET. We use the signal events for the particu-
lar run shown in Fig. 3 and consider trace tr to be some trace of NET then
tr^Commit.B.A.N
B
Ò ¯ tr Running.A.B.N
B
in tr
In other words, if Commit.B.A.N
B
is in tr then so is Running.A.B.N
B
, preceding it. If
the NET could be proved to satisfy this specification, then the protocol is proved
correct for the property of authentication. In order to prove that the NET meets the
trace specification, we restrict NET on the event Running.A.B.N
B
and check the result-
ing NET for the occurrence of the event Commit.B.A.N
B
. The restricted NET should
not allow Commit.B.A.N
B
to occur in its trace tr
NET
B
R
unning.A.B.N
||
Stop sat tr á Commit.B.A.N
B
= „Ò
Running.A.B.N
B
Commit.B.A.N
B
Initiator
A
Responder
B
(N
B
) Server
{A,{N
B
}
KAS
}
KBS
N
B
{N
B
}
KAS
{N
B
}
KBS
A
7
4 Analysing the Woo-Lam
In the previous section, we have built a CSP system along with a trace specification
that the system needs to satisfy. To verify the system for such a specification, Schnei-
der introduces the notion of a rank function [10]. We introduce the idea along with the
central rank function theorem [10] in Section 4.1. In Section 4.2, we construct a rank
function for the Woo-Lam protocol and evaluate the different conditions provided in
the theorem to judge the correctness of the protocol.
4.1 Rank functions
Consider the set of participant identities on the network to be U, the set of nonces
used by the participants in protocol runs as N and a set of encryption keys used as K.
The set of all such atoms is A, where the atoms are defined as A = U U N U K. We
consider a message space M to contain all the messages and signals that may appear
during a protocol’s execution, such that m A m M.
Schneider [10] defines a rank function ρ to map events and messages to integers ρ:
M
fZ. The message space is then divided into two parts where
M
p-
= {m M | ρ(m) ¯ 0} M
ρ+
= {m M | ρ(m) > 0}
The purpose of this partition of the message space is to characterise those messages
that the intruder might get hold of without compromising the protocol – assigned a
positive rank – and those messages that the enemy should never get hold of – assigned
a non-positive rank. It is desirable for a process never to transmit a message of non-
positive rank. For a certain process P to maintain positive rank, it is understood that it
will never transmit a message with a non-positive rank unless it has previously re-
ceived a message with a non-positive rank. The process P is said to maintain positive
ρ, if
P sat receive. U. U. M
p-
precedes send. U. U. M
p-
The process P satisfies the condition that if it transmits a message of non-positive
rank (send. U. U. M
p-
represents the transmission of a non-positive message, M
p-
from and to any participant U) then it has to have received a message of non-positive
rank earlier, represented by receive. U. U. M
p-
. It is not important who the message
is received from or is sent to.
Schneider also [10] introduces a generates ‘H’ relation to simulate cryptographic
functionality on behalf of an attacker. We use the relation to model encryption and
decryption of messages or simpler transformations such as concatenation of messages.
This relation, however, can be extended to model various cryptographic operations,
the details of which are available in [10]. A rank function theorem [10] is then used to
analyse such a rank function and verify that a trace specification is always met in all
possible runs of the protocol. We consider tr to be some trace of the NET as defined
in Section 3.2.
8
Rank function theorem. If, for sets R and T, there is a rank function ρ: M f Z satis-
fying
R1) m IK ρ(m) > 0
R2) (( s S ρ(s) > 0) S H m) ρ(m) > 0
R3) t T ρ(t) ¯ 0
R4) i U User
i
||
R
Stop sat maintain positive ρ
Then NET
||
R
Stop sat tr á T = „Ò
The theorem, the proof of which is available in [10], essentially states that if the
rank function, and therefore the underlying NET, satisfies the four properties, then no
secret messages of non-positive rank, denoted by set T, can be produced. In particular,
the Intruder should not be able to generate any illegal messages from the messages it
knows at the beginning of the protocol, and denoted by the set Initial Knowledge, IK,
nor from the messages it sees during the protocol execution. Also, honest participants
should not be able to generate any illegal messages unless they are sent one, that is,
they maintain positive ρ while being restricted on events in set R. The actual verifica-
tion of the theorem conditions is performed manually for every rank function con-
structed for a protocol. We now use this approach to analyse the Woo-Lam protocol.
4.2 Constructing the rank function
We identify the ranks on the message space for our NET and construct the rank func-
tion shown in Fig. 4 below. The rank function we have constructed assigns all user
identities in the set U a positive rank. The identity of all users is assumed to be known
to the Intruder and therefore could be impersonated by the intruder. All the nonces in
the set N, including N
B
, are assigned a positive rank. B sends out N
B
in cleartext and
therefore an Intruder can get hold of the nonce without further ado. The two shared
keys used in the protocol, K
AS
and K
BS
, are both assigned a non-positive rank as they
are supposed to be private to A and B. As the NET is restricted on the event Run-
ning.A.B.N
B
, the three messages (see Fig. 3) that follow this event, {N
B
}
KAS
,
{A,{N
B
}
KAS
}
KBS
and {N
B
}
KBS
, should not appear in the restricted NET either. We as-
sign these three messages a non-positive rank along with signal event Commit.B.A.N
B
,
which logically follows these three messages.
ρ(U) = 1 (including A, B and S)
0 if k = K
AS
ρ(K) = or k = K
BS
1 otherwise
ρ(N) = 1 (including N
B
)
0 if {m}
k
= {N
B
}
KAS
or {m}
k
= {A,{N
B
}
KAS
}
KBS
ρ({m}
k
) = or {m}
k
= {N
B
}
KBS
1 otherwise
ρ(Running.A.B.N
B
) = 1 ρ(Commit.B.A.N
B
) = 0
Fig. 4. A rank function for the Woo-Lam protocol
9
Recall that the rank function theorem is defined in terms of general sets R and T.
For our analysis, we assign the single event Running.A.B.N
B
to set R and assign the
single event Commit.B.A.N
B
to set T. This corresponds to the proof strategy described
in Section 3.2, where we need to check for the occurrence of Commit.B.A.N
B
in a
NET restricted on Running.A.B.N
B
. We now consider each of the conditions of the
rank function theorem and check whether our rank function satisfies them.
R1) m IK ρ(m) > 0
The set IK contains all the agent identities and a key K
IS
shared between I and S. There
is nothing in this set that is of non-positive rank. The condition is deemed satisfied.
R2) (( s S ρ(s) > 0) S H m) ρ(m) > 0
This conditions checks whether a message of non-positive rank can be generated un-
der the ‘H’ relation from a set of messages of positive rank. None of the messages
identified as of positive rank, shown in Fig. 4, let the Intruder generate any messages
that are of non-positive rank. The three messages of non-positive rank, {N
B
}
KAS
,
{A,{N
B
}
KAS
}
KBS
and {N
B
}
KBS
, are encrypted under keys K
AS
and K
BS
both of which are
of non-positive rank. This prevents the Intruder from generating these messages as the
Intruder has no way of acquiring these two keys. The condition is deemed satisfied.
R3) t T ρ(t) ¯ 0
This condition requires none of the events in T to be of positive rank. The only event
in set T is the signal event Commit.B.A.N
B
of non-positive rank. This condition is
deemed satisfied.
R4) i U User
i
||
R
Stop sat maintain positive ρ
For this condition to be satisfied every process in the NET needs to maintain positive
ρ while being restricted on the events in set R, where R = {Running.A.B.N
B
}. We
consider processes Initiator
A
, Responder
B
and Server, restrict them on Run-
ning.A.B.N
B
and check whether they maintain positive ρ. Since only Initiator
A
can
perform Running.A.B.N
B
, the other two processes remain unaffected. The restriction
on Initiator
A
simplifies to
Initiator
A
B
R
unning.A.B.N
||
Stop =
b
send.A.b.A
receive.A.b.n
if b = B n = N
B
then Stop
else Running.A.b.n
send.A.b.{n}
KAS
Stop
In the choice operator
b
, b indicates the other participants that Initiator
A
may
communicate with. If participant b = B and the nonce n = N
B
then we instruct Initia-
tor
A
to Stop. Any other participant instead of B or even a different nonce then N
B
would allow Initiator
A
to continue as normal.
10
Upon inspection, we observe that Initiator
A
B
R
unning.A.B.N
||
Stop fails to maintain
positive ρ. In terms of protocol runs, consider a run where A initiates the protocol with
a participant other than B (and I intercepts) as shown in Fig. 5 below
(1) A I(C) : A
(2) I(C) A : N
B
(3) A I(C) : {N
B
}
KAS
Fig. 5. A possible run of the protocol
In this case, the process Initiator
A
B
R
unning.A.B.N
||
Stop behaves as follows
send.A.C.A
receive.A.C.N
B
if b = B n
b
= N
B
then Stop
else Running.A.C.N
B
send.A.C.{N
B
}
KAS
Stop
A outputs the message {N
B
}
KAS
while communicating with another participant C.
The message {N
B
}
KAS
is of non-positive rank as shown in Fig 4. This shows that A
does not maintain positive ρ despite the restriction on it and the protocol, therefore,
fails to meet the trace specification presented in Section 3.2. The theorem has been
successful in finding a flaw in the Woo-Lam protocol, the existence of which we al-
ready demonstrated earlier in Section 2. Note that the failure of a rank function to
satisfy the conditions of the theorem signifies a flaw in the protocol but it may not
always be possible to construct an attack. It does, however, provide an insight into the
workings of a protocol, which is often enough to lead to the discovery of an attack.
5 Conclusion
While this approach provides a formally meticulous analysis, the process of identify-
ing a rank function is non-trivial. Once a rank function is constructed, however, it
gives confidence in the soundness of the protocol design. We have applied this theo-
rem to the Woo-Lam protocol to expose any flaws in the design and have managed to
identify the attacks discussed earlier successfully.
We recommend this approach for thorough investigation of similar protocols. The
process of finding a rank function requires intuitive understanding of such protocols
and focuses attention on relevant design aspects of these protocols.
11
References
1. D. Dolev and A. C. Yao, “On the security of public key protocols”, IEEE Transactions on
Information Theory, 29(2), March 1983, pp. 198-208
2. C. A. R Hoare, Communicating Sequential Processes, Prentice-Hall International, 1985
3. L. Gong, R. Needham and R. Yahalom, “Reasoning about Belief in Cryptographic Proto-
cols”, In IEEE Symposium on Research in Security and Privacy, IEEE Computer Society
Press, May 1990, pp. 234–248
4. A. D. Gordon and A. Jeffrey, “Authenticity by typing for security protocols” In 14th IEEE
Computer Security Foundations Workshop, 2001, pp. 145-159
5. G. Lowe, “Breaking and Fixing the Needham-Schroeder public-key protocol using FDR”,
Proceedings of TACAS, LNCS 1055, 1996, Springer-Verlag, pp. 147-166
6. C. Meadows “The NRL Protocol Analyzer: An overview”, Journal of Logic Programming,
26(2), 1996, pp. 113-131
7. J. C. Mitchell, M. Mitchell and U. Stern, “Automated analysis of cryptographic protocols
using Murϕ”, In IEEE Symposium on Security and Privacy, IEEE Computer Society Press,
1997, pp. 141-151
8. P. Ryan, S. Schneider, M. Goldsmith, G. Lowe and B. Roscoe, B. Modelling and Analysis
of Security Protocols. Addison-Wesley, 2001
9. S. Schneider, “Security Properties and CSP”, In IEEE Symposium Research in Security and
Privacy, Oakland, IEEE Computer Society Press, 1996
10. S. Schneider, “Verifying Authentication Protocols in CSP”, IEEE Transactions on Soft-
ware Engineering, Volume 24, No. 9, IEEE Computer Society Press, September 1998, pp.
741-758
11. P. F. Syverson and P. C. van Oorschot, “On unifying some cryptographic protocol logics”,
In IEEE Symposium on Research in Security and Privacy, IEEE Computer Society Press,
May 1994, pp. 14-28
12. F. J. Thayer Fábrega, J. C. Herzog and J. D. Guttman, “Strand spaces: Why is a security
protocol correct?”, In IEEE Symposium Research in Security and Privacy, IEEE Computer
Society Press, May 1998, pp. 24-34
13. T.Y.C. Woo and S. S. Lam, “Authentication for Distributed Systems”, Computer, 25(1),
January 1992, pp. 39-52
14. T.Y.C. Woo and S. S. Lam, “A lesson on Authenticated Protocol design”, Operating Sys-
tems Review, 28(3), 1994, pp. 24-37
12