Formal Models PDF

FORMAL MODELS AND TECHNIQUES FOR
ANALYZING SECURITY PROTOCOLS

ISSN 1871-6431 (print)
ISSN 1879-8101 (online)
Cryptology and Information Security Series
The Cryptology & Information Security Series (CISS) presents the latest research results in the
theory and practice, analysis and design, implementation, application and experience of
cryptology and information security techniques. It covers all aspects of cryptology and
information security for an audience of information security researchers with specialized
technical backgrounds.
Coordinating Series Editors: Raphael C.-W. Phan and Jianying Zhou
Series editors
Feng Bao, Institute for Infocomm Research, Singapore
Kefei Chen, Shanghai Jiaotong University, China
Robert Deng, SMU, Singapore
Yevgeniy Dodis, New York University, USA
Dieter Gollmann, TU Hamburg-Harburg, Germany
Markus Jakobsson, Indiana University, USA
Marc Joye, Thomson R&D, France
Javier Lopez, University of Malaga, Spain
Nasir Memon, Polytech University, USA
Chris Mitchell, RHUL, United Kingdom
David Naccache, cole Normale Suprieure, France
Gregory Neven, IBM Research, Switzerland
Phong Nguyen, CNRS / cole Normale Suprieure, France
Andrew Odlyzko, University of Minnesota, USA
Adam Young, MITRE Corporation, USA
Moti Yung, Columbia University, USA
Volume 5
Recently published in this series
Vol. 4. Y. Li and J. Zhou (Eds.), Radio Frequency Identification System Security
RFIDsec10 Asia Workshop Proceedings
Vol. 3. C. Czosseck and K. Geers (Eds.), The Virtual Battlefield: Perspectives on Cyber
Warfare
Vol. 2. M. Joye and G. Neven (Eds.), Identity-Based Cryptography
Vol. 1. J. Lopez and J. Zhou (Eds.), Wireless Sensor Network Security

Formal Models and Techniques for
Analyzing Security Protocols

Edited by
Vronique Cortier
CNRS
and
Steve Kremer
INRIA

Amsterdam Berlin Tokyo Washington, DC
2011 The authors and IOS Press.
All rights reserved. No part of this book may be reproduced, stored in a retrieval system,
or transmitted, in any form or by any means, without prior written permission from the publisher.
ISBN 978-1-60750-713-0 (print)
ISBN 978-1-60750-714-7 (online)
Library of Congress Control Number: 2011923591
Publisher
IOS Press BV
Nieuwe Hemweg 6B
1013 BG Amsterdam
The Netherlands
fax: +31 20 687 0019
e-mail: order@iospress.nl
Distributor in the USA and Canada
IOS Press, Inc.
4502 Rachael Manor Drive
Fairfax, VA 22032
USA
fax: +1 703 323 3668
e-mail: iosbooks@iospress.com
LEGAL NOTICE
The publisher is not responsible for the use which might be made of the following information.
PRINTED IN THE NETHERLANDS
Preface
Security protocols are small distributed programs which aim to achieve security proper-
ties such as confidentiality, authentication, anonymity, etc. Nowadays, security proto-
cols are omnipresent in our daily lives: home-banking, electronic commerce, mobile
phones, etc. However, because these protocols are generally implemented on poten-
tially insecure networks (e.g. the Internet) they are extremely difficult to devise. Using
Roger Needhams words Security protocols are three line programs that people still
manage to get wrong. Based on the seminal work of Dolev and Yao, symbolic meth-
ods for analyzing such protocols have been in development for about 25 years. The
main components of these models are the perfect cryptography assumption and an un-
bounded non-deterministic adversary that has complete control of the network.
The field of symbolic analysis of security protocols has seen significant advances
during the last few years. We now have a better understanding of decidability and com-
plexity questions and models with solid theoretical foundations have been developed
together with proof techniques. Automated tools have also been designed and success-
fully applied to numerous protocols, including industrial protocols, for the provision of
security or the discovery of attacks, and models have been extended with algebraic
properties in order to weaken the perfect cryptography assumption. Recently, even
computational soundness results towards cryptographic models have been achieved.
However, the field was still missing a book which summarized the state-of-the-art
of these advances. While we certainly do not pretend to give a complete overview of
the field, which would be impossible in a single book, nevertheless, we believe that we
have covered a representative sample of the ongoing work in this field, which is still
very active. This book contains an introduction and 10 tutorial-like chapters on selected
topics, each written by a leading expert in the field of formal analysis of security proto-
cols. We are extremely grateful to all the authors for their hard work and effort in pre-
paring these chapters.
January 2011
Vronique Cortier and Steve Kremer
Formal Models and Techniques for Analyzing Security Protocols
V. Cortier and S. Kremer (Eds.)
IOS Press, 2011
2011 The authors and IOS Press. All rights reserved.
v
This page intentionally left blank

Contents
Preface v
Introduction 1
Verifying a Bounded Number of Sessions and Its Complexity 13
Michael Rusinowitch and Mathieu Turuani
Constraint Solving Techniques and Enriching the Model with Equational
Theories 35
Hubert Comon-Lundh, Stphanie Delaune and Jonathan K. Millen
Analysing Security Protocols Using CSP 62
Gavin Lowe
Using Horn Clauses for Analyzing Security Protocols 86
Bruno Blanchet
Applied pi Calculus 112
Mark D. Ryan and Ben Smyth
Types for Security Protocols 143
Riccardo Focardi and Matteo Maffei
Protocol Composition Logic 182
Anupam Datta, John C. Mitchell, Arnab Roy and Stephan Hyeonjun Stiller
Shapes: Surveying Crypto Protocol Runs 222
Joshua D. Guttman
Security Analysis Using Rank Functions in CSP 258
Steve Schneider
Computational Soundness The Case of Diffie-Hellman Keys 277
Emmanuel Bresson, Yassine Lakhnech, Laurent Mazar and
Bogdan Warinschi
Author Index 303

vii
This page intentionally left blank
Introduction
Vronique CORTIER
a
and Steve KREMER
b
a
LORIA, CNRS
b
LSV, ENS Cachan & CNRS & INRIA
Formal methods have shown their interest when developing critical systems, where
safety or security is important. This is particularly true in the eld of security protocols.
Such protocols aim at securing communications over a public network. Small aws in
the development of such systems may cause important economical damages. Examples
of security protocols include the Transport Layer Security (TLS) protocol and its prede-
cessor, the Secure Sockets Layer (SSL). These protocols are typically used for guaran-
teeing a secure connection to a web site in particular for secure payment over the Inter-
net. Most web browsers display a small lock to indicate that you are executing a secure
session using one of these protocols. Another emergent application of security protocol
is electronic voting. For instance, in the 2007 national elections in Estonia the govern-
ment offered the possibility to vote via the Internet. The development of such proto-
cols is error-prone and aws are regularly discovered. For example, the SAML 2.0 Web
Browser Single Sign-On authentication system developed by Google has recently been
attacked. The Single Sign-On protocol allows a user to identify himself only once and
then access to various applications (such as Gmail or Google calendar). While designing
a formal model of this protocol, Armando et al [ACC
+
08] discovered that a dishonest
service provider could actually impersonate any of its users at another service provider.
This aw has been corrected since. Those examples show the need of precise security
guarantees when designing protocols. Moreover, the relatively small size of security pro-
tocols makes the use of formal verication reasonable.
The use of symbolic methods for formally analyzing security protocols goes back
to the seminal paper of Dolev and Yao [DY81]. While there is not a unique symbolic
model, the so-called Dolev-Yao models generally share the following ingredients: the ad-
versary is computationally unbounded and has complete control of the network while
cryptography is assumed to be perfect. For example, the adversary is not allowed to per-
form cryptanalysis or to decrypt a ciphertext without knowing the decryption key. Find-
ing collisions or guessing fresh nonces is also supposed to be impossible, etc. Most early
tools [Mil84,Low96b] and techniques [BAN89] were aiming above all at nding bugs in
protocols. Many errors have indeed been identied using formal methods, demonstrat-
ing their usefulness. At the end of the 90s more foundational questions were investi-
gated: the general undecidability results for automated verication of security protocols
have been rened and decidable classes of protocols and restrictions yielding decidabil-
ity were identied together with their complexity [DLM04,CC01,RT01]. At about the
same time, models [THG99,AF01] and tool support [Pau98,Bla01] were also developed
for proving protocols correct rather than only nding aws. When the focus shifted from
nding aws to proving security protocols correct, a natural question was raised about
the guarantees provided in these models relying on the so-called perfect cryptography
IOS Press, 2011
doi:10.3233/978-1-60750-714-7-1
1
assumption. A lot of efforts were performed to relax this assumption by introducing al-
gebraic properties of cryptographic primitives (see [CDL06] for a survey) or proving
that symbolic proofs can be transferred to more realistic, computational models starting
with [AR00]. Investigating these foundational questions not only sharpened our under-
standing of the underlying difculties of security protocol verication but also enabled
the development of efcient tools such as among others the AVISPAplatform[ABB
+
05],
the ProVerif [Bla01] and the Scyther [Cre08] tools. In recent years there have also been
works on widening the scope of the class of security protocols and properties that can
be analyzed, going beyond the classical protocols for guaranteeing authentication and
condentiality. For instance the ProVerif tool allows to check the resistance against dic-
tionary attacks [Bla04], as well as indistinguishability properties [BAF05]. Moreover,
complex properties of contract signing [KR02,CKS01,KK05] and electronic voting pro-
tocols [DKR09,KT09,BHM08a] have been formalized.
The theory as well as the tools for formal analysis have now reached a state of ma-
turity where they can be used on practical protocols. However, there is not one technique
or tool which combines all benets. There exist today many formalisms and approaches
which have each their own benets. The aim of this book is to give an overview of the
state of the art of the eld by showing some of the most inuential developments in this
eld.
1. Some examples of security protocols
Security protocols aim at different goals such as key distribution, message integrity, au-
thentication, non repudiation or voting. They all make use of cryptographic primitives as
a key ingredient to achieve security. Popular cryptographic primitives are symmetric and
asymmetric encryption, signatures, hash function and MACs for example. For the most
common primitives, we introduce hereafter notations that will be used throughout all the
chapters of this book. In particular, the symmetric encryption of a message m with key
k is denoted by {|m|}
s
k
. Similarly, we write {|m|}
a
pk
for the asymmetric encryption of m
with the public key pk and [m]
sk
for the digital signature of m with the secret key sk.
m
1
, m
2
denotes the pairing of the two messages m
1
and m
2
.
To illustrate the different results described in this book, we will use similar exam-
ples of protocols. This should allow the reader to compare the differences between each
approach.
1.1. Handshake protocol
A rst example of protocol is a naive handshake protocol between A and B, illus-
trated in Figure 1(a). This protocol has been proposed for illustration purposes by
Blanchet [Bla08]. The aim of the protocol is that A and B share a secret s at the end. Par-
ticipant A generates a fresh session key k, signs it with his secret key sk(A) and encrypts
it using Bs public key pk(B). When B receives this message he decrypts it using his
secret key, veries the digital signature and extracts the session key k. B uses this key to
symmetrically encrypt the secret s. The rationale is that when B receives this message he
should be the only one able to know its content (because of the asymmetric encryption).
Moreover, the digital signature should ensure that A is the originator of the message.
V. Cortier and S. Kremer / Introduction 2
A B
[k]
sk(A)
a
pk(B)
{|s|}
s
k
(a) (Flawed) handshake protocol
A C B
[k]
sk(A)
a
pk(C)
[k]
sk(A)
a
pk(B)
{|s|}
s
k
(b) Man in the middle attack
A B
[A, B, k]
sk(A)
a
pk(B)
{|s|}
s
k
(c) Corrected handshake protocol
Figure 1. Handshake protocol
However, this protocol is vulnerable to a man in the middle attack described in Fig-
ure 1(b). If A starts a session with a dishonest participant C then C is able to impersonate
A in a session he starts with B. At the end B believes that he shares the secret s with A
while he actually shares s with C.
The protocol can be easily corrected by adding the identities of the intended partici-
pants as depicted in Figure 1(c).
1.2. Needham-Schroeder public key protocol
A famous example of a protocol is the Needham-Schroeder public key (NSPK) protocol.
It was one of the rst protocols that was discovered to be awed using formal meth-
ods [Low96a]. The protocol is depicted in Figure 2(a). The protocol aims at achieving
mutual authentication while only using asymmetric encryption. N
A
and N
B
represent
nonces, i.e. random numbers freshly generated by A, respectively B. The rationale of
the protocol is that when A receives the second message it must originate from B as it
contains the fresh nonce N
A
which could only be extracted by B from the rst message
(due to the encryption of the rst message with Bs public key). Similarly, freshness of
the nonce N
B
should convince B that the third message originates from A.
A B
{|N
A
, A|}
a
pk(B)
{|N
A
, N
B
|}
a
pk(A)
{|N
B
|}
a
pk(B)
(a) NSPK protocol
A C B
{|N
A
, A|}
a
pk(C)
{|N
A
, C|}
a
pk(B)
{|N
A
, N
B
|}
a
pk(A)
{|N
A
, N
B
|}
a
pk(A)
{|N
B
|}
a
pk(C)
{|N
B
|}
a
pk(B)
(b) Man in the middle attack
Figure 2. Needham Schroeder Public Key protocol
However, similarly to the handshake protocol it is possible to mount a man in the
middle attack if A initiates a session with a dishonest participant C. In that case C can
successfully authenticate to B masquerading as A. Moreover C learns the a priori secret
nonces N
A
and N
B
. The attack is described in Figure 2(b). Simply adding the sender
identity in the second message, i.e. resulting in the message {|N
A
, N
B
, B|}
a
pk(A)
, xes
the protocol.
2. Formal models
One of the main advantages of formal methods is to provide a clear, well-dened math-
ematical model that allows to reason about the capacity of an attacker and to precisely
state the security guarantees achieved by a protocol in the given model. A large variety
of models have been proposed so far, proposing different trade-offs between expressivity
and the possibility to automate proofs.
While there exist a great variety of formal models, all of them have in common the
use of a term algebra for describing the messages exchanged during protocol execution.
Intuitively, a term algebra allows to model the structure of the messages, abstracting
away from the underlying cryptographic details of each primitive.
2.1. Term algebra
A term algebra is built over a set of variables and a signature, that is, a set of function
symbols given with their arity. A typical signature is = {{|_|}
s
_
, _, _} where the func-
x y
{|x|}
s
y
{|x|}
s
y
y
x
x y
x, y
x, y
x
x, y
y
Figure 3. Dolev-Yao deduction system.
tion symbols are of arity 2 and model symmetric encryption and concatenation respec-
tively.
The intruder capacities are then often represented using a deduction system. The
classical deduction system (often referred to as the Dolev-Yao system) for concatenation
and (symmetric) encryption is given by the ve rules of Figure 3.
The exact term algebra varies from one model to the other.
1. Some primitives may be added such as asymmetric encryption (denoted by {|_|}
a
_
)
signatures (denoted by [_]
_
) or hash functions (denoted by h(_)).
2. To reect the probabilistic nature of encryption, a third argument may be added
when modelling encryption: the same message m encrypted at two distinct time
with the same key k does not yield the same cipher-text. The encryption of m by
k is then modeled by the term {|m|}
s
k,r
where r represents the randomness used by
the encryption algorithm.
3. A last important difference that is introduced in some models is the use of explicit
destructors. Most often, the ability to encrypt and decrypt messages is modeled
by a deduction system like the one presented in Figure 3. An alternative approach
consists in explicitly introducing a functional symbol dec for decryption together
with the equation
dec({|x|}
s
y
, y) = x.
These two ways of modeling encryption are similar but not equivalent. For ex-
ample, Millen [Mil03] has shown that some attacks can be detected only when
destructors are explicitly represented. One of the advantages of using equa-
tional theories is to reect in a natural way the properties of the underlying
primitives. Indeed destructors correspond to functions that are actually avail-
able to an attacker. Many complex cryptographic primitives such as blind signa-
tures, re-encryption [DKR09], Exclusive Or, Dife-Hellman exponentiation and
non-interactive zero-knowledge proofs [BHM08b] have been modeled by these
means.
Different term algebra will be discussed throughout the chapters of this book.
2.2. A variety of formal models
Several symbolic models have been proposed for cryptographic protocols. A unied
model would enable better comparisons between each result but such a unied model
does not exist currently. The reason for having several popular symbolic models prob-
ably comes from the fact that symbolic models have to achieve two antagonistic goals.
On the one hand, models have to be as ne grained and expressive as possible in order
to better reect protocol behaviors. One the other hand, models have to remain relatively
simple in order to allow the design of (automatic) decision procedures.
Without aiming at an exhaustive list we mention below several symbolic models in
order to illustrate the kind of techniques and frameworks that have been used for security
protocol verication. In this book most of these models will be described in more details.
Early models. One of the rst symbolic models dedicated to security protocols has
been developed by Dolev et al. [DY81,DEK83]. Protocols are described by rewrite rules
on words (describing a sequence of encryptions and decryptions). A word s is secret if
it is not reachable by rewriting. Merritt et al. [DLM82,Mer83] have developed during
the same period of time a model where messages are also represented by words. These
models are however not expressive enough to reect primitives such as concatenation
or key generation. More complex and detailed models have then been proposed. For
example, Paulson [Pau98] has developed a transition-based model where each emission
of a message corresponds to an event. Protocol rules then specify possible transitions
between sets of events. Similarly, Meadows et al [Mea96] have proposed a language
(NPATRL) for specifying protocols, also based on events.
Rewrite rules. Several models represent the protocol itself as well as the intruder ca-
pabilities by rewrite rules. The main models are the multiset rewriting (MSR) model by
Mitchell et al. [CDL
+
99,BCJS02], the model based on rewrite rules by Rusinowitch and
Turuani used in the Casrul tool [RT01] and Compton and Dexters model [CD99] based
on linear logic.
Horn clauses. A variation of the modeling using rewrite rules is the modeling of
protocols and attacker actions using Horn clauses [Wei99,Bla01,Bla04,VSS05,CLC03,
Gou08]. The modeling in terms of Horn clauses allows to reuse existing results such
as different resolution strategies. One of the most successful tools for verifying an un-
bounded number of sessions is the ProVerif tool developed by Blanchet [Bla01,Bla05,
BAF08] which implements a specialised resolution strategy. A detailed description of
this approach and Blanchets algorithm will be given in chapter Using Horn Clauses
for Analyzing Security Protocols.
Strand spaces. The strand space model [THG99,GT01] is a special purpose model for
reasoning about the traces generated by security protocols. One appealing feature of
the model is that it has an intuitive graphical representation of the protocol executions.
Moreover, Guttman obtained several composition results in this model [GT00,Gut04,
Gut09].
Constraint systems. Constraint systems as a symbolic representation of the execution
of a bounded number of sessions were rst introduced by Millen and Shmatikov [MS01,
MS03] and later also developed by Comon-Lundh [CL04]. It is in particular the under-
lying model in which NP-completeness of secrecy has been proved by Rusinowitch and
Turuani [RT01], for a bounded number of sessions. This result will be presented in the
chapter Verifying a bounded number of sessions and its complexity. A more general
presentation of constraint systems and a decision procedure will be given in the chapter
Constraint solving techniques and enriching the model with equational theories.
Process algebras. A natural modelling of protocols which is closer to an actual im-
plementation is in terms of process algebras. Each role of a protocol corresponds to an
independent process. Process algebras (such as CSP [Sch97], the CCS variant Cryp-
toSPA [FM99], the spi-calculus [AG97] or the applied pi calculus [AF01]) provide com-
munication primitives for sending and receiving messages, restriction, parallel composi-
tion and replication of processes. This yields an accurate (symbolic) modelling of proto-
cols, with in particular generation of fresh nonces (using restriction) and the possibility
for an unbounded number of sessions by using replication.
The main difference between the different models based on process algebra lies in
the denition of security properties. Many models [AL00,ALV02,Sch96,Sch97,Bor01]
use reachability properties of the form: P

err. Other models [AG98,BDNP99,AG97,
AF01] base their property denition on an observational equivalence allowing to model
a wider range of properties including for instance anonymity and coercion-resistance in
voting protocols [KR05,DKR09].
Logics for security protocols. Another kind of reasoning about security protocols is to
use a Floyd-Hoare style logic. As for program analysis, assertions about the protocol
are propagated according to a set of rules. This type of logics goes back to the famous
BAN logic [BAN89] and has known many extensions and variations in the early nineties.
Recently, a new effort in this direction has been made by Mitchells group at Stanford
with a particular emphasis on compositionality resulting in the Protocol Composition
logic which will be described in the corresponding chapter of this volume.
2.3. Security properties
Cryptographic protocols aim at ensuring various security goals, depending on the appli-
cation. The two most classical security properties are secrecy and authentication. Most
of the verication techniques have been developed for these two properties.
Secrecy Secrecy is one of the most standard properties: a protocol ensures the con-
dentiality of some data s if this data is only known to participants which are entitled
to access the data. It is usually specied using a reachablity-based property: a protocol
is said to preserve the condentiality of some data s if no execution yields a state such
that an attacker is able to learn s. In the context of process algebras like the applied pi-
calculus [AF01], it is possible to specify a stronger property: a data s is said secret if
an attacker cannot distinguish a session of the protocol where s has been used from a
session where s has been replaced by an arbitrary data s
. This property is often referred

to as strong secrecy.
Authentication An authentication protocol should typically enable an agent to prove
her identity. Authentication properties are typically specied by requiring that for any
execution of a protocol where an agent B believes that he has received a message m from
A, then m has been indeed sent by A. Many variants have been proposed for authentica-
tion, e.g. by Schneider [Sch97] and by Lowe [Low97].
Equivalence-based properties While secrecy and authentication goals are usually spec-
ied as reachability properties, more complex properties such as privacy-like proper-
ties usually require the use of equivalence-based denitions. Strong secrecy, described
above, is a rst example of an equivalence-based denition. Equivalence-based prop-
erties are even more crucial when specifying anonymity-like properties. For example,
a protocol ensures anonymous communication if an agent cannot linked the received
messages to their respective senders. Several formal denitions of anonymity have been
proposed [Aba02,SH02,Low02]. In particular, the denition proposed by Shmatikov
and Hughes relies on observational equivalence. Other examples of security proper-
ties stated as equivalence-based properties are privacy in e-voting protocols, receipt-
freeness or coercion-resistance [DKR09]. Equivalence-based properties can also be used
for analysing security properties specied in cryptographic models [CLC08].
3. Outline of the book
Formal methods for analyzing security protocols have reached a good level of maturity.
Many algorithms and tools have been proposed and have been successfully applied to
a wide range of protocols. The goal of this book is twofolds. First, it presents several
foundational techniques for security protocol verication that have given raise to many
extensions or which are the key part of successful analysis tools. Second, it presents
several well known symbolic models for security protocols, showing the advantages of
each of them.
Even relatively simple properties such as secrecy and authentication are undecidable
for security protocols [DLMS99]. Hence, algorithms for automated analysis of security
protocols either consider restrictions on the protocols or the proposed techniques are
incomplete. Both kind of approaches will be covered in this book.
A rst mean to recover decidability is to consider a bounded number of sessions,
that is, to consider a limited (xed in advance) number of executions of the protocol.
The chapter Verifying a bounded number of sessions and its complexity presents one
of the rst decidability and complexity result for analysing a protocol for a bounded
number of sessions. It is based on constraint systems which have then been intensively
reused in the eld of security protocol verication. It has also given birth to an auto-
mated tool [ABB
+
02,ABB
+
05]. While many early models considered free termalgebras
it is now widely recognized that this is not sufcient for several important cryptographic
primitives. For example, exclusive or is a frequently used operator in security protocols.
It admits several algebraic properties, in particular associativity and commutativity. The
chapter Constraint solving techniques and enriching the model with equational theo-
ries extends the previous chapter in order to consider equational theories, in particular
for associative and commutative operators. The chapter Analysing Security Protocols
using CSP presents a technique for analysing protocols specied using a process alge-
bra. In particular this technique allowed the discovery of the famous man-in-the-middle
attack of the Needham-Schroeder public key protocol [Low96a].
To analyze protocols without bounding the number of sessions, several incomplete
techniques have been developed which have been shown very successful in practice.
The chapter Using Horn clauses for analyzing protocols presents an algorithm for
analysing protocols modeled in Horn clauses. This algorithm is in the heart of the very
successful tool ProVerif [Bla05]. The chapter Applied pi calculus presents the ap-
plied pi-calculus, a process algebra which allows to specify complex protocols such as
e-voting protocols. The chapter Types for security protocols then proposes a verica-
tion technique for a cryptographic pi-calculus, based on a type systems. Mitchell et al
have developed a logic (PCL) that allows to analyse protocols in a modular way. This
logic is presented in the chapter Protocol Composition Logic. Guttman et al. have de-
veloped the strand spaces model. This model allows to directly reason on the graphical
representation of protocol executions. The model and some of its associated verication
techniques are presented in the chapter Shapes: surveying crypto protocols runs. An-
other possibility for analysing protocols is to compute on over-approximation of the at-
tacker behavior, still showing the security of the protocol. This is the intuitive goal of
the rank functions dened by Schneider and presented in the chapter Security analysis
using rank functions in CSP.
Formal models differ signicantly from computational ones. In modern cryptogra-
phy, security denitions are based on complexity theory. Messages are modeled by bit-
strings and encryption functions are algorithms on bit-strings. The issue is then to de-
tect whether an adversary (a Turing machine) is able to learn a condential information
in reasonable (polynomial) time with non negligible probability. This notion of security
seems to better reect the class of attacks that can be mounted in practice. However, se-
curity proof are error-prone and difcult to automate. Computational and symbolic mod-
els have been developed separately since the 80s. They seem a priori very distinct and
difcult to conciliate. However, a recent line of research has developed a bridge between
the two approaches. In particular, Abadi and Rogaway [AR00] have shown that the cryp-
tographic indistinguishability of sequences of messages can be abstracted by the sym-
bolic equivalence of the corresponding sequences of terms. This result has then been fol-
lowed by many extensions. To conclude this book, the chapter Computational sound-
ness: the case of Dife-Helman keys illustrates this new line of research by presenting
a soundness result between symbolic and cryptographic equivalences for Dife-Hellman
encryption.
References
[Aba02] M. Abadi. Private authentication. Proc. of Workshop on Privacy Enhancing Technologies, 2002.
[ABB
+
02] A. Armando, D. A. Basin, M. Bouallagui, Y. Chevalier, L. Compagna, S. Bdersheim, M. Rusi-
nowitch, M. Turuani, L. Vigan, and L. Vigneron. The AVISS security protocol analysis tool. In
Ed Brinksma and Kim Guldstrand Larsen, editors, Proc. of the 14th International Conference of
Computer Aided Verication (CAV 2002), volume 2404 of LNCS, pages 349353. Springer, July
2002.
[ABB
+
05] A. Armando, D. Basin, Y. Boichut, Y. Chevalier, L. Compagna, J. Cuellar, P. Hankes Drielsma,
P.-C. Ham, O. Kouchnarenko, J. Mantovani, S. Mdersheim, D. von Oheimb, M. Rusinowitch,
J. Santiago, M. Turuani, L. Vigan, and L. Vigneron. The AVISPA Tool for the automated valida-
tion of internet security protocols and applications. In K. Etessami and S. Rajamani, editors, 17th
International Conference on Computer Aided Verication, CAV2005, volume 3576 of Lecture
Notes in Computer Science, pages 281285, Edinburgh, Scotland, 2005. Springer.
[ACC
+
08] Alessandro Armando, Roberto Carbone, Luca Compagna, Jorge Cuellar, and Llanos Tobarra
Abad. Formal analysis of saml 2.0 web browser single sign-on: Breaking the saml-based single
sign-on for google apps. In Proceedings of the 6th ACM Workshop on Formal Methods in Security
Engineering (FMSE 2008), pages 110, 2008.
[AF01] M. Abadi and C. Fournet. Mobile values, new names, and secure communication. In Proc. of
the 28th ACM Symposium on Principles of Programming Languages (POPL01), pages 104115,
January 2001.
[AG97] M. Abadi and A. D. Gordon. A calculus for cryptographic protocols: The spi calculus. In Proc.
of the 4th ACM Conference on Computer and Communications Security (CCS97), pages 3647.
ACM Press, 1997.
[AG98] M. Abadi and A. Gordon. A bisimulation method for cryptographic protocols. Nordic Journal of
Computing, 5(4):267303, 1998.
[AL00] R. Amadio and D. Lugiez. On the reachability problem in cryptographic protocols. In Proc. of the
12th International Conference on Concurrency Theory (CONCUR00), volume 1877 of LNCS,
pages 380394, 2000.
[ALV02] R. Amadio, D. Lugiez, and V. Vanackre. On the symbolic reduction of processes with crypto-
graphic functions. Theoretical Computer Science, 290(1):695740, 2002.
[AR00] M. Abadi and P. Rogaway. Reconciling two views of cryptography. In Proc. of the International
Conference on Theoretical Computer Science (IFIP TCS2000), pages 322, August 2000.
[BAF05] Bruno Blanchet, Martn Abadi, and Cdric Fournet. Automated verication of selected equiv-
alences for security protocols. In 20th IEEE Symposium on Logic in Computer Science (LICS
2005), pages 331340. IEEE Computer Society, June 2005.
[BAF08] Bruno Blanchet, Martn Abadi, and Cdric Fournet. Automated verication of selected equiva-
lences for security protocols. Journal of Logic and Algebraic Programming, 75(1):351, 2008.
[BAN89] M. Burrows, M. Abadi, and R. Needham. A logic of authentication. In Proc. of the Royal Society,
volume 426 of Series A, pages 233271. 1989. Also appeared as SRC Research Report 39 and,
in a shortened form, in ACM Transactions on Computer Systems 8, 1 (February 1990), 18-36.
[BCJS02] F. Butler, I. Cervesato, A. Jaggard, and Andre Scedrov. A formal analysis of some properties of
kerberos 5 using MSR. In S. Schneider, editor, Proc. of 15th IEEE Computer Security Founda-
tions Workshop (CSFW15), pages 175190. IEEE Computer Society Press, June 2002.
[BDNP99] M. Boreale, R. De Nicola, and R. Pugliese. Proof techniques for cryptographic processes. In
Logic in Computer Science, pages 157166, 1999.
[BHM08a] Michael Backes, Catalin Hritcu, and Matteo Maffei. Automated verication of remote electronic
voting protocols in the applied pi-calculus. In Proceedings of 21st IEEE Computer Security
Foundations Symposium (CSF), June 2008.
[BHM08b] Michael Backes, Catalin Hritcu, and Matteo Maffei. Type-checking zero-knowledge. In Pro-
ceedings of 2008 ACM Conference on Computer and Communication Security (CCS08, 2008.
[Bla01] B. Blanchet. An efcient cryptographic protocol verier based on prolog rules. In Proc. of the
14th Computer Security Foundations Workshop (CSFW01). IEEE Computer Society Press, June
2001.
[Bla04] Bruno Blanchet. Automatic proof of strong secrecy for security protocols. In IEEE Symposium
on Security and Privacy (SP04), pages 86100, Oakland, California, May 2004.
[Bla05] Bruno Blanchet. An automatic security protocol verier based on resolution theorem proving
(invited tutorial). In 20th International Conference on Automated Deduction (CADE-20), Tallinn,
Estonia, July 2005.
[Bla08] Bruno Blanchet. Vrication automatique de protocoles cryptographiques : modle formel et
modle calculatoire. Automatic verication of security protocols: formal model and compu-
tational model. Mmoire dhabilitation diriger des recherches, Universit Paris-Dauphine,
November 2008. En franais avec publications en anglais en annexe. In French with publications
in English in appendix.
[Bor01] M. Boreale. Symbolic trace analysis of cryptographic protocols. In Proc. of the 28th Int. Coll.
Automata, Languages, and Programming (ICALP01). Springer Verlag, July 2001.
[CC01] H. Comon and V. Cortier. Tree automata with one memory, set constraints and cryptographic
protocols. In Research Report LSV-01-13, december 2001.
[CD99] K. Compton and S. Dexter. Proof techniques for cryptographic protocols. In Proc. of the 26th
International Colloquium on Automata, Languages, and Programming (ICALP99), July 1999.
[CDL
+
99] I. Cervesato, N. Durgin, P. Lincoln, J. Mitchell, and A. Scedrov. A meta-notation for protocol
analysis. In Proc. of the 12th IEEE Computer Security Foundations Workshop (CSFW99), pages
5569. IEEE Computer Society Press, 1999.
[CDL06] V. Cortier, S. Delaune, and P. Lafourcade. A Survey of Algebraic Properties Used in Crypto-
graphic Protocols. Journal of Computer Security, 14(1/2006), 2006.
[CKS01] R. Chadha, M.I. Kanovich, and A. Scedrov. Inductive methods and contract-signing protocols.
In P. Samarati, editor, 8-th ACM Conference on Computer and Communications Security, pages
176185. ACM Press, November 2001.
[CL04] H. Comon-Lundh. Rsolution de contraintes et recherche dattaques pour un nombre
born de sessions. Available at http://www.lsv.ens-cachan.fr/~comon/CRYPTO/
bounded.ps, 2004.
[CLC03] H. Comon-Lundh and V. Cortier. New decidability results for fragments of rst-order logic and
application to cryptographic protocols. In Proc. of the 14th Int. Conf. on Rewriting Techniques
and Applications (RTA2003), volume 2706 of LNCS, pages 148164. Springer-Verlag, 2003.
[CLC08] Hubert Comon-Lundh and Vronique Cortier. Computational soundness of observational equiv-
alence. In Proceedings of the 15th ACM Conference on Computer and Communications Security
(CCS08), Alexandria, Virginia, USA, October 2008. ACM Press.
[Cre08] Cas Cremers. The Scyther Tool: Verication, falsication, and analysis of security protocols. In
Computer Aided Verication, 20th International Conference, CAV 2008, Princeton, USA, Proc.,
volume 5123/2008 of Lecture Notes in Computer Science, pages 414418. Springer, 2008.
[DEK83] D. Dolev, S. Even, and R.M. Karp. On the security of ping-pong protocols. In R.L. Rivest,
A. Sherman, and D. Chaum, editors, Proc. of CRYPTO 82, pages 177186. Plenum Press, 1983.
[DKR09] Stphanie Delaune, Steve Kremer, and Mark D. Ryan. Verifying privacy-type properties of elec-
tronic voting protocols. Journal of Computer Security, 17(4):435487, July 2009.
[DLM82] R. Demillo, N. Lynch, and M. Merritt. Cryptographic protocols. In Proc. of the 14
t h
ACM
SIGACT Symposium on Theory of Computing. ACM, May 1982.
[DLM04] Nancy A. Durgin, Patrick Lincoln, and John C. Mitchell. Multiset rewriting and the complexity
of bounded security protocols. Journal of Computer Security, 12(2):247311, 2004.
[DLMS99] N. Durgin, P. Lincoln, J. Mitchell, and A. Scedrov. Undecidability of bounded security protocols.
In Proc. of the Workshop on Formal Methods and Security Protocols, 1999.
[DY81] D. Dolev and A.C. Yao. On the security of public key protocols. In Proc. of the 22nd Symp. on
Foundations of ComputerScience, pages 350357. IEEE Computer Society Press, 1981.
[FM99] Riccardo Focardi and Fabio Martinelli. A uniform approach for the denition of security proper-
ties. In Proc. of World Congress on Formal Methods (FM99), volume 1708 of Lecture Notes in
Computer Science, pages 794813. Springer, 1999.
[Gou08] Jean Goubault-Larrecq. Towards producing formally checkable security proofs, automatically.
In Proceedings of the 21st IEEE Computer Security Foundations Symposium (CSF08), pages
224238, Pittsburgh, PA, USA, June 2008. IEEE Computer Society Press.
[GT00] Joshua D. Guttman and F. Javier Thayer. Protocol independence through disjoint encryption.
In Proc. 13th Computer Security Foundations Workshop (CSFW00), pages 2434. IEEE Comp.
Soc. Press, 2000.
[GT01] J.D. Guttman and F.J. Thayer. Authentication tests and the structure of bundles. Theoretical
Computer Science, 2001.
[Gut04] Joshua D. Guttman. Authentication tests and disjoint encryption: a design method for security
protocols. Journal of Computer Security, 12(34):409433, 2004.
[Gut09] Joshua D. Guttman. Cryptographic protocol composition via the authentication tests. In Foun-
dations of Software Science and Computation Structures (FOSSACS09), Lecture Notes in Com-
puter Science, March 2009.
[KK05] D. Khler and R. Ksters. Constraint Solving for Contract-Signing Protocols. In M. Abadi and
L. de Alfaro, editors, Proceedings of the 16th International Conference on Concurrency Theory
(CONCUR 2005), volume 3653 of Lecture Notes in Computer Science, pages 233247. Springer,
2005.
[KR02] S. Kremer and J.-F. Raskin. Game analysis of abuse-free contract signing. In Steve Schneider,
editor, Proc. of the 15th Computer Security Foundations Workshop (CSFW02), pages 206220.
IEEE Computer Society Press, June 2002.
[KR05] Steve Kremer and Mark. Ryan. Analysis of an electronic voting protocol in the applied pi-
calculus. In Mooly Sagiv, editor, Programming Languages and Systems Proceedings of the 14th
European Symposium on Programming (ESOP05), volume 3444 of Lecture Notes in Computer
Science, pages 186200, Edinburgh, U.K., April 2005. Springer.
[KT09] R. Ksters and T. Truderung. An Epistemic Approach to Coercion-Resistance for Electronic
Voting Protocols. In 2009 IEEE Symposium on Security and Privacy (S&P 2009), pages 251266.
IEEE Computer Society, 2009.
[Low96a] G. Lowe. Breaking and xing the Needham-Schroeder public-key protocol using FDR. In T. Mar-
garia and B. Steffen, editors, Tools and Algorithms for the Construction and Analysis of Systems
(TACAS96), volume 1055 of LNCS, pages 147166. Springer-Verlag, march 1996.
[Low96b] G. Lowe. Some new attacks upon security protocols. In Proc. of the 9th Computer Seurity
Foundation Workshop (CSFW96), pages 162169. IEEE Computer Society Press, 1996.
[Low97] G. Lowe. A hierarchy of authentication specication. In Proc. of the 10th Computer Security
Foundations Workshop (CSFW97). IEEE Computer Society Press, 1997.
[Low02] G. Lowe. Analysing Protocols Subject to Guessing Attacks. In Proc. of the Workshop on Issues
in the Theory of Security (WITS 02), 2002.
[Mea96] Catherine Meadows. Language generation and verication in the nrl protocol analyzer. In Pro-
ceedings of the 9th Computer Security Foundations Workshop (CSFW96). IEEE Computer So-
ciety Press, 1996.
[Mer83] Michael J. Merritt. Cryptographic Protocols. PhD thesis, Georgia Institute of Technology, Febru-
ary 1983.
[Mil84] Jonathan K. Millen. The interrogator: A tool for cryptographic protocol security. In IEEE Sym-
posium on Security and Privacy, pages 134141, 1984.
[Mil03] J. Millen. On the freedom of decryption. Information Processing Letters, 2003.
[MS01] J. Millen and V. Shmatikov. Constraint solving for bounded-process cryptographic protocol anal-
ysis. In Proc. of the 8th ACM Conference on Computer and Communications Security (CCS01),
2001.
[MS03] J. Millen and V. Shmatikov. Symbolic protocol analysis with products and dife-hellman expo-
nentiation. In Proc. of the 16th IEE Computer Seurity Foundation Workshop (CSFW03), 2003.
[Pau98] L. Paulson. The inductive approach to verifying cryptographic protocols. Journal of Computer
Security, 6(1):85128, 1998.
[RT01] M. Rusinowitch and M. Turuani. Protocol insecurity with nite number of sessions is NP-
complete. In Proc. of the 14th Computer Security Foundations Workshop (CSFW01), pages
[Sch96] S. A. Schneider. Security properties and CSP. In Proc. of the Symposium on Security and Privacy,
pages 174187. IEEE Computer Society Press, 1996.
[Sch97] S. Schneider. Verifying authentication protocols with CSP. In Proc. of the 10th Computer Security
Foundations Workshop (CSFW97). IEEE Computer Society Press, 1997.
[SH02] V. Shmatikov and D.J.D Hughes. Dening Anonymity and Privacy (extended abstract). In Proc.
of the Workshop on Issues in the Theory of Security (WITS 02), 2002.
[THG99] J. Thayer, J. Herzog, and J. Guttman. Strand spaces: proving security protocols correct. IEEE
Journal of Computer Security, 7:191230, 1999.
[VSS05] Kumar Neeraj Verma, Helmut Seidl, and Thomas Schwentick. On the complexity of equational
horn clauses. In Proc. of the 22th International Conference on Automated Deduction (CADE
2005), Lecture Notes in Computer Science, pages 337352. Springer-Verlag, 2005.
[Wei99] C. Weidenbach. Towards an automatic analysis of security protocols in rst-order logic. In
H. Ganzinger, editor, Proc. of the 16th International Conference on Automated Deduction,
CADE99, volume 1632 of LNCS, pages 378382, 1999.
Verifying a bounded number of sessions
and its complexity
Michael RUSINOWITCH
a
and Mathieu TURUANI
a
a
INRIA Nancy Grand Est
Abstract. We investigate the complexity of the protocol insecurity problem for a
nite number of sessions (xed number of interleaved runs). We show that this
problem is NP-complete with respect to a Dolev-Yao model of intruders. The result
does not assume a limit on the size of messages and supports asymetric and non-
atomic symmetric encryption keys. We also prove that in order to build an attack
with a xed number of sessions the intruder needs only to forge messages of linear
size, provided that they are represented as DAGs.
1. Introduction
Although the general protocol verication problem is undecidable [13] even in the re-
stricted case where the size of messages is bounded [12], it is interesting to investigate
decidable fragments of the underlying logics and their complexity. The success of prac-
tical verication tools indicates that there may exist interesting decidable fragments that
capture many concrete security problems. Dolev and Yao have proved that for simple
ping-pong protocols, insecurity can be decided in polynomial time [10]. On the other
hand [12] shows that when messages are bounded and when no nonces (i.e. new data) are
created by the protocol and the intruder, then the existence of a secrecy aw is decidable
and DEXPTIME-complete.
A related decidability result is presented in [14,1,20,19,4,17,16]. The authors give a
procedure for checking whether an unsafe state is reachable by the protocol. Their result
holds for the case of nite sessions but with no bounds on the intruder messages. The
proof in [1] does not allow general messages (not just names) as encryption keys. This
limitation is relaxed in [20,19,21]. The decision algorithm presented in this chapter is
similar to the one in [20] but its proof has been simplied.
The main result of this chapter states that for a xed number of interleaved pro-
tocol runs, but with no bounds on the intruder messages, the existence of an attack is
NP-complete. We allow public key encryption as well as the possibility of symmetric
encryption with composed keys i.e. with any message. Here we only consider secrecy
properties. However authentication can be handled in a similar way. Hence, a protocol is
considered insecure if it is possible to reach a state where the intruder possesses a secret
term.
With the same proof technique it is possible to extend the result directly to various
intruder models and to protocols with choice points. In particular many algebraic prop-
erties of cryptographic primitives can be covered by the approach ([5,6]). The result we
IOS Press, 2011
doi:10.3233/978-1-60750-714-7-13
13
present here can also be derived through a constraint solving approach and the careful
design of simplication rules to be applied to intruder constraints ([8]).
Although this result is of a theoretical avor, it gives information of practical rel-
evance since for its proof we have shown that in order to attack a protocol an intruder
needs only to forge messages of linear size with respect to the size of the protocol. This
gives a low bound for the message space to be explored when looking for a aw e.g. with
a model-checker and this explains also why many tools like the CL-ATSE [22] backend
from the AVISPA Tool [2] are effective in protocol analysis: to put it informally, in the
Dolev-Yao model awed protocols can be attacked with small faked messages.
Layout of the chapter: We rst introduce in Section 2 our model of protocols and in-
truder and give the notion of attack in Section 2.4. Then in Section 3 we study properties
of derivations with intruder rules. This allows us to derive polynomial bounds for normal
attacks in Section 4 and to show that the problem of nding a normal attack is in NP. We
show in Section 5 that the existence of an attack is NP-hard.
2. The Protocol Model
We consider a model of protocols in the style of [3]. The actions of any honest princi-
pal are specied as a partially ordered list that associates to (the format of) a received
message its corresponding reply. The activity of the intruder is modeled by rewrite rules
on sets of messages. We suppose that the initialization phase of distributing keys and
other information between principals is implicit. The approach is quite natural and it is
simple to compile a wide range of protocol descriptions into our formalism. For instance
existing tools such as CAPSL [18] or CASRUL [15] would perform this translation with
few modications. We present our model more formally now.
2.1. Messages
The messages exchanged during the protocol execution are built using pairing _, _ and
encryption operators {_}
s
_
, {_}
a
_
. We add a superscript to distinguish between public key
(
) and symmetric key (
) encryptions. The set of basic messages is nite and denoted

by . It contains names for principals and atomic keys from the set . Since
we have a nite number of sessions we also assume any nonce is a basic message: we
consider that it has been created before the session and belongs to the initial knowledge
of the principal that generates it.
Any message can be used as a key for symmetric encryption. Only elements from
are used for public key encryption. Given a public key (resp. private key) ,
1
denotes the associated private key (resp. public key) and it is an element of .
The messages are then generated by the following (tree) grammar:
::= , {}
a
{}
s
A signature, usually denoted by []
with a private key
(=
1
), is repre-
sented here ase {}
a
. For conciseness we denote by

1
, . . . ,
the set of messages

{
1
, . . . ,
}. Given two sets of messages and
we denote by ,
the union
of their elements and given a set of messages and a message , we denote by , the
set {}.
M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity 14
Decomposition rules Composition rules
(, ) : , , , ,
(, ) : , , , ,
({}
a
) : {}
a
,
1
{}
a
,
1
,
({}
a
) : , , , {}
a
({}
s
) : {}
s
, {}
s
, ,
({}
s
) : , , , {}
s
Table 1. Intruder Rules

2.2. Intruder
In the Dolev Yao model [10] the intruder has the ability to eavesdrop, divert and memo-
rize messages, to compose and decompose, to encrypt and decrypt when he has the key,
to generate new messages and send them to other participants with a false identity. We
assume here without loss of generality that the intruder systematically diverts messages,
possibly modies themand forwards themto the receiver under the identity of the ofcial
sender. In other words all communications are mediated by a hostile environment repre-
sented by the intruder. The intruder actions for modifying the messages are simulated by
rewrite rules on sets of messages.
The set of messages
0
represents the initial knowledge of the intruder. We assume
that at least the name of the intruder belongs to this set.
Intruder rules are divided in several groups, for composing or decomposing mes-
sages. These rules, which are described in Table 1, are the only one we consider in this
chapter and any mentions of rules refer to these rules. In Table 1 and in the remain-
ing of the chapter, , and represent any message and represents any element of
. For instance, the rule with label
(, ) replaces a set of messages , by the

following set of messages , , , .
The rewrite relation is dened by
if there exists one rule (from

Table 1) such that is a subset of and
is obtained by replacing by in .
We write
for the reexive and transitive closure of . We denote the applica-

tion of a rule to a set of messages with result
by
. We write
= {
() for all messages }, and
in the same way. We call derivation a se-

quence of rule applications
0

1

1

2
..
. The rules
for = 1..
are called the rules of this derivation . We write (abusively) to denote that
is one of the rules
, for = 1.., that has been used in the derivation . We omit the
subscripts
in the derivation when they are not relevant to the discussion. We write

if =
or if there exists a derivation

1
..
.
One can remark that if the intruder was allowed to generate new data he will not
get more power. He is already able to create innitely many data only known to him
with simple encryptions. For instance he can construct an innite sequence of terms only
known to him, like e.g. {}
s
,
{
{}
s
}
s
, ... assuming that is only known by the

intruder. For the class of protocols that we will consider honest principals receiving these
terms for the rst time cannot distinguish them from nonces. Alternatively, the result
in this chapter can also be easily extended to allow nonces for the intruder, simply by
processing them like any composed term only checkable by the intruder.
2.3. Protocols
We shall specify protocols by a list of actions for each principal. In order to describe the
protocol steps we introduce message terms (or terms for short). We assume that we have
a set of variables . Then the set of terms is generated by the following tree grammar:
::= , {}
a
{}
s
As for messages, a signature usually denoted as []
with a private key

is here represented as {}
a
. Let () be the set of variables that occur in a term

. A substitution assigns terms to variables. A ground substitution assigns messages to
variables. The application of a substitution to a term is written . We also write
[ ] the substitution dened by () = and () = for = . The set of
subterms of is denoted by (). These notations are extended to sets of terms in a
standard way. For instance, = { }.
Aprincipal (except the initiator) reply after receiving a message matching a specied
term associated to its current state. Then from the previously received messages (and
initial knowledge) he builds the next message he will send. This concrete message is
obtained by instantiating the variables in the message pattern associated to the current
step in the protocol specication.
A protocol is given with a nite set of principal names , and a
partially ordered list of steps for each principal name. This partial order aims at ensuring
that the actions of each principal are performed in the right order. More formally we
associate to each principal a partially ordered nite set (
, <
). Each protocol
step is specied by a pair of terms denoted and is intended to represent some
message expected by a principal and his reply to this message. Hence a protocol
specication is given by a set of steps:
{(,
) }
where = {(, ) and
} and
and
are terms. Given a

protocol, we will assume that for all (, ) , for all (
(,)
), there exists

(i.e. <
or = ) such that (
(,)
), meaning that any variable
must be received before it is sent.
We write for the size of . and are xed messages used to initiate and
close a protocol session. An environment for a protocol is a set of messages. A correct
execution order is a one-to-one mapping :
{1, ..,
} such that 1)
;
2) and for all and <
with (, )
, we have (, )
and
(, ) < (, ). In other words denes an execution order for the protocol steps.
This order is compatible with the partial order of each principal. It is not supposed to
be complete, but it must be acceptable (i.e. runnable) for principals. We write
for
the size of
in a correct execution order. For the readability of examples, we allow

writing protocol steps as
1
, ..,

1
, ..,
instead of
1
, ..,

1
, ..,
. A
protocol execution is given by a ground substitution , a correct execution order and
a sequence of environments
0
, ..,
verifying:
0
,
, and for all

1
1
()

1
and
1
()

.
Each step of the protocol extends the current environment by adding the corre-
sponding message
when
is present. One can remark that principals are not al-

lowed to generate any new data such as nonces. But this is not a problem when the num-
ber of sessions is nite: in this setting from the operational point it is equivalent to as-
sume that the new data generated by a principal during a protocol execution is part of his
initial knowledge.
A B
{
{}
a
}
a
{}
s
Figure 1. Handshake Protocol

Example: Handshake protocol
We recall this simple protocol (from Chapter Introduction ) and its presentation by
a message sequence chart. is a symmetric key,
a public key,
1
a private key
associated to the public key
and is a basic message.

Now we can express this protocol in our formal syntax. The orderings on steps is trivial
since
= {1}.
((A,1),
{
{}
a
}
a
)
((B,1),
{
{}
a
}
a
{}
s
)
2.4. Attacks: Passive and active cases
Considering a protocol specication and a special term (called secret term), we
say that there is an attack in protocol sessions if the intruder can obtain the secret term
in its knowledge set after completing at most sessions.
2.4.1. Passive case
We consider rst the case when the intruder has only the capability of eavesdropping
messages between honest participants. Hence the intruder cannot intercept and modify
the transmitted messages. If he can derive the secret with these limited means then we
say that the protocol is subject to a passive attack.
We introduce a predicate forge for checking whether a message can be constructed
by the intruder from some known messages.
Denition 1 (forge) Let be a set of terms and let be a term such that there is
with
and
. Then we say that is forged from and we denote it by

forge().
The existence of a passive attack can be reduced to a deduction problem:
Denition 2 (passive attack) If contains the initial intruder knowledge and the set of
messages eavesdropped from the protocol sessions, there is a passive attack if
forge().
2.4.2. Active case
Let us consider nowthe general case where the intruder has full power. Note that received
messages are matched by principals with the left-hand sides of protocol steps, meaning
that some substitution unies the messages sent by the intruder and the ones expected by
the principals. Hence the existence of an attack can be expressed as a constraint solving
problem: is there a way for the intruder to build from its initial knowledge and already
sent messages a new message (dened by a substitution for the variables of protocol
steps) that will be accepted by the recipient, and so on, until the end of the session, and
such that at the end the secret term is known by the intruder.
In other words an active attack is a protocol execution where the intruder can mod-
ify each intermediate environment and where the message belongs to the nal
environment. In an active attack the intruder is able to forge any message by using its
initial knowledge and already sent messages (spied in the environments). We note by
the cardinality of
in an (active) attack. Hence we can formulate the denition of an

attack using the predicate forge:
Denition 3 (active attack) Given a protocol = {
}, a secret
message and assuming the intruder has initial knowledge
0
, an active at-
tack (or an attack in short) is described by a ground substitution and a correct ex-
ecution order :
1, . . . , such that for all = 1, . . . , , we have

forge(
0
,
1
, ..,
1
) and forge(
0
,
1
, ..,
) where
1
()
and
1
()
.
The denition of an active attack we give here is slightly more general than the one
in [20] and was rst proposed in [9] since it does not require the protocol to be completely
executed. Before proceeding let us give some detailed examples.
Example: Attack on Handshake Protocol
Let us assume that Agent A initiates Handshake Protocol (see Chapter Introdution)
with Intruder Charlie (C in short). Then using the rst message from A, C can imperson-
ate A and initiate a session with B. This allows C to get the message
,
that should
have been known only by A and B.
In order to detect the potential attack displayed in Figure 2, we set up a system built
fromtwo handshake protocol sessions running in parallel. This system can be considered
as a single session for a protocol admitting 4 steps specied below:
((A,1),
{
{
,
}
a
}
a
)
((C,1),
{
{}
a
}
a
{
,
}
s
)
((A,1),
{
{
,
}
a
}
a
)
((B,1),
{
}
a
}
a
{
,
}
s
)
A C B
{
{
,
}
a
}
a
{
,
}
a
}
a
{
,
}
s
,
Figure 2. Attack on Simple Protocol
We assume that the initial intruder knowledge is
0
= {
,
1
, }.
Then an attack is obtained by taking the following ground substitution and execution
order:
Substitution Protocol steps
= [
,
,

,
] (, 1) = 1, (, 1
) = 2, (, 1
) = 3
This represents an attack since the following relations can be checked:
1
(1)
forge(
0
)
1
(2)
forge(
0
,
1
(1)
)
1
(3)
forge(
0
,
1
(1)
,
1
(2)
)
,
forge(
0
,
1
(1)
,
1
(2)
,
1
(3)
)
This can be veried easily. For instance, the last relation is valid since
,
1
1
(1)
=
{
{
,
}
a
}
a
1
(3)
= {
,
}
a
,
and
,
1
,
{
{
,
}
a
}
a
, {
,
}
s
,
1
,
{
{
,
}
a
}
a
, {
,
}
s
,
, {
,
}
a
,
1
,
{
{
,
}
a
}
a
, {
,
}
s
,
, {
,
}
a
,
,
,
1
,
{
{
,
}
a
}
a
, {
,
}
s
,
, {
,
}
a
,
,
,
,
A B S
, , , {
, , , }
s
, , , {
, , , }
s
,
{
, , , }
s
, {
}
s
,
{
}
s
, {
}
s
{}
s
Figure 3. Otway-Rees Protocol

Example: Attack on Otway-Rees Protocol
The participants of the protocol are , and the server . The symmetric keys
, will be respectively shared by the participants (, ) and (, ). The identi-
ers , , represents nonces. In Step 3, the server creates the new secret sym-
metric key to be used by and for further safe communications. We have ex-
tended the protocol with an extra step where uses the key
to send a secret mes-

sage to . In the attack, will be fooled into believing that the term , , (short-
hand for , , ) is in fact the new key. The sequence of messages dening Otway-
Rees is depicted in Figure 3. Let us write now this protocol specication with our nota-
tion, with
as a short-hand for
7
,
.
((, 1), , , , {
, , , }
s
)
((, 1),
2
,
3
, ,
4

2
,
3
, ,
4
, {
,
2
,
3
, }
s
)
((, 1),
, {
8
,
}
s
, {
9
,
}
s

7
, {
8
,
}
s
, {
9
,
}
s
, {
8
,
}
s
, {
9
,
}
s

7
, {
8
,
}
s
, {
9
,
}
s
)
((, 2),
2
,
5
, {
,
6
}
s

2
,
5
)
((, 2), , {
,
1
}
s
{}
s
1
)
((, 3), {}
s
6
)
A protocol execution can be obtained by taking the protocol steps in the given order and
by applying the following substitution:
1
=

2
=
3
=
5
= {
8
,
}
s
6
=
4
= {
, , , }
s
7
=
8
=

9
=
=
An attack can be performed on this protocol with initial intruder knowledge
0
=
{, }, using:
Substitution Protocol steps
= [
1
, , ] (, 1) = 1, (, 2) = 2
since we have:
1
(1)
forge(
0
)
1
(2)
forge(
0
,
1
(1)
)
forge(
0
,
1
(1)
,
1
(2)
)
3. Passive case
In this section we show how to decide efciently the existence of a passive attack on a
protocol. We rst show some basic facts on the DAG-representation of message terms.
Then we shall show how to obtain from any derivation a more compact one. We will then
be able to prove that a normal attack has a polynomial size w.r.t. the size of the protocol
and intruder knowledge, when using DAG representations.
3.1. DAG representation
The DAG-representation of a set of message terms is the graph (, ) with labeled
edges, where:
the set of vertices = (), the set of subterms of . The label of a vertice is
the root symbol of the corresponding subterm (_, _, {_}
s
_
,{_}
a
_
or an element
from ).
the set of edges =
1

2
:
1
= {
= {
}
s
or
= {
}
a
or
, }
2
= {
= {}
s
or
= {}
a
or
= ,
}
Let us note that the DAG representation is unique. Moreover if is the number of
elements in (), one can remark that (, ) has at most nodes and 2. edges. Hence
its size is linear in , and for convenience we shall dene the DAG-size of , denoted
by
, to be the number of distinct subterms of , i.e the number of elements in

(). For a term , we simply write
for {}
. We note that a standard

DAG representation of would use (.()) space with =
, but this differ-

ence with our DAG-size has no impact on the polynomial-time complexity of algorithms
presented below. An example of DAG representation can be found in Figure .
Now, why do we dene the DAG size for terms ? First, because it is a way to rep-
resent messages and thus protocols in a compact manner that strengthens the complexity
result; And second, because the subterm sharing works quite well with the replacement
of subterms by others, which will be the essence of the proof of our main property. Con-
sequently, we uses DAG size also to measure the size of attacks, and we concentrate on
the properties of smallest attacks called normal attack w.r.t the following denition :
4
_, _
{_}
s
_
_, _
_, _
_, _
Figure 4. DAG Representation of the First Message of Otway-Rees Protocol

Denition 4 Let be a protocol and (, ) an attack on . Then (, ) is a normal
attack iff it is minimal among all attacks on w.r.t the following measure :
(, ) = {} {()}

This is as expected except for the presence of the special atom . It ensures
that a normal attack uses preferably instead of any other atom or term, when it
is possible, thus allowing us to express properties on normal attacks which we prove by
replacing a subterm of by .
3.2. Simple lemmas on intruder derivations
In this section, we will give some useful denitions and properties of derivations. We
shall introduce a notion of normal derivation, denoted by
(). A related notion of

normal derivation has been studied in [7]. Rather than a natural deduction presentation
in [7] we use here term rewriting.
Denition 5 Given a derivation =
0

1

1

2
..
, a term is a goal
of if
and /
1
.
For instance if forge() there exists a derivation with goal : we take a derivation
=
1
. . .
with
and then we take the smallest prex of

containing . We will consider particular derivations minimal in length :
Denition 6 We denote
() a derivation of minimal length among the deriva-

tions from with goal (chosen arbitrarily among the possible ones).
In order to bound the length of such derivations, we can prove the two following
lemmas: every intermediate term in
() is a subterm of or . Lemma 1 means

that if a term is decomposed in a minimal derivation from then this term has not been
composed before and therefore belongs to :
Lemma 1 If there exists
such that
() then
is a subterm of
Proof:
Let =
() =
0

1

1
...
and
be (one of) the rst occuring

term not validating the lemma for , assuming there exists one (or more). That is, there
exists such that
),
is not a subterm of ,
1
=
0

1
...
1
, and for
all
()
1
, is a subtermof . (Note: > 1 since
/ ) Moreover, by minimality
of we have
) . Therefore,
has necessarily be obtained by a decomposition

rule in
1
, i.e. there exists a term with
subtermof such that
()
1
. However,
thanks to the minimality of
, this means that is a subterm of , and thus
too. So the
assumption is contradicted, and consequently and the lemma is proved.
Lemma 2 means that in a minimal derivation we only need to compose subterms of
the nal goal or keys occurring in the initial set :
Lemma 2 If there exists
such that
() then
is a subterm of {}
Proof:
Let =
() =
0

1

1
...
and
be (one of) the last occuring term

not validating the lemma for , assuming there exists one (or more). That is, there exists
such that
),
is not a subterm of {} ,
2
=
+1
...
, and
for all
()
2
, is a subterm of {} . (Note: < since
= ) Moreover, by
minimality of , we have
) . Similarly, by minimality of and since
= ,
there exists a rule in
2
using
: otherwise
) would be useless and would not

be minimal. Let us consider all possible rules using
in
2
. Decomposition of
is not
allowed as pointed above; Decomposition of {}
a
1
is not allowed because
is not an
atom (since it is composed), and thus not in ; Decomposition of {}
s
means that
there exists
()
2
such that
is a subterm of , and thus thanks to Lemma 1,
is a subterm of ; And nally, composition using
means that there exists
()
2
with
subterm of , and thus by hypothesis both and
are subterms of {} .
Therefore, in every case the assumption is contradicted, and consequently the lemma is
proved.
We show in the next proposition that there always exist derivations of a term from
a set with a number of rules bounded by the DAG-size of initial and nal terms , .
This will be very useful to bound the length of the derivations involved in a normal attack.
Proposition 1 For any set of terms and for any term , if
() =
1
..
then for all 1 ,
) (, ).
Proof:
Let
() =
1
...
. By denition of , for any term
subterm
of
=1..
there exists with
subterm of such that either
() or
() . Therefore, thanks to Lemmas 1 and 2 above, (and thus
) is a subterm of
{} . It follows that for = 0..,
(, ), which proves the proposition.

3.3. Decision Algorithm
We can now give a simple algorithm to decide whether forge(). It is depicted in
Algorithm1, and assumes a representation of (, ) as a DAG: anyway the DAG can
be computed in polynomial time from inputs given in standard tree representations.
1: INPUTS: , represented by a DAG for (, )
2:
1

3:
0
(, )
4: repeat
5:
6: for all (, ) do
7: if
0
, and ,
1
, with = {}
s
or = {}
a
or = , then
8:
0

0
{}
9:
1

1
{}
10: {}
11: end if
12: if
1
,
0
,
1
, with = {}
s
or = {}
a
then
13:
0

0
{}
14:
1

1
{}
15: {}
16: end if
17: if
1
with = , then
18:
1

1
{, }
19: end if
20: end for
21: until = or
1
22: if
1
then
23: True
24: else
25: False
26: end if
Algorithm 1. Passive Attack Decision
The correctness of Algorithm 1 is a consequence of the previous lemmas. We only
need to compute the set
1
of subterms of , that can be deduced from and check
whether belongs to this set. The algorithm computes iteratively
1
by checking for
each term whether it can be derived from the current
1
or can be decrypted (and if so
its content is added to
1
).
The REPEAT loop can be entered at most (, )
times. The FORALL

loop is executed (, )
times. The work done in this innermost loop is

also bounded by a constant. Hence the algorithm takes (
2
) time where =
(, )
.
We now suggest a more efcient solution by reduction to Horn-Sat:
Proposition 2 Given a set of terms and a term the existence of a passive attack can
be decided in linear time.
Proof:
Given (, ), we consider each subterm (, ) as a propositional variable
and we generate the following set of Horn clauses:
for = {}
s
or = {}
a
we generate the clauses: , and , ;

for = , we generate the clauses , , , and ;
for we generate ;
The union of all generated clauses and is a set called . Now obviously the set of
clauses is satisable iff cannot be derived by intruder rules from . There exists a
linear algorithm by Dowling and Gallier [11] to test the satisability of a set of Horn
clauses, hence we can conclude.
4. Active Case
4.1. Polynomial bound on attacks
We shall prove that when there exists an attack then a normal attack (see Denition 4) can
always be constructed fromsubterms that are already occurring in the problemspecica-
tion. This will allow to give bounds on the message sizes and on the number of rewriting
rules involved in such an attack.
Let us consider a protocol = {
}, a secret message
and a set of messages
0
as the initial intruder knowledge. We assume that there exists
an attack described by a ground substitution and a correct execution order :
1, . . . , (where is the cardinality of
). We dene
1
()
and
1
()
for
= 1, . . . , . Note that
now replace , for readability, unlike previous sections.

We also dene: as the set of subterms of the terms in the set = {
=
1, . . . , } {
= 0, . . . , }, and
the set of subterms of the terms in {
=
1, . . . , } {
= 0, . . . , }.
The following Proposition 3 is a key property of this chapter. It shows that every
substitution in a normal attack is only built with parts of the protocol specication.
Using this, we will be able to prove that every substitution , and every message, in a
normal attack have a DAG-size bounded by a polynomial in the protocols DAG-size.
However, this relies on the technical Lemma 3. Informally, it states that if a term
can be forged from a set of message by composing two messages
1
,
2
both derived
from then it is always possible to avoid decomposing in a derivation from (with
any goal ). Indeed, such a decomposition would generate messages
1
,
2
that can be
derived directly from in another way.
Lemma 3 Let forge() and forge() such that
() ends with an
application of a rule in
. Then there is a derivation with goal starting from , and

verifying
() / .
Proof:
Let forge() and forge() be given with
() ending with an appli-

cation of a rule in
. Let be
() without its last rule, i.e.
() is
followed by
. Let
be the derivation obtained from
() by replacing every
decomposition
of by . Then
is a correct derivation, since generates and

which are the two direct subterms of ( is obtained by a composition). does not
contain a decomposition
of by denition of
(), since it already contains

a composition of . Hence
build from , satises
() /
, and the lemma

follows.
We now state and prove our main property:
Proposition 3 Given a normal attack (, ), for any variable and any subterm of
(), we have .
Proof:
We prove this proposition by contradiction. That is, let (, ) be a normal attack with
( ()), and assume (*) / .
Let be minimal such that (
). It exists by denition of , since

there exists at least one protocol step containing the variable which value contains .
Consequently, there exists (
) such that is a (strict) subterm of (),

since otherwise (
) such that = , and (*) would be contradicted.

Moreover, by denition of any variable (including ) must be received before it is sent,
which means here that (
) since is minimal.
It follows that / (
0
, ..,
1
) but (
). However, we also
know that
forge(
0
, ..,
1
), meaning that necessarily
() with
=
(
0
, ..,
1
): only
rules can create new subterms along a deriva-

tion. We note that / (by denition of composition rules). By truncating up
to
(), it follows that :

forge(
0
, ..,
1
)
Second, we use the fact that can be built from
0
, ..,
1
to create a new and
smaller attack from . Let =
(
0
, ..,
1
). Thanks to the minimality of
, is not a subterm of
0
, ..,
1
, and thus, thanks to lemma 1 we know that
ends with a composition rule. We denote by the replacement of every occurrence of
in a term by . The replacement is extended to sets of terms, substitutions and
rules in the natural way. The new attack we are interested in will be dened by
=
and the same execution order as for , at the condition that every messages
can
still be build by the intruder from
0
, ..,
1
, for any . This is what we prove now:

Thanks to (*), including
and
for any , we have
= () =
(). Thus, this is simply denoted as .
If < , then / (
,
0
) with
0
=
0
, ..,
1
, and thus,
forge(
0
).
If , then thanks to Lemma 3 applied on , there exists a derivation
1

1

2
...
with goal
, starting from
0
=
0
, ..,
1
, and such that ,
(),
i.e. where is never decomposed. We show that for any = 1..,

forge(
1
):
If
() with = , or = {}
a
or = {}
s
, then either =
i.e.
forge(
1
) since can be build from and , or = i.e.
forge(
1
) since
0

1
.
If
() with = , or = {}
a
or = {}
s
, then = by con-
struction of the derivation. Therefore, is non-atomic and can be decomposed
i.e.
1

()

, meaning that
forge(
1
).
By iteration on from 1 to , it follows that
forge(
0
), and thus :
forge(
0
, ..,
1
)
Consequently, (
, ) denes an attack. However, this violates the minimality of (, )

as a normal attack (see Denition 4), since every occurrences of the non-atomic term
in were replaced by . Please note that is counted in the size of an
attack, even if it is not a subterm of . Also, appears in at least once. Therefore, the
hypothesis (*) is contradicted, which proves the proposition.
We can now use this property to bound the DAG-size of every (), and even all the
messages exchanged during a normal attack. This is shown in the following theorem:
Theorem 1 If is the substitution in a normal attack, then for every we have
. In particular, this holds for = , or = {
}
0
..
1
with = 1.., or = {}
0
..
.
Proof:
Let and be as above. That is,
= () () with the
number of elements in . Let be in (). By construction, there exists
such that (). Therefore, we have two cases depending on where occurs in
: either =
with
(), i.e. ; or (()) with (),

and thus thanks to Proposition 3, . Since in both cases we have , it
follows that () , and thus :
since applying to a set preserves or reduces its cardinality.

4.2. Decision Algorithm for Active Attacks
We are now going to present a NP decision procedure for nding an attack. The proce-
dure amounts to guess a correct execution order and a possible ground substitution
with a polynomially bounded DAG-size, and nally to check using the algorithm pre-
sented before for passive attacks that at each protocol step, the intruder can produce the
mesasge expected by honest participants.
We assume that we are given a protocol specication {(,
) }. Let
= {
}, a secret message and a nite set of messages

0
for initial
intruder knowledge. If ,
0
are not given in DAG-representation, they are rst converted
to this format (in polynomial time). We assume that the DAG-size of ,
0
, is ,
and the nite set of variables occuring in is .
The procedure for checking the existence of an active attack is written in Algo-
rithm 2. We discuss its correctness and complexity below, rst for a single session then
for the several ones.
1: INPUTS: Protocol specication , set of terms
0
, and term .
2: Guess a correct execution order :
{1, .., } with =
3: Guess a ground substitution such that
4: Let
1
()
and
1
()
for {1..}
5: Let
+1
be .
6: For each {1.. + 1}, check that
forge({
< } {
0
})
using Algorithm 1
7: If each check is successful then answer YES, otherwise answer NO.
Algorithm 2. NP Decision Procedure for the Insecurity Problem
4.2.1. Single Session Case
Let us rst remark that the procedure in Algorithm 2 is NP. A correct execution
order is a permutation of a subset of , and can be guessed in polynomial time. A ground
substitution such that
can be guessed in polynomial time : rst, guess

an ordered list of nodes, , and equip each of them with a label (either a binary
operator from the term algebra, an atom in or ), plus two edges pointing to
higher ordered nodes if the label was a binary operator, and none if it was an atom in
or ; by construction this denes an acyclic graph of size at most polynomial in
, representing a set of terms . This representation is not minimal as a DAG, but we
reduce it to a DAG representation by eliminating duplicate nodes (i.e. with same label
and same childs) in polynomial time. Now, we guess by choosing a term in as the
value of for each variable in . Finally, we know from Section 3 that the passive
attack decision algorithm is polynomial, and here it is used at most + 1 times.
We can now see that this procedure is correct and complete since it answers YES if
and only if the protocol has an attack. If an attack exists, then one of the smallest attacks
on this protocol is a normal attack, dening a correct execution order and a ground
substitution which are possible guesses for the algorithmsince the passive attack decision
algorithm is complete. On the other hand if the procedure answers YES, the verication
performed on the guessed substitution proves that the protocol has an attack, since the
passive attack decision algorithm is correct.
4.2.2. Multiple Sessions Case
We simulate the execution of several sessions of a protocol by the execution of a
single session for a more complex protocol
of size polynomial in where is

the number of sessions. Therefore this will reduce immediately the security problem for
several sessions to the security problem for one session and will show that the insecurity
problem is in NP for multiple sessions too. Note that the principals may have some
common initial knowledge in different sessions. Hence the sessions are not necessarily
disjoint.
We assume given a protocol specication with its associated partial order < on
a set of steps . Let be the number of sessions of this protocol we want to study,
let be the set of variables in and let be the set of nonces (a subset of
) in . The nonces are given fresh values at each new session by denition. Also
variables from different sessions should be different. This is because we consider that
in this model messages are not memorized from one session to another (except maybe
by the intruder). Therefore we shall dene renaming functions
, for = 1.., as
bijections from to new sets (mutually disjoint and disjoint from
) such that:
() =
for all
() =
for all
() =
for all
We assume that each set of steps
for = 1.., is provided with a partial order <
such that for all ,
and for all
, <
iff
<
. Let
be the protocol obtained by applying the renaming
to . We have now copy
,
= 1.., of the protocol. We combine them now into a unique protocol denoted .
as follows. The set of steps is by denition the union
=1
of the steps in all copies
, for = 1... The partial order on

=1

is dened as

=1
<
. It is easy to see
that the execution of one session of the new protocol is equivalent to the execution of
interleaved sessions of the initial protocol.
Lemma 4 Let
0
be the initial intruder knowledge. The DAG-size of (.,
0
) is (
) where is the DAG-size of ,
0
.
Therefore a normal attack of . can be bounded polynomially:
Corollary 1 If is the substitution in a normal attack of . assuming that the initial
intruder knowledge is
0
and the DAG-size of (,
0
) is , then can be represented in
(( )
2
).
Then applying the NP procedure for one session we derive immediately:
Theorem 2 Protocol insecurity for a nite number of sessions is decidable and in NP.
5. Complexity
We show now that the existence of an attack when the input are a protocol specication
and initial knowledge of the intruder is NP-hard by reduction from 3-SAT. The proof
is similar to the one given by [1] for their model, but does not need any conditional
branching in the protocol specication. The propositional variables are
1
, ..,
=

,
and an instance of 3-SAT is (
) =
,1
,1

,2
,2

,3
,3
) where , {1..3},
,
{
1
, ..,
},
,
{0, 1}, and
0
(resp.
1
) means (resp.).
The idea of the reduction is to let the intruder generate a rst message,
1
, ..,
,
representing a possible solution for this 3-SAT problem. From this initial message a
principal creates a term representing the instance of the formula by this solution.
Then the intruder will use the principals , , as oracles for verifying that this instance
can be evaluated to . In order to do it the intruder will have to select an adequate
protocol execution where each principal checks the truth of a literal in a conjunct. For
instance when the rst literal of a conjunct is a propositional variable (resp. a negated
variable), principal checks whether this variable was assigned the value (resp. ).
If the execution can be achieved then gives the term to the intruder, and the
protocol admits an attack.
Let us describe now the protocol. We introduce two atomic keys and , and an
atomic termfor representing the boolean value False. The encryption by will encode
negation, and thus, the boolean value True is represented by = {}
s
. This coding
of 3-SAT do not requires e.g. that
{
{}
s
}
s
reduce to , so multiple encryption with

over do not represent any specic boolean value. The symmetric key exists for
storing data under process. Then we dene :
(0,
,
) =
,
and (1,
,
) = {
,
}
s
) = (
,1
,
,1
), (
,2
,
,2
), (
,3
,
,3
) for all
The protocol variables , , occurring in the description of step (, ) should be
considered as indexed by (, ); the index will be omitted for readability. The partial
order on the protocol steps is the empty order. Hence the protocol steps can be executed
in any order. Note also that the number of steps for each principal , , is equal to the
number of conjuncts in the 3-SAT instance.
Principal A: (, 1),
1
, ..,
{
1
(
),
2
(
), ..,
), }
s
Principal B: (, ),
{
{}
s
, , ,
}
s
{}
s
for .
Principal C: (, ),
{
, {}
s
, ,
}
s
{}
s
for .
Principal D: (, ),
{
, , {}
s
}
s
{}
s
for .
Principal E: (, 1), {}
s

We take
0
= {, } as the initial intruder knowledge. Remember that =
{}
s
. By looking at this protocol, it is obvious that with such poor initial knowledge,
there is an attack iff the message sent by principal A can be reduced to {}
s
i.e. for
all , there exists {1, 2, 3} such that (
,
,
,
) = . But this means that
the intruder has given to a term representing a solution of 3-SAT, since (
,
,
,
) is
,
. Hence the protocol admits an attack iff the corresponding 3-SAT problem has a
solution. Moreover this reduction is obviously polynomial. Hence the problemof nding
an attack with bounded sessions is NP-hard.
The example above shows that the insecurity problem is NP-hard for protocols with
pairs, but without composed keys and without variables in key positions. But we can ob-
tain hardness for a class of protocols with different restrictions. The next protocol shows
that the insecurity problem remains NP-hard even without pairs, without composed keys
and with a unique honest principal whose steps are linearly ordered. On the other hand
we need to use variables at key positions.
Hence our next result will show that nding an attack to a single session of a se-
quential protocol is already an NP-hard problem. Therefore the non-determinism of the
intruder is sufcient for the insecurity problem to be NP-hard.
Let (
) =
=1

be an instance of 3-SAT following the same denition as

above (for the rst protocol), and let be the number of propositional variables of

.
In the following, and are protocol variables and we suppose that their occurrences
represent different variables in different steps of the protocols i.e. they are implicitly
indexed by the protocol steps. To each propositional variable
we associate an atom
, for = 1, . . . , . The initial intruder knowledge includes only these terms:

1.
{
{}
s
}
s
,
{
{}
s
}
s
, and . The intruder will assign boolean values to
by using {}
s
or {}
s
.
2.
{
{}
s
}
s
and
{
{}
s
}
s
, for = 1... These are faked values for

al-
lowing the intruder to skip some protocol steps when needed. But doing that,
he will not gain any useful knowledge.
We use only one honest principal , and the protocol steps of are linearly ordered by:
(, (, )) < (, (
)) iff <
or =
and <
, for = 0, . . . , + 1 and
= 1, . . . , :
(, (0, )) : {}
s
{}
s
In these steps, the intruder selects values for

. Since there is one and only one
step for each value
, the instantiation of

is complete and non redundant. Since the
intruder does not know , these values can only be {}
s
or {}
s
.
For each conjunct indices , 1 , and for each , 1 , such that
is
a variable in the conjunct
, let us dene the step (, (, )) as :

(, (, )) :
{
{}
s
}
s
}
s
if
occurs positively in
or
(, (, )) :
{
{}
s
}
s
}
s
if
occurs negatively in
The goal of the intruder is to know all terms
: this would prove that every

conjunct
is evaluated to . To do this, he must use for a value he knows in or-

der to decrypt at least one message {
}
s
for each . However the intruder has

only two possible actions: either he sends to the message
{
{}
s
}
s
or the mes-
sage
{
{}
s
}
s
but then he will receive back {
}
s
which is useless (this step

can be considered as blank for the intruder), or he has assigned to
the correct value

{
{}
s
}
s
or
{
{}
s
}
s
, and by sending it to at the right step he will get back

{
}
s
that he can decrypt with to get
.
The last protocol step is to ensure that the intruder knows each
. For this
purpose let us introduce an atom that will be revealed to the intruder iff he
knows every atom
. The last protocol step is:

(, ( + 1, 0)) :
{
..{}
s
1
..
}
s
.
Therefore, the intruder knows if and only if each conjunct
is eval-
uated to , and this protocol has an attack on if and only if the 3-SAT in-
stance admits a solution. This shows the correctness of the reduction, which is obviously
polynomial.
It is interesting to see that the class of protocols considered in the previous reduction
is very close to the simple class of ping-pong protocols [10]: the only difference is the
use of variables as keys (but these variables can take only atomic values).
Decomposition rules Composition rules
() : , with =
{}
s
() : , with =
{}
s
() : , with =
{}
a
() : , with =
{}
a
1
Table . Extension of the Intruder Model.
From the results above we nally conclude with the main result:
Theorem 3 Finding an attack for a protocol with a xed number of sessions is an NP-
complete problem.
6. Conclusion
By representing messages as DAGs we have been able to prove that when the number of
sessions of a protocol is xed, an intruder needs only to forge messages of linear size in
order to nd an attack. This result admits obvious practical implications since it gives an
a priori bound on the space of messages to be explored for nding aws in the protocol
(with a model-checker, for instance). We have then derived an NP-procedure for nding
an attack with a xed number of sessions and composed keys. This result matches the
lower bound of the problem. Several interesting variants of our model can be reduced to
it. These variants are also easy to implement.
First we could consider that a principal is unable to recognize that a message sup-
posed to be encrypted by some key has really been constructed by an encryption with
. This can be exploited to derive new attacks: if we assume that the rules in Table
are added to the intruder model, then new attacks can now be performed as shown in the
following example (the message is omitted).
Protocol Rules Attack
((, 0), {}
a
((, 1), {}
a
1
) () =
{
{}
a
}
a
((, 2),
{
{}
a
}
a
) () =
since {}
a
{}
a
,
{
{}
a
}
a
}
a
1
and (, 1) produces
{
{}
a
}
a
and (, 2) produces
Obviously, such an attack cannot be performed if the
rules are not included in the

intruder rewrite system. Since simple cryptographic systems verify the property that en-
cryption is idempotent, it might be interesting to add these new
rules. Moreover, it is
in fact quite easy to prove that the insecurity problem remains NP-complete when these
and
rules are included: they behave exactly in the same way as
and
, allow-
ing us again to restrict ourselves to consider only some special derivations. See [20] for
more informations on this.
We have only considered secrecy properties so far. However, correspondence prop-
erties like authentication, integrity, some kinds of fairness, etc.. can also be expressed us-
ing an appropriate execution order and a polynomial number of forge constraints. Thus,
they can also be detected in NP time.
2
2
Without Nonces With Nonces
No bounds [13] Undecidable Undecidable
Innite number of sessions, and bounded messages [12] DEXPTIME-complete Undecidable
Finite number of sessions, and unbounded messages NP-complete NP-complete
Table . Known results
Moreover, protocols with more complex control can also be decided in NP, as long
as executions can be described in polynomial space and checked on a polynomial number
of protocol steps in polynomial time. In particular, branching or synchronizations are not
a problem, thus allowing honest participants to make choices.
Finally, let us notice that our model remains valid when the intruder is allowed to
generate any number of new data: we simply replace in an attack all data that is freshly
generated by the intruder by its name . Since honest agents do not test inequal-
ities, especially inequalities between data obtained from the intruder, all the constraints
are satised and the attack still works. Moreover, even allowing inequalities is possible :
since in each attack at most a polynomial number of inequalities can be performed, at
most a polynomial number of nonces are required, and thus, they can be picked up from
the (nite) set of Atoms. This implies that in the nite session case, the intruder does not
gain any power by creating nonces. We can summarize the known results in the Table .
More extensions of the presented results, especially by adding algebraic properties
to the protocol and intruder models, can be found e.g. in [5,6,16].
References
[1] R. Amadio and D. Lugiez. On the reachability problem in cryptographic protocols. In C. Palamidessi,
editor, Proceedings of Concur, LNCS 1877, pages 380394. Springer-Verlag, 2000.
[2] A. Armando, D. Basin, Y. Boichut, Y. Chevalier, L. Compagna, J. Cuellar, P. Hankes Drielsma, P.-C.
Ham, O. Kouchnarenko, J. Mantovani, S. Mdersheim, D. von Oheimb, M. Rusinowitch, J. Santiago,
M. Turuani, L. Vigan, and L. Vigneron. The AVISPA Tool for the automated validation of internet
security protocols and applications. In K. Etessami and S. Rajamani, editors, 17th International Confer-
ence on Computer Aided Verication, CAV2005, volume 3576 of Lecture Notes in Computer Science,
pages 281285, Edinburgh, Scotland, 2005. Springer.
[3] I. Cervesato, N. Durgin, P. Lincoln, J. Mitchell, and A. Scedrov. A meta-notation for protocol analysis.
In Proceedings of the 12th IEEE Computer Security Foundations Workshop: CSFW99, pages 5569.
IEEE Computer Society Press, 1999.
[4] Y. Chevalier. Rsolution de problmes daccessibilit pour la compilation et la validation de protocoles
cryptographiques. Phd thesis, Universit Henri Poincar, Nancy, deecember 2003.
[5] Y. Chevalier, R. Ksters, M. Rusinowitch, and M. Turuani. An NP Decision Procedure for Protocol
Insecurity with XOR. In Proceedings of the Logic In Computer Science Conference, LICS03, pages
261270, 2003. http://www.avispa-project.org.
[6] Y. Chevalier, R. Ksters, M. Rusinowitch, M. Turuani, and L. Vigneron. Deciding the Security of Proto-
cols with Dife-Hellman Exponentiation and Products in Exponents. In Proceedings of FSTTCS2003,
Lecture Notes in Computer Science. Springer-Verlag, 2003.
[7] E. M. Clarke, S. Jha, and W. R. Marrero. Using state space exploration and a natural deduction style
message derivation engine to verify security protocols. In Programming Concepts and Methods, IFIP
TC2/WG2.2,2.3 International Conference on Programming Concepts and Methods (PROCOMET 98)
8-12 June 1998, Shelter Island, New York, USA, volume 125 of IFIP Conference Proceedings, pages
87106. Chapman & Hall, 1998.
[8] H. Comon-Lundh, V. Cortier, and E. Zalinescu. Deciding security properties for cryptographic protocols.
application to key cycles. ACM Trans. Comput. Log., 11(2), 2010.
3
3
[9] R. Corin and S. Etalle. An Improved Constraint-Based System for the Verication of Security Protocols.
In Proceedings of SAS 2002, LNCS 2477, pages 326341. Springer-Verlag, 2002.
[10] D. Dolev and A. Yao. On the Security of Public-Key Protocols. IEEE Transactions on Information
Theory, 2(29), 1983.
[11] W. F. Dowling and J. H. Gallier. Continuation semantics for owgraph equations. Theor. Comput. Sci.,
44:307331, 1986.
[12] N. Durgin, P. Lincoln, J. Mitchell, and A. Scedrov. Undecidability of bounded security protocols. In
Proceedings of the Workshop on Formal Methods and Security Protocols, 1999.
[13] S. Even and O. Goldreich. On the security of multi-party ping-pong protocols. Foundations of Computer
Science, Annual IEEE Symposium on, 0:3439, 1983.
[14] A. Huima. Efcient innite-state analysis of security protocols. In Proceedings of the FLOC99 Work-
shop on Formal Methods and Security Protocols (FMSP99), 1999.
[15] F. Jacquemard, M. Rusinowitch, and L. Vigneron. Compiling and Verifying Security Protocols. In
M. Parigot and A. Voronkov, editors, Proceedings of LPAR 2000, LNCS 1955, pages 131160. Springer-
Verlag, 2000.
[16] Z. Liang and R. M. Verma. Correcting and Improving the NP Proof for Cryptographic Protocol Inse-
curity. In Information Systems Security, 5th International Conference, ICISS 2009, Kolkata, India, De-
cember 14-18, 2009, Proceedings, volume 5905 of Lecture Notes in Computer Science, pages 101116.
Springer, 2009.
[17] F. Martinelli and T. C. N. R. Analysis of security protocols as open systems. Theoretical Computer
Science, 290:10571106, 2003.
[18] J. K. Millen and G. Denker. Capsl and mucapsl. Journal of Telecommunications and Information
Technology, 4:1627, 2002.
[19] J. K. Millen and V. Shmatikov. Constraint solving for bounded-process cryptographic protocol analysis.
In ACM Conference on Computer and Communications Security, pages 166175, 2001.
[20] M. Rusinowitch and M. Turuani. Protocol Insecurity with Finite Number of Sessions is NP-Complete.
In 14th Computer Security Foundations Workshop (CSFW-14 2001), June 11-13, 2001, Cape Breton,
Nova Scotia, Canada, pages 174. IEEE Computer Society, 2001.
[21] M. Turuani. Scurit des Protocoles Cryptographiques: Dcidabilit et Complexit. Phd thesis, Univer-
sit Henri Poincar, Nancy, december 2003.
[22] M. Turuani. The CL-Atse Protocol Analyser. In Term Rewriting and Applications - Proc. of RTA,
volume 4098 of Lecture Notes in Computer Science, pages 277286, Seattle, WA, USA, 2006.
Constraint solving techniques and
enriching the model with equational
theories
Hubert COMON-LUNDH
a
and Stphanie DELAUNE
a
and Jonathan K. MILLEN
b
a
CNRS, ENS Cachan & CNRS
b
The MITRE Corporation
Abstract. Derivability constraints represent in a symbolic way the innite set of
possible executions of a nite protocol, in presence of an arbitrary active attacker.
Solving a derivability constraint consists in computing a simplied representation
of such executions, which is amenable to the verication of any (trace) security
property. Our goal is to explain this method on a non-trivial combination of primi-
tives.
In this chapter we explain how to model the protocol executions using derivabil-
ity constraints, and how such constraints are interpreted, depending on the cryp-
tographic primitives and the assumed attacker capabilities. Such capabilities are
represented as a deduction system that has some specic properties. We choose as
an example the combination of exclusive-or, symmetric encryption/decryption and
pairing/unpairing. We explain the properties of the deduction system in this case
and give a complete and terminating set of rules that solves derivability constraints.
A similar set of rules has been already published for the classical Dolev-Yao at-
tacker, but it is a new result for the combination of primitives that we consider.
This allows to decide trace security properties for this combination of primitives
and arbitrary nite protocols.
1. Introduction
A protocol species a set of roles, each of which is a template for a nite sequence of ac-
tions that send or receive messages. Each role may be instantiated any number of times;
the instances are sessions. A trace of a protocol is a global sequence of actions that is an
interleaving of a nite number of sessions. A protocol has many possible traces, depend-
ing on how many sessions there are, and on the particular interleaving. Even when such
an ordering of actions is xed, there are still many (actually innitely many) possible in-
stances of a trace with the same sequence of actions, because the intruder may affect the
content of the messages by intercepting sent messages and forging received messages.
In this chapter, we introduce derivability constraints. Such constraints represent in
a symbolic and compact way which trace instances are possible, when an interleaving of
actions is xed. Then the existence of an attack can be expressed as the satisability of
the derivability constraints, together with the negation of the security goal. For instance,
if the security goal is the condentiality of some data , then the protocol is secure if
the derivability contraints, together with the derivability of , is unsatisable. Hence, de-
IOS Press, 2011
doi:10.3233/978-1-60750-714-7-35
35
ciding the satisability of a derivability constraint (together with some other formula)
yields, as a particular case, an alternative to the decision algorithm described in the previ-
ous chapter. We may however, in addition, consider other security properties, that can be
expressed as properties of symbolic traces. Typical examples of such properties include
agreement properties or timing properties.
Derivability constraints and their satisability were rst introduced in [33]. Since
then, the approach has been followed by many papers, which show the decidability of the
problem in many different settings, depending on the cryptographic primitives and the
supposed properties that they satisfy (e.g. exclusive-or [19,11], some algebraic properties
of modular exponentiation [10,34,15,8], monoidal equational theories [24]).
In this chapter, we explain a method for simplifying derivability constraints when
the security primitives consist in exclusive-or, symmetric encryption/decryption and pair-
ing/unpairing. In principle, the same method can be applied to numerous other crypto-
graphic primitives, adapting however the underlying set of simplication rules. The pro-
cedure that we describe in this chapter is actually a generalization of the known proce-
dures for such primitives [19,11]: we provide with a constraint simplication algorithm
that transforms a constraint into nitely many equivalent and simpler ones, called solved
forms. This allows us not only to decide the existence of a solution, but also to represent
all solutions. Such a feature is used in [16] for deciding trace properties such as authenti-
cation and key cycles in security protocols, and also in [26] for deciding game-theoretic
security properties such as abuse-freeness. As far as we know, the result presented here
is new. Some proofs that are not detailed in this chapter can be found in [18].
Finally, we claim that our decision procedure is simple: we only give a few transfor-
mation rules that are applied to constraints until they are solved. The difcult part is then
the design of a complete and terminating strategy. In this introductory chapter, we do not
try to get the best performance. There are many possible optimizations that we discuss
only briey. We prove, however, the correctness, completeness and termination of the
constraint solving method, along the same lines as [16], but extending the primitives with
an exclusive-or operator.
Before introducing the derivability constraints in Section 3, we discuss in Section 2
the intruder capabilities. The main idea of the constraint solving technique is to search
for an intruder strategy, only considering strategies that are optimal. In other words, an
intruder may have several ways to compute a given message, some of which are simpler.
Then, when solving the derivability constraints, we only look for the last step of an
intruders proof that is optimal, until the constraint is solved.
Outline. In Section 2, we review the various ways of describing the intruders capa-
bilities. In Section 3, we introduce the constraint solving approach and its relationship
with the security analysis of protocols. In Section 4, we give a more detailed exposi-
tion of the constraint solving method, in the case of symmetric encryption, pairing, and
exclusive-or.
2. Intruder capabilities
2.1. Messages
In the formal setting that is considered in this chapter, messages are terms that are built
from a set of function symbols . These function symbols allow us to represent crypto-
H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model 36
graphic primitives. Here is a sampling of typical function symbols. We will not use all of
them.
pairing and projections: , ,
1
(), and
2
();
symmetric encryption/decryption: {}
s
, and {}
s
;
asymmetric encryption/decryption: {}
a
, and {}
a
;
private and public keys for asymmetric encryption: dk(), and pk().
signature and signature check: []
, and []
;
signature key and verication key for signature: sk(), and vk();
hash function: hash();
exclusive-or: ;
random numbers, symmetric keys: , , , . . .
The set of terms () (or messages) is untyped in our denitions. A typed version
can be encoded using tags and possibly additional function symbols and rules. We as-
sume that typing and type-checking is performed in an explicit way, which we believe is
the most conservative solution.
We may need to consider messages with unknown (arbitrary) parts; given a set of
variables , the set (, ) is the set of terms built from and the variables in .
We denote by vars() the set of variables that occurs in . We also use substitutions. A
substitution = {
1

1
, . . . ,
} is the simultaneous replacement of
with
for every 1 . We require that no
may occur in any
. We denote by the
term that results from the application of the substitution to the term . Occasionally it
is convenient to regard as a conjunction of equations
1
=
1
...
. We
denote by top() the top symbol of the term , i.e. the function symbol that occurs at its
root position.
2.2. Deductions
In a formal security analysis that follows the Dolev-Yao model [25], the intruder is as-
sumed capable of intercepting all messages in the network, and deriving new messages
from prior messages by decomposing and composing them. The ability of an intruder
to create a message from others can be inferred either from relations in an equational
theory or from deduction rules expressing possible intruder derivations. For example, the
intruder may derive from {}
s
and the key either by noticing that {{}

s
}
s
=
or by applying the deduction rule:
{
1
}
s
1
Deduction rules state that any instance of the conclusion can be computed by the
intruder from a corresponding instance of the premisses.
Example 1 A possible set of deduction rules for asymmetric encryption, signatures and
pairing is described below. There are several small variants of these rules, which we do
not describe here.

(P)
,
,
(U
1
)
,
(U
2
)

(AE)
{}
a
{}
a
pk()
dk()
(AD)
(PK)
pk()

(S)
[]
[]
sk()
vk()
(V)
(VK)
vk()
The balance between equations or deduction rules to specify intruder capabilities
depends on the rest of the formalization, and on the algorithms that will be used in the
analysis. There is no choice if the message algebra is a free algebra that has no destruc-
tors. In particular, in a free algebra, decryption {}
s
and projection
(, ) opera-
tions are not available, and intruder decomposition capabilities are necessarily modeled
by deduction rules. The loss of generality entailed by the use of a free algebra, and the
cure for it, is discussed in [32] and [30]. As we will see below, there are cryptographic
primitives such as exclusive-or (see Example 2) that cannot be expressed fully and sat-
isfactorily with deduction rules. We need to model them by the means of an equational
theory. An equational theory E is a set of equations between terms. Given two terms
and , we write =
E
if the equation = is a consequence of E.
Example 2 The equational theory E
for the exclusive-or operator is dened by the

following equations:
( ) = ( ) =
= 0 0 =
The symbol is a binary function symbol whereas 0 is a constant. The two rst equations
modeled the associativity and commutativity properties of the symbol whereas the two
last ones modeled the nilpotency and the fact that 0 is a neutral element.
For instance, consider three distinct constant symbols , , and . We have that
( ) =
E
whereas =
E
.
Having decided upon the split between deduction rules and a set of equations E, we
can dene the derivability relation, denoted , that represents the intruder capability
to derive a message from a set of available messages .
Denition 1 (derivability relation) The derivability relation is dened as the least
relation such that, when is a nite set of terms and and are terms, we have that:
when ;
when there is a term such that =
E
and ;
if there is a deduction rule
1
. . .
and a substitution such

that = and
for every {1, . . . , }.

Example 3 Let = {{}
a
pk()
, vk(), [dk()]
sk()
}. Using the rules given in Example 1,
we may model the deduction of from the set of terms as follows:
{}
a
pk()
[dk()]
sk()
vk()
dk()
In many cases, equations like {{}

s
}
s
= can be oriented to form term rewriting

rules, in this case {{}
s
}
s
. If the resulting term rewriting system is convergent,

any term has a unique normal form , which is obtained by applying the rewriting
rules in any order and as long as possible. In that case, is a canonical representative
of the equivalence class of with respect to =
E
, i.e. =
E
if, and only if, = .
If, in addition, there is no premisse of any deduction rule that overlaps a left side of a
rewriting rule in a non-trivial way, we may simply apply a normalization step after each
deduction step.
In some cases, it is not possible to get a nite convergent rewriting system from the
set of equations, nor to turn the equations into nitely many deduction rules. A typical
example is the set of equations given in Example 2 and that allows one to model the
exclusive-or operator. The associativity and commutativity properties of the symbol
prevent us from getting a convergent rewriting system. Usually, such symbols are con-
sidered as varyadic: we may write
1

, since the parentheses (and the ordering)

on
1
, . . . ,
are irrelevant. Keeping such a at representation is useful, since the AC

properties consist only in rearranging the arguments of a operator, without changing
the structure of the message. This requires, however, an innite (yet recursive) set of
deduction rules, relying on an extended rewriting system.
Fromnowon, we use only the deduction rules, rewrite rules, and equations displayed
in Figure 1. For simplicity, we only keep symmetric encryption and pairing, and do not
consider asymmetric encryption and signatures. Notice that some exclusive-or equations
have been oriented into rewrite rules; this set of rules is convergent (modulo the equa-
tions): every term has a unique normal form modulo associativity and commutativity,
which we write . The set of equations then only consists of permutative equations (on
attened terms). We will omit the index E in =
E
, leaving implicit both the attening and
the possible permutation of arguments.
Example 4 Let = {{}
s
, {}
s
, {}
s
}. We show that , using the

rules described in Figure 1. First, we show that {}
s
and . Indeed, the two

derivations
1
and
2
described below are witnesses of these facts.
1
=
{}
s
{}
s
{}
s
{}
s
(XOR)

(SD)
(XOR)
{}
s

Deduction rules:
(XOR)
(
1

)
for any
1

2
(P)
1
,
2
1
,
2
(U
1
)
1
,
2
(U
2
)
1

2
(SE)
{
1
}
s
2
{
1
}
s
2
(SD)
1
Rewrite rules: 0 0
Equations:
1

=
(1)

()
for any and any permutation .
Figure 1. Deduction rules, rewriting rules, and equations for encryption, pairing, and exclusive-or.
2
=
{}
s
{}
s
{}
s
(XOR)

(SD)
{}
s
{}
s
(XOR)

(XOR)
Now, it is easy to see that .

2.3. Proofs
The intruders deductions are represented as tree proofs, as in the previous example. We
formalize these notions here.
Denition 2 (proof) A proof with respect to a set of deduction rules (and a conver-
gent rewriting system ) is a tree whose nodes are labeled with terms and such that, if
a node is labeled with a term and its sons are labeled with terms
1
, . . . ,
, then there
is a deduction rule
1
, . . . ,
and a substitution such that
for every
1 and = .
The hypotheses hyp() of a proof are the labels of the leaves of . Its conclusion
conc() is the label of the root of . The last deduction rule last() is the instance of the
deduction rule that yields the root. We say that is a proof of if hyp() and
conc() = . Finally, step() is the set of all labels of . A subproof of is a subtree
of . It is also a proof.
Example 5 In Example 4, the proof
1
is such that step(
1
) = { , , {}
s
},
conc(
1
) = {}
s
, hyp(
1
) = = {{}
s
, {}
s
, {}
s
}, and last(
1
) is an
instance of the XOR deduction rule. More precisely, we have that:
last(
1
) =
{}
s

(XOR)
{}
s
.
The instances of the deduction rules (U
1
), (U
2
), and (SD) and instances of the
(XOR) for which the conclusion is not headed with are called decompositions. More
generally, an instance of a deduction rule is a decomposition if its conclusion is a sub-
term of the premisses and is irrelevant in the rewriting/equational steps. By convention,
if is reduced to a leaf, then we also say that last() is a decomposition.
Example 6 The following are instances of deduction rules, that are decompositions:
{ }
s

(SD)

{}
s

(XOR)
{}
s
while the following are instances of deduction rules, that are not decompositions:

(XOR)

{ }
s
{ }
s

(XOR)

An instance of a deduction rule is a composition if its premisses are subterms of the
conclusion. Typical examples of compositions are all the instances of the deduction rules
(SE) and (P). Note that some instances of the deduction rule (XOR) are compositions,
and some others are never compositions, nor decompositions.
Example 7 Consider the following three instances of the deduction rule (XOR):

The rst instance is a decomposition, the second instance is a composition whereas the
third one is neither a composition nor a decomposition.
2.4. Normal proofs
Typical results concerning the deduction rules show that if a term can be derived then
there is a normal proof of it. The notion of normal proof will depend on the intruder
deduction system, but it has the property to avoid any unnecessary detour. Normal proofs
allow us to restrict the search space when looking for an attack.
We dene below the normal proofs for the deduction system given in Figure 1. We
simplify the proofs according to the rules presented in Figure 2. These rules simply
gather together successive (XOR) deduction rules and otherwise, they only remove use-
less parts of the proofs. They are (strongly) terminating: a normal proof is a proof, that
is irreducible with respect to the rules of Figure 2. For other equational axioms or infer-
ence rules, there are also similar simplication and gathering rules [24]. There is how-
ever no general procedure that yields an appropriate notion of normal proofs for arbitrary
equational theories.
Locality is a subformula property that holds on normal proofs. In the denition
that follows, St() is the set of subterms of . Let =
1
. . .
be a term such that

top(
) = for every {1, . . . , }. Then, the strict direct subterms of , also called
the factors of and denoted fact(), are the individual arguments
only.
Denition 3 (local proof) A local proof of is a proof in which

+1

+1

(XOR)

+1

+1

(XOR)
(XOR)

+1

(XOR)

+1

(XOR)
+1
+1

(XOR)
1
(P)
,
1
(U
1
)
(P)
1
,
(U
2
)
1
(SE)
{}
s
1
(SD)
Figure 2. Proof normalization rules

either last() is a decomposition and step() St()
or else step() St( {}).
This general property of proof systems is ensured by our proof normalization process:
Lemma 1 If is a normal proof of then is a local proof of .
Proof:
Let be a normal proof of . Let us prove that is local by induction on the size of
, i.e. its number of nodes.
Base case: If is reduced to a leaf, then and is a local proof of .
Induction step: We distinguish two cases depending on whether last() is a decomposi-
tion or not.
1. If last() is not a decomposition, either hyp(last()) are subterms of its con-
clusion (e.g. an instance of (SE) or (P)) in which case we can simply use the
induction hypothesis, or else we have that
=
{

1

(XOR)
with conc(
) / St() for some .

Let
= conc(
) for {1, . . . , }. We have that = (

1

). By
proof normalization, for every , either last(
) is not a decomposition, and then

top(
) = or else last(
) is a decomposition and, by induction hypothesis,

step(
) St(). Consider an index such that
is maximal (with respect

to the subterm relation) in the set {
1
, . . . ,
}.
If last(
) is not a decomposition, then top(
) = . Furthermore, thanks to the

rewriting rules for , we are in one of the following cases:

is a strict subterm of some
. This is ruled out by the maximality assump-

tion on
for some = . This is ruled out by the proof normalization rules.

= . This is ruled out by the proof normalisation rules

fact() is a strict subterm of (i.e., it does not disappear in the normal-

isation of
1
. . .
).
Since only the last case is possible, every maximal term in {
1
, . . . ,
}, that
is not obtained by a decomposition, is a strict subterm of and therefore, by
induction hypothesis, step(
) St(
) St() St() St().

It follows that for every maximal term in {
1
, . . . ,
}, we have that step(
)
St() St(). Then, for any term
, there is a maximal term
such that
St(
) and therefore St(
) St() St(
) St() St() St().

It follows that, for every , step(
) St() St(), hence step() St()

St().
2. Assume now that last() is a decomposition. We consider all possible rules for
last().
Case 1: The proof ends with an instance of (U
1
) (or (U
2
)), i.e.
=
{

1
(U
i
)
with conc(
1
) is either a pair , or a pair , . In both cases, in order to get
a term whose top symbol is a pairing, last(
1
) must be either a pairing rule or a
decomposition rule. The rst case is ruled out since is a normal proof. Hence
we can apply the induction hypothesis and conclude that step(
1
) St(). It
follows that step() St().
Case 2: The proof ends with an instance of (SD), i.e.
=
{

1

2
(SD)
with conc(
1
) = {}
s
, conc(
2
) = . Since conc(
1
) is headed with an en-
cryption symbol, last(
1
) must be either an instance of (SE) or a decomposi-
tion. The rst case is ruled out since is a normal proof, hence last(
1
) is a de-
composition. By induction hypothesis step(
1
) St(). In particular, we have
that St(conc(
1
)) St(). Now, by induction hypothesis, we have that
step(
2
) St( {}) St(). It follows that step() St().
Case 3: The proof ends with an instance of (XOR), i.e.
=
{

1

(XOR)
Let
= conc(
) for every {1, . . . , }. By hypothesis, we know that

last() is a decomposition, thus top() = and fact(
) for some
{1, . . . , }.
For every , last(
) cannot be an instance of the (XOR) deduction rule, be-

cause is a normal proof. Therefore, if last(
) is not a decomposition, then

top(
) = . It must then be a subterm of some
, = (actually a strict sub-

term since is a normal proof). Thus, the maximal terms in {
1
, . . . ,
} with
respect to the subterm relation, are terms
, such that last(
) is a decomposi-
tion. By induction hypothesis, it follows that, for every {1, . . . , }, we have
that step(
) St() and therefore we have that step() St().
As a consequence, the derivation problem, i.e. given and , the problem of decid-
ing whether is derivable from or not, is in PTIME. We may indeed run a xed point
computation algorithm on the set St( {}). It will terminate in polynomial time, as
long as the one-step deducibility relation is decidable in PTIME, which is the case for our
rules in Figure 1, as well as in many other cases (see [24]). There are several other such
results for some classes of equational theories (e.g. [24,9]). An overview of equational
properties that are relevant to security protocols is given in [21].
3. Derivation constraints: denitions and examples
3.1. Introduction with an example
Consider the awed handshake protocol example described in Figure 3, temporarily re-
turning to a larger set of operations. We want to check, for a xed number of sessions (let
us call this the bounded scenario case), whether or not there is an attack on the protocol
that compromises the secret , which the participant generates and wishes to share
with the participant . This security property turns out to be a trace property, so that we
can check it when we know which protocol traces are possible.
In the bounded scenario case, the number of messages that are exchanged is
bounded. However, as explained in Chapter Verifying a bounded number of sessions and
its complexity, there are still an innite number of possible message instances. Hence
the verication cannot be performed by a simple enumeration of scenarii. The solution
is to use a symbolic representation of sequences of messages, treating uninstantiated
parameters as variables.
Let us show how it works on the handshake protocol described in Figure 3, when
there is one instance of the role (with agent parameters and ) and one instance of
{[]
sk()
}
a
pk()

{}
s
Figure 3. Flawed handshake protocol

the role (with agent parameters and ). The roles are simply threads, in which some
names are hidden: this corresponds to local random generation. To be more precise, we
consider two threads expressed in a spi-calculus style, with pattern matching:
(, ) : . send({[]
sk()
}
a
pk()
). get({}
s
).
(, ) : . get({[]
sk()
}
a
pk()
). send({}
s
).
Note that, in this scenario, the name occurs free in both (, ) and in (, ). It
cannot be renamed in any of the two threads: the name is shared by these threads. Let us
see informally what the thread (, ) does in more detail. First it has , as parameters:
it is a program executed on behalf of an agent , who wishes to communicate with .
Given and , it generates a fresh key (the construction). Then it constructs the
rst encrypted message and sends it. Next, it waits for some message containing the
encryption of some value with . When the message is received, it tries to decrypt
it with . If this succeeds, then it retrieves the message . Otherwise, if the decryption
fails, the program aborts (this is not specied here). The thread (, ) works in a similar
way: rst it waits for a message encrypted with its own public key, and extracts a value
signed by . If the signature checks, it sends back the nonce (secret) encrypted with the
(supposed) key .
Then, these roles are composed, using parallel composition, name hiding and possi-
bly replication, to build scenarii. For instance, (, )(, ) is a scenario where there
is one instance of the role (with agent parameters and ) and one instance of the
role (with agent parameters and ).
The operational semantics of such threads is described (in slightly different avors)
in several papers such as [1,39,37]. The important features are that each of these threads
is executed concurrently in a hostile environment: messages that are sent over the net-
work can be intercepted and modied by an intruder. Therefore, what an agent gets is
the message that has been forged by the intruder from his current knowledge and the
messages that circulated on the network. It is out of the scope of this chapter to dene
a precise operational semantics of such a process algebra (see the chapter Applied Pi
Calculus). It is not always sufcient to consider a small system consisting of only one
thread per role, for security analysis. Conditions under which such small systems are
sufcient are given by Lowe and others [29,35,2].
In this scenario, we assume that the keys pk(), pk(), pk(), vk(), vk(), vk()
are public, hence available to all agents, including the intruder. The other keys are pri-
vate: they are normally held by their owners only. In this example, we suppose that is
compromised: this means that the secret keys dk() and sk() are also available to the
intruder. Finally, the intruder knows the names of the agents, namely , and . Thus,
the total initial intruder knowledge is the set of terms:
init
= {pk(), pk(), pk(), vk(), vk(), vk(), dk(), sk(), , , }.
The next step is to construct the parallel composition of the two sessions. The paral-
lel composition has no more than six possible traces, which are the various interleavings
of the two ordered message actions of each of the two sessions. In general, if there are
two sessions of length and , respectively, the number of interleavings is the number
of combinations (+, ). However, not all of the interleavings are solvable. A trace
is solvable if, and only if, there is a substitution for its variables such that the message
in each get() action is derivable by the intruder from the intruders initial knowledge
plus the messages that have been sent in prior send actions. This condition generates a
derivation constraint for each received message.
Coming back to our running example, one of the interleaving is:
send({[]
sk()
}
a
pk()
), get({[]
sk()
}
a
pk()
), send({}
s
), get({}
s
)
Is it solvable? There are two get actions, hence two derivation constraints:
=
init
, {[]
sk()
}
a
pk()
?
{[]
sk()
}
a
pk()
init
, {[]
sk()
}
a
pk()
, {}
s
?
{}
s
Note that the set of terms on the left of each derivation constraint is actually a union
init
..., but it simplies the notation to write these sets as comma-separated lists. The
difference between a derivation constraint, denoted by
?
, and a derivation, denoted
by , is that the constraint asks for a substitution such that .
Example 8 The constraints in are simultaneously satised by the substitution
= { , }.
The fact that the second constraint is satised is obvious. Indeed, a normal proof of
init
, {[]
sk()
}
a
pk()
, {}
s
{}
s
is actually reduced to a leaf. The fact that the rst

constraint is satised takes some effort to see. A normal proof witnessing this fact is
described below.
{[]
sk()
}
a
pk()
sk()
[]
sk()
pk()
{[]
sk()
}
a
pk()
We still have to ask whether this trace violates the security goal of the protocol. It
does, because the intruder can obtain from []
sk()
and then from {}
s
. There is a
trick to help us gure this out: we add a role () = get() to the protocol and the
scenario. An articial role of this kind, introduced to test a secrecy property, is called a
listener. This means that the action get() must be included in each trace. This causes
a new constraint to be generated, of the form
init
, ...
?
.
A substitution satisfying all the constraints, including this one, will demonstrate that
the secret can be read by the intruder. This reduces detection of secrecy violations to
the basic constraint solution problem.
Before proceeding with the method for solving constraints, we remark that there are
some easy optimizations that relieve us from considering every possible trace. If both of
the traces ....get(). send(
).... and ....send(
). get().... are possible, we can

discard the rst one, because any substitution that satises the constraints arising from
the rst will also satisfy the second. Also, if a trace has consecutive send actions, their
order is irrelevant, so one particular order is sufcient. This means that, when counting
(or generating) interleavings, one need only consider the number and order of get
actions in each session. By a similar argument, a listener action may always be placed
last in a trace.
The basic constraint solving approach, therefore, has two stages: the rst is to gen-
erate a sufcient set of traces, and the second is to generate and attempt to solve the
constraint system arising from each trace. An alternative approach is used in [20]: while
generating traces, attempt to solve the current partial constraint system each time a get
action is added to a trace. If there is no solution, the partial trace need not be extended,
eliminating a subtree of trace continuations. This approach can lead to more solution
attempts in the worst case, but in practice it usually saves considerable time. Constraint
differentiation [4] offers another kind of optimization.
3.2. Derivation constraints
We can now formally dene the notion of a derivation constraint system, which is not
specic to our set of primitives/deduction rules.
Denition 4 (derivation constraint system) A derivation constraint system consists
of a conjunction of equations and a sequence of derivation constraints:
1
?

1

1
?
=
1
. . .
?
=
where
1
, . . . ,
are nite sets of terms. Moreover, we assume that:

Monotonicity:
1

2

,
Determinacy: for every {1, . . . , }, for every
, we have that
{
1
, . . . ,
1
} , where is a nite set of ground terms.
We just saw, with the handshake protocol, how a sequence of derivation constraints
arises from a candidate trace of a protocol scenario. A constraint sequence arising this
way always satises the two properties mentioned above, for some nite set of ground
terms, that represents the initial knowledge of the agents.
The rst condition states that the intruder knowledge is increasing along the protocol
execution. The second condition states that the message , which is emitted at some
stage, can be computed from all data that are possibly available at this stage. We do
not commit here to any particular program that computes , but only state that such a
program must exist, if we assume that the corresponding agent has access to all data. This
is a reasonable assumption, that only rules out non-deterministic choices and possibly
some encodings of complex operations.
Let us remark that the monotonicity and determinacy conditions imply two impor-
tant properties:
Origination: for every {1, . . . , }, for every vars(
), there must be a
< such that vars(
). In particular, we have that vars(

1
) = . Indeed,
if / {
1
, ,
1
}, then / vars() for any term that can be deduced from
{
1
, ,
1
} .
Stability by instantiation: If is a derivation constraint system, then, for every
substitution , we have that is also a derivation constraint system.
These two properties are actually what we need, and they could replace the determi-
nacy property, yielding a more general (yet less natural) denition of constraint systems
(see also [34]).
Example 9 Consider the following sets of derivation constraints:
1
=
?

?

2
= ,
?
, , {}
s
?
, , {}
s
,
?

3
= ,
?
{}
s
, ,
?

4
= ,
?
{, }
s
, ,
?

The set
1
is not a derivation constraint system since it violates the monotonicity
property. The set
2
is not a derivation constraint system, since it violates determinacy
(actually, it violates origination). The set
3
is not a derivation constraint system since
is not derivable from {}
s
for any set of ground terms . Intuitively, the agent

receiving {}
s
cannot retrieve and cannot retrieve without having the key. This set
of derivation constraints could still be handled since it satises the origination and any
instance of it also satises the origination. Lastly,
4
is a derivation constraint system.
In particular, we have that {, }
s
, .
In addition to these constructions, we may need to introduce new variables along
with constraint simplications. In order to keep the set of solutions, we may add existen-
tial quantiers for these new variables, in front of a derivation constraint system.
Actually, we may consider some additional formulas with only slight modications
of the constraint solving technique. Typically, we may wish to add disequalities, either
because our threads contain conditionals or because we wish to express agreement prop-
erties. The constraint solving algorithm is not modied, until the end; we only need to
add a simple test as a last step (see [16]). Similarly, membership constraints (expressing
for instance typing information) or timing constraints can be added with minor changes.
Denition 5 (solution) Given a convergent set of rewrite rules (possibly modulo as-
sociativity and commutativity) and a set of derivation rules that describe the intruder
capabilities (as in Figure 1), a solution of a set of derivation constraints =
1
?
, together with a set of equations , is a substitution of its free

variables such that, for every ,
and, for every equation

?
= in , we
have that = .
Example 10 Consider the following derivation constraint system (with no equation):
=
{}
s
, {}
s
?

{}
s
, {}
s
, {}
s
?

The substitution { } is a solution. A witness of the fact that satises the last
derivation constraint is given in Example 4.
3.3. Solved constraints
A variable is solved in a derivation constraint system if it occurs as a member of an
equation
?
= , and nowhere else in the derivation constraint system. A variable is
pre-solved if it occurs in a derivation constraint
?
such that / vars() and does
not occur in any term such that
?
is a derivation constraint such that
. A
derivation constraint system is solved if it is of the form
1
?
=
1
. . .
?
=

1
?

1
. . .
where
1
, . . . ,
are solved variables and

1
, . . . ,
are pre-solved variables. In partic-

ular, this implies that
1
, . . . ,
are distinct variables.

Lemma 2 A solved constraint systemhas always at least one solution (actually, innitely
many solutions if it is not a trivial system).
Proof:
Let
1
?

1
, . . .
be the derivation constraints that occur in the system, and

assume that
1
. . .
. We construct a solution by induction on .

Base case: = 0. In such a case, the equational part denes a substitution that is a
solution of the constraint.
Induction step: If 1, rst choose
1
=
1

1
and replace
1
with
1
in the
remainder of the constraint. After removing the constraint
1
?

1
, the resulting system
is still a derivation constraint system and it is still solved (since the variables
are
distinct). Then we apply the induction hypothesis.
This lemma can be easily extended, considering additional disequality (resp. mem-
bership) constraints [16]. For instance, if we wish to decide a security property that can
be expressed with equalities (typically an agreement property), then, as explained in in-
troduction, we consider the derivation constraint system, together with the negation of
these equalities. It is satisable if and only if the security property can be violated. If
the derivation constraint is in solved form and there is no trivial disequality, then the
above lemma implies that there is a solution, hence the security property is violated. In
other words, it sufces to simplify the derivation constraints into solved forms (which
may yield some replacements of the variables in the disequality part) and then check the
satisability of the disequality part.
R
1
:
?

1
,
2

?

1

?

2
R
2
:
?
{
1
}
s
2

?

1

?

2
R
3
:
?
.
?
,
R
4
:
?
.
?
,
R
5
:
?
.
?
{}
s

?

R
6
:
?

?

?
if
R
7
:
?

?
= if
Figure 4. Naive constraint reduction rules
This idea can be applied to other security properties than agreement or condential-
ity, as long as they can be expressed with a formula on the same variables as the variables
of the derivation constraints.
4. Solving a derivation constraint system
4.1. Constraint reduction
Constraint reduction (see [33]) is a relatively straightforward and efcient way to solve
a derivation constraint system arising from a candidate protocol trace. It solves a system
iteratively by reducing individual constraints until the system is solved.
Each reduction step should be sound in the sense that any solution of the reduced
constraint system is a solution of the original system. At each step, several reductions
may be possible. Hence, reduction sequences form a branching tree. Some paths may
lead to a failure, while others yield solved forms, hence solutions. A desirable property
is the completeness of the reduction rules: if is a solution of , then there is a possible
reduction of into a constraint system
, of which is a solution. In other words, there

is a path in the tree that will yield a solved constraint system of which is a solution.
We could simply get a sound and complete set of constraint reduction rules by guess-
ing the last intruder computation step. For instance in a system with only symmetric
encryption and pairing, given a constraint
?
such that is not a variable, for any
solution , the last step in the proof of must be a pairing (this is only possible
if is a pair) or an encryption (this is only possible if is a ciphertext), or a decryption
or a projection, or a trivial step (this is only possible if belongs to ). This yields a
naive set of reduction rules, that is displayed in Figure 4.
The two rst rules correspond to pairing and encryption. The three following rules
correspond to projections and decryption. Then, the last one is actually the only one
that builds a solution: we guess here that the proof is completed, as (the instance of)
belongs to (the corresponding instance of) . In addition to such rules, we need an
equality constraint solving rule:
?
= if = mgu(, )
We do not include it in Figure 4 since this rule is a deterministic simplication rule: it
may be applied to any constraint without considering any alternative simplication. By
convention, = is a failure if the two terms are not uniable.
Unfortunately, such rules are too naive: while sound and complete, they will not
terminate, as the three rules that correspond to projections and decryption (namely R
3
,
R
4
and R
5
) can be repeatedly applied any number of times. That is why we do not aim at
reproducing any possible intruders computation, but only some of its computations, and
at least one for each resulting term. This results in using the same set of rules as the above
one, however restricting the three rules R
3
, R
4
and, R
5
; while keeping completeness. This
is, in essence, what is performed in the decision procedures based on constraint solving.
We now give a complete and terminating procedure, including primitives such as
exclusive-or.
4.2. A constraint solving procedure for exclusive-or
We display in Figure 5 a set of constraint simplication rules for a theory of exclusive-or,
pairing and symmetric encryption. The simplication rules exactly reect the intruder
capabilities. They must be applied dont know: this is a non-deterministic procedure, in
which all possible applicable rules must be considered if we wish to get a completeness
result.
Ax :
?

?
= if
C :
?
(
1
, . . . ,
)
?

1
. . .
?

if =
C
:
?

?

?

D
1
:
?

?
,
?
= if , St()
D
2
:
?

?
,
?
= if , St()
D
dec
:
?

?
{}
s

?

?
= if {}
s
St()
D
:
?

?

1
. . .
?

?
=
1
. . .
if
1
, . . . ,
St()
Geq :
?

?

?
= if St() St()
and top() {{_}
s
_
, _, _}
Figure 5. Constraint transformation rules
In addition to these rules, equational constraints are simplied and the resulting
substitutions are applied to the rest of the constraint:
U :
mgu()

Here, mgu() denotes a complete set of most general uniers of modulo E
. Such a
set is nite and has even more properties, as we will see in the Lemma 8. Contrary to the
case of encryption and pairing only, the set of minimal uniers, though nite, may not
be reduced to a singleton.
Example 11 The equation , ,
?
= , , has two most general uniers
1
= { , } and
2
= { , }.
In addition, we simplify the constraints with the rules
S
1
:
?

?

?
if
S
2
:
?

1
?

1

?

1
,
?

1

,
?

if
1
, . . . ,
are all left hand sides such that
, and /
.
We also use two simplications of right members of constraints of the form :
XR
1
:
?

?

?

?
if

XR
2
:
?
.
?

?
=
if / vars() vars() and XR
1
cannot be applied
By convention, newly quantied variables should not occur previously in the con-
straint.
The rules of Figure 5 concerning pairing and symmetric encryption are very similar
to the naive rules of Figure 4. The only differences are the side constraints, that impose
the newly introduced terms to be already subterms of the constraint. We will show that
this is complete. On the other hand, this gives an upper bound on the possible right
members of the constraints, allowing us to derive a terminating strategy.
Example 12 Consider the constraint system given in Example 10 and for which =
{ } is a solution. Let
1
= { {}
s
, {}
s
} and
2
=
1
{{}
s
}. We
have the following transformation sequence that leads to a derivation constraint system
in solved form for which is still a solution. For sake of simplicity, trivial equations are
omitted.
1
?

2
?

S
2
1
?

2
,
?

D
dec
1
?

2
,
?
{}
s
2
,
?

1
?

2
,
?
{}
s
2
,
?

2
,
?

Ax
1
?

2
,
?

2
,
?

1
?

2
,
?

2
,
?
{}
s
2
,
?
{}
s
Ax
1
?

2
,
?

2
,
?
{}
s
Ax
1
?

2
,
?

D
dec
1
?

2
,
?
{}
s
2
,
?

S
1
1
?

2
,
?
{}
s
Ax
1
?

The rules can actually be rened, for instance preventing from applying successively
twice D
on a same constraint (two consecutive rules never occurs in a normal proof).

Some of the rules (for instance Geq) might even be unnecessary.
It is not very difcult to show that the simplication rules S
1
, S
2
, XR
1
, XR
2
, U pre-
serve the set of solutions, hence we may eagerly (and deterministically) apply these rules:
Lemma 3 (soundness and completeness of simplication rules) The simplication rules
U, S
1
, S
2
, XR
1
, XR
2
are sound and complete: they preserve the set of solutions.
Then the rules of the Figure 5 are applied to simplied derivation constraints. It
remains now to prove three main properties:
1. The rules do transform the derivation constraints into derivation constraints, and
they do not introduce new solutions. This is stated in the Lemma 4.
2. If a derivation constraint system is not in solved form, then, for every solution ,
there is a rule that can be applied and that yields another constraint, of which
is a solution; this is the completeness result, which we eventually prove in Corol-
lary 1. This shows that every solution of a derivation constraint can be eventually
retrieved from a solved form.
3. There is a complete strategy such that there is no innite sequence of transforma-
tions. We will prove this last result Section 4.4.
Lemma 4 (soundness of transformation rules) The rules of Figure 5 are sound: they
transform a constraint system into a constraint system
such that any solution of
is also a solution of .
4.3. Completeness of the transformation rules
The completeness would be straightforward for a set of naive rules such as the rules dis-
played in the Figure 4. We imposed however additional restrictions, typically that, for
decompositions, we may only consider the subterms of . This reects the fact that we
may restrict our attention to normal proofs. However, our terms now contain variables.
Thanks to Lemma 1, if is a normal proof of such that last() is a decom-
position, then step() St(). This does not necessarily mean that hyp(last())
are instances of terms in St(), because St() St(). The main difculty for
showing the completeness is to get an analog of Lemma 1, however lifted to terms with
variables. This is what we start in Lemma 5, however with a slightly weaker conclusion.
Lemma 5 Let be a nite set of terms, be a ground term in normal form and be
a substitution mapping the variables of to ground terms in normal form. We assume
moreover that, for every vars(), there is a
and a proof
,
of
,
such that last(
,
) is not a decomposition and, for every vars(
), we have that
. Let be a normal proof of .

If last() is a decomposition, then
either there is vars() and a subproof
of
,
such that conc(
) =
and last(
) is not a decomposition
or else St()
For every
fact(), we have that either
, or else
St().
It is actually not sufcient to consider normal proofs to show the completeness of
our transformation rules. We have to consider normal proofs that are alien-free. In an
alien-free proof, we control the premisses of the instances of the XOR deduction rule.
A proof of is alien-free if, for every subproof
(XOR)
of , for every , either conc(
) St() or conc(
) fact().
Lemma 6 Let be a nite set of terms, be a substitution mapping the variables of
to ground terms in normal form and be a ground term in normal form. We assume
that, for every variable vars(), there is a
and a normal proof

,
of
such that last(

,
) is not a decomposition and, for every vars(
), we
have that
. We assume moreover here that vars() and vars(
for
every variable .
If
0
is a normal proof of , then there is a normal alien-free proof of
.
Example 13 Consider the following derivation constraint system.
, , , ,
?

, , , , , , , { }
s
,
?
,
Let = { , , },
= {, , , , }, and =

{ , , { }
s
, }. We have that {} = vars() , and = vars(
.
The proof
,
described below is a proof of
that does not end with a

decomposition.
,
=

,

,
, ,
Let
0
be the following proof of , .
0
=
{ }
s

( )

,
,
The proof
0
is a proof in normal form whose last step is not a decomposition.
According to Lemma 5, for every
{, , }, we have that either
, or
St(). Indeed, we have that , , and St(). However,

0
is
not alien-free since , is neither in St() nor a factor of , . An alien-free
proof
0
of , is given below:
0
=

,
{ }
s

( )
,
Lemma 7 There is a mapping from derivation constraint systems and substitutions to
a well-founded ordered set such that, for every derivation constraint system and every
solution of , either is in solved form or else there is a constraint system
such that

, is a solution of
, and (, ) > (
, ).
Note that this lemma does not prove the termination of our rules, since we only show
that, for every solution , the derivation sequences of which is a solution is nite. There
might be however an innite sequence of solutions, each yielding a longer derivation
sequence than the previous ones.
As a consequence of this lemma, we get a completeness result, stating that, for every
solution of , there is a solved system that can be derived from and of which is a
solution:
Corollary 1 (completeness) If is a derivation constraint system and is a solution
of , then there is a solved derivation constraint system
such that
and is a
solution of
.
4.4. Termination
The termination can be ensured by a complete strategy on the rules application, as long
as unication reduces the number of variables. This property is true, at least, for the
combination of a free theory and the exclusive-or theory.
Lemma 8 Suppose that is a set of equations over the disjoint combination of the
theory of {, 0} and a free theory with (at least) symmetric encryption and pairing.
Then either has no solution, or every substitution is a solution of , or else there
is a nite complete set of uniers of such that, for any , we have that
vars() < vars().
Proof (sketch):
To establish this result, we rely on the procedure described in [3] for combining disjoint
equational theories. Given a system of equations, we let
be the maximal number

of independent equations in , i.e. we only consider equations that are not a logical
consequence of the other equations (with respect to the considered equational theory).
Then, we show that the difference between
and the number of variables
is non-
decreasing. This allows us to conclude.
This says that the number of new variables introduced by the substitution is less than
the number of variables eliminated by the substitution. The examples below show that it
is sometimes needed to introduce new variables.
Example 14 We consider two sets that are made up of one equation only.
Let = { = ( )}. This set has mgu = { (), () }
where is a new variable. We have that
vars() = = 1 < 2 = {, } = vars().
Let = { = ( ) }. This set has mgu = { (
) ,
(
} where
is a new variable. We have that

vars() = {
, } = 2 < 3 = {, , } = vars().
We use the following strategy: the rules U, S
1
, S
2
, XR
1
, XR
2
are applied eagerly (in
this order) and then the rules of Figure 5 are applied to a constraint
?
such that,
for any
and every constraint
?
, we have that is a variable that does not
occur in
. According to the results of the previous section, this strategy preserves the
completeness.
Let () be the pair (, ) such that is the number of unsolved variables of
and is the number of variables of that are neither solved nor pre-solved. Such pairs
are ordered lexicographically.
Lemma 9 Let and
be two derivation constraint systems such that
, we have
that () (
).
Proof (sketch):
Let us consider successively the transformation rule, including the simplication rules,
for which the statement is not straightforward.
When applying U, either the equation is trivial (in which case () remains con-
stant), or the equation is unsatisable (in which case () is decreasing), or else,
thanks to Lemma 8, there are more variables that become solved than variables
that are introduced. Hence the rst component of () is strictly decreasing.
When applying XR
2
, followed by a replacement of with , the number
of unsolved variables is constant ( was unsolved before applying the rule and
becomes solved after the replacement with ). The number of non-pre-solved
variables is strictly decreasing since was not pre-solved before the rule and ,
are both pre-solved after applying the rule.
The other rules do not introduce new variables: the rst component of () can
only decrease or remain constant. According to our strategy, the only situations in
which the number of pre-solved variables could decrease is when a transformation
rule is applied to a constraint
?
where is a variable. This may happen
with the rules Ax, D
1
, D
2
, D
dec
, D
, that mimic decompositions. But, in these

cases, at least one non trivial equation is added, which yields, after applying U, a
strict decreasingness of the rst component of ().
Now, if a transformation preserves (), then there is no simplication by

U, XR
1
, XR
2
that takes place at this step (except trivial equations simplications), and
the side conditions of the rules ensure that no new subterm appears. More precisely, let
() = St() { , St()}, then we have the following lemma.
Lemma 10 Let and
be two derivation constraint systems such that
and
() = (
), then (
) ().
It sufces then to cut looping branches in order to get a terminating and complete
procedure: according to Lemma 9, from any innite transformation sequence we may
extract an innite transformation sequence
0

1

on which
(
0
) = (
1
) = = (
) = . Then, according to Lemma 10, the set of subterms

in any derivation constraint system of the sequence is bounded by the set of subterms
of the original constraint system
0
. Now, each individual constraint
?
can appear
only once in any constraint system, thanks to S
1
. Therefore, there are only nitely many
derivation constraint systems that can be built once the set of subterms (more precisely
the set ()) is xed. This means that any innite sequence of transformations must be
looping.
Now, remains to justify that cutting the loops still yields a complete procedure. The
reason is that, according to the lemma 7, for every solution of
0
, there is a sequence
0

1

such that is a solution of
and (
0
, ) > (
, ), hence
the sequence does not include any loop, since the ordering on measures is well-founded.
As a conclusion of this section, we get a termination result:
Theorem 1 (Termination) There is a complete strategy such that any simplication se-
quence is nite and yields a solved form.
The termination proof does not give much information about complexity. Further-
more, the strategy is quite rough and can be rened: there is still some work to do, if
we wish to get the shortest simplication sequence. For instance we would need to avoid
repeating several times the same simplications (as explained in [16]).
With such an additional work, the simplication of constraints might yield a NP
decision procedure for the satisability of derivation constraint systems.
4.5. Further results
The constraint solving approach to the security of protocols was introduced in [33]. In
the case of symmetric and asymmetric cryptography, it has been shown to yield a NP
decision procedure (for the existence of an attack) in [36]. For the same set of cryp-
tographic primitives as the one we have shown in this chapter, but without exclusive-
or, a full constraint solving procedure, preserving all solutions, is given in [16]. Such a
procedure allows us to decide more trace properties (such as authentication, key cycles,
timeliness).
Extensions of decision results (for secrecy) to other primitives have been extensively
studied. For exclusive-or there are two concurrent publications [19,11]. However, these
results only provide decision results. In this respect, the procedure that we gave in this
chapter is a new result, since it preserves all solutions; it could be used for deciding other
security properties.
The second most popular equational theories are modeling parts of arithmetic, in
particular modular exponentiation. There is no hope to get a general decision result for
the full arithmetic, as unication is already undecidable. The rst fragment considers
some properties of modular exponentiation that are sufcient for modeling some classical
protocols [31,10,12]. In case of an Abelian group theory, the constraint solving approach
is also proved to yield a decision procedure [38,34]. This is extended, yet considering a
richer fragment of arithmetic in [8].
There are many more relevant equational theories, as described in [21]. For instance
homomorphism properties are considered in [23,24], blind signatures in [22,6],... Some
classes of equational theories are considered, relying on a constraint solving approach in
[24,9].
Finally, we complete the tour by mentioning combinations of decision procedures:
for disjoint theories [13], hierarchical combinations [14] and more [8].
All these works make use of techniques similar to derivation constraint solving,
but they also use a small attack property, showing that, if a derivation constraint is
satisable, then there is a small solution. This kind of result allows us to restrict the set
of solutions that has to be considered; the constraint solving rules (or their counterparts)
then do not necessarily preserve the solutions, but only preserve the small solutions,
hence the satisability. In this chapter (as in [16,9]), we went a step further, preserving
the set of all solutions.
4.6. Software resources
There are a few specialized theorem provers that can deal with some algebraic prop-
erties of cryptographic primitives [5,7,40]. There are also ways of getting rid of some
equational axioms, and then using the veriers that are designed for free term algebras
[17,27,28]. Only some [33,4,40] are (currently) really relying on constraint solving tech-
niques. But the recent theoretical advances in this area may, in the next few years, yield
new tools based on these techniques.
5. Research directions
Much is known at this stage about the foundations of security protocol analysis. The basic
decidability and complexity results are known. Several specialized software tools, and
methods for applying more general tools, are available, with staggering improvements
in performance compared with a decade ago: seconds instead of hours to analyze most
protocols. More attention is needed now to the presentation of the best algorithms, so
that future students, tool developers, and analysts will be able to build on clear and useful
knowledge rather than tricks hidden in software.
There is always a need to extend analysis approaches to cover more kinds of cryp-
tographic primitives, such as bilinear pairings, used in elliptic curve cryptography, and
zero-knowledge proofs. Another persistent demand is to handle more kinds of secu-
rity goals, such as anonymity, fair exchange, group key management, and properties ex-
pressed in terms of observational equivalence.
Observational equivalence deserves a special attention. It allows one to state some
stronger security properties, typically that an attacker cannot learn anything relevant, be-
cause the process is indistinguishable from an ideal process in which all relevant infor-
mations have been shufed or hidden.
The constraint solving approach is relevant for deciding equivalences of processes.
It requires however signicant new insights since the constraint solving method that we
described in this chapter is complete only w.r.t. what an attacker can deduce, but not w.r.t.
how it can be deduced. On the other hand, if an attacker has different ways to deduce a
given message in two different experiments, he could distinguish between them.
At this stage in the development of security protocol analysis, the most useful chal-
lenge for the research community might not be research at all, but rather a transfer of
the state of the art to the state of practice. A collaboration of researchers, educators, and
tool builders may be necessary to create texts, expectations, and software that exhibits
the best of what is possible and explains how to use it. After this kind of consolidation
step, it will be easier to see what is most important to do next.
References
[1] M. Abadi and C. Fournet. Mobile values, new names, and secure communication. In Proceedings of the
28th ACM Symposium on Principles of Programming Languages (POPL01), pages 104115, 2001.
[2] M. Arapinis, S. Delaune, and S. Kremer. From one session to many: Dynamic tags for security protocols.
In Proceedings of the 15th International Conference on Logic for Programming, Articial Intelligence,
and Reasoning (LPAR08), volume 5330 of LNAI, pages 128142. Springer, 2008.
[3] F. Baader and K. Schulz. Unication in the union of disjoint equational theories: Combining decision
procedures. Journal of Symbolic Computation, 21:211243, 1996.
[4] D. Basin, S. Mdersheim, and L. Vigan. Constraint differentiation: a new reduction technique for
constraint-based analysis of security protocols. In Proceedings of the ACM Conference on Computer
and Communications Security (CCS03), pages 335344. ACM, 2003.
[5] D. Basin, S. Mdersheim, and L. Vigan. Algebraic intruder deductions. In Proceedings of the 12th
International Conference on Logic for Programming, Articial Intelligence, and Reasoning (LPAR05),
volume 3835 of LNAI, pages 549564. Springer-Verlag, 2005.
[6] V. Bernat and H. Comon-Lundh. Normal proofs in intruder theories. In Revised Selected Papers of the
11th Asian Computing Science Conference (ASIAN06), volume 4435 of LNCS. Springer, 2008.
[7] B. Blanchet, M. Abadi, and C. Fournet. Automated verication of selected equivalences for security
protocols. Journal of Logic and Algebraic Programming, 75(1):351, 2008.
[8] S. Bursuc and H. Comon-Lundh. Protocol security and algebraic properties: Decision results for a
bounded number of sessions. In Proceedings of the 20th International Conference on Rewriting Tech-
niques and Applications (RTA09), volume 5595 of LNCS, pages 133147. Springer, 2009.
[9] S. Bursuc, S. Delaune, and H. Comon-Lundh. Deducibility constraints. In Proceedings of the 13th Asian
Computing Science Conference (ASIAN09), LNCS. Springer, 2009.
[10] Y. Chevalier, R. Ksters, M. Rusinowitch, and M. Turuani. Deciding the security of protocols with
Dife-Hellman exponentiation and products in exponents. In Proceedings of the 23rd Conference on
Foundations of Software Technology and Theoretical Computer Science (FST&TCS03), volume 2914
of LNCS, 2003.
[11] Y. Chevalier, R. Ksters, M. Rusinowitch, and M. Turuani. An NP decision procedure for protocol
insecurity with XOR. Theoretical Computer Science, 338(1-3):247274, 2005.
[12] Y. Chevalier, R. Ksters, M. Rusinowitch, and M. Turuani. Complexity results for security protocols
with Dife-Hellman exponentiation and commuting public key encryption. ACM Trans. Comput. Log.,
9(4), 2008.
[13] Y. Chevalier and M. Rusinowitch. Combining Intruder Theories. In Proceedings of the 32nd Inter-
national Colloquium on Automata, Languages and Programming, ICALP05, volume 3580 of LNCS,
pages 639651. Springer, 2005.
[14] Y. Chevalier and M. Rusinowitch. Hierarchical combination of intruder theories. In Proceedings of
the 17th International Conference on Rewriting Techniques and Application (RTA06), volume 4098 of
LNCS, pages 108122, 2006.
[15] Y. Chevalier and M. Rusinowitch. Hierarchical combination of intruder theories. Information and
Computation, 206(2-4):352377, 2008.
[16] H. Comon-Lundh, V. Cortier, and E. Zalinescu. Deciding security properties of cryptographic protocols.
application to key cycles. Transaction on Computational Logic, 11(2), 2010.
[17] H. Comon-Lundh and S. Delaune. The nite variant property: How to get rid of some algebraic prop-
erties. In Proceedings of the 16th International Conference on Rewriting Techniques and Applications
(RTA05), volume 3467 of LNCS, 2005.
[18] H. Comon-Lundh, S. Delaune, and J. Millen. Constraint solving techniques and enriching the model
with equational theories. Research Report LSV-10-18, Laboratoire Spcication et Vrication, ENS
Cachan, France, Nov. 2010.
[19] H. Comon-Lundh and V. Shmatikov. Intruder deductions, constraint solving and insecurity decision in
presence of exclusive or. In Proceedings of the 18th Annual IEEE Symposium on Logic in Computer
Science. IEEE Comp. Soc., 2003.
[20] R. Corin and S. Etalle. An improved constraint-based system for the verication of security protocols.
In Proceedings of the 9th Static Analysis Symposium (SAS02), volume 2477 of LNCS, pages 326341,
2002.
[21] V. Cortier, S. Delaune, and P. Lafourcade. A survey of algebraic properties used in cryptographic proto-
cols. Journal of Computer Security, 14(1):143, 2006.
[22] V. Cortier, M. Rusinowitch, and E. Zalinescu. Aresolution strategy for verifying cryptographic protocols
with CBC encryption and blind signatures. In Proceedings of the 7th ACM-SIGPLAN International
Conference on Principles and Practice of Declarative Programming (PPDP05), pages 1222. ACM
press, 2005.
[23] S. Delaune, P. Lafourcade, D. Lugiez, and R. Treinen. Symbolic protocol analysis in presence of a
homomorphism operator and exclusive or. In Proceedings of the 33rd International Colloquium on
Automata, Languages and Programming, (ICALP06), Part II, volume 4052 of LNCS, pages 132143,
2006.
[24] S. Delaune, P. Lafourcade, D. Lugiez, and R. Treinen. Symbolic protocol analysis for monoidal equa-
tional theories. Information and Computation, 206(2-4):312351, 2008.
[25] D. Dolev and A. Yao. On the security of public key protocols. In Proceedings of the 22nd Symposium
on Foundations of Computer Science, pages 350357, Nashville (USA, Tennessee, 1981. IEEE Comp.
Soc. Press.
[26] D. Khler and R. Ksters. Constraint solving for contract-signing protocols. In Proceedings of the
16th International Conference on Concurrency Theory (CONCUR05), volume 3653 of LNCS, pages
233247. Springer, 2005.
[27] R. Ksters and T. Truderung. Reducing protocol analysis with XOR to the XOR-free case in the Horn
theory based approach. In Proceedings of the ACM Conference on Computer and Communications
Security (CCS08), pages 129138. ACM, 2008.
[28] R. Ksters and T. Truderung. Using ProVerif to Analyze Protocols with Dife-Hellman Exponentiation.
In Proceedings of the 22nd IEEE Computer Security Foundations Symposium (CSF 2009), pages 157
171. IEEE Computer Society, 2009.
[29] G. Lowe. Towards a completeness result for model checking of security protocols. Journal of Computer
Security, 7(2-3):89146, 1999.
[30] C. Lynch and C. Meadows. On the relative soundness of the free algebra model for public key encryp-
tion. ENTCS, 125(1):4354, 2005.
[31] C. Meadows and P. Narendran. A unication algorithm for the group Dife-Hellman protocol. In
Proceedings of the Workshop on Issues in the Theory of Security (WITS02), 2002.
[32] J. Millen. On the freedom of decryption. Information Processing Letters, 86(6):329333, 2003.
[33] J. Millen and V. Shmatikov. Constraint solving for bounded-process cryptographic protocol analysis. In
Proceedings of the 8th ACM Conference on Computer and Communications Security, 2001.
[34] J. Millen and V. Shmatikov. Symbolic protocol analysis with an abelian group operator or Dife-
Hellman exponentiation. Journal of Computer Security, 2005.
[35] R. Ramanujamand S. P. Suresh. Decidability of context-explicit security protocols. Journal of Computer
Security, 13(1):135165, 2005.
[36] M. Rusinowitch and M. Turuani. Protocol insecurity with nite number of sessions is NP-complete. In
Proceedings of the 14th IEEE Computer Security Foundations Workshop. IEEE Comp. Soc. Press, 2001.
[37] S. Schneider. Security properties and CSP. In IEEE Symposium on Security and Privacy, pages 174
187, 1996.
[38] V. Shmatikov. Decidable analysis of cryptographic protocols with products and modular exponentiation.
In Proceedings of the 13th European Symposium on Programming (ESOP04), volume 2986 of LNCS,
2004.
[39] F. J. Thayer, J. C. Herzog, and J. D. Guttman. Strand spaces: Proving security protocols correct. Journal
of Computer Security, 7(1), 1999.
[40] M. Turuani. The CL-Atse protocol analyser. In Proceedings of the 17th International Conference on
Term Rewriting and Applications (RTA06), volume 4098 of LNCS, pages 277286. Springer, 2006.
Analysing Security Protocols using CSP
Gavin LOWE
Oxford University Computing Laboratory
Abstract. In this chapter we describe an approach to analysing security protocols
using the process algebra CSP and the model checker FDR. The basic approach
is to build a CSP model of a small system running the protocol, together with the
most general intruder who can interact with the protocol. We then use the model
checker FDR to explore the state space, looking for insecure states. In the second
half of the chapter, we extend this approach so as to be able to analyse an arbitrary
system running the protocol.
1. Introduction
In this chapter we describe how security protocols can be analysed using the process
algebra CSP and the model checker FDR. The basic technique is to build a CSP model
of a small system running the protocol, together with the most general intruder who can
interact with that protocol, and then to use the model checker FDR to explore the state
space, looking for insecure behaviours.
We will base our explanation of the technique upon the books running example:
Message 1. a b : {[k]
SK(a)
}
a
PK(b)
Message 2. b a : {s}
s
k
The initiator a creates a fresh session key k, signs it with her secret key SK(a), encrypts
it with the responder bs public key PK(b), and sends it to b. The responder b then
uses k to encrypt some secret value s to return to a.
We analyse the protocol in the context of the Dolev-Yao model [DY83]. We assume
that the intruder has complete control of the network and so can: overhear messages
passing on the network; intercept messages, to prevent them reaching their intended re-
cipients; encrypt and decrypt messages using keys he knows, so as to learn new mes-
sages; and send messages that he knows, possibly using a false identity. However, we
do not allow the intruder to perform cryptanalytic attacks: we effectively assume perfect
cryptography.
In the next section we give a brief introduction to CSP. Then in Section 3 we produce
a CSP model of the protocol: we build a model of a small system running the protocol,
including a single initiator, Alice, and a single responder, Bob, together with the most
general intruder who can interact with the protocol. In Section 4 we describe how the
security properties of secrecy and authentication can be captured as CSP specications,
and how FDR can be used to nd attacks against these properties. We then adapt the
protocol to prevent these attacks. FDR nds no attacks when it is used to analyse a small
IOS Press, 2011
doi:10.3233/978-1-60750-714-7-62
62
system running the adapted protocol. However, this does not immediately imply that
there is no attack against some larger system running the protocol. We tackle this issue
in Section 5, by showing how to build a model that abstracts an arbitrary system running
the protocol: any attack upon an arbitrary system running the protocol will be reected
in an attack upon this model. In Section 6 we describe Casper, a compiler that can be
used to produce the CSP models from a more abstract description, and in Section 7 we
give bibliographic notes and briey discuss some extensions of the technique.
2. A brief overview of CSP
Communicating Sequential Processes (CSP) [Hoa85,Ros97] is a process algebra for de-
scribing programs or processes that interact with their environment by communication.
That environment might be other processes running in parallel, or might be processes
outside the system being modelled. In this section we give a brief overview of the frag-
ment of the syntax that we use subsequently, and describe the trace semantics of CSP;
for more details, see [Ros97].
CSP processes communicate via atomic events, from some set . Typically, events
correspond to communications over channels; for example the event c.3 represents the
communication of the value 3 over the channel c. Each channel is declared to pass data
of a particular type. The set of events over channel c is denoted {c}.
The simplest process is STOP, which represents a deadlocked process that cannot
communicate with its environment. The process a P offers its environment the
event a; if the event is performed, it then acts like P. This is generalised by the process
c?x : X P(x), which is willing to do any event of the form c.x for x X, and then
acts like P(x); this represents an input of x on channel c; if the set X is omitted, it is
taken to be the type of the channel.
If b is a boolean and P is a process, then b & P represents the process that acts
like P if b is true, and like STOP if b is false; in other words, b acts as a boolean guard
on P.
The process P Q can act like either P or Q: the environment is offered the choice
between the initial events of P and Q. The process
i:I
P(i ) represents an indexed
choice between the processes P(i ) for i I . Chaos(A) is a totally nondeterministic
process that can communicate arbitrary events from A.
The process P
A
Q runs P and Q in parallel, synchronising on events from A,
i.e. events from A can occur only when both P and Q are willing to perform them. An
indexed version is written as
i:I
[
i
]P
i
: each process P
i
synchronises on events from
its alphabet
i
. By contrast, P Q runs P and Q in parallel with no synchronisation.
The process P A acts like P, except the events from A are hidden, i.e. turned
into internal, invisible events, denoted . Finally, the process P[[a/b]] represents the
process P but where every occurrence of the event b is renamed to a. An indexed version
of this is written, for example, P[[c.x/d.x x X]].
A trace is a sequence of events that a process can perform; we write traces(P) for
the set of traces of P. We say that P is rened by Q, written P
T
Q, if all the traces
of Q are traces of P:
P
T
Q traces(P) traces(Q).
G. Lowe / Analysing Security Protocols Using CSP 63
Typically, Q will be a model of a system and P will be a specication process that
can perform those traces that meet some requirement; the renement will hold if P can
perform only traces that meet the requirement. The tool FDR [Ros94,For97] can be used
to test such renements automatically, for nite state processes.
3. Modelling the protocol
In this section we describe the basic technique of CSP model checking of security proto-
cols. As noted in the introduction, we consider a small system running the protocol: we
include a single initiator Alice, who will use the session key Ka, and a single responder
Bob, who will use the secret Sb. We also include an intruder, Mallory, who has complete
control over the network, as illustrated in Figure 1.
Intruder
s
e
n
d
A
l
i
c
e
.
M
a
l
l
o
r
y
r
e
c
e
i
v
e
.
M
a
l
l
o
r
y
.
B
o
b
r
e
c
e
i
v
e
.
A
l
i
c
e
.
B
o
b
s
e
n
d
.
A
l
i
c
e
.
B
o
b
Initiator(Alice,Ka) Responder(Bob,Sb)
Figure 1. The system
In the next subsection we give some basic denitions of the underlying types, etc.
In Subsection 3.2 we give CSP models for the honest participants in the protocol, and in
Subsection 3.3 we give a model for the intruder. Finally, in Subsection 3.4 we put them
together to form a model of the whole system.
We present the denitions using blackboard CSP; it is straightforward to translate
this into machine-readable CSP, for use with FDR.
3.1. The basics
We begin by dening a datatype Encryption representing the space of all possible mes-
sages. The datatype includes the atomic values indicated in Figure 1, together with a
session key and a secret that the intruder will know initially. It includes constructors that
correspond to concatenation and encryption; we do not distinguish between symmetric
encryption, asymmetric encryption and signing, although it would be straightforward to
include separate constructors for each of these. The datatype also includes constructors
to give the public keys and secret keys of agents.
datatype Encryption =
Alice Bob Mallory Ka Km Sb Sm PK .Agent SK .Agent
Sq.Seq(Encryption) Encrypt .(AllKeys, Encryption),
where the set AllKeys is dened below. For example, a typical instance of
message 1 of the form {[k]
SK(a)
}
a
PK(b)
would be represented by the element
Encrypt .(PK .b, Encrypt .(SK .a, k)) of Encryption.
For convenience, we dene functions to return the public and secret keys of agents,
and a number of subtypes of Encryption.
PK(a) = PK .a, SK(a) = SK .a,
Agent = {Alice, Bob, Mallory}, Honest = Agent {Mallory},
Secret = {Sb, Sm}, SessionKey = {Ka, Km},
PublicKey = {PK(a) a Agent }, SecretKey = {SK(a) a Agent },
AllKeys = SessionKey PublicKey Secretkey.
We also dene a function to return the inverse key of a given key:
inverse(Ka) = Ka, inverse(Km) = Km,
inverse(PK .a) = SK .a, inverse(SK .a) = PK .a.
We will represent each message by a (Label , Encryption) pair (the Label simply
helps with interpretation of the output from FDR). We dene Msg to be the set of all
such pairs that are used in the protocol:
datatype Label = Msg1 Msg2 Env0,
Msg = {(Msg1, Encrypt .(PK(b), Encrypt .(SK(a), k)))
k SessionKey, a Agent , b Agent }
{(Msg2, Encrypt .(k, s)) k SessionKey, s Secret }.
And we dene channels to represent the sending and receiving of messages:
channel send, receive : Agent .Agent .Msg.
For example, agent a sending a message 1 of the protocol intended for agent b will
be represented by the event send.a.b.(Msg1, Encrypt .(PK(b), Encrypt .(SK(a), k)));
agent b receiving the message will be represented by the event receive.a.b.(Msg1,
Encrypt .(PK(b), Encrypt .(SK(a), k))).
It is useful to model interactions between the protocol and its environment (e.g. com-
mands from a user to run the protocol). Here we want to model the protocol for the
initiator receiving a message from its environment, telling it to run the protocol with a
particular agent b.
EnvMsg = {(Env0, b) b Agent },
channel env : EnvMsg.
3.2. Modelling the honest agents
We now describe how we can model the honest agents running the protocol as CSP pro-
cesses. We give a parametrised process Initiator(a, k) to represent an agent a running
the protocol as initiator, and using session key k. The process starts by receiving a mes-
sage from the environment, telling it with whom to run the protocol. It then sends an ap-
propriate message 1, and receives back an appropriate message 2 containing an arbitrary
value for s.
Initiator(a, k) =
b:Agent
env.a.(Env0, b)
send.a.b.(Msg1, Encrypt .(PK(b), Encrypt .(SK(a), k)))
s:Secret
receive.b.a.(Msg2, Encrypt .(k, s)) STOP.
The denition of the responder is similar: the process Responder(b, s) represents
agent b running the protocol as responder using secret s. The responder starts by receiv-
ing a message 1, from an arbitrary agent a and containing an arbitrary session key k. It
then sends back the corresponding message 2.
Responder(b, s) =
a:Agent,k:SessionKey
receive.a.b.(Msg1, Encrypt .(PK(b), Encrypt .(SK(a), k)))
send.b.a.(Msg2, Encrypt .(k, s)) STOP.
As noted above, we consider a small system, comprising Alice acting as initiator,
using key Ka, and Bob acting as responder, using secret Sb. The two agents do not
communicate directly: we arrange below for all communications to go via the intruder.
We model this as an interleaving.
System
0
= Initiator(Alice, Ka) Responder(Bob, Sb).
Of course, it is straightforward to consider larger systems, with more agents, or with
particular agents running the protocol multiple times, perhaps with different roles.
3.3. Modelling the intruder
We now describe how we can model the intruder. The main issue is modelling which
messages the intruder is able to understand and to create. We need to keep track, there-
fore, of which submessages of protocol messages the intruder knows; we term these
facts:
Fact = {Encrypt .(PK(b), Encrypt .(SK(a), k))
k SessionKey, a Agent , b Agent }
{Encrypt .(k, s) k SessionKey, s Secret }
{Encrypt .(SK(a), k) k SessionKey, a Agent }
Agent SessionKey Secret SecretKey PublicKey.
What we do is dene a deduction system to capture the intruders capabilities: we write
X f if, given set of facts X, he is able to create the fact f . The relation is dened by
the following four rules:
{f , k} Encrypt .(k, f ), for k AllKeys,
{Encrypt .(k, f ), inverse(k)} f , for k AllKeys,
{f
1
, . . . , f
n
} Sq.f
1
, . . . , f
n
,
{Sq.f
1
, . . . , f
n
} f
i
, for i = 1, . . . , n.
If the intruder knows a fact f and a key k then he can encrypt f with k; if he knows an
encrypted message and the corresponding decryption key, he can perform the decryption
to obtain the body; if he knows a collection of facts, he can concatenate them together;
if he knows a concatenation, he can split it up into the individual components.
We will create a denition for the intruder that can hear messages sent across the
network, deduce new facts from what he knows (as dened by the relation), and then
send facts he knows to other agents (possibly using identities other than his own).
We dene MsgBody to be the bodies of messages (i.e., without the label), and de-
clare two channels on which the intruder can hear and say message bodies; later we will
arrange for these events to synchronise with send and receive events of honest agents.
We also declare a channel to capture inferences, and a channel on which the intruder can
signal that he knows a particular secret.
MsgBody = {m l (l , m) Msg},
channel hear, say : MsgBody,
channel infer : {(f , X) X f },
channel leak : Secret .
One way to dene the intruder is as follows; the parameter S represents the intruders
current knowledge.
Intruder
0
(S) =
hear?f : MsgBody Intruder
0
(S {f })
say?f : S MsgBody Intruder

0
(S)
leak?f : S Secret Intruder

0
(S)
f :Fact, XS, Xf , f / S
infer.(f , X) Intruder
0
(S {f }).
The intruder can: hear a message sent on the network, and add it to his knowledge; say
a message that he knows; signal that he knows a particular secret; or infer a new fact f if
for some subset X of his current knowledge, X f , and then add f to his knowledge.
Below we will instantiate S with a set IIK that represents the intruders initial
knowledge; we assume that the intruder knows all the agents identities, all the public
keys, his own secret key, a session key, and a secret:
IIK = Agent {PK(a) a Agent } {SK(Mallory), Km, Sm}.
The denition of the intruder ensures
1
tr
say.f traces(Intruder
0
(IIK))
S IIK {f
hear.f

in tr
} S f .
The intruder can say a message only if he can deduce it from his initial knowledge and
what he has heard.
The above design of the intruder process works in theory, but is very inefcient in
practice, because of the way FDR works. FDR produces explicit state machines for se-
1
denotes concatenation of traces.

quential processes, such as Intruder
0
(IIK) above. If there are N facts that the intruder
might learn, then the Intruder
0
process has 2
N
states. It is typical for N to be of the or-
der of several thousand; clearly it is infeasible to construct the intruder process explicitly
in such cases.
Observe, though, that most states of the intruder will not be reachable in the context
of a particular system otherwise model checking would be infeasible. What we want
to do is avoid constructing the entire intruder process, but simply to explore the parts that
are reachable in the context of the given system.
The way we do this is to construct the intruder in a different way. Rather than build
the intruder as a single sequential process with 2
N
states, we build it out of N component
processes, one for each fact f , each with two states corresponding to whether the intruder
does or does not know f .
Ignorant(f ) =
f MsgBody & hear.f Knows(f )
XFact, Xf
infer.(f , X) Knows(f ),
Knows(f ) =
f MsgBody & hear.f Knows(f )
f MsgBody & say.f Knows(f )
f Secret & leak.f Knows(f )
:Fact, XFact, f X, Xf
infer.(f

, X) Knows(f ).
If the intruder doesnt know f , he can hear f on the network, or deduce it from some
set X (that he does know), at which point he will knowf . When he knows f he can: hear
it on the network again; say it; signal that he knows it (if it is a secret); or use it within
the inference of another fact.
We build the intruder by composing the component processes together in parallel,
where the component for fact f synchronises on the events in its alphabet alpha(f ).
Intruder
0
=
f :Fact
[alpha(f )] if f IIK then Knows(f ) else Ignorant(f ),
alpha(f ) = {hear.f , say.f , leak.f }
{infer.(f , X) X Fact , X f }
{infer.(f

, X) f

Fact , X Fact , f X, X f

}.
Note in particular that an inference of the form infer.(f , X) can occur precisely when
the component for fact f is in the Ignorant state, and for each f

X, the component
for f

is in the Knows state. The above highly parallel process is, then, equivalent to the
original sequential denition, but FDR can construct it much more quickly.
We can make the denition more efcient, still, in order to reduce the size of the
state space explored by FDR. When the intruder learns one fact, he can often use it to
deduce many more facts; thus deductions often come together. The more deductions
that are made, the more the intruder can do, so it makes sense to force the intruder to
make all possible inferences, rather than allowing FDR to explore states where he makes
a subset of those deductions. Further, if the intruder can make k independent such new
deductions, then there are k! orders in which those deductions can be made. But all
different orders of the deductions reach the same state, so it doesnt matter what order
they are made in: we should force FDRto consider just a single order of those deductions.
The FDR function chase will do both of these for us: it forces internal events to occur,
but picking an arbitrary order, and performing as many as possible. We therefore hide
the inferences and apply chase, to force the intruder to perform as many inferences as
possible, but in an arbitrary order.
Intruder
1
= chase(Intruder
0
{infer}).
Finally, we rename the hear and say events within the intruder to send and receive
events, ready to synchronise with the honest agents.
Intruder = Intruder
1
[[send.a.b.(l , m)/hear.m
a Agent {Mallory}, b Agent , (l , m) Msg]]
[[receive.a.b.(l , m)/say.m
a Agent , b Agent {Mallory}, (l , m) Msg]]
3.4. Putting it together
Finally, we construct our model of the complete system by composing the honest agents
and the intruder together in parallel, synchronising on all the send and receive events to
reect the fact that the intruder has complete control over the network:
System = System
0

{send,receive}
Intruder.
4. Testing for security properties
We now describe how to test for various security properties: rst secrecy properties, then
authentication properties.
4.1. Secrecy properties
There are two properties concerning the secret s that we want to test for:
1. If an initiator a receives a value s, apparently from b, and b is not the intruder,
then the intruder does not know s;
2. If a responder b sends a value s, intended for a, and a is not the intruder, then
the intruder does not know s.
We can test for both of these together.
What we do is introduce new events of the form claimSecret.a.s.b to indicate that
a thinks that s is a secret that only b should know, and similar events with a and b
swapped. We transform the system so that these events occur when a and b receive or
send (respectively) a message 2, corresponding to items 1 and 2 above. We then hide all
events other than the claimSecret and leak events.
SecretSystem =
System [[claimSecret.a.s.b/receive.b.a.(Msg2, Encrypt .(k, s)),
claimSecret.b.s.a/send.b.a.(Msg2, Encrypt .(k, s))
a Agent , b Agent , s Secret , k SessionKey]]
( {claimSecret, leak}).
We want to test that, whenever an honest agent a performs a claimSecret .a.s.b
event, with b not the intruder, the intruder does not subsequently performleak.s indicat-
ing that he has learnt s. The process SecretSpec below allows precisely those traces that
satisfy this property; the parameter of the subsidiary process SecretSpec
records those
secrets for which there has been a corresponding claimSecret, and so must not be leaked
by the intruder.
SecretSpec = SecretSpec
({}),
SecretSpec
(secs) =
claimSecret?a?s?b
if b Honest then SecretSpec
(secs {s}) else SecretSpec
(secs)
leak?s : Secret secs SecretSpec
(secs).
We can then test our secrecy properties by checking that every trace of SecretSystem
is also a trace of SecretSpec; we can do this by using FDR to test the renement
SecretSpec
T
SecretSystem.
When we performthis check, FDR nds that the renement does not hold, and gives
a witness trace of SecretSystem that is not a trace of SecretSpec; this correspond to an
attack against item 2 above. It turns out, though, that there is no attack against item 1.
The witness trace returned by FDR is
claimSecret.Bob.Sb.Alice, leak.Sb.
Bob believes that Sb is a secret that only Alice should learn, yet the intruder does learn it.
The FDR debugger can be used to nd that the corresponding trace of System is:
env.Alice.(Env0, Mallory),
send.Alice.Mallory.
(Msg1, Encrypt .(PK .Mallory, Encrypt .(SK .Alice, Ka))),
receive.Alice.Bob.(Msg1, Encrypt .(PK .Bob, Encrypt .(SK .Alice, Ka))),
send.Bob.Alice.(Msg2, Encrypt .(Ka, Sb)),
leak.Sb .
This can be described in more standard notation as follows (the notation I
Alice
represents
the intruder faking a message, pretending to be Alice, or intercepting a message intended
for Alice):
Message 0. Alice : Mallory
Message 1. Alice Mallory : {[Ka]
SK(Alice)
}
a
PK(Mallory)
Message 1. I
Alice
Bob : {[Ka]
SK(Alice)
}
a
PK(Bob)
Message 2. Bob I
Alice
: {Sb}
s
Ka
The intruder knows Sb.
Alice runs the protocol with Mallory, sending him a key Ka, signed with her public key.
But Mallory can then use this signed key to send a fake message to Bob, pretending to
be Alice. Bob accepts this key as having come from Alice, and so uses it to try to send
Alice the secret Sb. However, the intruder knows Ka so can learn Sb.
4.2. Authentication
We now consider authentication of the responder to the initiator, and vice versa. More
precisely, we consider the following questions:
1. If an initiator a completes a run of the protocol, apparently with b, then has b
been running the protocol, apparently with a, and do they agree upon the value
of the secret s and the session key k?
2. If a responder b completes a run of the protocol, apparently with a, then has a
been running the protocol, apparently with b, and do they agree upon the value
of the session key k? (Note that b can receive no guarantee that he and a agree
upon s, because he cannot be sure that a even receives message 2.)
We describe how to test for the latter property; the test for the former is very similar.
We introduce new events, as follows:
The event Running.InitiatorRole.a.b.k indicates that a thinks that she is run-
ning the protocol as initiator, apparently with b, using session key k;
The event Complete.ResponderRole.b.a.k indicates that b thinks he has com-
pleted a run of the protocol as responder, apparently with a, using session key k.
We will then check that whenever the latter event occurs, the former event has previously
occurred.
We arrange for initiator a to performthe Running event when she sends message 1,
and we arrange for responder b to performthe Complete event when he sends message 2;
we hide all other events.
AuthSystem
0
=
System[[Running.InitiatorRole.a.b.k/
send.a.b.(Msg1, Encrypt .(PK(b), Encrypt .(SK(a), k))),
Complete.ResponderRole.b.a.k/
send.b.a.(Msg2, Encrypt .(k, s))
a Agent , b Agent , k SessionKey, s Secret ]]
( alphaAuthSystem),
alphaAuthSystem =
{Running.InitiatorRole.a.b, Complete.ResponderRole.b.a
a Honest, b Honest}.
(More generally, the Complete event is performed at the last step in the protocol taken
by that agent, and the Running event is performed when the agent sends a message that
should be causally linked to the other agent receiving a message.)
Recall that we want to check that whenever a responder b performs a Complete
event concerning initiator a, then a has previously performed a corresponding Running
event concerning b. We therefore consider the following specication process, which
allows only such traces
AuthSpec = Running.InitiatorRole?a.b.k
Chaos({Complete.ResponderRole.b.a.k}).
Note that this specication allows b to perform an arbitrary number of Complete
events corresponding to a single Running event, and so does not insist that there
is a one-one relationship between the runs of a and the runs of b. We could test
for such a relationship by replacing the Chaos({Complete.ResponderRole.b.a.k}) by
Complete.ResponderRole.b.a.k STOP.
We can use FDR to test the renement
AuthSpec
T
AuthSystem.
(The above renement test is appropriate since AuthSystem performs at most a single
Running event; for a system that could performn such events, we would replace the left
hand side of the renement test by an interleaving of n copies of AuthSpec.) FDR nds
that this renement does not hold, and returns the following witness trace:
Complete.ResponderRole.Bob.Alice.Ka.
Bob thinks he has completed a run of the protocol with Alice, but Alice did not think that
she was running the protocol with Bob. We can again use the FDR debugger to nd the
corresponding trace of System:
env.Alice.(Env0, Mallory)
send.Alice.Mallory.
(Msg1, Encrypt .(PK .Mallory, Encrypt .(SK .Alice, Ka)))
receive.Alice.Bob.(Msg1, Encrypt .(PK .Bob, Encrypt .(SK .Alice, Ka)))
send.Bob.Alice.(Msg2, Encrypt .(Ka1, Sb)) .
This is the same as the attack against secrecy.
We can test whether the responder is authenticated to the initiator (item 1 above) in
a similar way. FDR nds no attack in this case.
It is interesting to consider what guarantees the responder does receive from the
protocol. We claim that if responder b completes a run of the protocol, apparently with a,
then a has been running the protocol, and that they agree upon the value of the session
key k. Note though that a might have been running the protocol with some agent c other
than b, and so performed a Running.InitiatorRole.Alice.c.k event. We can test this
condition using the renement check
AlivenessSpec
T
SystemAliveness,
where
AlivenessSpec = Running.InitiatorRole.Alice?c?k
Chaos({Complete.ResponderRole.b.Alice.k b Agent }),
SystemAliveness = AuthSystem
0
( alphaSystemAliveness),
alphaSystemAliveness =
{Running.InitiatorRole.a.b, Complete.ResponderRole.b.a
a Honest, b Agent }.
4.3. Correcting the protocol
It is fairly straightforward to correct the protocol to prevent the attacks identied above.
Each attack was caused by Bob accepting a key signed by Alice that had been intended
for Mallory rather than himself. The obvious way to prevent this attack, then, is to
include the intended recipients identity within this signed message. We also include the
senders identity, although this is not actually necessary:
Message 1. a b : {[a, b, k]
SK(a)
}
a
PK(b)
Message 2. b a : {s}
s
k
It is straightforward to adapt the CSP model to reect this change in the protocol: it
simply requires a change to the denitions of the honest agents, the sets Msg and Fact ,
and the renamings performed to the nal system, all restricted to the parts that deal with
message 1.
When we analyse this version of the protocol using FDR, we nd no attacks against
the main security properties discussed above. If we use the version of the authentication
check that tests whether there is a one-one relationship between the runs of a and the
runs of b, we nd that this does not hold: clearly the intruder can replay a message 1
sent by a multiple times so that b thinks hes performed multiple runs corresponding to
a single run of a; we consider this a limitation of the protocol rather than a serious aw.
We should be clear, though, about the limitations of this analysis. When we model
check a particular system running the protocol and nd no attacks, that does not nec-
essarily imply that there is no attack upon some other system running the protocol (al-
though in practice most attacks can be found by considering fairly small systems). We
address this problem in the following section.
5. Model checking arbitrary systems
In this section we show how to build a model that abstracts an arbitrary system running
the protocol: if no attack is found on this model, then no attack exists on the protocol.
For ease of exposition, we consider only the question of attacks upon the responder.
By symmetry, it is enough to consider attacks upon a particular instance of a particular
responder, say the instance Responder(Bob, Sb), which we call the principal responder.
We want to consider all possible systems containing this principal responder, together
with arbitrary other instances of honest agents (possibly including other instances of
Bob, as either initiator or responder) and the intruder. Each such system can be written
in the form
System
0
= (Responder(Bob, Sb) Others)
{send,receive}
Intruder,
where Others models all the other honest instances. Of course, there are innitely many
such systems. However, we show how to construct a model that is guaranteed to nd all
attacks upon all such systems.
Our development proceeds in several steps. In the next subsection, we show how
to build models that represent the effects of the other honest agents, Others, internally
within the intruder. However, that still produces an innite number of models, param-
eterised by the types used. In Subsection 5.2 we show how to reduce those models to
a single nite model, using techniques from the area of data independence. Finally, in
Subsection 5.3 we show how we can analyse the resulting model, and, if we nd no at-
tacks, deduce that there are no attacks upon an arbitrary system of the form of System
0
,
above.
5.1. Internalising agents
Recall that we are interested only in attacks against the principal responder. In so far as
such attacks are concerned, there are two contributions that the other instances Others
can make:
1. An initiator instance within Others can send a message 1, which the intruder can
overhear and hence use;
2. A responder instance within Others can send a message 2, which the intruder
can overhear and hence use; note that this will happen only after that responder
has received a corresponding message 1, which the intruder will know.
We build a new intruder process, Intruder
, that corresponds to the combination of

Intruder and Others, except it represents messages sent by the other honest agents in a
different way. We represent those messages as deductions within the new intruder, rather
than as explicit messages: in other words, these interactions are modelled internally to
the intruder, rather than externally.
Consider, rst, item 1 above, corresponding to an initiator instance, a say, sending
a message 1. Our new model will represent this by a deduction of the corresponding
message from the empty set. For later convenience, we partition the set SessionKey
into three subtypes: those keys that an honest initiator intends to share with the intruder,
denoted SessionKeyKnown; those keys that an honest initiator intends to share with
an honest agent, denoted SessionKeyUnknown; and those keys that the intruder knows
initially, denoted SessionKeyIntruder; in the rst two cases, the sufxes Known and
Unknown indicate whether or not we expect the value to be known by the intruder.
The intruder overhearing a message 1 intended for some honest agent b can then be
represented by a deduction of the following form:
{} Encrypt .(PK(b), Encrypt .(SK(a), Sq.a, b, k)),
for a, b Honest, k SessionKeyUnknown.
(1)
Similarly, the intruder receiving a message 1 intended for himself can be represented by
a deduction of the following form:
{} Encrypt .(PK(Mallory), Encrypt .(SK(a), Sq.a, Mallory, k)),
for a Honest, k SessionKeyKnown.
(2)
We now consider item 2 above, corresponding to the responder b sending a mes-
sage 2 in response to receiving a message 1 that the intruder knows. We can represent
this by a deduction of the message 2 from the message 1. We partition Secret into four
subtypes: the distinguished secret Sb used by the principal responder; those other se-
crets that an honest responder intends to share with the intruder, denoted SecretKnown;
those other secrets that an honest responder intends to share with an honest agent,
denoted SecretUnknown; and those secrets that the intruder knows initially, denoted
SecretIntruder. The intruder overhearing a message 2 intended for some honest agent a
can then be represented by a deduction of the following form:
{Encrypt .(PK(b), Encrypt .(SK(a), Sq.a, b, k))} Encrypt .(k, s),
for a, b Honest, s SecretUnknown, k SessionKey.
(3)
Similarly, the intruder receiving a message 2 intended for himself can be represented by
a deduction of the following form:
{Encrypt .(PK(b), Encrypt .(SK(Mallory), Sq.Mallory, b, k))}
Encrypt .(k, s),
for b Honest, s SecretKnown, k SessionKey.
(4)
Note that in both cases we allow k to range over all of SessionKey: we do not want to
make any assumptions about the set of keys for which the intruder can construct a valid
message 1 that is accepted by an honest agent.
Let Intruder
be constructed using this extended deduction relation, in the same

way that Intruder was constructed in Section 3.3, except with none of the infer events
corresponding to new deductions hidden. We can then construct a new system
System
Int
= Responder(Bob, Sb)
{send,receive}
Intruder
.
This is analogous to System, except that messages from the other agents have been
replaced by corresponding infer events.
In fact, System
Int
has slightly more behaviours than System. For example, it allows
multiple deductions that produce messages containing the same fresh value: for instance,
it would allow the intruder to perform both the deductions
{} Encrypt .(PK(Bob), Encrypt .(SK(Alice), Sq.Alice, Bob, K1)),
{} Encrypt .(PK(Bill ), Encrypt .(SK(Alison), Sq.Alison, Bill , K1)),
using the same key K1, whereas within System only a single message 1 containing K1
would be sent. Of course, these extra behaviours are safe: if we can verify System
Int
then we can deduce that System is secure. There is a possibility of these extra behaviours
leading to the discovery of false attacks: attacks against System
Int
where there is no
corresponding attack on System. However, we have designed System
Int
so that these
false attacks do not arise in practice: this is one reason why we partitioned SessionKey
and Secret into those values intended for use with the intruder or with honest agents.
Note that we have, in fact, produced an innite family of systems, one for each
choice of the types Agent , SessionKey and Secret (and their subtypes); we sometimes
write System
Int
(Agent , SessionKey, Secret ) to make this dependence explicit. Note
in particular that the intruder is also parameterised by these types, both in the denition
of the set of deductions, and in the denition of his initial knowledge IIK as dened in
Section 3.3. We cannot directly check all members of this family. In the next section we
show how to perform a further reduction, in order to reduce the analysis of all systems
of the form System
Int
(Agent , SessionKey, Secret ) to the analysis of a single system
System
Int
(Agent
, SessionKey
, Secret
), for some xed types Agent
, SessionKey
and Secret
.
5.2. Reducing the system
A process P(T) is said to be data independent in its type parameter T if it can input and
output values from T, store them for later use, perform polymorphic operations such as
tupling upon them, but not performany computations that constrain what T may be. The
processes we have dened to model the protocol have been data independent in the types
Agent , SessionKey, and Secret . A number of interesting results have been proven that
allow one to deduce results about a data independent process P(T) for all choices of T
froman analysis of P(T
) for some xed type T
; see, for example [Ros97, Chapter 15].

We apply some of the theory of data independence here.
Without loss of generality, we may assume that each type Agent , SessionKey
and Secret contains at least as many elements as the corresponding types Agent
,
SessionKey
and Secret
, since increasing the sizes of the types does not remove any
traces from System
Int
(Agent , SessionKey, Secret ).
In order to reduce the innite family of systems of the form of System
Int
, we
will dene a function : Fact Fact , and (informally speaking) consider a system
that uses fact (f ) whenever System
Int
uses f . Given a particular choice of Agent ,
SessionKey and Secret , we dene as the homomorphism induced by three surjective
functions on atomic types:
Ag
: Agent Agent
SK
: SessionKey SessionKey
Sec
: Secret Secret
.
So, for example,
(Encrypt .(SK(a), Sq.a, b, k)) =
(Encrypt .(SK(
Ag
(a)), Sq.
Ag
(a),
Ag
(b),
SK
(k))).
We lift to events in the obvious way, for example (send.a.b.(l , m)) = send.
Ag
(a).
Ag
(b).(l , (m)). We lift to sets, traces, etc., by point-wise application.
The system we will consider, then, is
System
= System
Int
(
Ag
(Agent ),
SK
(SessionKey),
Sec
(Secret ))
= System
Int
(Agent
, SessionKey
, Secret
).
We give the denitions of
Ag
, etc., below (in fact, well use different denitions de-
pending on the property were checking). However, they will each map values onto
small xed ranges, Agent
, etc., so that the above process System
is independent of
the choices of Agent , SessionKey and Secret . In other words, we will reduce arbitrary
systems to some xed nite system.
In order to deduce results about System
Int
from an analysis of System
, we would
like to be able to relate their traces. The property we would like to deduce is
traces(System
)
{(tr) tr traces(System
Int
(Agent , SessionKey, Secret ))}.
(5)
If we can do that, and prove some property of the traces of System
(by performing a
renement check using FDR) we will be able to deduce a corresponding property about
the traces of System
Int
. Equation (5) does hold, but this requires some justication;
indeed the generalisation to an arbitrary CSP process P parameterised by type T,
traces(P((T)) {(tr) tr traces(P(T))}, (6)
does not hold. To see why not, consider the process (taken from [RB99]):
P(T) = in?x : T in?y : T if x = y then a STOP else b STOP.
Suppose T = {0, 1} and (0) = (1) = 0; then the trace in.0, in.0, b is contained
in {(tr) tr traces(T)}, but not in traces(P((T))).
Lazi c [Laz99] shows that the following condition, known as PosConjEqT (positive
conjunction of equality tests), is enough to ensure that equation (6) does hold (in fact, the
two sides of the equation are equal in this case):
A process P satises PosConjEqT precisely when the failure of each equality check
in P results in the process STOP.
For example, the following process satises PosConjEqT:
P(T) = in?x : T in?y : T if x = y then a STOP else STOP.
The CSP processes we have dened to model the honest protocol participants satisfy
PosConjEqT. However, this wont be the case in protocols where an agent performs
inequality tests say between two values she receives, or between the identity of her
apparent partner and her own identity before proceeding.
The process we have dened to model the intruder also satises equation (6).
In [RB99], it is shown that this will be the case provided the underlying deduction rela-
tion is positive, i.e., whenever X f , it is also the case that (X) (f ); in other
words, if the intruder can make a particular deduction before the types are collapsed, he
can make the corresponding deduction after the types are collapsed. This is true of the
deduction system we are using here.
2
2
As an example of a deduction system that is not positive, consider the following, designed to capture the
cracking of a one-time pad that has been used with two distinct texts ( denotes bit-wise exclusive-or):
{k t
1
, k t
2
} k, for k Key, t
1
, t
2
Text, t
1
= t
2
.
If (t
1
) = (t
2
), for some t
1
= t
2
, then the deduction system is not positive.
We have shown that both components of System
satisfy equation (6). One can

show that this property is preserved by parallel composition. Hence the entire protocol
model System
satises equation (5).

5.3. Testing for secrecy and authentication
We now describe how to adapt the renement test for secrecy from Section 4.1. Recall
that we are only considering secrecy from the point of view of the principal responder.
We dene the reduction functions
Ag
, etc., as follows, to reduce each of the sub-
types to singleton values:
Ag
(Bob) = Bob,
Ag
(Mallory) = Mallory,
Ag
(a) = Alice, for a Honest {Bob},
Sec
(Sb) = Sb,
Sec
(s) = Sm, for s SecretKnown SecretIntruder,
Sec
(s) = Sa, for s SecretUnknown,
SK
(k) = Km, for k SessionKeyKnown
SessionKeyIntruder,
SK
(k) = Ka, for k SessionKeyUnknown.
This denition means that Agent
= {Alice, Bob, Mallory}, Secret
= {Sa, Sb, Sm},

and SessionKey
= {Ka, Km}. For convenience, write Honest
for {Alice, Bob}.

In particular, the effect of this reduction is to reduce the intruders initial knowledge
in the new system to
{Alice, Bob, Mallory, Sm, Km, SK(Mallory),
PK(Alice), PK(Bob), PK(Mallory)}.
Further, it reduces the deductions corresponding to internalised agents (equations (14))
to the following, where a and b range over Honest
, and k ranges over SessionKey
:
{} Encrypt .(PK(b), Encrypt .(SK(a), Sq.a, b, Ka)),
{} Encrypt .(PK(Mallory), Encrypt .(SK(a), Sq.a, Mallory, Km)),
{Encrypt .(PK(b), Encrypt .(SK(a), Sq.a, b, k))} Encrypt .(k, Sa),
{Encrypt .(PK(b), Encrypt .(SK(Mallory), Sq.Mallory, b, k))}
Encrypt .(k, Sm).
In order to test whether the secrecy property is satised, we perform a renaming
and hiding to System
, analogous to that which produced SecretSystem (but with the

renaming restricted to just the principal responder):
SecretSystem
=
System
[[claimSecret.Bob.Sb.a/send.Bob.a.(Msg2, Encrypt .(k, Sb))

a Agent
, k SessionKey
]]
( {claimSecret, leak.Sb}).
We consider a specication analogous to SecretSpec, but restricted to just the principal
responder and the principal responders nonce, Sb:
SecretSpec
= claimSecret.Bob.Sb?a
if a Honest
then SecretSpec1
else SecretSpec
leak.Sb SecretSpec
,
SecretSpec1
= claimSecret.Bob.Sb?a SecretSpec1
.
We can then use FDR to verify that
SecretSpec
T
SecretSystem
.
We now deduce a corresponding result for System
Int
. The success of the above
renement test means that SecretSystem
has no trace of the form

. . . , claimSecret.Bob.Sb.a, . . . , leak.Sb,
for a Honest
. Hence System
has no trace of the form

. . . , send.Bob.a.(Msg2, Encrypt .(k, Sb)), . . . , leak.Sb,
for k SessionKey
. Therefore, by equation (5), and using the denition of

Ag
etc.,
System
Int
(Agent , SessionKey, Secret ) has no trace of the form
. . . , send.Bob.a.(Msg2, Encrypt .(k, Sb)), . . . , leak.Sb,
for a Honest and k SessionKey. We deduce that there is no secrecy attack against
System
Int
(Agent , SessionKey, Secret ), for all choices of the types.
Thus we have veried that, for an arbitrary system running the protocol, there is
no secrecy attack against the principal responder, and hence, by symmetry, there is no
secrecy attack against an arbitrary responder.
We now consider how to adapt the test for authentication from Section 4.2. Recall
that we are considering only authentication attacks on authentication against the principal
responder, and testing for agreement on the session key.
We let Agent
= {Alice, Bob, Mallory}, SessionKey
= {Ka, Kb, Km} and

Secret
= {Sa, Sb, Sm}. We let

Sec
be as in the previous section; we dene
Ag
and
SK
below.
In order to test for authentication, we produce a system similar to AuthSystem from
Section 4.2. However, we are only interested in checking for authentication to the princi-
pal responder Bob, so we need produce only the corresponding Running and Complete
signals. Recall that in Section 4.2 the Running event was produced by renaming the
sending of a message 1. However, in System
that send is modelled by an internalised

inference, of the form
infer.(Encrypt .(PK(Bob), Encrypt .(SK(a), Sq.a, Bob, k)), {}).
For ease of reference, we write Msg1Inf (a, k) for the above event. We therefore need
to produce the Running event by renaming the corresponding Msg1Inf (a, k) event:
3
AuthSystem
=
System
[[Running.InitiatorRole.a.Bob.k/Msg1Inf (a, k),

Complete.ResponderRole.Bob.a.k/send.Bob.a.(Msg2, Encrypt .(k, s))
a Agent , k SessionKey, s Secret ]]
( alphaAuthSystem
),
alphaAuthSystem
=
{Running.InitiatorRole.a.Bob, Complete.ResponderRole.Bob.a
a Honest}.
We can also produce a specication process, similar to AuthSpec from Section 4.2, but
specialised to the principal responder:
AuthSpec
= Running.InitiatorRole?a!Bob?k
Chaos({Complete.ResponderRole.Bob.a.k}).
We can then use FDR to verify that
AuthSpec
T
AuthSystem
.
We can use this to deduce a corresponding result for System
Int
. The success of the
above renement test means that for every trace tr of System
, and for all a Honest
and k SessionKey
if tr = tr
send.Bob.a.(Msg2, Encrypt .(k, s))

then Msg1Inf (a, k) in tr
.
(7)
We claim that a similar result holds for System
Int
(Agent , SessionKey, Secret ). Sup-
pose, for a contradiction, that System
Int
(Agent , SessionKey, Secret ) does have a
trace tr such that for some A Honest and K SessionKey
tr = tr
send.Bob.A.(Msg2, Encrypt .(K, s))

but not Msg1Inf (A, K) in tr
.
(8)
Consider the collapsing functions
Ag
and
SK
below:
Ag
(A) = Alice,
Ag
(Bob) = Bob,
Ag
(c) = Mallory, for c = A, Bob,
SK
(K) = Kb,
SK
(k) = Km, for k SessionKeyKnown
SessionKeyIntruder {K},
SK
(k) = Ka, for k SessionKeyUnknown {K}.
3
In the interests of efciency, we should hide and chase all infer events other than Msg1Inf (a, k) events
when we construct the intruder process.
Then
(tr) = (tr
send.Bob.Alice.(Msg2, Encrypt .(Kb,

Sec
(s))).
However, (tr
) has no corresponding Msg1Inf (Alice, Kb) event, by the way we have

constructed . But equation (5) implies that (tr) traces(System
), which con-
tradicts equation (7). Thus we have obtained a contradiction to equation (8). Hence
System
Int
(Agent , SessionKey, Secret ) satises the authentication property, for all
choices of the types. Thus we have veried that, for an arbitrary system running the
protocol, there is no authentication attack against the principal responder, and hence, by
symmetry, no authentication attack against an arbitrary responder.
6. Casper
In the previous sections, we have described the CSP models of security protocols. How-
ever, creating these models by hand is time-consuming and error-prone. Casper is a
compiler that automates this process, creating the CSP models from a more abstract de-
scription written by the user. In this section we briey outline the Casper input syntax;
for more details see [LBDH].
A complete input le, corresponding to the model in Sections 3 and 4, is given in
Figure 2. The script is split into eight sections, each beginning with a header starting
with #. The rst three sections describe the protocol; the fourth section denes the
specications for it to be tested against; and the last four sections describe the system to
be checked.
The #Free variables section declares the variables to be used in the protocol
description, together with their types; it also denes which keys are inverses of one an-
other. The #Processes section denes names for the agents running in the protocol,
together with parameters for them; Casper uses these names for the corresponding CSP
processes. This section also denes the initial knowledge of the agents; Casper uses this
information to check that the protocol is feasible, in that each agent has all the informa-
tion necessary to run the protocol. The #Protocol description section denes the
protocol itself, using an ascii representation of standard protocol notation. In particular,
it includes a message 0 that a receives from its environment, telling it with whom to run
the protocol, and corresponding to the environment message in the CSP model.
The #Specification section denes the security properties to be tested. The
two Secret specications correspond to the two secrecy properties considered in Sec-
tion 4.1: that a believes that s is a secret that only b should know, and vice versa. The
two Agreement specications correspond to the rst two authentication properties con-
sidered in Section 4.2: that b is authenticated to a and that they agree upon the values
of s and k; and that a is authenticated to b and that they agree upon the value of k.
The Aliveness specication corresponds to the property considered at the end of Sec-
tion 4.2: that if b completes a run of the protocol, apparently with a, then a has previ-
ously been running the protocol.
The #Actual variables section denes the atomic values to be used in the pro-
tocol model; this is used in the denition of the Encryption datatype in the model. This
section also denes which keys are inverses of one another. The #Functions section
tells Casper to produce symbolic denitions for the functions PK and SK; alternatively,
#Free variables
a, b : Agent
k : SessionKey
s : Secret
PK : Agent -> PublicKey
SK : Agent -> SecretKey
InverseKeys = (PK, SK), (k, k)
#Processes
Initiator(a, k) knows PK, SK(a)
Responder(b, s) knows PK, SK(b)
#Protocol description
0. -> a : b
1. a -> b : { {k}{SK(a)} }{PK(b)}
2. b -> a : {s}{k}
#Specification
Secret(a, s, [b])
Secret(b, s, [a])
Agreement(b, a, [s,k])
Agreement(a, b, [k])
Aliveness(a, b)
#Actual variables
Alice, Bob, Mallory : Agent
Ka, Km : SessionKey
Sb, Sm : Secret
InverseKeys = (Ka, Ka), (Km, Km)
#Functions
symbolic PK, SK
#System
Initiator(Alice, Ka)
Responder(Bob, Sb)
#Intruder Information
Intruder = Mallory
IntruderKnowledge = \
{Alice, Bob, Mallory, PK, SK(Mallory), Km, Sm}
Figure 2. Casper script for the example protocol
the user can provide his own denitions. The #System section denes the instances of
honest agents in the system. Finally, the #Intruder Information section gives the
name of the intruder, and his initial knowledge (corresponding to IIK in the CSP model).
Casper also provides support for analysing systems of unbounded size, as described
in Section 5. Most sections of the Casper script are unchanged; Figure 3 gives those
sections that are changed.
The generates clauses in the #Processes section indicates that the initia-
#Processes
INITIATOR(a,k) knows PK, SK(a) generates k
RESPONDER(b,s) knows PK, SK(b) generates s
#Actual variables
Mallory : Agent
#System
GenerateSystem = True
#Intruder Information
Intruder = Mallory
IntruderKnowledge = {PK, SK(Mallory)}
UnboundParallel = True
Figure 3. Changes to the Casper script to allow checking of arbitrary systems
tor and responder generate fresh values for k and s, respectively. The #Intruder
Information section includes the directive UnboundParallel = True to indicate
that unboundedly many instances of other agents should be modelled as internal agents.
Those types used in generates clauses (here SessionKey and Secret) and the types
of agent identities (here Agent) are treated as being data independent.
The #System section includes the directive GenerateSystem = True to indicate
that Casper should automatically generate a system containing just enough agents, gen-
erate types containing just enough values, and give the intruder just enough initial knowl-
edge, in order for the security of this small system to imply the security of arbitrary sys-
tems, using an argument as in Section 5.3. The user has to declare only the intruders
identity, and to specify what initial knowledge from non-data-independent types the in-
truder should have. (It is also possible for the user to specify the system and types, as in
a standard script.)
Analyses based on scripts of this form are less good for detecting attacks than those
of the standard form, since counterexamples returned by FDR are harder to understand
(many of the details of the attack are hidden within internalised deductions), but are
appropriate for protocols that are believed to be correct.
7. Notes
In this section we give brief historical notes concerning the development of the tech-
niques described in this chapter, and pointers to other extensions.
The rst uses of model checkers to analyse security protocols are due to Millen
et al. [MCF87] and Meadows [Mea96]. Roscoe was the rst to consider the use of CSP
and FDR in [Ros95], but the ideas gained more prominence in [Low96] and [LR97]. The
highly-parallel model of the intruder from Section 3.3 was proposed in [RG97].
Casper was rst described in [Low97a,Low98]; Casper itself is available from
[Low09]. Different types of authentication requirements, and how to model them in CSP,
were discussed in [Low97b]. The book [RSG
+
00] includes a more detailed description
of the CSP approach to modelling and analysis of security protocols.
A number of other extensions have been made to the approach. Some cryptographic
systems have interesting algebraic properties; for example, Vernam encryption (bit-wise
exclusive-or) is associative and commutative, and Dife-Hellman encryption depends
upon commutativity of exponentiation. In [RG97], Roscoe and Goldsmith describe how
to model such algebraic properties, by renaming each fact to a representative member of
its equivalence class. Some protocols make use of passwords, which might be poorly-
chosen and so appear in an on-line dictionary; some such protocols may be subject to
guessing attacks, where the intruder is able to test in some way whether a particular guess
of the password is correct, and to iterate this process through all words in the dictionary;
[Low04] describes how to analyse protocols for such guessing attacks. In some protocols
(such as the running example in this book!), if an old session key is compromised, the
intruder can replay it in order to launch subsequent attacks; [Hui01] describes how to
nd such attacks.
The theory of data independence, as applied to CSP, was developed in [Laz99].
Roscoe rst applied data independence to security protocols in [Ros98], using a tech-
nique to recycle fresh values in a protocol, to give a model that simulated a system
with an unbounded number of sequential runs (but with a limited number of concurrent
runs). Roscoe and Broadfoot extended these ideas in [RB99], and introduced the idea of
internalising agents, although there it was applied to secondary agents such as servers,
and was intended as a technique for reducing the size of the state space rather than to
provide for a general proof. These ideas were extended in [BR02,Bro01] to show that in-
ternalising agents can be used to provide a general proof; however, in that development,
considerable machinery was necessary to avoid false attacks. The models we have pre-
sented here are due to Kleiner [Kle08]; Kleiner also presents some extensions we have
not discussed, and presents several theorems giving appropriate choices for the collapsed
datatypes for checking different security properties.
Acknowledgments
I would like to thank Bill Roscoe for discussions about security protocols and their
analysis using CSP, stretching over the last 15 years. I would also like to thank Eldar
Kleiner for discussions about his techniques for internalising agents and applying data
independence techniques. I received useful comments on this chapter from Tom Gibson-
Robinson, Steve Kremer, Tomasz Mazur, Toby Murray and Bernard Sufrin.
References
[BR02] P. J. Broadfoot and A. W. Roscoe. Capturing parallel attacks within the data independence frame-
work. In Proceedings of the 15th IEEE Computer Security Foundations Workshop, 2002.
[Bro01] Philippa Broadfoot. Data independence in the model checking of security protocols. DPhil thesis,
Oxford University, 2001.
[DY83] D. Dolev and A.C. Yao. On the security of public-key protocols. Communications of the ACM,
29(8):198208, August 1983.
[For97] Formal Systems (Europe) Ltd. Failures-Divergence RenementFDR 2 User Manual, 1997.
Available via URL http://www.formal.demon.co.uk/FDR2.html.
[Hoa85] C. A. R. Hoare. Communicating Sequential Processes. Prentice Hall, 1985.
[Hui01] Mei Lin Hui. A CSP Appraoch to the Analysis of Security Protocols. PhD thesis, University of
Leicester, 2001.
[Kle08] Eldar Kleiner. A Web Services Security Study using Casper and FDR. DPhil thesis, Oxford
University, 2008.
[Laz99] Ranko Lazi c. A Semantic Study of Data Independence with Applications to Model Checking.
DPhil thesis, Oxford University, 1999.
[LBDH] Gavin Lowe, Philippa Broadfoot, Christopher Dilloway, and Mei Lin Hui. Casper: A Com-
piler for the Analysis of Security Protocols, User Manual and Tutorial. Oxford University Com-
puting Laboratory. Available via http://www.comlab.ox.ac.uk/people/gavin.
lowe/Security/Casper/index.html.
[Low96] Gavin Lowe. Breaking and xing the Needham-Schroeder public-key protocol using FDR. In
Proceedings of TACAS, volume 1055 of Lecture Notes in Computer Science, pages 147166.
Springer Verlag, 1996. Also in SoftwareConcepts and Tools, 17:93102, 1996.
[Low97a] Gavin Lowe. Casper: A compiler for the analysis of security protocols. In Proceedings of 10th
IEEE Computer Security Foundations Workshop, pages 1830, 1997.
[Low97b] Gavin Lowe. A hierarchy of authentication specications. In Proceedings of 10th IEEE Computer
Security Foundations Workshop, 1997.
[Low98] Gavin Lowe. Casper: A compiler for the analysis of security protocols. Journal of Computer
Security, 6:5384, 1998.
[Low04] Gavin Lowe. Analysing protocols subject to guessing attacks. Journal of Computer Security,
12(1):8398, 2004.
[Low09] Gavin Lowe. Casper: A compiler for the analysis of security protocols, 19962009.
World Wide Web home page at URL http://www.comlab.ox.ac.uk/people/gavin.
lowe/Security/Casper/index.html.
[LR97] Gavin Lowe and Bill Roscoe. Using CSP to detect errors in the TMNprotocol. IEEE Transactions
on Software Engineering, 23(10):659669, 1997.
[MCF87] J. K. Millen, S. C. Clark, and S. B. Freedman. The interrogator: Protocol security analysis. IEEE
Transactions on software Engineering, 13(2), 1987.
[Mea96] Catherine Meadows. The NRL Protocol Analyzer: An overview. Journal of Logic Programming,
26(2):113131, 1996.
[RB99] A. W. Roscoe and P. J. Broadfoot. Proving security protocols with model checkers by data inde-
pendence techniques. Journal of Computer Security, 7(2, 3):147190, 1999.
[RG97] A. W. Roscoe and M. H. Goldsmith. The perfect spy for model-checking cryptoprotocols. In
Proceedings of the DIMACS Workshop on Design and Formal Verication of Security Protocols,
1997. Available via URL http://dimacs.rutgers.edu/Workshops/Security/
program2/program.html.
[Ros94] A. W. Roscoe. Model-checking CSP. In A Classical Mind, Essays in Honour of C. A. R. Hoare.
Prentice-Hall, 1994.
[Ros95] A. W. Roscoe. Modelling and verifying key-exchange protocols using CSP and FDR. In 8th
IEEE Computer Security Foundations Workshop, 1995.
[Ros97] A. W. Roscoe. The Theory and Practice of Concurrency. Prentice Hall, 1997.
[Ros98] A. W. Roscoe. Proving security protocols with model checkers by data independence techniques.
In 11th Computer Security Foundations Workshop, pages 8495, 1998.
[RSG
+
00] Peter Ryan, Steve Schneider, Michael Goldsmith, Gavin Lowe, and Bill Roscoe. Modelling and
Analysis of Security Protocols. Pearson Education, 2000.
Using Horn Clauses for Analyzing
Security Protocols
Bruno BLANCHET
1
CNRS, cole Normale Suprieure, INRIA, Paris, France
Abstract. This chapter presents a method for verifying security protocols based on
an abstract representation of protocols by Horn clauses. This method is the foun-
dation of the protocol verier ProVerif. It is fully automatic, efcient, and can han-
dle an unbounded number of sessions and an unbounded message space. It sup-
ports various cryptographic primitives dened by rewrite rules or equations. Even
if we focus on secrecy in this chapter, this method can also prove other security
properties, including authentication and process equivalences.
Keywords. Automatic verication, security protocols, Horn clauses, secrecy.
Introduction
Security protocols can be veried by an approach based on Horn clauses; the main goal
of this approach is to prove security properties of protocols in the Dolev-Yao model in
a fully automatic way without bounding the number of sessions or the message space
of the protocol. In contrast to the case of a bounded number of sessions in which de-
cidability results could be obtained (see Chapters Verifying a bounded number of ses-
sions and its complexity and Constraint solving techniques and enriching the model
with equational theories ), the case of an unbounded number of sessions is undecidable
for a reasonable model of protocols [56]. Possible solutions to this problem are rely-
ing on user interaction, allowing non-termination, and performing sound approximations
(in which case the technique is incomplete: correct security properties cannot always
be proved). Theorem proving [84] and logics (Chapter Protocol Composition Logic)
rely on user interaction or on manual proofs. Typing (Chapter Using types for security
protocol analysis) generally relies on lightweight user annotations and is incomplete.
Strand spaces (Chapter Shapes: Surveying Crypto Protocol Runs) and rank functions
(Chapter Security analysis using rank functions in CSP) also provide techniques that
can handle an unbounded number of sessions at the cost of incompleteness.
Many methods rely on sound abstractions [50]: they overestimate the possibilities
of attacks, most of the time by computing an overapproximation of the attacker knowl-
edge. They make it possible to obtain fully automatic, but incomplete, systems. The Horn
clause approach is one such method. It was rst introduced by Weidenbach [86]. This
chapter presents a variant of his method and extensions that are at the basis of the auto-
1
Corresponding Author: Bruno Blanchet, cole Normale Suprieure, DI, 45 rue dUlm, 75005 Paris, France;
E-mail: blanchet@di.ens.fr.
IOS Press, 2011
doi:10.3233/978-1-60750-714-7-86
86
matic protocol verier ProVerif that we developed. In this method, messages are repre-
sented by terms ; the fact attacker() means that the attacker may have the message
; Horn clauses (i.e. logic programming rules) give implications between these facts.
An efcient resolution algorithmdetermines whether a fact is derivable from the clauses,
which can be used for proving security properties. In particular, when attacker() is
not derivable from the clauses, the attacker cannot have , that is, is secret. This
method is incomplete since it ignores the number of repetitions of each action in the
protocol. (Horn clauses can be applied any number of times.) This abstraction is key to
avoid bounding the number of runs of the protocol. It is sound, in the sense that if the
verier does not nd a aw in the protocol, then there is no aw. The verier therefore
provides real security guarantees. In contrast, it may give a false attack against the proto-
col. However, false attacks are rare in practice, as experiments demonstrate. Termination
is not guaranteed in general, but it is guaranteed on certain subclasses of protocols and
can be obtained in all cases by an additional approximation (see Section 2.4).
Without this additional approximation, even if it does not always terminate and is in-
complete, this method provides a good balance in practice: it terminates in the vast major-
ity of cases and is very efcient and precise. It can handle a wide variety of cryptographic
primitives dened by rewrite rules or by equations, including shared-key and public-key
cryptography (encryption and signatures), hash functions, and the Dife-Hellman key
agreement. It can prove various security properties (secrecy, authentication, and process
equivalences). We mainly focus on secrecy in this chapter and give references for other
properties in Section 3.2.
Other methods rely on abstractions:
Bolignano [40] was a precursor of abstraction methods for security protocols. He
merges keys, nonces, . . . so that only a nite set remains and applies a decision
procedure.
Monniaux [80] introduced a verication method based on an abstract representa-
tion of the attacker knowledge by tree automata. This method was extended by
Goubault-Larrecq [62]. Genet and Klay [59] combine tree automata with rewrit-
ing. This method has lead to the implementation of the TA4SP verier (Tree-
Automata-based Automatic Approximations for the Analysis of Security Proto-
cols) [39].
The main drawback of this approach is that, in contrast to Horn clauses, tree au-
tomata cannot represent relational information on messages: when a variable ap-
pears several times in a message, one forgets that it has the same value at all its oc-
currences, which limits the precision of the analysis. The Horn clause method can
be understood as a generalization of the tree automata technique. (Tree automata
can be encoded into Horn clauses.)
Control-ow analysis [36,38] computes the possible messages at each program
point. It is also non-relational, and merges nonces created at the same program
point in different sessions. These approximations make it possible to obtain a
complexity at most cubic in the size of the protocol. It was rst dened for secrecy
for shared-key protocols, then extended to message authenticity and public-key
protocols [37], with a polynomial complexity.
Most protocol veriers compute the knowledge of the attacker. In contrast, Her-
ms [41] computes the form of messages, for instance encryption under certain
keys, that guarantee the preservation of secrecy. The paper handles shared-key
B. Blanchet / Using Horn Clauses for Analyzing Security Protocols 87
, ::= terms
variable
[
1
, . . . ,
] name
(
1
, . . . ,
) function application
::= (
1
, . . . ,
) fact
::=
1
. . .
Horn clause
Figure 1. Syntax of our protocol representation
and public-key encryption, but the method also applies to signatures and hash
functions.
Backes et al. [15] prove secrecy and authentication by an abstract-interpretation-
based analysis. This analysis builds a causal graph that captures the causality
between events in the protocol. The security properties are proved by traversing
this graph. This analysis always terminates but is incomplete. It assumes that
messages are typed, so that names (which represent random numbers) can be
distinguished from other messages.
One of the rst verication methods for security protocols, the Interrogator [79] is also
related to the Horn clause approach: in this system, written in Prolog, the reachability
of the state after a sequence of messages is represented by a predicate, and the program
uses a backward search in order to determine whether a state is reachable or not. The
main problem of this approach is non-termination, and it is partly solved by relying on
user interaction to guide the search. In contrast, we provide a fully automatic approach
by using a different resolution strategy that provides termination in most cases.
The NRL protocol analyzer [77,57] improves the technique of the Interrogator by
using narrowing on rewriting systems. It does not make abstractions, so it is correct and
complete but may not terminate.
Overview Section 1 details our protocol representation. Section 2 describes our resolu-
tion algorithm, and sketches its proof of correctness. Several extensions of this work are
detailed in Section 3. Section 4 presents experimental results and Section 5 concludes.
1. Abstract Representation of Protocols by Horn Clauses
A protocol is represented by a set of Horn clauses; the syntax of these clauses is given
in Figure 1. In this gure, ranges over variables, over names, over function sym-
bols, and over predicate symbols. The terms represent messages that are exchanged
between participants of the protocol. A variable can represent any term. Names repre-
sent atomic values, such as keys and nonces (random numbers). Each principal has the
ability of creating new names: fresh names are created at each run of the protocol. Here,
the created names are considered as functions of the messages previously received by
the principal that creates the name. Thus, names are distinguished only when the pre-
ceding messages are different. As noticed by Martn Abadi (personal communication),
this approximation is in fact similar to the approximation done in some type systems
(such as [2]): the type of the new name depends on the types in the environment. It is
enough to handle many protocols, and can be enriched by adding other parameters to
the name. In particular, by adding as parameter a session identier that takes a different
value in each run of the protocol, one can distinguish all names. This is necessary for
proving authentication but not for secrecy, so we omit session identiers here for simplic-
ity. We refer the reader to [32,58] for additional information. The function applications
(
1
, . . . ,
) build terms: examples of functions are encryption and hash functions.

A fact = (
1
, . . . ,
) expresses a property of the messages

1
, . . . ,
. Several
predicates can be used but, for a rst example, we are going to use a single predicate
attacker, such that the fact attacker() means the attacker may have the message .
A clause =
1
. . .
means that, if all facts

1
, . . . ,
are true, then is

also true. A clause with no hypothesis is written simply .
We use as a running example the naive handshake protocol introduced in Example 1
of Chapter Introduction:
Message 1. :
{
[]
sk
}
a
pk
Message 2. : {}
s
We refer the reader to Chapter Introduction for an explanation of this protocol. We

denote by sk
the secret key of , pk
his public key, sk
the secret key of , pk
his
public key.
1.1. Representation of Primitives
Cryptographic primitives are represented by functions. For instance, we represent the
public-key encryption by a function pencrypt(, pk), which takes two arguments: the
message to encrypt and the public key pk. There is a function pk that builds the public
key fromthe secret key. (We could also have two functions pk and sk to build respectively
the public and secret keys from a secret.) The secret key is represented by a name that
has no arguments (that is, there exists only one copy of this name) sk
[ ] for and sk
[ ]
for . Then pk
= pk(sk
[ ]) and pk
= pk(sk
[ ]).
More generally, we consider two kinds of functions: constructors and destructors.
The constructors are the functions that explicitly appear in the terms that represent mes-
sages. For instance, pencrypt and pk are constructors. Destructors manipulate terms. A
destructor is dened by a set def() of rewrite rules of the form(
1
, . . . ,
)
where
1
, . . . ,
, are terms that contain only variables and constructors and the
variables of all occur in
1
, . . . ,
. For instance, the decryption pdecrypt is a de-

structor, dened by pdecrypt(pencrypt(, pk(sk)), sk) . This rewrite rule mod-
els that, by decrypting a ciphertext with the corresponding secret key, one obtains the
cleartext. Other functions are dened similarly:
For signatures, we use a constructor sign and write sign(, sk) for the message
signed under the secret key sk. A destructor getmess dened by getmess(sign(,
sk)) returns the message without its signature, and checksign(sign(, sk),
pk(sk)) returns the message only if the signature is valid.
The shared-key encryption is a constructor sencrypt and the decryption is a de-
structor sdecrypt, dened by sdecrypt(sencrypt(, ), ) .
A one-way hash function is represented by a constructor (and no destructor).
Tuples of arity are represented by a constructor (_, . . . , _) and destructors
th
dened by th
((
1
, . . . ,
))
, {1, . . . , }. Tuples can be used to

represent various data structures in protocols.
Rewrite rules offer a exible method for dening many cryptographic primitives. It can
be further extended by using equations, as sketched in Section 3.1.
1.2. Representation of the Abilities of the Attacker
We assume that the protocol is executed in the presence of an attacker that can intercept
all messages, compute new messages from the messages it has received, and send any
message it can build, following the so-called Dolev-Yao model [55]. We rst present the
encoding of the computation abilities of the attacker. The encoding of the protocol will
be detailed in Section 1.3.
During its computations, the attacker can apply all constructors and destructors. If
is a constructor of arity , this leads to the clause:
attacker(
1
) . . . attacker(
) attacker((
1
, . . . ,
)).
If is a destructor, for each rewrite rule (
1
, . . . ,
) in def(), we have the

clause:
attacker(
1
) . . . attacker(
) attacker().
The destructors never appear in the clauses, they are coded by pattern-matching on their
parameters (here
1
, . . . ,
) in the hypothesis of the clause and generating their result

in the conclusion. In the particular case of public-key encryption, this yields:
attacker() attacker(pk) attacker(pencrypt(, pk)),
attacker(sk) attacker(pk(sk)),
attacker(pencrypt(, pk(sk))) attacker(sk) attacker(), (1)
where the rst two clauses correspond to the constructors pencrypt and pk, and the last
clause corresponds to the destructor pdecrypt. When the attacker has an encrypted mes-
sage pencrypt(, pk) and the decryption key sk, then it also has the cleartext . (We
assume that the cryptography is perfect, hence the attacker can obtain the cleartext from
the encrypted message only if it has the key.)
Clauses for signatures (sign, getmess, checksign) and for shared-key encryption
(sencrypt, sdecrypt) are given in Figure 2.
The clauses above describe the computation abilities of the attacker. Moreover, the
attacker initially has the public keys of the protocol participants. Therefore, we add the
clauses attacker(pk(sk
[ ])) and attacker(pk(sk
[ ])). We also give a name to the

attacker, that will represent all names it can generate: attacker([ ]). In particular, [ ] can
represent the secret key of any dishonest participant, his public key being pk([ ]), which
the attacker can compute by the clause for constructor pk.
1.3. Representation of the Protocol Itself
Now, we describe how the protocol itself is represented. We consider that and
are willing to talk to any principal, , but also malicious principals that
are represented by the attacker. Therefore, the rst message sent by can be
pencrypt(sign(, sk
[ ]), pk()) for any . We leave to the attacker the task of start-
ing the protocol with the principal it wants, that is, the attacker will send a preliminary
message to , mentioning the public key of the principal with which should talk.
This principal can be , or another principal represented by the attacker. Hence, if the
attacker has some key pk(), it can send pk() to ; replies with his rst message,
which the attacker can intercept, so the attacker obtains pencrypt(sign(, sk
[ ]), pk()).
Therefore, we have a clause of the form
attacker(pk()) attacker(pencrypt(sign(, sk
[ ]), pk())).
Moreover, a new key is created each time the protocol is run. Hence, if two different
keys pk() are received by , the generated keys are certainly different: depends on
pk(). The clause becomes:
attacker(pk()) attacker(pencrypt(sign([pk()], sk
[ ]), pk())). (2)

When receives a message, he decrypts it with his secret key sk
, so ex-
pects a message of the form pencrypt(
, pk(sk
[ ])). Next, tests whether has

signed
, that is, evaluates checksign(
, pk
), and this succeeds only when
=
sign(, sk
[ ]). If so, he assumes that the key is only known by , and sends a secret
s (a constant that the attacker does not have a priori) encrypted under . We assume that
the attacker relays the message coming from , and intercepts the message sent by .
Hence the clause:
attacker(pencrypt(sign(, sk
[ ]), pk(sk
[ ]))) attacker(sencrypt(s, )).

Remark 1 With these clauses, cannot play the role of and vice-versa. In order to
model a situation in which all principals play both roles, we can replace all occurrences
of sk
[ ] with sk
[ ] in the clauses above. Then plays both roles, and is the only honest
principal. A single honest principal is sufcient for proving secrecy properties by [48].
More generally, a protocol that contains messages is encoded by sets of clauses.
If a principal sends the th message, the th set of clauses contains clauses that have
as hypotheses the patterns of the messages previously received by in the protocol, and
as conclusion the pattern of the th message. There may be several possible patterns for
the previous messages as well as for the sent message, in particular when the principal
uses a function dened by several rewrite rules, such as the function exp of Section 3.1.
In this case, a clause must be generated for each combination of possible patterns. More-
over, notice that the hypotheses of the clauses describe all messages previously received,
not only the last one. This is important since in some protocols the fth message for
instance can contain elements received in the rst message. The hypotheses summarize
the history of the exchanged messages.
Computation abilities of the attacker:
For each constructor of arity :
attacker(
1
) . . . attacker(
) attacker((
1
, . . . ,
))
For each destructor , for each rewrite rule (
1
, . . . ,
) in def():
attacker(
1
) . . . attacker(
) attacker()
that is
pencrypt attacker() attacker(pk) attacker(pencrypt(, pk))
pk attacker(sk) attacker(pk(sk))
pdecrypt attacker(pencrypt(, pk(sk))) attacker(sk) attacker()
sign attacker() attacker(sk) attacker(sign(, sk))
getmess attacker(sign(, sk)) attacker()
checksign attacker(sign(, sk)) attacker(pk(sk)) attacker()
sencrypt attacker() attacker() attacker(sencrypt(, ))
sdecrypt attacker(sencrypt(, )) attacker() attacker()
Name generation: attacker([ ])
Initial knowledge: attacker(pk(sk
[ ])), attacker(pk(sk
[ ]))
The protocol:
First message: attacker(pk())
attacker(pencrypt(sign([pk()], sk
[ ]), pk()))
Second message: attacker(pencrypt(sign(, sk
[ ]), pk(sk
[ ])))
attacker(sencrypt(s, ))
Figure 2. Summary of our representation of the protocol of Example 1 of Chapter Introduction
Remark 2 When the protocol makes some communications on private channels, on
which the attacker cannot a priori listen or send messages, a second predicate can be
used: message(, ) meaning the message can appear on channel . In this
case, if the attacker manages to get the name of the channel , it will be able to lis-
ten and send messages on this channel. Thus, two new clauses have to be added to
describe the behavior of the attacker. The attacker can listen on all channels it has:
message(, ) attacker() attacker(). It can send all messages it has on all chan-
nels it has: attacker() attacker() message(, ).
1.4. Summary
To sum up, a protocol can be represented by three sets of Horn clauses, as detailed in
Figure 2 for the protocol of Example 1 of Chapter Introduction:
Clauses representing the computation abilities of the attacker: constructors, de-
structors, and name generation.
Facts corresponding to the initial knowledge of the attacker. In general, there are
facts giving the public keys of the participants and/or their names to the attacker.
Clauses representing the messages of the protocol itself. There is one set of
clauses for each message in the protocol. In the set corresponding to the th mes-
sage, sent by principal , the clauses are of the form attacker(
1
) . . .
attacker(
) attacker(
) where
1
, . . . ,
are the patterns of the

messages received by before sending the th message, and
is the pattern of
the th message.
1.5. Approximations
The reader can notice that our representation of protocols is approximate. Specically,
the number of repetitions of each action is ignored, since Horn clauses can be applied
any number of times. So a step of the protocol can be completed several times, as long as
the previous steps have been completed at least once between the same principals (even
when future steps have already been completed). For instance, consider the following
protocol (communicated by Vronique Cortier)
First step: sends {
1
, }
s
, {
2
, }
s
Second step: If receives {, }

s
, he replies with
Third step: If receives
1
,
2
, he replies with s
where
1
,
2
, and are nonces. In an exact model, never sends s, since {
1
, }
s
or {
2
, }
s
can be decrypted, but not both. In the Horn clause model, even though
the rst step is executed once, the second step may be executed twice for the same
(that is, the corresponding clause can be applied twice), so that both {
1
, }
s
and
{
2
, }
s
can be decrypted, and may send s. We have a false attack against the
secrecy of s.
However, the important point is that the approximations are sound: if an attack exists
in a more precise model, such as the applied pi calculus [6] or multiset rewriting [52],
then it also exists in our representation. This is shown for the applied pi calculus in [3]
and for multiset rewriting in [29]. In particular, we have shown formally that the only ap-
proximation with respect to the multiset rewriting model is that the number of repetitions
of actions is ignored. Performing approximations enables us to build a much more ef-
cient verier, which will be able to handle larger and more complex protocols. Another
advantage is that the verier does not have to limit the number of runs of the protocol.
The price to pay is that false attacks may be found by the verier: sequences of clause
applications that do not correspond to a protocol run, as illustrated above. False attacks
appear in particular for protocols with temporary secrets: when some value rst needs
to be kept secret and is revealed later in the protocol, the Horn clause model considers
that this value can be reused in the beginning of the protocol, thus breaking the protocol.
When a false attack is found, we cannot know whether the protocol is secure or not: a
real attack may also exist. A more precise analysis is required in this case. Fortunately,
our representation is precise enough so that false attacks are rare. (This is demonstrated
by our experiments, see Section 4.)
1.6. Secrecy Criterion
Our goal is to determine secrecy properties: for instance, can the attacker get the secret
s? That is, can the fact attacker(s) be derived from the clauses? If attacker(s) can be
derived, the sequence of clauses applied to derive attacker(s) will lead to the description
of an attack.
Our notion of secrecy is similar to that of [2,36,44]: a term is secret if the attacker
cannot get it by listening and sending messages, and performing computations. This
notion of secrecy is weaker than non-interference, but it is adequate to deal with the
secrecy of fresh names. Non-interference is better at excluding implicit information ows
or ows of parts of compound values. (See [1, Section 6] for further discussion and
references.)
In our running example, attacker(s) is derivable from the clauses. The derivation is
as follows. The attacker generates a fresh name [ ] (considered as a secret key), it com-
putes pk([ ]) by the clause for pk, obtains pencrypt(sign([pk([ ])], sk
[ ]), pk([ ]))

by the clause for the rst message. It decrypts this message using the clause for pdecrypt
and its knowledge of [ ], thus obtaining sign([pk([ ])], sk
[ ]). It reencrypts the sig-

nature under pk(sk
[ ]) by the clause for pencrypt (using its initial knowledge of

pk(sk
[ ])), thus obtaining pencrypt(sign([pk([ ])], sk
[ ]), pk(sk
[ ])). By the clause

for the second message, it obtains sencrypt(s, [pk([ ])]). On the other hand, from
sign([pk([ ])], sk
[ ]), it obtains [pk([ ])] by the clause for getmess, so it can de-
crypt sencrypt(s, [pk([ ])]) by the clause for sdecrypt, thus obtaining s. In other words,
the attacker starts a session between and a dishonest participant of secret key [ ]. It
gets the rst message pencrypt(sign(, sk
[ ]), pk([ ])), decrypts it, reencrypts it under

pk(sk
[ ]), and sends it to . For , this message looks like the rst message of a ses-
sion between and , so replies with sencrypt(s, ), which the attacker can decrypt
since it obtains from the rst message. Hence, the obtained derivation corresponds to
the known attack against this protocol. In contrast, if we x the protocol by adding the
public key of in the rst message
{
[pk
, ]
sk
}
a
pk
, attacker(s) is not derivable

from the clauses, so the xed protocol preserves the secrecy of s.
Next, we formally dene when a given fact can be derived from a given set of
clauses. We shall see in the next section how we determine that. Technically, the hy-
potheses
1
, . . . ,
of a clause are considered as a multiset. This means that the order

of the hypotheses is irrelevant, but the number of times a hypothesis is repeated is im-
portant. (This is not related to multiset rewriting models of protocols: the semantics of a
clause does not depend on the number of repetitions of its hypotheses, but considering
multisets is necessary in the proof of the resolution algorithm.) We use for clauses
(logic programming rules), for hypothesis, and for conclusion.
Denition 1 (Subsumption) We say that
1

1
subsumes
2

2
, and we write
(
1

1
) (
2

2
), if and only if there exists a substitution such that
1
=
2
and
1

2
(multiset inclusion).
We write
1

2
when
2
can be obtained by adding hypotheses to a particular
instance of
1
. In this case, all facts that can be derived by
2
can also be derived by
1
.
A derivation is dened as follows, as illustrated in Figure 3.
Denition 2 (Derivability) Let be a closed fact, that is, a fact without variable. Let
be a set of clauses. is derivable from if and only if there exists a derivation of
from , that is, a nite tree dened as follows:
1. Its nodes (except the root) are labeled by clauses ;
2. Its edges are labeled by closed facts;
3. If the tree contains a node labeled by with one incoming edge labeled by
0
and outgoing edges labeled by
1
, . . . ,
, then
1
. . .

0
.
4. The root has one outgoing edge, labeled by . The unique son of the root is
named the subroot.
subroot
root
1
. . . . . . . . .
. . .
. . .
. . .
0
Figure 3. Derivation of
In a derivation, if there is a node labeled by with one incoming edge labeled by
0
and outgoing edges labeled by
1
, . . . ,
, then
0
can be derived from
1
, . . . ,
by the clause . Therefore, there exists a derivation of fromif and only if can be
derived from clauses in (in classical logic).
2. Resolution Algorithm
Our representation is a set of Horn clauses, and our goal is to determine whether a given
fact can be derived from these clauses or not. This is exactly the problemsolved by usual
Prolog systems. However, we cannot use such systems here, because they would not
terminate. For instance, the clause:
attacker(pencrypt(, pk(sk))) attacker(sk) attacker()
leads to considering more and more complex terms, with an unbounded number of en-
cryptions. We could of course limit arbitrarily the depth of terms to solve the problem,
but we can do much better than that.
As detailed below, the main idea is to combine pairs of clauses by resolution, and to
guide this resolution process by a selection function: our resolution algorithm is resolu-
tion with free selection [51,75,14]. This algorithm is similar to ordered resolution with
selection, used by [86], but without the ordering constraints.
Notice that, since a term is secret when a fact is not derivable from the clauses,
soundness in terms of security (if the verier claims that there is no attack, then there is
no attack) corresponds to the completeness of the resolution algorithm in terms of logic
programming (if the algorithm claims that a fact is not derivable, then it is not). The
resolution algorithm that we use must therefore be complete.
2.1. The Basic Algorithm
Let us rst dene resolution: when the conclusion of a clause unies with a hypothesis
of another (or the same) clause
, resolution infers a new clause that corresponds to

applying and
one after the other. Formally, resolution is dened as follows:

Denition 3 Let and
be two clauses, = , and
. Assume
that there exists
0

such that and

0
are uniable and is the most general
unier of and
0
. In this case, we dene
= ( (
{
0
}))
.
The clause
is the result of resolving
with upon
0
.
For example, if is the clause (2),
is the clause (1), and the fact

0
is
0
=
attacker(pencrypt(, pk())), then
is
attacker(pk()) attacker() attacker(sign([pk()], sk
[ ]))
with the substitution = {sk , sign([pk()], sk
[ ])}.
We guide the resolution by a selection function:
Denition 4 A selection function sel is a function from clauses to sets of facts, such that
sel ( ) . If sel (), we say that is selected in . If sel () = , we say
that no hypothesis is selected in , or that the conclusion of is selected.
The resolution algorithm is correct (sound and complete) with any selection function, as
we show below. However, the choice of the selection function can change dramatically
the behavior of the algorithm. The essential idea of the algorithm is to combine clauses
by resolution only when the facts unied in the resolution are selected. We will therefore
choose the selection function to reduce the number of possible unications between se-
lected facts. Having several selected facts slows down the algorithm, because it has more
choices of resolutions to perform, therefore we will select at most one fact in each clause.
In the case of protocols, facts of the form attacker(), with variable, can be unied
will all facts of the form attacker(). Therefore, we should avoid selecting them. So a
basic selection function is a function sel
0
that satises the constraint
sel
0
( ) =
{
if , variable, = attacker()
{
0
} where
0
and variable,
0
= attacker()
(3)
The resolution algorithm works in two phases, described in Figure 4. The rst phase
transforms the initial set of clauses into a new one that derives the same facts. The second
phase uses a depth-rst search to determine whether a fact can be derived or not from the
clauses.
The rst phase, saturate(
0
), contains 3 steps.
The rst step inserts in the initial clauses representing the protocol and the
attacker (clauses that are in
0
), after elimination of subsumed clauses by elim:
if
subsumes , and and
are in , then is removed by elim().

The second step is a xpoint iteration that adds clauses created by resolution. The
resolution of clauses and
is added only if no hypothesis is selected in and

the hypothesis
0
of
that we unify is selected. When a clause is created by

resolution, it is added to the set of clauses . Subsumed clauses are eliminated
from .
At last, the third step returns the set of clauses of with no selected hypothesis.
Basically, saturate preserves derivability (it is both sound and complete):
First phase: saturation
saturate(
0
) =
1. .
For each
0
, elim({} ).
2. Repeat until a xpoint is reached
for each such that sel () = ,
for each
, for each
0
sel (
) such that
is dened,
elim({
} ).
3. Return { sel () = }.
Second phase: backward depth-rst search
deriv(, ,
1
) =
if

{} otherwise, if sel () =
{deriv(
0
, {} ,
1
)

1
,
0
sel () such that
0
is dened } otherwise
derivable(,
1
) = deriv( , ,
1
)
Figure 4. Resolution algorithm
Lemma 1 (Correctness of saturate) Let be a closed fact. is derivable from
0
if
and only if it is derivable from saturate(
0
).
This result is proved by transforming a derivation of from
0
into a deriva-
tion of from saturate(
0
). Basically, when the derivation contains a clause
with
sel (
) = , we replace in this derivation two clauses , with sel () = , and
that
have been combined by resolution during the execution of saturate with a single clause
. This replacement decreases the number of clauses in the derivation, so it termi-

nates, and, upon termination, all clauses of the obtained derivation satisfy sel (
) =
so they are in saturate(
0
). A detailed proof is given in Section 2.2.
Usually, resolution with selection is used for proofs by refutation. That is, the nega-
tion of the goal is added to the clauses, under the form of a clause without conclu-
sion: . The goal is derivable if and only if the empty clause can be derived.
Here, we would like to avoid repeating the whole resolution process for each goal, since
in general we prove the secrecy of several values for the same protocol. For non-closed
goals, we also want to be able to know which instances of the goal can be derived. That
is why we prove that the clauses in saturate(
0
) derive the same facts as the clauses in
0
. The set of clauses saturate(
0
) can then be used to query several goals, using the
second phase of the algorithm described next.
The second phase searches the facts that can be derived from
1
= saturate(
0
).
This is simply a backward depth-rst search. The call derivable(,
1
) returns a set of
clauses = with no selected hypothesis, such that can be obtained by
resolution from
1
, is an instance of , and all instances of derivable from
1
can
be derived by using as last clause a clause of derivable(,
1
). (Formally, if
is an
instance of derivable from
1
, then there exist a clause derivable(,
1
)
and a substitution such that
= and is derivable from

1
.)
The search itself is performed by deriv(, ,
1
). The function deriv starts with
= and transforms the hypothesis of by using a clause
of
1
to derive
an element
0
of the hypothesis of . So is replaced with
0
(third case of the
denition of deriv). The fact
0
is chosen using the selection function sel . (Hence deriv
derives the hypothesis of using a backward depth-rst search. At each step, the clause
can be obtained by resolution from clauses of
1
, and concludes an instance of .)
The set is the set of clauses that we have already seen during the search. Initially, is
empty, and the clause is added to in the third case of the denition of deriv.
The transformation of described above is repeated until one of the following two
conditions is satised:
is subsumed by a clause in : we are in a cycle; we are looking for instances
of facts that we have already looked for (rst case of the denition of deriv);
sel () is empty: we have obtained a suitable clause and we return it (second
case of the denition of deriv).
Intuitively, the correctness of derivable expresses that if
, instance of , is deriv-
able, then
is derivable from
1
by a derivation in which the clause that concludes
is in derivable(,
1
).
Lemma 2 (Correctness of derivable) Let
be a closed instance of .
is derivable
from
1
if and only if there exist a clause in derivable(,
1
) and a substitution
such that =
and all elements of are derivable from

1
.
Basically, this result is proved by transforming a derivation of
from
1
into a deriva-
tion of
whose last clause (the one that concludes
) is and whose other

clauses are still in
1
. The transformation relies on the replacement of clauses combined
by resolution during the execution of derivable. A detailed proof is given in Section 2.2.
It is important to apply saturate before derivable, so that all clauses in
1
have no
selected hypothesis. Then the conclusion of these clauses is in general not attacker()
(with the optimizations of Section 2.3 and a selection function that satises (3), it is never
attacker()), so that we avoid unifying with attacker().
The following theorem gives the correctness of the whole algorithm. It shows that
we can use our algorithm to determine whether a fact is derivable or not from the initial
clauses. The rst part simply combines Lemmas 1 and 2. The second part mentions two
easy and important particular cases.
Theorem 1 (Correctness) Let
be a closed instance of .
is derivable from
0
if
and only if there exist a clause in derivable(, saturate(
0
)) and a substitution
such that =
and all elements of are derivable from saturate(

0
).
In particular, if derivable(, saturate(
0
)) = , then no instance of is deriv-
able from saturate(
0
). If the selection function satises (3) and is closed, then is
derivable from
0
if and only if derivable(, saturate(
0
)) = .
Proof:
The rst part of the theorem is obvious from Lemmas 1 and 2. The rst particular case
is also an obvious consequence. For the second particular case, if is derivable from
0
, then derivable(, saturate(
0
)) = by the rst particular case. For the converse,
suppose that derivable(, saturate(
0
)) = . Then derivable(, saturate(
0
)) contains
a clause . By denition of derivable, is an instance of , so = , and
sel ( ) = , so all elements of are of the form attacker(
) for some variable

1
(
1
{
0
})
0
Figure 5. Merging of nodes of Lemma 3
. The attacker has at least one term , for instance [ ], so attacker(
) is derivable
from
0
, where
= . Hence all elements of are derivable from

0
, so from
saturate(
0
), and = . Therefore, is derivable from
0
.
2.2. Proofs
In this section, we detail the proofs of Lemmas 1 and 2. We rst need to prove a few
preliminary lemmas. The rst one shows that two nodes in a derivation can be replaced
by one when combining their clauses by resolution.
Lemma 3 Consider a derivation containing a node
, labeled
. Let
0
be a hypothe-
sis of
. Then there exists a son of
, labeled , such that the edge
is labeled
by an instance of
0
,
is dened, and one obtains a derivation of the same fact

by replacing the nodes and
with a node
labeled
.
Proof:
This proof is illustrated in Figure 5. Let
1
be the multiset of the labels
of the outgoing edges of
, and
1
the label of its incoming edge. We have
1
), so there exists a substitution such that
1
and
1
. Since
0

1
, so there is an outgoing edge of
labeled
0
. Let be the node at the end
of this edge, let = be the label of . We rename the variables of so that they
are distinct from the variables of
. Let
1
be the multiset of the labels of the outgoing
edges of . So (
1

0
). By the above choice of distinct variables, we can then
extend so that
1
and =
0
.
The edge
is labeled
0
, instance of
0
. Since =
0
, the facts and
0
are uniable, so
is dened. Let
be the most general unier of and
0
, and
such that =
. We have
( (
{
0
}))
.
Moreover,
( (
{
0
}))
1
(
1
{
0
}) and
1
.
Hence
(
1
(
1
{
0
}))
1
. The multiset of labels of outgoing
edges of
is precisely
1
(
1
{
0
}) and the label of its incoming edge is
1
,
therefore we have obtained a correct derivation by replacing and
with
.
Lemma 4 If a node of a derivation is labeled by , then one obtains a derivation
of the same fact as by relabeling with a clause
such that
.
Proof:
Let be the multiset of labels of outgoing edges of the considered node , and be the
label of its incoming edge. We have . By transitivity of ,
.
So we can relabel with
.
Lemma 5 At the end of saturate, satises the following properties:
1. For all
0
, is subsumed by a clause in ;
2. Let and
. Assume that sel () = and there exists

0
sel (
)
such that
is dened. In this case,
is subsumed by a clause in
.
Proof:
To prove the rst property, let
0
. We show that, after the addition of to , is
subsumed by a clause in .
In the rst step of saturate, we execute the instruction elim({} ). After
execution of this instruction, is subsumed by a clause in .
Assume that we execute elim({
} ) for some clause
and that, before

this execution, is subsumed by a clause in , say
. If
is removed by this instruc-

tion, there exists a clause
1
in that subsumes
, so by transitivity of subsumption,
1
subsumes , hence is subsumed by the clause
1
after this instruction. If
is not removed by this instruction, then is subsumed by the clause
after this
instruction.
Hence, at the end of saturate, is subsumed by a clause in , which proves the
rst property.
In order to prove the second property, we just need to notice that the xpoint is
reached at the end of saturate, so = elim({
} ). Hence,
is
eliminated by elim, so it is subsumed by some clause in .
Proof of Lemma 1:
Assume that is derivable from
0
and consider a derivation of from
0
. We show
that is derivable from saturate(
0
).
We consider the value of the set of clauses at the end of saturate. For each clause
in
0
, is subsumed by a clause in (Lemma 5, Property 1). So, by Lemma 4, we
can replace all clauses in the considered derivation with a clause in . Therefore, we
obtain a derivation of from .
Next, we build a derivation of from
1
, where
1
= saturate(
0
). If contains
a node labeled by a clause not in
1
, we can transform as follows. Let
be a lowest
node of labeled by a clause not in
1
. So all sons of
are labeled by elements of

1
.
Let
be the clause labeling
. Since
/
1
, sel (
) = . Take
0
sel (
). By
Lemma 3, there exists a son of of
labeled by , such that
is dened, and we
can replace and
with a node
labeled by
. Since all sons of
are labeled
by elements of
1
,
1
. Hence sel () = . So, by Lemma 5, Property 2,
is subsumed by a clause
in . By Lemma 4, we can relabel
with
. The total
number of nodes strictly decreases since and
are replaced with a single node
.
So we obtain a derivation
of from , such that the total number of nodes

strictly decreases. Hence, this replacement process terminates. Upon termination, all
clauses are in
1
. So we obtain a derivation of from
1
, which is the expected result.
For the converse implication, notice that, if a fact is derivable from
1
, then it is
derivable from , and that all clauses added to do not create new derivable facts: if a
fact is derivable by applying the clause
, then it is also derivable by applying

and
.
Proof of Lemma 2:
Let us prove the direct implication. We show that, if
is derivable from
1
, then there
exist a clause in derivable(,
1
) and a substitution such that =
and
all elements of are derivable from
1
.
Let be the set of derivations
of
such that, for some , the clause
at the
subroot of
satises deriv(
, ,
1
) derivable(,
1
) and
,
and the other clauses of
are in
1
.
Let
0
be a derivation of
from
1
. Let
0
be obtained from
0
by adding
a node labeled by
= at the subroot of
0
. By denition of derivable,
deriv(
, ,
1
) derivable(,
1
), and
. Hence
0
is a derivation
of
in , so is non-empty.
Now, consider a derivation
1
in with the smallest number of nodes. The clause
labeling the subroot
of
1
satises deriv(
, ,
1
) derivable(,
1
), and
. In order to obtain a contradiction, we assume that sel (
) = . Let
0
sel (
). By Lemma 3, there exists a son of
, labeled by , such that
is dened and we can replace and
with a node
labeled by
0
=
,
obtaining a derivation
2
of
with fewer nodes than

1
. The subroot of
2
is the node
labeled by
0
.
By hypothesis on the derivation
1
,
1
, so deriv(
0
, {
} ,
1
)
deriv(
, ,
1
) derivable(,
1
) (third case of the denition of deriv(
, ,
1
)).
If
1
{
} ,
1

0
,
2
is a derivation of
in , with fewer nodes

than
1
, which is a contradiction.
Otherwise,
1
{
} ,
1

0
. Therefore, by Lemma 4, we can build
a derivation
3
by relabeling
with
1
in
2
. There is an older call to deriv,
of the form deriv(
1
,
,
1
), such that deriv(
1
,
,
1
) derivable(,
1
).
Moreover,
1
has been added to
in this call, since

1
appears in {
} .
Therefore the third case of the denition of deriv(
1
,
,
1
) has been applied,
and not the rst case. So
2

,
2

1
, so the derivation
3
is in and
has fewer nodes than
1
, which is a contradiction.
In all cases, we could nd a derivation in that has fewer nodes than
1
. This is a
contradiction, so sel (
) = , hence deriv(
, ,
1
) = {
} (second case of the

denition of deriv), so
derivable(,
1
). The other clauses of this derivation are in
1
. By denition of a derivation,
where
is the multiset of labels of

the outgoing edges of the subroot of the derivation. Taking
= , there exists
such that = and
, so all elements of are derivable from

1
.
The proof of the converse implication is left to the reader. (Basically, if a fact is
derivable by applying the clause
, then it is also derivable by applying and
.)
2.3. Optimizations
The resolution algorithm uses several optimizations, in order to speed up resolution. The
rst two are standard, while the last three are specic to protocols.
Elimination of duplicate hypotheses If a clause contains several times the same hy-
potheses, the duplicate hypotheses are removed, so that at most one occurrence of each
hypothesis remains.
Elimination of tautologies If a clause has a conclusion that is already in the hypotheses,
this clause is a tautology: it does not derive new facts. Such clauses are removed.
Elimination of hypotheses attacker() If a clause contains in its hypotheses
attacker(), where is a variable that does not appear elsewhere in the clause, then the
hypothesis attacker() is removed. Indeed, the attacker always has at least one message,
so attacker() is always satised for some value of .
Decomposition of data constructors A data constructor is a constructor of arity
that comes with associated destructors
for {1, . . . , } dened by
((
1
, . . . ,
))
. Data constructors are typically used for representing data structures. Tuples
are examples of data constructors. For each data constructor , the following clauses are
generated:
attacker(
1
) . . . attacker(
) attacker((
1
, . . . ,
)) (Rf)
attacker((
1
, . . . ,
)) attacker(
) (Rg)
Therefore, attacker((
1
, . . . ,
)) is derivable if and only if {1, . . . , },

attacker(
) is derivable. When a fact of the form attacker((

1
, . . . ,
)) is met, it is
replaced with attacker(
1
). . .attacker(
). If this replacement is done in the conclu-

sion of a clause attacker((
1
, . . . ,
)), clauses are created: attacker(
)
for each {1, . . . , }. This replacement is of course done recursively: if
itself is
a data constructor application, it is replaced again. The clauses (Rf) and (Rg) for data
constructors are left unchanged. (When attacker() cannot be selected, the clauses (Rf)
and (Rg) for data constructors are in fact not necessary, because they generate only tau-
tologies during resolution. However, when attacker() can be selected, which cannot be
excluded with certain extensions, these clauses may become necessary for soundness.)
Secrecy assumptions When the user knows that a fact will not be derivable, he can tell
it to the verier. (When this fact is of the formattacker(), the user tells that remains
secret.) The tool then removes all clauses which have this fact in their hypotheses. At
the end of the computation, the tool checks that the fact is indeed underivable from
the obtained clauses. If the user has given erroneous information, an error message is
displayed. Even in this case, the verier never wrongly claims that a protocol is secure.
Mentioning such underivable facts prunes the search space, by removing useless
clauses. This speeds up the resolution algorithm. In most cases, the secret keys of
the principals cannot be known by the attacker. So, examples of underivable facts are
attacker(sk
[ ]), attacker(sk
[ ]), . . .
For simplicity, the proofs given in Section 2.2 do not take into account these opti-
mizations. For a full proof, we refer the reader to [30, Appendix C].
2.4. Termination
In general, the resolution algorithm may not terminate. (The derivability problem is un-
decidable.) In practice, however, it terminates in most examples.
We have shown with Podelski that it always terminates on a large and interesting
class of protocols, the tagged protocols [35]. We consider protocols that use as crypto-
graphic primitives only public-key encryption and signatures with atomic keys, shared-
key encryption, message authentication codes, and hash functions. Basically, a protocol
is tagged when each application of a cryptographic primitive is marked with a distinct
constant tag. It is easy to transform a protocol into a tagged protocol by adding tags. For
instance, our example of protocol can be transformed into a tagged protocol, by adding
the tags
0
,
1
,
2
to distinguish the encryptions and signature:
Message 1. :
{
1
, [
0
, ]
sk
}
a
pk
Message 2. : {
2
, }
s
Adding tags preserves the expected behavior of the protocol, that is, the attack-free ex-
ecutions are unchanged. In the presence of attacks, the tagged protocol may be more
secure. Hence, tagging is a feature of good protocol design, as explained e.g. in [9]: the
tags are checked when the messages are received; they facilitate the decoding of the re-
ceived messages and prevent confusions between messages. More formally, tagging pre-
vents type-aw attacks [66], which occur when a message is taken for another message.
However, the tagged protocol is potentially more secure than its untagged version, so, in
other words, a proof of security for the tagged protocol does not imply the security of its
untagged version.
Other authors have proved related results: Ramanujan and Suresh [85] have shown
that secrecy is decidable for tagged protocols. However, their tagging scheme is stronger
since it forbids blind copies. A blind copy happens when a protocol participant sends
back part of a message he received without looking at what is contained inside this part.
On the other hand, they obtain a decidability result, while we obtain a termination result
for an algorithm which is sound, efcient in practice, but approximate. Arapinis and Du-
ot [13] extend this result but still forbid blind copies. Comon-Lundh and Cortier [47]
show that an algorithm using ordered binary resolution, ordered factorization and split-
ting terminates on protocols that blindly copy at most one term in each message. In con-
trast, our result puts no limit on the number of blind copies, but requires tagging.
For protocols that are not tagged, we have also designed some heuristics to adapt the
selection function in order to obtain termination more often. We refer the reader to [32,
Section 8.2] for more details.
It is also possible to obtain termination in all cases at the cost of additional abstrac-
tions. For instance, Goubault-Larrecq shows that one can abstract the clauses into clauses
in the decidable class
1
[63], by losing some relational information on the messages.
3. Extensions
3.1. Treatment of Equations
Up to now, we have dened cryptographic primitives by associating rewrite rules to de-
structors. Another way of dening primitives is by equational theories, as in the applied
pi calculus [6]. This allows us to model, for instance, variants of encryption for which
the failure of decryption cannot be detected or more complex primitives such as Dife-
Hellman key agreements. The Dife-Hellman key agreement [54] enables two principals
to build a shared secret. It is used as an elementary step in more complex protocols, such
as Skeme [69], SSH, SSL, and IPsec.
The Horn clause verication approach can be extended to handle some equational
theories. For example, the Dife-Hellman key agreement can be modeled by using a
constant g and a function exp that satisfy the equation
exp(exp(g, ), ) = exp(exp(g, ), ). (4)
In practice, the function is exp(, ) =
mod , where is prime and g is a gen-

erator of
. The equation exp(exp(g, ), ) = (g
mod = (g
mod =
exp(exp(g, ), ) is satised. In ProVerif, following the ideas used in the applied pi cal-
culus [6], we do not consider the underlying number theory; we work abstractly with
the equation (4). The Dife-Hellman key agreement involves two principals and .
chooses a random name
0
, and sends exp(g,
0
) to . Similarly, chooses a random
name
1
, and sends exp(g,
1
) to . Then computes exp(exp(g,
1
),
0
) and com-
putes exp(exp(g,
0
),
1
). Both values are equal by (4), and they are secret: assuming
that the attacker cannot have
0
or
1
, it can compute neither exp(exp(g,
1
),
0
) nor
exp(exp(g,
0
),
1
).
In ProVerif, the equation (4) is translated into the rewrite rules
exp(exp(g, ), ) exp(exp(g, ), ) exp(, ) exp(, ).
Notice that this denition of exp is non-deterministic: a term such as exp(exp(g, ), )
can be reduced to exp(exp(g, ), ) and exp(exp(g, ), ), so that exp(exp(g, ), ) re-
duces to its two forms modulo the equational theory. The rewrite rules in the denition
of function symbols are applied exactly once when the function is applied. So the rewrite
rule exp(, ) exp(, ) is necessary to make sure that exp never fails, even when
the rst rewrite rule cannot be applied, and these rewrite rules do not loop because they
are applied only once at each application of exp. More details on the treatment of equa-
tions in ProVerif and, in particular, a proof that these rewrite rules correctly model the
equation (4) can be found in [33, Section 5].
This treatment of equations has the advantage that resolution can still use syntactic
unication, so it remains efcient. However, it also has limitations; for example, it cannot
handle associative functions, such as XOR, because it would generate an innite number
of rewrite rules for the destructors. Recently, other treatments of equations that can han-
dle XOR and Dife-Hellman key agreements with more detailed algebraic relations (in-
cluding equations of the multiplicative group modulo ) within the Horn clause approach
have been proposed by Ksters and Truderung: they handle XOR provided one of its two
arguments is a constant in the clauses that model the protocol [71] and Dife-Hellman
key agreements provided the exponents are constants in the clauses that model the pro-
tocol [72]; they proceed by transforming the initial clauses into richer clauses on which
the standard resolution algorithm is applied. We refer the reader to Chapter Verifying
a bounded number of sessions and its complexity for the treatment of equations for a
bounded number of sessions, to [49,46] for treatments of XOR for a bounded number
of sessions, and to [76,45,65,78] for other treatments of Dife-Hellman key agreements,
using unication modulo [76,65] or for a bounded number of sessions [45,78].
3.2. Translation from the Applied Pi Calculus
ProVerif does not require the user to manually enter the Horn clauses described previ-
ously. These clauses can be generated automatically from a specication of the protocol
in the applied pi calculus [6]. (Chapter Applied Pi Calculus presents cryptographic pi
calculi, and the applied pi calculus in particular.) On such specications, ProVerif can
verify various security properties, by using an adequate translation into Horn clauses:
secrecy, as described above. The translation from the applied pi calculus to Horn
clauses is given in [3].
correspondences, which are properties of the formif an event has been executed,
then other events have been executed [32]. They can in particular be used for
formalizing authentication.
some process equivalences, which mean intuitively that the attacker cannot dis-
tinguish two processes (i.e. protocols). Process equivalences can be used for for-
malizing various security properties, in particular by expressing that the attacker
cannot distinguish a process from its specication. ProVerif can prove particu-
lar cases of observational equivalences. It can prove strong secrecy [28], which
means that the attacker cannot see when the value of the secret changes. This is a
stronger notion of secrecy than the one mentioned previously. It can be used, for
instance, for expressing the secrecy of values taken among a set of known con-
stants, such as bits: one shows that the attacker cannot distinguish whether the bit
is 0 or 1. More generally, ProVerif can also prove equivalences between processes
that differ by the terms they contain, but have otherwise the same structure [33].
In particular, these equivalences can express that a password-based protocol is
resistant to guessing attacks: even if the attacker guesses the password, it cannot
verify that its guess is correct.
As for secrecy, when no derivation from the clauses is found, the desired security prop-
erty is proved. When a derivation is found, there may be attack. ProVerif then tries to
reconstruct a trace in the applied pi calculus semantics that corresponds to this deriva-
tion [11]. (Trace reconstruction may fail, in particular when the derivation corresponds
to a false attack; in this case, one does not know whether there is an attack or not.)
4. Application to Examples of Protocols
The automatic protocol verier ProVerif is available at http://www.proverif.
ens.fr/. It was successfully applied to many protocols of the literature, to prove
secrecy and authentication properties: awed and corrected versions of the Needham-
Schroeder public-key [81,73] and shared-key [81,42,82], Woo-Lam public-key [87,88]
and shared-key [87,12,9,88,61], Denning-Sacco [53,9], Yahalom [42], Otway-Rees [83,
9,84], and Skeme [69] protocols. No false attack occurred in these tests and the only non-
termination cases were some awed versions of the Woo-Lam shared-key protocol. The
other protocols were veried in less than one second each on a Pentium M 1.8 GHz [30].
ProVerif was also used for proving strong secrecy in the corrected version of the
Needham-Schroeder public-key protocol [73] and in the Otway-Rees [83], Yahalom[42],
and Skeme [69] protocols, the resistance to guessing attacks for the password-based pro-
tocols EKE [18] and Augmented EKE [19], and authentication in the Wide-Mouth-Frog
protocol [8] (version with one session). The runtime went from less than one second to
15 s on these tests, on a Pentium M 1.8 GHz [28,33].
Moreover, ProVerif was also used in more substantial case studies:
With Abadi [4], we applied it to the verication of a certied email protocol [7].
We use correspondence properties to prove that the receiver receives the message
if and only if the sender has a receipt for the message. (We use simple manual
arguments to take into account that the reception of sent messages is guaranteed.)
One of the tested versions includes the SSH transport layer in order to establish a
secure channel. (Total runtime: 6 min on a Pentium M 1.8 GHz.)
With Abadi and Fournet [5], we studied the JFK protocol (Just Fast Keying) [10],
which was one of the candidates to the replacement of IKE as key exchange proto-
col in IPSec. We combined manual proofs and ProVerif to prove correspondences
and equivalences. (Total runtime: 3 min on a Pentium M 1.8 GHz.)
With Chaudhuri [34], we studied the secure lesystem Plutus [67] with ProVerif,
which allowed us to discover and x weaknesses of the initial system.
Other authors also use ProVerif for verifying protocols or for building other tools:
Bhargavan et al. [26,22,20] use it to build the Web services verication tool Tu-
laFale: Web services are protocols that send XML messages; TulaFale translates
them into the input format of ProVerif and uses ProVerif to prove the desired
security properties.
Bhargavan et al. [25,23,24] use ProVerif for verifying implementations of pro-
tocols in F# (a functional language of the Microsoft .NET environment): a sub-
set of F# large enough for expressing security protocols is translated into the in-
put format of ProVerif. The TLS protocol, in particular, was studied using this
technique [21].
Canetti and Herzog [43] use ProVerif for verifying protocols in the computational
model: they show that, for a restricted class of protocols that use only public-key
encryption, a proof in the Dolev-Yao model implies security in the computational
model, in the universal composability framework. Authentication is veried using
correspondences, while secrecy of keys corresponds to strong secrecy.
ProVerif was also used for verifying a certied email web service [74], a certied
mailing-list protocol [68], e-voting protocols [70,16], the ad-hoc routing protocol
ARAN (Authenticated Routing for Adhoc Networks) [60], and zero-knowledge
protocols [17].
Finally, Goubault-Larrecq and Parrennes [64] also use the Horn clause method for ana-
lyzing implementations of protocols written in C. However, they translate protocols into
clauses of the
1
class and use the
1
prover by Goubault-Larrecq [63] rather than
ProVerif to prove secrecy properties of the protocol.
5. Conclusion
A strong aspect of the Horn clause approach is that it can prove security properties of
protocols for an unbounded number of sessions, in a fully automatic way. This is essential
for the certication of protocols. It also supports a wide variety of security primitives and
can prove a wide variety of security properties.
On the other hand, the verication problemis undecidable for an unbounded number
of sessions, so the approach is not complete: it does not always terminate and it performs
approximations, so there exist secure protocols that it cannot prove, even if it is very
precise and efcient in practice.
Acknowledgments This work owes much to discussions with Martn Abadi. I am very
grateful to him for what he taught me. We thank Mark Ryan and Ben Smyth for com-
ments on a draft of this chapter. This work was partly done at Bell Labs Research, Lucent
Technologies, Palo Alto and at Max-Planck-Institut fr Informatik, Saarbrcken. This
chapter borrows material from [27,31,32].
References
[1] M. Abadi. Security protocols and their properties. In Foundations of Secure Computation, NATO
Science Series, pages 3960. IOS Press, 2000.
[2] M. Abadi and B. Blanchet. Secrecy types for asymmetric communication. In Foundations of Software
Science and Computation Structures (FoSSaCS 2001), volume 2030 of LNCS, pages 2541. Springer,
Apr. 2001.
[3] M. Abadi and B. Blanchet. Analyzing security protocols with secrecy types and logic programs. Journal
of the ACM, 52(1):102146, Jan. 2005.
[4] M. Abadi and B. Blanchet. Computer-assisted verication of a protocol for certied email. Science of
Computer Programming, 58(12):327, Oct. 2005. Special issue SAS03.
[5] M. Abadi, B. Blanchet, and C. Fournet. Just Fast Keying in the pi calculus. ACM Transactions on
Information and System Security (TISSEC), 10(3):159, July 2007.
[6] M. Abadi and C. Fournet. Mobile values, new names, and secure communication. In 28th Annual ACM
SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL01), pages 104115.
ACM Press, Jan. 2001.
[7] M. Abadi, N. Glew, B. Horne, and B. Pinkas. Certied email with a light on-line trusted third party:
Design and implementation. In 11th International World Wide Web Conference, pages 387395. ACM
Press, May 2002.
[8] M. Abadi and A. D. Gordon. A calculus for cryptographic protocols: The spi calculus. Information and
Computation, 148(1):170, Jan. 1999.
[9] M. Abadi and R. Needham. Prudent engineering practice for cryptographic protocols. IEEE Transac-
tions on Software Engineering, 22(1):615, Jan. 1996.
[10] W. Aiello, S. M. Bellovin, M. Blaze, R. Canetti, J. Ioannidis, K. Keromytis, and O. Reingold. Just Fast
Keying: Key agreement in a hostile Internet. ACM Transactions on Information and System Security,
7(2):242273, May 2004.
[11] X. Allamigeon and B. Blanchet. Reconstruction of attacks against cryptographic protocols. In 18th
IEEE Computer Security Foundations Workshop (CSFW-18), pages 140154. IEEE, June 2005.
[12] R. Anderson and R. Needham. Programming Satans computer. In Computer Science Today: Recent
Trends and Developments, volume 1000 of LNCS, pages 426440. Springer, 1995.
[13] M. Arapinis and M. Duot. Bounding messages for free in security protocols. In 27th Conference on
Foundations of Software Technology and Theoretical Computer Science (FSTTCS07), volume 4855 of
LNCS, pages 376387. Springer, Dec. 2007.
[14] L. Bachmair and H. Ganzinger. Resolution theorem proving. In Handbook of Automated Reasoning,
volume 1, chapter 2, pages 19100. North Holland, 2001.
[15] M. Backes, A. Cortesi, and M. Maffei. Causality-based abstraction of multiplicity in security protocols.
In 20th IEEE Computer Security Foundations Symposium (CSF07), pages 355369. IEEE, July 2007.
[16] M. Backes, C. Hritcu, and M. Maffei. Automated verication of electronic voting protocols in the
applied pi-calculus. In 21st IEEE Computer Security Foundations Symposium (CSF08), pages 195209.
IEEE Computer Society, June 2008.
[17] M. Backes, M. Maffei, and D. Unruh. Zero-knowledge in the applied pi-calculus and automated veri-
cation of the direct anonymous attestation protocol. In 29th IEEE Symposium on Security and Privacy,
pages 202215. IEEE, May 2008.
[18] S. M. Bellovin and M. Merritt. Encrypted Key Exchange: Password-based protocols secure against
dictionary attacks. In Proceedings of the 1992 IEEE Computer Society Symposium on Research in
Security and Privacy, pages 7284, May 1992.
[19] S. M. Bellovin and M. Merritt. Augmented Encrypted Key Exchange: a password-based protocol secure
against dictionary attacks and password le compromise. In Proceedings of the First ACM Conference
on Computer and Communications Security, pages 244250, Nov. 1993.
[20] K. Bhargavan, R. Corin, C. Fournet, and A. Gordon. Secure sessions for web services. In ACMWorkshop
on Secure Web Services (SWS04), Oct. 2004.
[21] K. Bhargavan, R. Corin, C. Fournet, and E. Z alinescu. Cryptographically veried implementations
for TLS. In Proceedings of the 15th ACM Conference on Computer and Communications Security
(CCS08), pages 459468. ACM, Oct. 2008.
[22] K. Bhargavan, C. Fournet, and A. Gordon. Verifying policy-based security for web services. In ACM
Conference on Computer and Communications Security (CCS04), pages 268277. ACM, Oct. 2004.
[23] K. Bhargavan, C. Fournet, and A. Gordon. Veried reference implementations of WS-Security protocols.
In 3rd International Workshop on Web Services and Formal Methods (WS-FM 2006), volume 4184 of
LNCS, pages 88106. Springer, Sept. 2006.
[24] K. Bhargavan, C. Fournet, A. Gordon, and N. Swamy. Veried implementations of the information card
federated identity-management protocol. In ACM Symposium on Information, Computer and Commu-
nications Security (ASIACCS08), pages 123135. ACM, Mar. 2008.
[25] K. Bhargavan, C. Fournet, A. Gordon, and S. Tse. Veried interoperable implementations of security
protocols. In 19th IEEE Computer Security Foundations Workshop (CSFW06), pages 139152. IEEE
Computer Society, July 2006.
[26] K. Bhargavan, C. Fournet, A. D. Gordon, and R. Pucella. TulaFale: A security tool for web services. In
Formal Methods for Components and Objects (FMCO 2003), volume 3188 of LNCS, pages 197222.
Springer, Nov. 2003. Paper and tool available at http://securing.ws/.
[27] B. Blanchet. An efcient cryptographic protocol verier based on Prolog rules. In 14th IEEE Computer
Security Foundations Workshop (CSFW-14), pages 8296. IEEE Computer Society, June 2001.
[28] B. Blanchet. Automatic proof of strong secrecy for security protocols. In IEEE Symposium on Security
and Privacy, pages 86100, May 2004.
[29] B. Blanchet. Security protocols: From linear to classical logic by abstract interpretation. Information
Processing Letters, 95(5):473479, Sept. 2005.
[30] B. Blanchet. Automatic verication of correspondences for security protocols. Report
arXiv:0802.3444v1, 2008. Available at http://arxiv.org/abs/0802.3444v1.
[31] B. Blanchet. Vrication automatique de protocoles cryptographiques : modle formel et modle cal-
culatoire. Mmoire dhabilitation diriger des recherches, Universit Paris-Dauphine, Nov. 2008.
[32] B. Blanchet. Automatic verication of correspondences for security protocols. Journal of Computer
Security, 17(4):363434, July 2009.
[33] B. Blanchet, M. Abadi, and C. Fournet. Automated verication of selected equivalences for security
protocols. Journal of Logic and Algebraic Programming, 75(1):351, Feb.Mar. 2008.
[34] B. Blanchet and A. Chaudhuri. Automated formal analysis of a protocol for secure le sharing on
untrusted storage. In IEEE Symposium on Security and Privacy, pages 417431. IEEE, May 2008.
[35] B. Blanchet and A. Podelski. Verication of cryptographic protocols: Tagging enforces termination.
Theoretical Computer Science, 333(1-2):6790, Mar. 2005. Special issue FoSSaCS03.
[36] C. Bodei. Security Issues in Process Calculi. PhD thesis, Universit di Pisa, Jan. 2000.
[37] C. Bodei, M. Buchholtz, P. Degano, F. Nielson, and H. R. Nielson. Static validation of security protocols.
Journal of Computer Security, 13(3):347390, 2005.
[38] C. Bodei, P. Degano, F. Nielson, and H. R. Nielson. Control ow analysis for the -calculus. In
International Conference on Concurrency Theory (CONCUR98), volume 1466 of LNCS, pages 8498.
Springer, Sept. 1998.
[39] Y. Boichut, N. Kosmatov, and L. Vigneron. Validation of prouv protocols using the automatic tool
TA4SP. In Proceedings of the Third Taiwanese-French Conference on Information Technology (TFIT
2006), pages 467480, Mar. 2006.
[40] D. Bolignano. Towards a mechanization of cryptographic protocol verication. In 9th International
Conference on Computer Aided Verication (CAV97), volume 1254 of LNCS, pages 131142. Springer,
1997.
[41] L. Bozga, Y. Lakhnech, and M. Prin. Pattern-based abstraction for verifying secrecy in protocols.
International Journal on Software Tools for Technology Transfer (STTT), 8(1):5776, Feb. 2006.
[42] M. Burrows, M. Abadi, and R. Needham. A logic of authentication. Proceedings of the Royal Society
of London A, 426:233271, 1989.
[43] R. Canetti and J. Herzog. Universally composable symbolic analysis of mutual authentication and key
exchange protocols. In Proceedings, Theory of Cryptography Conference (TCC06), volume 3876 of
LNCS, pages 380403. Springer, Mar. 2006.
[44] L. Cardelli, G. Ghelli, and A. D. Gordon. Secrecy and group creation. In CONCUR 2000: Concurrency
Theory, volume 1877 of LNCS, pages 365379. Springer, Aug. 2000.
[45] Y. Chevalier, R. Ksters, M. Rusinowitch, and M. Turuani. Deciding the security of protocols with
Dife-Hellman exponentiation and products in exponents. In FST TCS 2003: Foundations of Software
Technology and Theoretical Computer Science, 23rd Conference, volume 2914 of LNCS, pages 124
135. Springer, Dec. 2003.
[46] Y. Chevalier, R. Ksters, M. Rusinowitch, and M. Turuani. An NP decision procedure for protocol
insecurity with XOR. Theoretical Computer Science, 338(13):247274, June 2005.
[47] H. Comon-Lundh and V. Cortier. New decidability results for fragments of rst-order logic and applica-
tion to cryptographic protocols. In 14th Int. Conf. Rewriting Techniques and Applications (RTA2003),
volume 2706 of LNCS, pages 148164. Springer, June 2003.
[48] H. Comon-Lundh and V. Cortier. Security properties: two agents are sufcient. In Programming Lan-
guages and Systems: 12th European Symposium on Programming (ESOP03), volume 2618 of LNCS,
pages 99113. Springer, Apr. 2003.
[49] H. Comon-Lundh and V. Shmatikov. Intruder deductions, constraint solving and insecurity decision in
presence of exclusive or. In Symposium on Logic in Computer Science (LICS03), pages 271280. IEEE
Computer Society, June 2003.
[50] P. Cousot and R. Cousot. Systematic design of program analysis frameworks. In 6th Annual ACM
Symposium on Principles of Programming Languages, pages 269282, 29-31 Jan. 1979.
[51] H. de Nivelle. Ordering Renements of Resolution. PhD thesis, Technische Universiteit Delft, Oct.
1995.
[52] G. Denker, J. Meseguer, and C. Talcott. Protocol specication and analysis in Maude. In Workshop on
Formal Methods and Security Protocols, 25 June 1998.
[53] D. E. Denning and G. M. Sacco. Timestamps in key distribution protocols. Commun. ACM, 24(8):533
536, Aug. 1981.
[54] W. Dife and M. Hellman. New directions in cryptography. IEEE Transactions on Information Theory,
IT-22(6):644654, Nov. 1976.
[55] D. Dolev and A. C. Yao. On the security of public key protocols. IEEE Transactions on Information
Theory, IT-29(12):198208, Mar. 1983.
[56] N. Durgin, P. Lincoln, J. C. Mitchell, and A. Scedrov. Multiset rewriting and the complexity of bounded
security protocols. Journal of Computer Security, 12(2):247311, 2004.
[57] S. Escobar, C. Meadows, and J. Meseguer. A rewriting-based inference system for the NRL protocol
analyzer and its meta-logical properties. Theoretical Computer Science, 367(1-2):162202, 2006.
[58] G. Fil and R. Vigo. Expressive power of denite clauses for verifying authenticity. In 22nd IEEE
Computer Security Foundations Symposium (CSF09), pages 251265. IEEE, July 2009.
[59] T. Genet and F. Klay. Rewriting for cryptographic protocol verication. In 17thInternational Conference
on Automated Deduction (CADE-17), volume 1831 of LNCS, pages 271290. Springer, June 2000.
[60] J. C. Godskesen. Formal verication of the ARAN protocol using the applied pi-calculus. In 6th
International IFIP WG 1.7 Workshop on Issues in the Theory of Security (WITS06), pages 99113, Mar.
2006.
[61] A. Gordon and A. Jeffrey. Authenticity by typing for security protocols. Journal of Computer Security,
11(4):451521, 2003.
[62] J. Goubault-Larrecq. A method for automatic cryptographic protocol verication (extended abstract),
invited paper. In Fifth International Workshop on Formal Methods for Parallel Programming: Theory
and Applications (FMPPTA2000), volume 1800 of LNCS, pages 977984. Springer, May 2000.
[63] J. Goubault-Larrecq. Deciding
1
by resolution. Information Processing Letters, 95(3):401408, Aug.
2005.
[64] J. Goubault-Larrecq and F. Parrennes. Cryptographic protocol analysis on real C code. In Proceed-
ings of the 6th International Conference on Verication, Model Checking and Abstract Interpretation
(VMCAI05), volume 3385 of LNCS, pages 363379. Springer, Jan. 2005.
[65] J. Goubault-Larrecq, M. Roger, and K. N. Verma. Abstraction and resolution modulo AC: How to verify
Dife-Hellman-like protocols automatically. Journal of Logic and Algebraic Programming, 64(2):219
251, Aug. 2005.
[66] J. Heather, G. Lowe, and S. Schneider. How to prevent type aw attacks on security protocols. In 13th
IEEE Computer Security Foundations Workshop (CSFW-13), pages 255268, July 2000.
[67] M. Kallahalla, E. Riedel, R. Swaminathan, Q. Wang, and K. Fu. Plutus: Scalable secure le sharing
on untrusted storage. In 2nd Conference on File and Storage Technologies (FAST03), pages 2942.
Usenix, Apr. 2003.
[68] H. Khurana and H.-S. Hahm. Certied mailing lists. In Proceedings of the ACM Symposium on Com-
munication, Information, Computer and Communication Security (ASIACCS06), pages 4658. ACM,
Mar. 2006.
[69] H. Krawczyk. SKEME: A versatile secure key exchange mechanism for Internet. In Internet Society
Symposium on Network and Distributed Systems Security, Feb. 1996.
[70] S. Kremer and M. D. Ryan. Analysis of an electronic voting protocol in the applied pi calculus. In Pro-
gramming Languages and Systems: 14th European Symposium on Programming, ESOP 2005, volume
3444 of LNCS, pages 186200. Springer, Apr. 2005.
[71] R. Ksters and T. Truderung. Reducing protocol analysis with XOR to the XOR-free case in the Horn
theory based approach. In Proceedings of the 15th ACM conference on Computer and communications
security (CCS08), pages 129138. ACM, Oct. 2008.
[72] R. Ksters and T. Truderung. Using ProVerif to analyze protocols with Dife-Hellman exponentiation.
In 22nd IEEE Computer Security Foundations Symposium (CSF09), pages 157171. IEEE, July 2009.
[73] G. Lowe. Breaking and xing the Needham-Schroeder public-key protocol using FDR. In Tools and Al-
gorithms for the Construction and Analysis of Systems, volume 1055 of LNCS, pages 147166. Springer,
1996.
[74] K. D. Lux, M. J. May, N. L. Bhattad, and C. A. Gunter. WSEmail: Secure internet messaging based on
web services. In International Conference on Web Services (ICWS05), pages 7582. IEEE Computer
Society, July 2005.
[75] C. Lynch. Oriented equational logic programming is complete. Journal of Symbolic Computation,
21(1):2345, 1997.
[76] C. Meadows and P. Narendran. A unication algorithm for the group Dife-Hellman protocol. In
Workshop on Issues in the Theory of Security (WITS02), Jan. 2002.
[77] C. A. Meadows. The NRL protocol analyzer: An overview. Journal of Logic Programming, 26(2):113
131, 1996.
[78] J. Millen and V. Shmatikov. Symbolic protocol analysis with an abelian group operator or Dife-
Hellman exponentiation. Journal of Computer Security, 13(3):515564, 2005.
[79] J. K. Millen, S. C. Clark, and S. B. Freedman. The Interrogator: Protocol security analysis. IEEE
Transactions on Software Engineering, SE-13(2):274288, Feb. 1987.
[80] D. Monniaux. Abstracting cryptographic protocols with tree automata. Science of Computer Program-
ming, 47(23):177202, 2003.
[81] R. M. Needham and M. D. Schroeder. Using encryption for authentication in large networks of comput-
ers. Commun. ACM, 21(12):993999, Dec. 1978.
[82] R. M. Needham and M. D. Schroeder. Authentication revisited. Operating Systems Review, 21(1):7,
1987.
[83] D. Otway and O. Rees. Efcient and timely mutual authentication. Operating Systems Review, 21(1):8
10, 1987.
[84] L. C. Paulson. The inductive approach to verifying cryptographic protocols. Journal of Computer
Security, 6(12):85128, 1998.
[85] R. Ramanujam and S. Suresh. Tagging makes secrecy decidable with unbounded nonces as well. In
FST TCS 2003: Foundations of Software Technology and Theoretical Computer Science, volume 2914
of LNCS, pages 363374. Springer, Dec. 2003.
[86] C. Weidenbach. Towards an automatic analysis of security protocols in rst-order logic. In 16th Inter-
national Conference on Automated Deduction (CADE-16), volume 1632 of Lecture Notes in Articial
Intelligence, pages 314328. Springer, July 1999.
[87] T. Y. C. Woo and S. S. Lam. Authentication for distributed systems. Computer, 25(1):3952, Jan. 1992.
[88] T. Y. C. Woo and S. S. Lam. Authentication for distributed systems. In Internet Besieged: Countering
Cyberspace Scofaws, pages 319355. ACM Press and Addison-Wesley, Oct. 1997.
Applied pi calculus
Mark D. RYAN and Ben SMYTH
School of Computer Science,
University of Birmingham,
United Kingdom
e-mail: M.D.Ryan@cs.bham.ac.uk, research@bensmyth.com
Abstract. The applied pi calculus is a language for modelling security protocols.
It is an extension of the pi calculus, a language for studying concurrency and pro-
cess interaction. This chapter presents the applied pi calculus in a tutorial style. It
describes reachability, correspondence, and observational equivalence properties,
with examples showing how to model secrecy, authentication, and privacy aspects
of protocols.
Keywords: Cryptographic protocols, protocol verication, formal methods, reach-
ability, correspondence properties, observational equivalence, tutorial.
1. Introduction
The applied pi calculus [8] is a language for describing and analysing security protocols.
It provides an intuitive process syntax for detailing the actions of the participants in a
protocol, emphasising their communication. The syntax is coupled with a formal seman-
tics to allow reasoning about protocols. The language is based on the pi calculus with the
addition of a rich term algebra to enable modelling of the cryptographic operations used
by security protocols. A wide variety of cryptographic primitives can be abstractly mod-
elled by means of an equational theory. The calculus allows one to express several types
of security goal, and to analyse whether the protocol meets its goal or not. This analysis
can sometimes be performed automatically, using the ProVerif software tool [23,21,25].
The applied pi calculus has been used to model security protocols in a variety of
areas. The following examples are not exhaustive:
Certied email [4];
Privacy properties [38,34,12,40], and election-veriability properties [39] in elec-
tronic voting;
Authorisation protocols [27,43], and attestation protocols [46,13] in trusted com-
puting;
Interoperability of web services, where a compiler [17] converts descriptions in
the F# language [47] into applied pi, suitable for analysis by ProVerif;
Integrity of le systems on untrusted storage [24];
Authentication protocols and key agreement [5].
IOS Press, 2011
doi:10.3233/978-1-60750-714-7-112
112
1.1. Handshake protocol
We recall the nave Handshake protocol (Chapter Introduction) between a client and
server . It is assumed that each of them has a public/private key pair, and that the client
knows the servers public key pk(
). The aim of the protocol is to establish a secret

symmetric key , enabling the client to communicate a secret to the server. The protocol
proceeds as follows. On request from a client , server generates a fresh session key
, signs it with her private key
and encrypts it using her clients public key pk(
).
When receives this message he decrypts it using his private key
, veries the digital

signature made by using her public key pk(
), and extracts the session key . uses

this key to symmetrically encrypt the secret and sends the encrypted message to . The
rationale behind the protocol is that receives the signature asymmetrically encrypted
with his public key and hence he should be the only one able to decrypt its content.
Moreover, the digital signature should ensure that is the originator of the message. The
protocol narration is illustrated as follows:
Client () Server ()
{[]
}
a
pk(
)
{}
s

Note that protocol narrations (as above) are useful, but lack detail. For example, they do
not specify the construction of nonces, nor do they describe any checks which should
be made by the participants during the execution of the protocol. Such checks include
verifying digital signatures and ensuring that encrypted messages are correctly formed.
Failure of these checks typically results in the participant aborting the protocol. These
details will be explicitly stated when protocols are modelled in the applied pi calculus.
(For further discussion on protocol specication see [11,1].)
Informally, the three properties we would like this protocol to provide are:
1. Secrecy: The value is known only to and .
2. Authentication of : if reaches the end of the protocol with session key , then
proposed for use by .
3. Authentication of : if reaches the end of the protocol and believes session key
has been shared with , then was indeed her interlocutor and has .
The different forms of the two authentication properties arise because of the different
assumptions we made about and . Recall that knows s public key, and is only
willing to run the protocol with . But is willing to run the protocol with anyone.
Careful analysis reveals that the protocol does not satisfy all three of the intended
properties. It is vulnerable to a man-in-the-middle attack. If a dishonest participant
starts a session with , then is able to impersonate in a subsequent session he starts
with . At the end of the protocol believes that he shares the secret with , while
he actually shares with . (This attack is further detailed in the extended version of
this chapter [44].) The protocol can easily be corrected by adding the identities of the
intended participants to the data that is signed in the rst message. With this correction,
is not able to re-use the signed key from in his session with .
M.D. Ryan and B. Smyth / Applied pi Calculus 113
2. Applied pi calculus
The applied pi calculus [8] is a language for describing concurrent processes and their
interactions. It is based on the pi calculus but is intended to be more convenient to use,
and it is specically targeted at modelling security protocols. In this respect the applied
pi calculus also has similarities with the spi calculus [10]. The key difference concerns
the way in which cryptographic primitives are handled. The spi calculus has a xed set
of primitives built-in (namely, symmetric and public key encryption), while the applied
pi calculus allows a wide variety of more complex primitives (including, for example,
non-deterministic encryption, digital signatures, and proofs of knowledge) to be dened
by means of an equational theory.
2.1. Syntax and informal semantics
The calculus assumes an innite set of names, an innite set of variables and a signa-
ture consisting of a nite set of function symbols each with an associated arity. Func-
tion symbols capture primitives used by cryptographic protocols (for example: one-way
hash functions, encryption, digital signatures, and data structures such as pairing). A
function symbol with arity 0 is a constant. Terms are built by applying function symbols
to names, variables and other terms:
, , , , , ::= terms
, , , . . . , , . . . , , , . . . , name
, , variable
(
1
, . . . ,
) function application
where ranges over the functions of and is the arity of . We use metavariables
, , to range over both names and variables. Tuples
1
, . . . ,
and
1
, . . . ,
are
occasionally abbreviated and

. We write {
} for the syntactic substitution (usu-

ally just called substitution) that replaces the variable with the term . Similarly, we
write {
} for the substitution that replaces the name with the name . Arbitrarily
large substitutions can be written as {
1
/
1
, . . . ,
} or {

/

}. The letters and
range over substitutions. We write for the result of applying to the free variables
(or free names) of . A term is ground when it does not contain variables.
We assume a type system (also known as a sort system) for terms generated by a
set of base types , which includes the universal type Data. In addition, if is a type,
then Channel is a type too. Formally, the set of types generated by the base types
is the smallest set satisfying: 1) ; and 2) if then Channel . Names
and variables can have any type. By convention we use , , for channel names, , as
names of base type and , for names of any type. A channel of type Channel may
communicate messages of type . For simplicity, function symbols can only be applied
to, and return, terms of base type. We always assume that terms are well-typed and that
syntactic substitutions preserve types.
The grammar for processes is shown below:
, , ::= processes (or plain processes)
0 null process
parallel composition
! replication
. name restriction
if = then else conditional
(). message input
. message output
The null process 0 does nothing; is the parallel composition of processes
and , used to represent participants of a protocol running in parallel; and replication
! is the innite composition . . ., which is often used to capture an un-
bounded number of sessions. Name restriction . binds inside , the introduc-
tion of restricted names (or private names) is useful to capture both fresh random num-
bers (modelling nonces and keys, for example) and private channels. The conditional
if = then else is standard, but we stress = represents equality (modulo
an equational theory) rather than strict syntactic identity. For convenience we abbreviate
conditionals as if = then , when is the null process. Finally, communication
is captured by message input and message output. The process (). awaits a message
from channel and then behaves as with the received message bound to the variable
; that is, every free occurrence of in refers to the message received. The process
. is ready to send on channel and then run . In both of these cases we may
omit when it is 0. We sometimes write let = in in place of {
}, that is,
with all free occurrences of replaced by . In such a substitution, we insist that no
name occurring in becomes bound by a restriction occurring in ; for example,
let = in . is not allowed, but let = in
is permitted.
Bracketing must be used to avoid ambiguities in the way processes are written down.
For example, the process ! might be interpreted as (!) , or as !( ).
These processes are different. To avoid too much bracketing, we adopt conventions about
the precedence of process operators. Unary operators !, , (), and bind more
closely than binary operators; and the binary if-then-else operator binds more closely
than the binary operator . It follows that the expression ().if = then !
means (().if = then ) (!) . We remark that different conventions are
used elsewhere, for example [25].
The expression is also ambiguous, since it could mean either ( )
or ( ). However, we will later see that these processes are semantically identical,
so we tolerate the ambiguity in the syntax. Another possible ambiguity arises because of
the convention of omitting else 0 in the if-then-else construct: it is not clear which if
the else applies to in the expression:
if = then if = then else .
In absence of brackets indicating the contrary, we adopt the convention that the else
branch belongs to the closest if and hence the statement should be interpreted as if =
then (if = then else ).
Processes are extended with active substitutions to capture the knowledge exposed
to the adversarial environment:
, , ::= extended processes
plain process
parallel composition
. name restriction
. variable restriction
{
} active substitution
The active substitution {
} represents a process that has previously output . The

value is now available to the environment by reference to the handle . The ac-
tive substitution {
} can replace the variable for the term in every process it

comes into contact with. This behaviour can be controlled by restriction, and the process
.({
} ) corresponds exactly to let = in . This allows access to terms

which the environment cannot construct; such a scenario may arise, for example, when
the environment does not know all of the names occurring in a term. Arbitrarily large
active substitutions can be obtained by parallel composition and we occasionally abbre-
viate {
1
/
1
} . . . {
} as {
1
/
1
, . . . ,
} or {

/

}. We also use and
to range over active substitutions. Extended processes must have at most one active sub-
stitution for each variable and there is exactly one when the variable is under restriction.
In particular, this means that can only occur if there is an active substitution {
}
in its scope. Finally, we write for the (possibly empty) series of pairwise-distinct
binders
1
.
2
. . . . .
.
Active substitutions are different from syntactic substitions. Firstly, active substi-
tutions are processes, whereas syntactic substitions are not. In addition, their semantic
behaviours differ. Syntactic substitutions can be applied directly to processes; for exam-
ple, the application of a syntactic substitution to the free variables of an extended pro-
cess is written . By contrast, active substitutions cannot be applied directly to pro-
cesses (or terms). Active and syntactic substitutions are always assumed to be cycle-free:
given substitution , the repeated application of to itself may only result in a bounded
number of replacements. For example, the substitution {
()
/
} is cycle free; but

{
()
/
} is not, since {
()
/
} will result in the variable referring to a term

of innite length.
The type system for terms is extended to processes. It enforces that , are of
the same type in the conditional expression if = then else ; message input
() is dened only where is of type Channel and is of type ; and similarly
message output requires of type Channel and of type . In addition, we
assume that in active substitutions {
}, the term and the variable are of the same

base type. This assumption was not explicitly stated in [8] but its necessity has been
conrmed [9] and is essential for the validity of Theorem 1 [16]. Finally, we assume
extended processes are well-typed.
The scope of names and variables are delimited by binders () and . The set
of bound names bn() contains every name which is under restriction inside .
The set of bound variables bv() consists of all those variables occurring in that are
bound by restriction or input (). We also dene the set of free names and the set
of free variables. The set of free names in , denoted fn(), consists of those names
occurring in not in the scope of the binder . The set of free variables fv() contains
the variables occurring in which are not in the scope of a restriction or input
(). Note that a name or variable can occur both free and bound in . Thus, the sets
fv() bv() and fn() bn() may be non-empty. We occasionally write fn() and
fv(), for the set of names, respectively variables, which appear in term. The concept
of bound and free values is similar to local and global scope in programming languages.
An extended process is closed when every variable is either bound or dened by an
active substitution, (that is, the process contains {
} for some term ). Example 1

demonstrates name and variable scope. Bound names and bound variables are subject to
-conversion (also called -renaming); that is, they may be uniformly renamed without
changing the meaning of the process, as demonstrated in Example 2.
A frame, denoted or , is an extended process built from 0 and active substitu-
tions {
}; which are composed by parallel composition and restriction. The domain

dom() of a frame is the set of variables that exports; that is, the set of variables
for which contains an active substitution {
} such that is not under restriction.

Every extended process can be mapped to a frame () by replacing every plain pro-
cess in with 0. The frame () represents the static knowledge output by a process to
its environment. The domain dom() of is the domain of ().
Example 1 (Name and variable scope) Consider the closed process .((().
aenc(pair(, ), )) ( .{
}) {
(,
)
/
}) dened with respect to the signature

= {aenc, h, pair} where aenc, h, pair are all binary functions. The occurrences of the
variable are bound by the variable restriction and those of are bound by the
input (). The name is bound by the name restriction . The remaining name
and
variable occur free. To summarise, we have fv() = {}, bv() = {, }, fn() =
{
} and bn() = {}. Now let
}, and observe that the occurrences of

and in the active substitution {
} are free. They have no relation to the bound values

, which occur in . To avoid confusion it is good practice to use distinct identiers
for free and bound, names and variables.
Example 2 (-conversion) -conversion means renaming a bound name or variable
without changing the semantics. This is also done in logic (the statements .() and
.() are equivalent), and in programming (the programs for i in I do P(i)
and for j in I do P(j) are equivalent). In the applied pi calculus, the process
.().senc(, ) is equivalent to .().senc(, ); we have -renamed all
occurrences of the name to the name and similarly the variable has been renamed
. But, .(). .senc(, ) is not -equivalent to .(). .senc(, ).
2.1.1. Modelling the Handshake protocol
The Handshake protocol (Section 1.1) is dened with respect to the signature
=
{true, fst, snd, hash, pk, getmsg, pair, sdec, senc, adec, aenc, sign, checksign, mac} wh-
ere true is a constant; fst, snd, hash, pk, getmsg are unary functions; and pair, sdec,
senc, adec, aenc, sign, checksign, mac are binary functions. The behaviour of these func-
tions is captured by the smallest equational theory
satisfying the following equations

over variables , :
fst(pair(, )) =
snd(pair(, )) =
sdec(, senc(, )) =
adec(, aenc(pk(), )) =
getmsg(sign(, )) =
checksign(pk(), sign(, )) = true
This theory allows us to model: pairing, both symmetric and asymmetric cryp-
tography, digital signature schemes with message recovery, hash functions and mes-
sage authentication codes. For example, in order to express that the application of
the symmetric decryption function sdec to the term modelling a symmetric encryp-
tion senc(, ) should return the plaintext if the correct key is supplied, we
use the equation sdec(, senc(, )) = . The absence of any equational theory as-
sociated with the hash function ensures preimage resistance, second-preimage resis-
tance and collision resistance properties of cryptographic hash functions (in fact, far
stronger properties are ensured); and similar properties for the function mac. Ob-
serve that a tuple
1
, . . . ,
of an arbitrary length can be constructed by pairing

pair(
1
, pair(
2
, pair(. . . , pair(
1
,
) . . .))) and an element can be extracted us-

ing the equations dened for fst, snd.
The Handshake protocol can now be captured in our calculus as the process ,
dened as follows.

. .
let
= pk(
) in let
= pk(
) in
(
( ). .aenc( , sign(
, )).
().if fst(sdec(, )) = then
().let
= adec(
, ) in let = getmsg(
) in
if checksign(
) = true then
senc( , pair(, ))
The process begins by constructing the private keys
for principals , respec-

tively. The public key parts pk(
), pk(
) are then output on the public communi-

cation channel , ensuring they are available to the adversary. (Observe that this is done
using handles
and
for convenience.) The protocol then launches multiple copies

of processes
representing multiple sessions of the roles of and . Note that syn-

tactic scope does not represent the knowledge of a protocols participants. For example,
the servers private key
is assumed not to be known by the client (hence it does

not occur in
), even though
is in the scope of
.
We assume that is willing to run the protocol with any other principal; the choice
of her interlocutor will be made by the environment. This is captured by modelling the
rst input ( ) to
as the interlocutors public key. on the other hand only wishes

to share his secret with , and is assumed to know s public key; accordingly, s
public key is hard-coded into the process
. We additionally assume that each principal

is willing to engage in an unbounded number of sessions and hence
are under
replication.
Figure 1. Properties of equality modulo the equational theory
Given an equational theory the following properties are satised for all terms , , ,
functions of arity , substitutions and names , :
1. = =

2. Equivalence relation:
Reexivity: =

Symmetry: =

Transitivity: =

3. Application of function symbols:
1
=

(
1
, . . . ,
) =
(
1
, . . . ,
)
4. Substitution of terms for variables: =

5. Bijective renaming of names: =
} =
}, where
(fn() fn()).
On request from her interlocutor, server starts the protocol by selecting key and
outputting aenc( , sign(
, )); that is, her signature on the key encrypted with

her interlocutors public key . Meanwhile awaits the input of his interlocutors
signature on the key encrypted using his public key. decrypts the message and veri-
es the signature. Next, if believes he is indeed talking to , he outputs his secret en-
crypted with the symmetric key . Note that he inserts a tag (modelled as a free name), so
that the decryptor can verify that the decryption has worked correctly. Principal inputs
and conrms the presence of the tag. Finally, principal executes the process . The
description of is independent of the protocol, but one would expect the recovery of the
interlocutors secret; that is, is dened by the process let = snd(sdec(, )) in
for some
.
The purpose of the protocol is to establish a session key to transport the secret rep-
resented by . We abstract away from the details of what is, and how many such secrets
there are, by modelling it simply as a restricted name.
2.2. Operational semantics
The signature is equipped with an equational theory , that is, a set of equations of the
form = , where terms , are dened over the signature (sometimes written
,
). This allows us to capture relationships between primitives dened in .

We dene equality modulo the equational theory, written =
, as the smallest equivalence

relation on terms, that contains and is closed under application of function symbols,
substitution of terms for variables and bijective renaming of names. The properties of
=
are summarised in Figure 1. We write =
when the equation = is in

the theory and keep the signature implicit. When is clear from the context we may
abbreviate =
as = . The negation of =
is denoted =
(and
similarly abbreviated = ). For further discussion on equational theories see [8, 3]
and [7].
Example 3 (Reasoning with equational theories) Consider the signature
and the
equational theory
. Show that each of the following equalities hold:

1. sdec(, senc(, )) =

2. pair(, ) =
pair(sdec(, senc(, fst(pair(, )))), )

3. fst(sdec(snd(pair(, )), senc(fst(pair(, )), pair(, )))) =

Hint. Figure 1 may be helpful.
Contexts may be used to represent the adversarial environment in which a process
is run; that environment provides the data that the process inputs, and consumes the
data that it outputs. We dene context [ ] to be an extended process with a hole. We
obtain [] as the result of lling [ ]s hole with the extended process . An evaluation
context is a context whose hole is not in the scope of a replication, a conditional, an input,
or an output. A context [ ] closes when [] is closed.
2.2.1. Structural equivalence
Informally, two processes are structurally equivalent if they model the same thing, but
the grammar permits different encodings. For example, to describe a pair of processes
, running in parallel, the grammar forces us to put one on the left and one on the
right, that is, we have to write either , or . These two processes are said to be
structurally equivalent. Formally, structural equivalence () is the smallest equivalence
relation on extended processes that is closed by -conversion of both bound names and
bound variables, and closed under application of evaluation contexts such that:
PAR-0 0
PAR-A ( ) ( )
PAR-C
REPL ! !
NEW-0 .0 0
NEW-C . . . .
NEW-PAR . .( )
where fv() fn()
ALIAS .{
} 0
SUBST {
} {
} {
}
REWRITE {
} {
}
where =

The rules for parallel composition, replication and restriction are self-explanatory. ALIAS
enables the introduction of an arbitrary active substitution with restricted scope. SUBST
describes the application of an active substitution to a process that it comes into contact
with. The rule helps demonstrate the distinction between syntactic and active substitu-
tions with respect to processes. In the process {
} , the expression {
} is a
subprocess, whose meaning is that is a handle for the environment to refer to . In
the process {
}, the expression {
} is a substitution meaning that free occur-

rences of in should be replaced by (in such a way that no names or variables
in become bound). The nal rule, REWRITE, allows terms that are equal modulo the
equational theory to be swapped as desired.
Structural equivalence allows every closed extended process to be rewritten as a
substitution and a closed plain process with some restricted names: .({

/

}
) where fv(

) = fv() = and fn(

). It follows immediately that every closed
frame can be rewritten as a substitution with some restricted names: .{

/

}
where fv(

) = and fn(

). We note that the domain of is .
2.2.2. Internal reduction.
A process can be executed without contact with its environment, either because if-
statements are evaluated and the then- or else-branch is taken, or because internal sub-
processes communicate with each other. The execution of a process with respect to con-
trol ow and communication is captured by internal reduction. Formally, internal reduc-
tion () is the smallest relation on extended processes closed under structural equiva-
lence and application of evaluation contexts such that:
COMM . ().
THEN if = then else
ELSE if = then else
for ground terms , where =

Communication (COMM) is dened on variables, making it look rather restricted. How-
ever, this entails no loss of generality because ALIAS and SUBST can be used to al-
low communication of an arbitrary term instead of a variable . To see how this
works, consider the process . ().. We can suppose that is not in fv()
(if it is, pick any
fv() and -rename the bound variable to
in ().).
Then . (). .(. (). {
}). Since . ().

by COMM, we derive {
} by application of an evaluation con-

text. To see this step in more detail, consider [ ] = .( {
}) and observe
.(. (). {
}) = [. ().] [ ] which is struc-

turally equivalent to {
}. Since is closed under structural equivalence, we

have . (). {
}.
Conditionals (THEN and ELSE) are dependent on the equational theory. Applications
of THEN may require the use of the structural equivalence rule REWRITE to derive =
from = where =
. ELSE may require that active substitutions in the

context be applied using ALIAS and SUBST to ensure , are ground.
2.2.3. Labelled reductions
The semantics in Section 2.2.2 allow us to reason about protocols with an adversary rep-
resented by a context. In order to prove that security properties hold for all adversaries,
quantication over all contexts is typically required, which can be difcult in practice.
The labelled operational semantics we now present aim to eliminate universal quanti-
cation of the context.
The labelled semantics denes a ternary relation written,

, where is a label
of the form (), , or . such that is either a channel name or a variable
of base type. The transition
()
means that the process performs an input of
the term from the environment on the channel , and the resulting process is . The
situation for output is a bit more complicated, since there are several cases. If the item
is a free variable or a free channel name , then the label , respectively , is
used. If the item being output is a restricted channel name , then the label . is
used. Finally, if the item is a term , then the label . is used, after replacing
the occurrence of the term by and wrapping the process in .({
} ). The
operational semantics of 2.2.1 are extended to include the following rules:
IN ().
()
{
}
OUT-ATOM .

OPEN-ATOM

=
.
.

SCOPE

does not occur in

.

.
PAR

bv() fv() = bn() fn() =

STRUCT

The rule OPEN-ATOM is used in two ways: 1) to output a restricted channel; and
2) to output a term. The rst instance is straight forward and one may prove that
..
.
, provided = . The latter is a little more complicated since it re-
quires the use of structural equivalence rules. Observe that .
.
{
},
where fv(), by rst writing . as .(. {
}). The full derivation

is given below:
.
OUT-ATOM
.

PAR
. {
}

{
}
OPEN-ATOM
.(. {
})
.
{
} {
}
STRUCT
.
.
{
}
Note that the fact fv() is needed for the rst of the two structural equivalences in
the occurrence of STRUCT.
Example 4 (Labelled semantics) Consider the process .. Show the re-
ductions
.
.
{
} {
}. Also show the reductions

.
}. (Hint. The last one involves an application of SUBST.)

2.2.4. Names and the environment
The reduction ..
.
.( {
}) represents an important idiom of

the applied pi calculus. It is the way that an arbitrary term is output to the environment.
This illustrates the way that the environments use of names is controlled.
If is a restricted name in a process then the environment cannot use that to
construct a term. Moreover, if the environment uses the name , then it is not the same
as the one in the process. Consider for example the process
.(().if = then )
This process can never output , because no term input as can be equal to the
new created by the process. More precisely, there is no sequence of reductions

{

/
}
for some process and variable .
Now suppose the process
creates a new and outputs some term containing :
.(hash().
)
We have
.
.(
{
hash()
/
}). This process exposes hash() to the envi-

ronment, by reference to the handle . Although the environment still does not have , it
can use hash() in an expression, simply by using in its place. For example, it can use
to construct input in
.
Now consider the process
which creates a new , outputs the encryption of by

a (free) key , and then accepts an input and tests if the input is .
.(senc(, ).().if = then )

This test can succeed; the process can output , as shown by the following execu-
tion:
.
.(().if = then {
senc(, )
/
})
(sdec(,))
.(if sdec(, ) = then {
senc(, )
/
})
.(if sdec(, senc(, )) = then {
senc(, )
/
})
.(if = then {
senc(, )
/
})
.( {
senc(, )
/
})
.
.({
senc(, )
/
} {

/
})
.({
senc(, )
/
}) {

/
}
The rst of the equivalences holds by the rule SUBST; the second one is by REWRITE,
using the equation sdec(, senc(, )) = . Intuitively, the environment has taken the
encrypted output and decrypted it (since the key is a name known to the environment).
It can then input the result to the process, which sees that it is indeed equal to .
It is instructive to return to the process .(().if = then )
above, and consider what happens if the environment gives it the name as input. As
stated earlier, intuitively this from the environment is considered different from the
that the process constructs. Technically, this is handled as follows. If we try to perform a
transition
()
, we nd that we cannot quite use the expected combination of the
rules IN and SCOPE, because IN asks us to perform the substitution
.(if = then {
})
which would insert the from the substitution into the scope of the . As previ-
ously mentioned, such substitutions are not allowed. We can resolve the situation by
-renaming the bound rst:

.(().if =
then ).
Recall that if = then is an abbreviation of if = then else 0 and hence
we have the reductions:

.(().if =
then )
()
if =
then 0.
3. Secrecy and correspondence properties
This section presents formal denitions of secrecy and correspondence in the presence
of an adversary who has full control of the network. The attacker can therefore eaves-
drop, replay, inject and block messages. Formally the attacker is captured as an arbitrary
process and is sometimes called the Dolev-Yao adversary [36].
3.1. Secrecy
Intuitively, a protocol preserves the secrecy of some term if an adversary cannot obtain
by constructing it from the outputs of the protocol [3]. We formalise the adversary as
a process running in parallel with the protocol, that after constructing outputs it on a
public channel. The adversary process does not have any of the protocols secrets.
A term may refer to names inside a process; to analyse secrecy of the term, it is
important that these names appear unambiguously in the process. Otherwise it is not
clear which name the term refers to. For example, if a name in the term is both bound
and free in the process, then it is not clear whether the term refers to the free instance, or
the bound instance. We formalise that by requiring the process to be name distinct for
the names mentioned in the term.
Denition 1 (name-distinct for ) A closed plain process is name-distinct for a set
of names , if fn()bn() = and for each name bn() there is exactly
one name restriction occurring in , and the restriction is not under replication !.
Denition 2 (Can output) A plain process can output the term if there exists an
evaluation context [ ], a channel name bn() and process such that the reduc-
tion
[.] holds with no alpha-renaming of the names in fn().

In Denition 2, the process [.] is capable of outputting the term on the
free channel in one further step. Note that the denition forbids renaming names in
during the reduction
[.], because we must not change which names in

are referred to by . Thus, the process . cannot output ; if we allowed renaming,
we could write the process as . and it would be able to output .
Denition 3 (Reachability-based secrecy) Let be a term, and be a closed plain
process that is name-distinct for fn(). Then preserves the reachability-based secrecy
of if there is no plain process such that (fn() bn()) bn() = and can
output .
In the denition above, is the adversary (or intruder) process. Typically, it is built
in order to receive the outputs from , and then possibly to construct from them the
secret term , and output it. If there is no such intruder, then keeps secret. This
denition is based on the one in [3], but extends it to cope with bound names.
Example 5 (Reasoning with secrecy) Consider the process corresponding to the
Handshake protocol (Section 2.1.1) and the equational theory
. We show that does

not preserve the secrecy of , by presenting an adversarial process
( ).pk(
).().
aenc( , adec(
, )).().
snd(sdec(getmsg(adec(
, )), ))
and demonstrating that can evolve to a process that can output on a public
channel. To aid readability, we apply all the substitutions denoted by let occurring in
, and we use the context
[ ]
. . ( !
)
and write [pk(
) pk(
]. Since
, fn()fv(),
we have
[ pk(
) pk(
)
( ). .aenc( , sign(
, )).
().if checksign(pk(
), adec(
, )) = true then
senc(getmsg(adec(
, )), pair(, ))
]
Intuitively, the following sequence takes place:
1. s public key pk(
) is published and hence made available to the adversary,

who inputs it as
.
2. The adversary provides her public key pk(
) as s interlocutor.
3. outputs her signature on , encrypted for the adversary, and the adversary
inputs it as . (Observe that closure under structural equivalence is used to move
the name restriction outside of the context; more precisely, the rules NEW-C,
NEW-PAR are applied.)
4. The adversary gives to the value signed by , this time encrypted for .
5. The process is further rewritten using structural equivalence (essentially several
occurrences of the rule REWRITE with respect to
). (Note that this rewriting

could have been included in the previous step because internal reduction is closed
under structural equivalence, but we explicitly present it for clarity.)
6. The conditional is evaluated and sends the value senc(, pair(, )) to the
adversary.
7. Observe that snd(sdec(, senc(, pair(, )))) and hence the adver-
sary can obtain and publish the value on a public channel.
The execution path which results in the adversary being able to output on a public
channel is described in a detailed gure in the extended version of this chapter [44].
3.2. Correspondence properties
Correspondence properties are used to capture relationships between events that can be
expressed in the form if an event has been executed then event
has been previ-

ously executed. Moreover, these events may contain arguments, which allow relation-
ships between the arguments of events to be expressed. To reason with correspondence
properties we annotate processes with events, marking important stages reached by the
protocol which do not otherwise affect behaviour. Events are analogous to breakpoints
used in software development. In this chapter, we only consider basic correspondence
properties, which are sufcient to model authentication. More elaborate formalisms can
be found in [5,21]. Events are message outputs where is an event channel (a
name in a particular set, disjoint from the set of ordinary channel names). In labelled
transitions, output labels for events use event variables . Those event variables are not
allowed to appear in input labels (), so the adversary cannot use them. (This condi-
tion is important, since events are added just for checking correspondence properties; in
particular an event does not reveal M to the adversary.) Hence, the execution of
the process after inserting events is the execution of without events, plus the
recording of events using labels . and active substitutions {
}.
Denition 4 (Correspondence property) A correspondence property is a formula of
the form: .
The property asserts that if the event has been executed in a trace with parameters
, then the event must have been previously executed with parameters .
Authentication can be captured as a correspondence property. Recall that in addition
to the secrecy property mentioned for the Handshake protocol in Section 1, there were
also authentication properties. The protocol is intended to ensure that if thinks she
executes the protocol with , then she really does so, and vice versa. When we say she
thinks that she executes it with , we mean that the data she receives indicates that
fact. Accordingly we annotate the Handshake protocol with events. To capture equality
tests within events we include the binary function eq in the signature
and extend the

equational theory
with the equation eq(, ) = true.

Example 6 (Annotated Handshake protocol) The annotated Handshake protocol is
presented below

. .
let
= pk(
) in let
= pk(
) in
(
( ). .pair( , )
aenc( , sign(
, )).
pair(, eq( ,
)).
().let
= adec(
, ) in let = getmsg(
) in

if checksign(
) = true then
senc( , pair(, ))
pair(
, )
where the four events are interpreted as follows:
pair( , ) means that considers she has started the protocol with
an interlocutor whose public key is , and she has proposed as the session
key.
means that considers he has started the protocol with the ses-
sion key .
pair(, ) means that believes she has completed the protocol
with session key and if =
true, then the protocol was completed with .

pair(
, ) means that considers he has successfully com-

pleted the protocol with using session key , where
is his public key.

Correspondence properties can now be dened to allow the analysis of authentication.
Recall that the client is only willing to share her secret with the server . We formalise
the authentication of using the correspondence property
pair(, ) pair(, ).
In comparison, is willing to run the protocol with any other principal. The corre-
spondence property says that if she believes was her interlocutor, then must have
completed the protocol with the suggested key. This is formalised as:
pair(, true)
The subtle differences between the two correspondence properties is due to the differing
authentication properties expected by participants and .
Formally we dene the validity of a correspondence property in Denition 5. Intu-
itively, it ensures that if the event is executed, then the event must have been pre-
viously executed. Moreover, the parametrisation of the events must satisfy any relation-
ships dened by , ; that is, the variables fv() fv() must be parametrised in the
same way.
Denition 5 (Validity of correspondence property) Let be an equational theory,
and
0
an extended process. We say that
0
satises the correspondence property
if for all execution paths
,
and all index , substitution and variable such that
= . and
(
) =
, there exists and
such that
) =

and < .
Example 7 (Reasoning with correspondence) Consider the annotated Handshake pro-
tocol (Example 6). The rst correspondence property, namely pair(, )
pair(, ) is not valid. This can be observed by constructing an execution
path in which the events and both occur, but with different argu-
ments. To aid readability, we apply some of the substitutions denoted by let occurring in
, and we reuse the context [ ]
. . ( !
) from Example 5. The

execution path is shown in Figures 2 & 3. Intuitively, the following sequence of actions
takes place (the item numbers correspond to the transitions in the gures):
1. s public key pk(
) is output, using the handle . This public key is now

available to the environment.
2. The environment provides the public key pk(
) as s interlocutor.
3. The event pair( , ) is executed with the environments public key
pk(
) assigned to parameter .
4. outputs as the value signed by and encrypted for the environment.
5. The environment gives to the value signed by , this time encrypted for .
6. The process is rewritten using structural equivalence (essentially several occur-
rences of the rules SUBST and REWRITE).
7. The event is executed with as parameter .
8. The conditional is trivially evaluated and outputs the value senc(, pair(, ))
as .
9. Finally, the event pair(
, ) is executed with respect to the

value assigned to parameter .
Thus, the conditions of Denition 5 are violated; we have
3
, and al-
though we do have a previous
1
, it does not have the same arguments as can
be observed from the frame.
3.2.1. Injective correspondence properties
The denition of correspondence we have just discussed is insufcient to capture injec-
tive relationships between events; making it unsuitable for certain authentication prop-
erties. For example, consider a nancial transaction in which a server requests payment
from a client; the server should only complete a transaction, when that transaction was
started by the client. (If this were not the case, the client could be charged for several
transactions, even if the client only started one.) The situation is similar for access control
and other scenarios. Further discussion can be found in [41].
Figure 2. Execution of Handshake protocol, part I (labelled semantics)
1.
.
[pk(
) {
pk(
)
/

}
( ). .pair( , ).
aenc( , sign(
, )).
pair(, eq( , pk(
))).
().
let
= adec(
, ) in
let = getmsg(
) in
.
if checksign(pk(
),
) = true then
senc( , pair(, ))
pair(pk(
), )]
2.
(pk(
))
3.

1
.
1
4.
.
.[pk(
) {
pk(
)
/

}
{
pair(pk(
), )
/
1
}
{
aenc(pk(
), sign(
, ))
/
}
pair(, eq(pk(
), pk(
))).
().
let
= adec(
, ) in
let = getmsg(
) in
.
if checksign(pk(
),
) = true then
senc( , pair(, ))
pair(pk(
), )]
Example 8 Consider the process
..
which satises the correspondence , but permits two occur-
rences of the event to be matched by a single event .
Injective correspondence properties are denoted by the presence of the keyword inj.
Denition 6 (Injective correspondence property) An injective correspondence prop-
erty is a formula of the form: inj .
Informally, it asserts that if a process executes event , then there is a distinct earlier
occurrence of the event and any relationship between the event parameters is satised.
It follows immediately that the number of occurrences of the label . is greater
than, or equal to, the number of occurrences of
for some event variables ,
.
Figure 3. Execution of Handshake protocol, part II (labelled semantics)
5.
(aenc( ,adec(
,)))
.[pk(
) {
pk(
)
/

}
{
pair(pk(
), )
/
1
}
{
aenc(pk(
), sign(
, ))
/
}
pair(, eq(pk(
), pk(
))).
let
= adec(
, aenc( , adec(
, ))) in
let = getmsg(
) in
.
if checksign(pk(
),
) = true then
senc( , pair(, ))
pair(pk(
), )]
6. .[pk(
) {
pk(
)
/

}
{
pair(pk(
), )
/
1
}
{
aenc(pk(
), sign(
, ))
/
}
pair(, eq(pk(
), pk(
))).
.
if true = true then
senc(, pair(, ))
pair(pk(
), )]
7.

2
.
2
8.
.
9.

3
.
3
.[pk(
) {
pk(
)
/

}
{
pair(pk(
), )
/
1
}
{
aenc(pk(
), sign(
, ))
/
}
pair(, eq(pk(
), pk(
))).
{
2
}
{
senc(, pair(, ))
/
}
{
pair(pk(
), )
/
3
}]
Denition 7 (Validity of injective correspondence property) Let be an equational
theory, and
0
an extended process. We say that
0
satises the injective correspondence
property inj if for all execution paths
,
there exists a partial injective function : {1, . . . , } {1, . . . , } such that for all
{1, . . . , }, substitution and variable such that
= . and (
) =
,
then the following conditions are satised: (1) () is dened; (2)
()
=
for
some
such that
(
()
) =
; and, (3) () < .

Returning to our Handshake protocol (Example 9), observe that authentication of
is injective; that is, if reaches the end of the protocol with the belief that she has session
key with interlocutor , then she has indeed done so; and moreover, has done so in
this session (that is, there is an injective relationship).
Example 9 (Reasoning with correspondence, revisited) Consider the annotated Hand-
shake protocol and observe the injective correspondence property pair(,
true) inj is valid. To show this conclusively, one has to consider all
the possible execution paths, and show that for each of them, whenever there is a label
. associated with the substitution {
pair(, true)
/
}, then there is an
earlier label
and substitution {
}; such that no two occurrences

of the event are mapped to the same event . ProVerif can be used
to prove this result.
Fixing the Handshake protocol. As mentioned in Section 1, the man-in-the-middle at-
tack can be avoided by putting the participants public keys along with in the signature
formed by . The resulting process and further discussion can be found in the extended
version of this chapter [44].
4. Equivalence properties
The notion of indistinguishability is a powerful concept which allows us to reason about
complex properties that cannot be expressed as secrecy or correspondence properties.
Intuitively, two processes are said to be equivalent if an observer has no way to tell them
apart. The processes may be handling different data, and internally performing quite
different computations, but they look the same to an external observer. This notion allows
us to dene strong notions of secrecy and privacy.
A natural starting point for dening observational equivalence says that processes
and are equivalent if they can output on the same channels, no matter what the context
they are placed inside. Formally we write when can evolve to a process that can
send a message on channel , that is, when
[.] for some term , process

and evaluation context [ ] that does not bind . This then allows us to characterise
equivalence as follows: for all contexts [ ], we have [] if and only if [] .
One might think that this condition is too weak it should say that [] and [] output
the same term on the channel but that is not necessary, since if two processes output
different terms then a context that inspects the output could be constructed to distinguish
them.
4.1. Observational equivalence
In practice, the denition motivated above is hard to compute, and instead a stronger
denition is often used. The stronger denition, called observational equivalence, has a
recursive character. Roughly speaking, processes and are said to be observationally
equivalent if they can output on the same channel for all contexts they are placed inside
(as before); and also, for all contexts and every step made by inside the context, there
exists a step that can make (inside the context), such that the resulting pair of processes
are observationally equivalent (and vice-versa). We avoid the circularity of this informal
characterisation, and dene it rigorously as follows.
Denition 8 (Observational equivalence) Observational equivalence () is the largest
symmetric relation between closed extended processes with the same domain such that
implies:
1. if , then ;
2. if
, then
and
for some
;
3. [] [] for all closing evaluation contexts [ ].
Note that we insist that is symmetric, so we can state the Conditions 1 and 2 in a
non-symmetric way (the symmetric part is guaranteed by the symmetry of ). Note
also the added condition that the two processes have the same domain; this captures the
observable difference between processes in which the value of a variable appearing in
one frame, is not dened in the other.
A classical example illustrates the difference between observational equivalence and
the notion of equivalence mentioned at the start of Section 4 (sometimes called trace
equivalence). Intuitively, trace equivalence checks that the outputs on the traces allowed
by [] are the same as those of [], but it does not enforce that decisions inside and
occur at the same point. Let us use the notation
1
+
2
to mean the non-deterministic
choice of
1
or
2
. This is expressible in applied pi, as follows:
1
+
2
.(left right ().if = left then
1
else
2
)
Here, left and right are names, and a scheduler chooses which message output left
or right to perform, and hence whether
1
or
2
runs. Note that only one of
1
and
2
runs, in contrast with
1

2
; moreover, only one of the outputs left, right
may occur, because there is only one input (), and is restricted. Now consider the
processes
1
.
2
+
1
.
3
and
1
.(
2
+
3
). One can see
that they are trace equivalent, by experimenting with a variety of contexts. However, in
the decision between outputting
2
or
3
is taken earlier than it is in . Observational
equivalence captures this as an observable difference. Consider the context [ ] =
(). Although [] and [] have the same output capabilities, [] can evolve to
a process (namely
2
+
3
) which is not equivalent to any process that [] can
evolve to (namely, the processes
2
or
3
).
4.2. Labelled bisimilarity
The quantication over contexts makes the denition of observational equivalence hard
to use in practice. Therefore, labelled bisimilarity is introduced, which is more suitable
for both manual and automatic reasoning. Labelled bisimilarity relies on an equivalence
relation between frames, called static equivalence, which we dene rst. Intuitively, two
frames are statically equivalent if no test = can tell them apart, where and
have variables that are substituted from the frame. Formally:
Denition 9 (Static equivalence) Two closed frames and are statically equivalent,
denoted
, if dom() = dom() and there exists a set of names and substitutions

, such that . and . and for all terms , such that (fn()
fn()) = , we have =
holds if and only if =
holds. We say two

closed extended processes , are statically equivalent, and write
, when their
frames are statically equivalent; that is, ()
().
The relation is called static equivalence because it only examines the current state of the
processes (as represented by their frames), and not the processes dynamic behaviour
(that is, the ways in which they may execute in the future). Thus, two processes are stat-
ically equivalent if they cannot be distinguished on the basis of their output so far. Static
equivalence captures the static part of observational equivalence. More precisely, obser-
vational equivalence and static equivalence coincide on frames. Static equivalence can
straightforwardly be shown to be closed under structural equivalence, internal reduction
and application of closing evaluation contexts.
Example 10 (Static equivalence) In the following examples we assume the signature
= {hash, fst, snd, pair} and the smallest equational theory
satisfying the equa-

tions fst(pair(, )) = , snd(pair(, )) = over all variables , , where as expected
hash, fst, snd are unary functions and pair is a binary function.
.{
.{
}; trivial, since they are structurally equivalent.

.{
.{
hash()
/
}.
{
{
hash()
/
}. The rst one satises = but the second one does

not.
.{
} .{
.({
hash(pair(, ))
/
} {
hash(pair(, ))
/
}.
.{
} .{
.({
} {
hash()
/
}), since the second one satis-

es hash() = and the rst one does not.
.{
pair(, )
/
.{
}, since the rst one satises pair(fst(), snd()) =

but the second one does not.
As mentioned, static equivalence captures the static part of observational equiva-
lence. The following denition of labelled bisimilarity captures the dynamic part.
Denition 10 (Labelled bisimilarity) Labelled bisimilarity (
) is the largest symmet-

ric relation on closed extended processes such that implies:
1.
;
2. if
, then
and
for some
;
3. if

and fv() dom() and bn() fn() = ; then
and
for some
.
Clauses 2 and 3 of this denition correspond to classical notions of bisimilarity [42].
Notice the use of the largest relation construction, to allow us to insist that the pro-
cesses
and
are again within the relation. Clause 1 asserts static equivalence at each
step of the bisimulation.
Let us now consider the side condition of Clause 3. Recall that there are three pos-
sibilities for , namely (), , and ., where is either a channel name or
a variable of base type. In Clause 3, can have free variables (in the cases () and
), but any such variables must be dened by the frame of (and since
, also
by the frame of ). Hence the condition fv() dom(). The label can also have
bound names (in the case ., where is a channel name), in which case the transi-
tion

has the effect of removing the restriction on a bound channel name. That
channel must not occur free in , to avoid confusing the restricted name with the global
name; hence the condition bn() fn() = . To see this in more detail, consider ,
such that
, and suppose fn()fn(). (For example, is 0 and is if =

then .) Intuitively, we would like (.)
(.). But to achieve

that, we need the side condition, for otherwise the transition (.)
.

would have to be matched on the right hand side by (.)
.
, which is
false.
Working with labelled bisimilarity. To show labelled bisimilarity of and , it is nec-
essary to nd a symmetric relation that satises the conditions contained in Denition
10, such that . Note that the we nd is not required to be the largest one. That
is because the set of relations that satises the conditions contained in Denition 10 is
closed under union. Therefore, the largest one is the union of them all. Any relation sat-
isfying the conditions of Denition 10 can serve as a witness to show that two processes
are labelled bisimilar. Note also that, although labelled bisimilarity is easily seen to be
an equivalence relation, the relation is merely required to be symmetric.
Example 11 (Labelled bisimilarity) We prove that for all closed processes
1
,
2
,
and names such that , we have .(.
1
().
2
)
.(
1

2
{
}) . Intuitively, the equivalence holds because the only choice that the left side
has, which the right side does not, is an internal reduction (private channel communica-
tion). Let hold if there exists a closed extended process
such that one of the

following holds:
.(.
1
().
2
)
and .(
1

2
{
})
; or
.(.
1
().
2
)
and .(
1

2
{
})
; or
.
One may show that satises the conditions contained in Denition 10. First, is
easily seen to be symmetric. For the next part, suppose .
1. We show
. There are three cases.

(a) .(.
1
().
2
)
and .(
1

2
{
})
. Since
.(.
1
().
2
)
.(
1

2
{
}), we have
.
(b) .(.
1
().
2
)
and .(
1

2
{
})
. In this
case, a similar argument applies.
(c) and hence we trivially have
.
2. Now suppose
. There are again three cases to consider.

(a) .(.
1
().
2
)
and .(
1

2
{
})
. If

.(
1

2
{
})
, then let
. Otherwise,
.(.
1

().
2
)
for some
, in which case let
.(
1

2
{
})
.
(b) .(
1

2
{
})
and .(.
1
().
2
)
. Since
, it follows that
, so let
.
(c) and hence the result follows trivially by
.
In all cases we have
, as required.
3. Now suppose

. Again we have three cases:

(a) .(.
1
().
2
)
and .(
1

2
{
})
. Since
only the
part is able to make a labelled transition,
.(.
1

().
2
)
for some
, in which case let
.(
1

2
{
})
,
and we have

.
(b) .(
1

2
{
})
and .(.
1
().
2
)
. Since
, it follows that
, so let
.
(c) and hence the result is trivial by
.
In all cases we have
, as required.
Abadi & Fournet [8] state the following useful results, although as far as we are
aware fully detailed proofs have not yet been published.
Lemma 1 Given closed extended processes , and a closing evaluation context [ ],
we have
implies []
[].
Theorem 1 Observational equivalence and labelled bisimilarity coincide: =
.
The condition stating that active substitutions are of base type (Section 2.1) is crucial
to Theorem 1. Without this constraint, one would have the following counterexample:
.({
} ().) .{
} (this can be seen using the closing evaluation

context [ ] = ); whereas .({
} ().)
.{
}.
4.3. Strong secrecy
Our earlier denition of secrecy required that the secret was not obtained by the adver-
sary. We will now use notions of equivalence to demonstrate a stronger notion of secrecy
which states an adversary is unable to distinguish when the secret changes [1,30]. Intu-
itively, this means the value of the secret should not effect the observable behaviour of
the protocol. Strong secrecy is useful, for example, to capture the adversarys inability to
learn any partial information about the secret.
Strong secrecy is also useful to formalise dictionary attacks, also known as guess-
ing attacks, in which the attacker tries all the possible values of the secret until he nds
the right one. If a secret is chosen from a relatively small set of possible values, then such
an attack might be possible; we call such a secret weak. Passwords are often examples
of weak secrets. For example, a server which requires the user to send her password ,
deterministically encrypted with servers public key , that is, to send {}
a
, is vul-
nerable to guessing attacks on . That is because an attacker in possession of {}
a
can
make a guess
of the password , and check the validity of his guess by constructing

{
}
a
and comparing it with {}

a
. Suppose instead the server requires the user to

include a random nonce in the encryption, that is, to send {, }
a
, where is a nonce
chosen from a large set. In that case the system is not vulnerable to guessing attacks.
This may be formalised by the following denitions [14,32].
Denition 11 Let .
be a frame. We say that is resistant to guessing attacks

against if, and only if, .(
})
..(
}) where
is a fresh
name and is a variable such that dom().
The denition says that the environment cannot distinguish between a situation in
which he possesses the correct value of the secret, from another one in which he has
some random value instead. This denition can be extended to the more general case.
Denition 12 (Guessing attacks) Let be a process and bn(). We say that is
resistant to guessing attacks against if, for every process such that (
,
then we have that () is resistant to guessing attacks against .
Example 12 (TPM authentication [26]) We consider a protocol where a client
shares a secret with a server (the protocol is based on the one used in the Trusted
Platform Module [48]). In this example, the terms and are commonly used for
tuples, so it is convenient to introduce a little syntactic sugar to express them. We write
(
1
, . . . ,
) to mean pair(
1
, pair(
2
, pair(. . . , pair(
, ) . . . ))), where is any

constant. We also write 1st(), 2nd(), and 3rd() to mean fst(), fst(snd()),
and fst(snd(snd())) respectively. Note that (
1
, . . . ,
), 1st(), etc., are not new

functions, but merely syntactic sugar for combinations of functions that we already have.
The protocol proceeds as follows. The client sends commands to the server, and authen-
ticates them by supplying a MAC of the command values, keyed on . An additional
nonce is supplied and used in the MAC, to ensure it has high entropy. More precisely,
to run the command comm, sends the message (comm, , mac(, (comm, ))).
checks the MAC by reconstructing it, and if it is correct, sends the response resp. This
protocol may be modelled by the following process , where we assume the signature
{mac} and equational theory
(recall that
and
were dened in
Example 10, and note that binary function mac has no equations).
.(!
.(comm, , mac(, (comm, )))
().if 3rd() = mac(, (1st(), 2nd())) then resp

is vulnerable to guessing attacks on . To see this, we consider the transition
.
.(.{
(comm, , mac(, (comm, )))
/
} !
)
The frame of this latter process is vulnerable to guessing attacks on , since we have
..({
/
} {
})
...({
/
} {
})
as witnessed by the test
3rd() = mac(, (1st(), 2nd())).
A comparison of two views of secrecy. The reachability-based secrecy introduced in
Section 3.1 requires that the adversary should never learn secret values; the equivalence-
based (strong) secrecy introduced in this section states that two executions of a protocol
are indistinguishable regardless of the chosen secret values. The formulation of strong
secrecy offers a higher degree of security, but reachability-based secrecy has been more
widely studied resulting in more automated support. For further discussion on the re-
lationship between these two styles of secrecy the reader is referred to [30,1], see also
Blanchet for a more generic formalisation of strong secrecy [20].
4.4. Vote privacy for electronic voting
Electronic voting systems are being introduced, or trialled, in several countries to provide
more efcient voting procedures with an increased level of security. The applied pi cal-
culus can be used to formalise the properties which an electronic voting scheme should
satisfy [39,34,12]. For example, the property of vote privacy (or ballot secrecy) means
that no-one (not even the election ofcers) can link a particular vote with the voter.
Consider the following protocol, which is a simplication of the one by Fujioka,
Okamoto, and Ohta [37]. We assume the signature
= {true, fst, snd, pk, getmsg,

pair, sign, checksign, blind, unblind}, the arities of which are dened in the usual way;
that is, true is a constant; fst, snd, pk, getmsg are unary functions; and pair, sign,
checksign, blind, unblind are binary functions. The protocol [37] relies on blind signa-
tures; with this cryptographic primitive, an election ofcer can sign a text without hav-
ing seen it. The voter rst blinds the text and the ofcer signs it. The voter can then un-
blind the message to recover the ofcers signature on the text. We do not need to con-
sider how this cryptography actually works; we can encode the effect using the equation
unblind(, sign(, blind(, ))) = sign(, ) which says that if one blinds a text using
a blinding factor , and then signs it with the private key , and then unblinds it (again
using ), then the result is the text signed by in the usual way. Blind signatures are
useful in electronic voting because they allow the ofcer to sign a vote (thus establishing
its eligibility for counting) without knowing what the vote is. The equations associated
with the remaining functions in
are dened in the usual way (see Section 2.1.1).

The protocol proceeds as follows. The voter wishing to vote for candidate creates
a nonce , and blinds the tuple , using a random blinding factor . She then signs
this value and sends it to the election ofcer. The ofcer checks the voters eligibility
and also checks she has not already voted. If these checks succeed, then the ofcer signs
the blinded vote-nonce pair and sends it back to the voter. The voter can now unblind
the signature, recovering the ofcers signature on the vote-nonce pair. Once all voters
have obtained the ofcers signature in this way, they can anonymously submit the signed
vote-nonce pair for counting. The protocol thus proceeds as follows:
Voter Ofcer
sign(
, blind(, pair(, )))

sign(
, blind(, pair(, )))

synch
sign(
, pair(, ))

The purpose of the value is to allow the ofcer to count the signed vote only once.
The synchronisation point, denoted synch, ensures that every voter receives the ofcers
signature before any of them submit the unblinded value for counting. It is necessary to
ensure vote privacy; without it, trafc analysis might link the voters signature in the rst
message with the anonymous submission in the third one. This protocol is inadequate for
a real election, but it does satisfy the property of vote privacy.
We formalise this illustrative voting protocol in the applied pi calculus as follows.
We assume a public channel for communication between the voter and the ofcer, and
a channel for the ofcer to declare the list of counted votes.

1
. . .
.
let
1
= pk(
1
) in . . . let
= pk(
) in
1
. . . . .
.
let
= pk(
) in
.
(
1
/
1
/
} !
..let = blind(, pair(, )) in

pair(pk(
), sign(
, )).
().if checksign(
, ) = true then
if getmsg() = then
synch.
unblind(, )
().if checksign(fst(), snd()) = true then

if Eligible(fst()) = true then
sign(
, getmsg(snd())).
().
if checksign(
, ) = true then
if NotSeen() = true then
fst(getmsg())
In the above process, we assume functions Eligible() and NotSeen() are available
to the ofcer. Eligible() checks whether the voter with public key is eligible and
hasnt already voted; NotSeen() stores and returns true if it has not seen before;
otherwise it returns false. The purpose of NotSeen() is to ensure that the voter cant
use the signed token twice. We also assume a subprocess synch which a voter uses to
synchronise with other voters. This can be modelled by dening a process to coordinate
the synchronisation. In the case of voters, the coordination process receives precisely
tokens, and then sends them back. To synchronise with the other voters, a voter sends
a token to this synchronisation coordinator and awaits its response. Thus,
synch .
()
(
1
) . . . (
).
. . .
where ,
are private channels shared between the voters and , is any name
and is a variable.
Now we dene the property of vote privacy. Since it should hold even if the ofcer is
corrupt, we can suppose that the ofcer is part of the attacker, and we need not consider
its formalisation as
above. This means the secrecy of the ofcers key is not required
for the vote privacy property, so we can treat it as a free name. Moreover, the voters
secret keys are also not required to be kept secret in order to ensure the vote privacy
property. They too can be treated as free names. (Of course, these keys are required to
be secret for other properties.)
Consider two voters , and two candidates
. Based upon [34], we formalise

vote privacy for two voters with the assertion that the attacker (including the election
ofcers) cannot distinguish between a situation in which votes
and votes
, from
another one in which votes
and votes
. We will write this as the equivalence:

.
.(
} )
.(
} )
To prove this equivalence, let us call the left hand side LHS, and the right hand side RHS.
We need to show a relation satisfying the requirements of Denition 10 such that
LHS RHS. As we have seen, the idea of is to relate successors of LHS and RHS that
are expected to correspond to each other in the bisimulation. As LHS evolves, the corre-
sponding evolution of RHS is the one that mimics moves in LHS with moves in RHS,
and moves in LHS with moves in RHS, up to the synchronisation. After the synchro-
nisation, moves in LHS are mimicked by moves in RHS, and moves in LHS are
mimicked by moves in RHS. The reason for the swap in mimicking is to ensure that
the static equivalences will hold; before the synchronisation, the output data produced
by on both the LHS and RHS are indistinguishable (and similarly for ). Observe that
the output data reveals the keys pk(
), pk(
) (matched by pk(
), pk(
)) and
the signed blind votes sign(
, blind(, pair(
, ))), sign(
, blind(
, pair(
)))
(matched by sign(
, blind(, pair(
, ))), sign(
, blind(
, pair(
)))) where
names ,
, ,
are under restriction in both LHS and RHS. Indistinguishability be-

tween the LHS and RHS with respect to the signed blind votes is due to the properties of
blinding. After the synchronisation will reveal
on the LHS and
on the RHS (sim-

ilarly will reveal
on the LHS and
on the RHS). Hence after synchronisation the

actions mimicked are swapped. A formal proof of this result is included in the extended
version of this chapter [44].
5. Outlook
This chapter studies the applied pi calculus and demonstrates its applicability for
analysing secrecy, correspondence and observational equivalence properties in the con-
text of security protocols. In this section we briey refer to some on-going research about
the calculus. Our discussion is neither exhaustive nor complete.
The ability to reason with security properties is largely dependent on being able
to reason with the equational theory. Abadi & Cortier [6] have studied decidability of
secrecy and static equivalence for a large class of equational theories in the presence of
a passive adversary. Subsequent work by Baudet, Cortier & Delaune [15] and Ciob ac a,
Delaune & Kremer [28] introduces automated tools for analysing static equivalence with
respect to convergent equational theories.
For an active adversary, reachability properties, in particular secrecy, have been stud-
ied in [18,2] with updated and extended versions [3] and in Chapter Using Horn clauses
for analyzing protocols of this book. Strong secrecy has been considered in [20]. Cor-
respondence properties have been presented in the context of authenticity [19], and sub-
sequently extended upon and revised in [21]. Proofs of observational equivalence have
been studied with respect to processes that differ only by the choice of the terms that they
contain, using the notion of uniformity [22,23]. But this notion of uniformity is often
too strict; for example, the voting process discussed in this chapter does not satisfy it.
A practical approach to overcoming the problem is introduced [35], [45, Chapter 5] and
subsequently used [12,31]. As an alternative to uniformity as a proof technique, a sym-
bolic version of the applied pi calculus is introduced in [33]; by treating inputs symboli-
cally, it avoids potentially innite branching of processes due to inputs from the environ-
ment. Cortier & Delaune [29] have shown that observational equivalence coincides with
trace equivalence for determinate processes; and based on the symbolic semantics, this
yields a decision procedure for observational equivalence of nite determinate processes
without replication.
Acknowledgements
We are very grateful to Myrto Arapinis and the editors of the Handbook for careful read-
ing of a draft of this chapter. This work has been partly supported by the EPSRC projects:
UbiVal: Fundamental Approaches to Validation of Ubiquitous Computing Applications
and Infrastructures (EP/D076625/2); and Verifying Interoperability Requirements in Per-
vasive Systems (EP/F033540/1). This work was partly done while Ben Smyth was at
CNRS, D epartement dInformatique,

Ecole Normale Sup erieure, Paris, France with sup-
port from the Direction G en erale pour lArmement (DGA).
References
[1] Martn Abadi. Security Protocols and their Properties. In Friedrich L. Bauer and Ralf Steinbr uggen,
editors, Foundations of Secure Computation, NATO Science Series, pages 3960. IOS Press, 2000.
[2] Martn Abadi and Bruno Blanchet. Analyzing Security Protocols with Secrecy Types and Logic Pro-
grams. In POPL02: Proceedings of the 29th ACM SIGPLAN-SIGACT Symposium on Principles of
Programming Languages, pages 3344. ACM Press, 2002.
[3] Martn Abadi and Bruno Blanchet. Analyzing Security Protocols with Secrecy Types and Logic Pro-
grams. Journal of the ACM, 52(1):102146, 2005.
[4] Martn Abadi and Bruno Blanchet. Computer-Assisted Verication of a Protocol for Certied Email.
Science of Computer Programming, 58(12):327, 2005. Special issue SAS03.
[5] Martn Abadi, Bruno Blanchet, and C edric Fournet. Just Fast Keying in the Pi Calculus. ACM Transac-
tions on Information and System Security, 10(3):159, 2007.
[6] Martn Abadi and V eronique Cortier. Deciding knowledge in security protocols under equational the-
ories. In ICALP04: Proceedings of the 31st International Colloquium on Automata, Languages and
Programming, volume 3142 of LNCS, pages 4658. Springer, 2004.
[7] Martn Abadi and V eronique Cortier. Deciding knowledge in security protocols under equational theo-
ries. Theoretical Computer Science, 367(12):232, 2006.
[8] Martn Abadi and C edric Fournet. Mobile values, new names, and secure communication. In POPL01:
28th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 104115.
ACM Press, 2001.
[9] Martn Abadi and C edric Fournet. Private email communication, 24th May 2006.
[10] Martn Abadi and Andrew D. Gordon. A calculus for cryptographic protocols: the spi calculus. In
CCS97: 4th ACM conference on Computer and Communications Cecurity, pages 3647. ACM Press,
1997.
[11] Martn Abadi and Roger Needham. Prudent engineering practice for cryptographic protocols. IEEE
Transactions on Software Engineering, 22(1):615, January 1996.
[12] Michael Backes, Catalin Hritcu, and Matteo Maffei. Automated Verication of Remote Electronic Vot-
ing Protocols in the Applied Pi-Calculus. In CSF08: 21st IEEE Computer Security Foundations Sym-
posium, pages 195209. IEEE Computer Society, 2008.
[13] Michael Backes, Matteo Maffei, and Dominique Unruh. Zero-Knowledge in the Applied Pi-calculus
and Automated Verication of the Direct Anonymous Attestation Protocol. In S&P08: 29th IEEE
Symposium on Security and Privacy, pages 202215. IEEE Computer Society, 2008.
[14] Mathieu Baudet. Deciding security of protocols against off-line guessing attacks. In CCS05: Pro-
ceedings of the 12th Conference on Computer and Communications Security, pages 1625. ACM Press,
2005.
[15] Mathieu Baudet, V eronique Cortier, and St ephanie Delaune. YAPA: A generic tool for computing in-
truder knowledge. In RTA09: Proceedings of the 20th International Conference on Rewriting Tech-
niques and Applications, volume 5595 of LNCS, pages 148163. Springer, 2009.
[16] Jesper Bengtson, Magnus Johansson, Joachim Parrow, and Bj orn Victor. Psi-calculi: Mobile Processes,
Nominal Data, and Logic. In LICS 09: 24th Annual IEEE Symposium on Logic In Computer Science,
pages 3948. IEEE Computer Society, 2009.
[17] Karthikeyan Bhargavan, Cedric Fournet, Andrew D. Gordon, and Stephen Tse. Veried Interoperable
Implementations of Security Protocols. In CSFW06: IEEE Computer Security Foundations Workshop,
pages 139152. IEEE Computer Society, 2006.
[18] Bruno Blanchet. An efcient cryptographic protocol verier based on Prolog rules. In CSFW01:
Proceedings of the 14th IEEE Computer Security Foundations Workshop, pages 8296. IEEE Computer
Society, 2001.
[19] Bruno Blanchet. From Secrecy to Authenticity in Security Protocols. In SAS02: Proceedings of the 9th
International Static Analysis Symposium, volume 2477 of LNCS, pages 342359. Springer, 2002.
[20] Bruno Blanchet. Automatic Proof of Strong Secrecy for Security Protocols. In S&P04: 25th IEEE
Symposium on Security and Privacy, pages 86100. IEEE Computer Society, 2004.
[21] Bruno Blanchet. Automatic Verication of Correspondences for Security Protocols. Journal of Com-
puter Security, 17(4):363434, 2009.
[22] Bruno Blanchet, Martn Abadi, and C edric Fournet. Automated verication of selected equivalences
for security protocols. In LICS05: Proceedings of the 20th IEEE Symposium on Logic in Computer
Science, pages 331340. IEEE Computer Society, 2005.
[23] Bruno Blanchet, Martn Abadi, and C edric Fournet. Automated Verication of Selected Equivalences
for Security Protocols. Journal of Logic and Algebraic Programming, 75(1):351, 2008.
[24] Bruno Blanchet and Avik Chaudhuri. Automated Formal Analysis of a Protocol for Secure File Sharing
on Untrusted Storage. In S&P08: 29th IEEE Symposium on Security and Privacy, pages 417431.
IEEE Computer Society, 2008.
[25] Bruno Blanchet and Ben Smyth. ProVerif: Automatic Cryptographic Protocol Verier User Manual &
Tutorial. Available from http://www.proverif.ens.fr/, 2010.
[26] Liqun Chen and Mark D. Ryan. Ofine dictionary attack on TCG TPM weak authorisation data, and
solution. In David Gawrock, Helmut Reimer, Ahmad-Reza Sadeghi, and Claire Vishik, editors, Future
of Trust in Computing. Vieweg & Teubner, 2008.
[27] Liqun Chen and Mark D. Ryan. Attack, solution and verication for shared authorisation data in TCG
TPM. In FAST09: 6th Formal Aspects in Security and Trust, LNCS. Springer, 2009.
[28] S tefan Ciob ac a, St ephanie Delaune, and Steve Kremer. Computing knowledge in security protocols
under convergent equational theories. In CADE09: Proceedings of the 22nd International Conference
on Automated Deduction, Lecture Notes in Articial Intelligence, pages 355370. Springer, 2009.
[29] V eronique Cortier and St ephanie Delaune. A method for proving observational equivalence. In CSF09:
22nd IEEE Computer Security Foundations Symposium, pages 266276. IEEE Computer Society, 2009.
[30] V eronique Cortier, Micha el Rusinowitch, and Eugen Z alinescu. Relating two standard notions of se-
crecy. Logical Methods in Computer Science, 3(3), 2007.
[31] Morten Dahl, St ephanie Delaune, and Graham Steel. Formal Analysis of Privacy for Vehicular Mix-
Zones. In ESORICS10: 15th European Symposium on Research in Computer Security, volume 6345 of
LNCS, pages 5570. Springer, 2010.
[32] St ephanie Delaune, Steve Kremer, and Mark D. Ryan. Composition of password-based protocols. In
CSF08: Proceedings of the 21st IEEE Computer Security Foundations Symposium, pages 239251,
Pittsburgh, PA, USA, 2008. IEEE Computer Society.
[33] St ephanie Delaune, Steve Kremer, and Mark D. Ryan. Symbolic bisimulation for the applied pi calculus.
Journal of Computer Security, 2009.
[34] St ephanie Delaune, Steve Kremer, and Mark D. Ryan. Verifying Privacy-type Properties of Electronic
Voting Protocols. Journal of Computer Security, 2009.
[35] St ephanie Delaune, Mark D. Ryan, and Ben Smyth. Automatic verication of privacy properties in
the applied pi-calculus. In IFIPTM08: Proceedings of the 2nd Joint iTrust and PST Conferences on
Privacy, Trust Management and Security, volume 263 of IFIP Conference Proceedings, pages 263278.
Springer, 2008.
[36] Danny Dolev and Andrew C. Yao. On the security of public key protocols. Information Theory, 29:198
208, 1983.
[37] Atsushi Fujioka, Tatsuaki Okamoto, and Kazui Ohta. A practical secret voting scheme for large scale
elections. In AUSCRYPT92: Advances in Cryptology, volume 718 of LNCS, pages 244251. Springer,
1992.
[38] Steve Kremer and Mark D. Ryan. Analysis of an Electronic Voting Protocol in the Applied Pi-Calculus.
In ESOP05: Proceedings of the 14th European Symposium On Programming, volume 3444 of LNCS,
pages 186200. Springer, 2005.
[39] Steve Kremer, Mark D. Ryan, and Ben Smyth. Election veriability in electronic voting protocols. In
ESORICS10: 15th European Symposium on Research in Computer Security, volume 6345 of LNCS,
pages 389404. Springer, 2010. An extended version of this paper appears in [45, Chapter 3].
[40] Ralf K usters and Tomasz Truderung. An Epistemic Approach to Coercion-Resistance for Electronic
Voting Protocols. In S&P09: 30th IEEE Symposium on Security and Privacy, pages 251266. IEEE
Computer Society, 2009.
[41] Gavin Lowe. A hierarchy of authentication specications. In CSFW97: 10th IEEE workshop on Com-
puter Security Foundations, pages 3143. IEEE Computer Society, 1997.
[42] Robin Milner. Communicating and mobile systems: the -calculus. Cambridge University Press, 1999.
[43] Aybek Mukhamedov, Andrew D. Gordon, and Mark D. Ryan. Towards a Veried Reference Implemen-
tation of the Trusted Platform Module. In 17th International Workshop on Security Protocols, LNCS.
Springer, 2009.
[44] Mark D. Ryan and Ben Smyth. Applied pi calculus. Available fromhttp://www.bensmyth.com/
publications/10applied-pi/, 2010.
[45] Ben Smyth. Formal verication of cryptographic protocols with automated reasoning. PhD thesis,
School of Computer Science, University of Birmingham, 2011.
[46] Ben Smyth, Mark D. Ryan, and Liqun Chen. Direct Anonymous Attestation (DAA): Ensuring privacy
with corrupt administrators. In ESAS07: 4th European Workshop on Security and Privacy in Ad hoc
and Sensor Networks, volume 4572 of LNCS, pages 218231, 2007. An extended version of this paper
appears in [45, Chapter 4].
[47] D. Syme, A. Granicz, and A. Cisternino. Expert F#. Apress, 2007.
[48] Trusted Computing Group. TPM Specication version 1.2. Parts 13., 2007. Available from http:
//www.trustedcomputinggroup.org/specs/TPM/.
Types for Security Protocols
1
Riccardo FOCARDI
a
and Matteo MAFFEI
b
a
University of Venice, Italy
b
Saarland University, Germany
Abstract. We revise existing type-based analyses of security protocols by devising
a core type system for secrecy, integrity and authentication in the setting of spi-
calculus processes. These fundamental security properties are usually studied inde-
pendently. Our exercise of considering all of them in a uniform framework is inter-
esting under different perspectives: () it provides a general overview of how type
theory can be applied to reason on security protocols; () it illustrates and com-
pares the main results and techniques in literature; () perhaps more importantly,
it shows that by combining techniques deployed for different properties, existing
type-systems can be signicantly simplied.
1. Introduction
Predicting the behaviour of a protocol or program by just inspecting its code is a very
intriguing challenge which can be approached in different ways. Techniques such as ab-
stract interpretation [18] or control ow analysis [33,12] aim at dening sound abstrac-
tions of the actual semantics which overapproximate the behaviour of the protocol: all
the concrete executions are guaranteed to be captured by the abstract semantics. This
allows for developing efcient analyses which can certify the correctness of a protocol
with respect to some target (security) property P: if the abstraction satises P we are
guaranteed that all the concrete runs will also satisfy P.
Type theory takes a somehow complementary perspective. Saying, for example, that
a message has a certain type allows for statically check that such a message will be used
in a controlled way so to avoid violating the target property P. Instead of abstracting
the behaviour of the protocol and check P over the abstraction, we devise a set of rules
that dictate how typed data and protocols should be programmed so to respect P. One
interesting aspect of this approach is that it forces understanding why and how security
is achieved. This is particularly useful for security protocols whose aws often derive by
some degree of ambiguity in the role that messages play in achieving a certain goal. Type-
based reasoning is therefore particularly valuable, as it forces one to clarify protocol
specications by making explicit the underlying security mechanisms.
A toy example. We consider Condentiality, i.e., the property of data being accessible
only by authorized users. In a (idealized) distributed setting we might think of honest
principals sharing secure communication channels. Thus, a simple way to achieve con-
1
Work partially supported by the initiative for excellence and the Emmy Noether program of the German
federal government and by Miur07 Project SOFT: Security Oriented Formal Techniques.
IOS Press, 2011
doi:10.3233/978-1-60750-714-7-143
143
dentiality might be to impose that high-condential (or secret) data are only sent on
secure channels. If denotes the output of over channel we might formalize the
above idea as:
: Secret, : Secure
meaning that under the hypothesis is of type Secret and is of type Secure we can
type-check the output . Of course we do not want to write a different rule for every
different case. For example it is clearly safe to even send a public message over a secure
channel. For this reason it is useful to introduce a notion of derived type: : Secret
meaning that can be given type Secret starting from the type bindings listed in .
For example, clearly, : Secret, : Secure : Secret. But we could also say that
: Public, : Secure : Secret, since a public data can be safely regarded as
secret. The typing rule for the output can be now rewritten as:
: Secret : Secure

The fact that a type is less demanding than another one
is usually formalized
through a subtyping relation
. Thus, in our case it is enough to state that

Public Secret in order to allow all public data to be regarded also as secrets. As-
suming this, the above typing rule does not actually say much: on a secure channel we
can send whatever kind of data, both public and secret. It is instead more interesting to
regulate what can be done on insecure channels
: Public : Insecure

Given that Secret Public we intuitively have that secret data will never be sent on
insecure channels.
To be useful, types must be preserved at run-time, i.e., a typed protocol should re-
main typed when it is executed and, in particular, when variables get bound to names
received from the network. In our small toy example, this amounts to specify what type
we expect when we receive messages from the network: in particular we are required to
give type Secret to all messages coming from secure channels. Noting (). a protocol
reading a message from channel and binding with in the sequent , we can
write:
, : Secret : Secure
().
If the channel is secure, is given type Secret and the sequent is typed under this
assumption, meaning that must treat as it were a secret.
A fourth rule might state that when reading from insecure channels we can safely
give type public to . At this point, however, one is tempted to try to nd a more suc-
cinct way to express these four cases. One attempt might be to equate Secret with Se-
cure and Public with Insecure, but this would lead to an insecure channel being re-
garded as secure, obviously breaking condentiality. A more appropriate way to nd a
connection between data and channel types is to look at their security level. We can write
(Secret) = (Secure) = and (Public) = (Insecure) = , meaning that
secret data and secure channels have a high security level, while public data and inse-
R. Focardi and M. Maffei / Types for Security Protocols 144
cure channels have a low one. With this idea in mind the whole toy type system can be
summarized as follows:
(
) = (
)
:
) = (
)
, :
().
where
ranges over Secret and Public and
ranges over Secure and Insecure.

Intuitively, a message can be sent over if its security level does not exceed the one
of the channel (a secret message can never be sent on an insecure channel); notice that
a public message can be risen to secret via subtyping, and be sent on a secure channel;
dually, a message received from must be assumed to be at least at the security level of
the channel (a message received from a secure channel must be regarded as secret). For
example if is : Insecure, : Secure we can type-check protocol ()., which
forwards messages read from an insecure channel to a secure one. The typing derivation
is as follows:
Public Secret
, : Public : Secret , : Public : Secure
, : Public
().
If we swap the channels, of course, the protocol becomes not typable as messages
read from secure channels should never be forwarded on insecure ones. Formally,
(). since , : Secret , being insecure.
Type-based analysis of Security Protocols: an overview. Type-based analysis of secu-
rity protocols dates back to Abadis seminal work [1] on secrecy by typing. This work
focuses on security protocols based on symmetric-key cryptography and on the secrecy
of data. The idea is to model cryptographic protocols in the spi-calculus [6] and to verify
condentiality with a type system. One of the fundamental contributions is the method-
ology used to type-check the opponent: processes manipulating only messages of type
Public are shown to be always well-typed (opponent typability). This technique allows
for type-checking the opponent without posing any constraints on his behavior. The con-
dentiality property established by the type system is expressed in terms of noninterfer-
ence: an opponent will never be able to distinguish two protocol executions in which the
initial value of sensitive data may differ. Abadi and Blanchet subsequently extended the
type system to reason about security protocols based on asymmetric cryptography [4,5]
Among the foundational contributions of this research line, we point out the tech-
nique used to type-check encrypted messages. Keys are given a type of the form
Key
[], which dictates the type of the messages encrypted with that key. The security
level species whether the key is possibly known to the opponent (=Public) or not
(=Secret). The receiver of a ciphertext can thus determine the type of the decrypted
message by the type of the key. If the key has type Key
Secret
[], then the ciphertext comes
from a well-typed process and the decrypted message has type ; if the key has type
Key
Public
[], then the ciphertext might come from a well-typed process as well as from
the opponent and the continuation process has to be type-checked twice, once with the
message being of type and once with the message being of type Public.
Gordon and Jeffrey proposed a type and effect system for verifying authenticity in
cryptographic protocols based on symmetric [23] and asymmetric cryptography [24].
The fundamental idea is to formulate authenticity properties in terms of correspondence
assertions [38] and to use dependent types in order to characterize the assertions valid
for each message. Correspondence assertions are protocol annotations of the form be-
gin() and end(), marking the begin and the end of a protocol session for authen-
ticating message . Intuitively, a protocol guarantees authenticity if every end is pre-
ceded by a corresponding begin [28]. The type system was subsequently extended to
handle conditional secrecy (a renement of secrecy, where a message is unknown to the
adversary unless particular messages or principals are compromised) [25] and protocols
based on time-stamps [26].
Bugliesi et al. proposed an alternative technique for the verication of authenticity
in security protocols [13,30,15]. This framework is based on a dynamic type and effect
system, which exploits a set of tags that uniquely identify the type and effect of encrypted
messages. The analysis enjoys strong compositionality guarantees and is well-suited to
reason about multi-protocol systems [29], although it assumes a tagging discipline for
messages. We refer the interested reader to [14] for a formal comparison between this
type and effect system and the above one by Gordon and Jeffrey.
Building upon this research line, Fournet et al. proposed a type system for the ver-
ication of authorization policies in security protocols [20]. The idea is to decorate the
protocol with assumptions and assertions of the form assume and assert , respec-
tively, where is a logical formula. A protocol is safe if every assertion is entailed by
the active assumptions. Authorization policies allow for reasoning about authenticity as
well as other security requirements, for instance access control policies. Authorization
policies, however, do not capture the freshness of authentication requests and the type
system does not handle nonce handshakes. The authors subsequently extended the type
system to reason about distributed systems where some of the principals are compro-
mised [21]. Backes et al. further rened the expressivity of the type system to reason
about protocols based on zero-knowledge proofs [9].
Even if security protocols are properly designed, security aws may still affect im-
plementations. For this reason, the analysis of executable code is crucial to provide end-
to-end security guarantees. Bengtson et al. [10] recently proposed a framework for the
type-based analysis of authorization policies in F# implementations of security proto-
cols. The type system is based on renement types, which describe the type of values as
well as logical formulas that characterize such values. The language is a lambda-calculus
with primitives for concurrency, which is used to dene the syntax of a large fragment
of F# by encoding. One important contribution of this work is the denition of a library
of symbolic cryptography in the lambda-calculus. In contrast to previous approaches,
cryptographic primitives are not modelled by ad-hoc language primitives and veried
by specic typing rules. They are instead dened by symbolic libraries based on seal-
ing [32,36,35] and veried by the standard typing rules for functions. This makes the
type system easily extensible to a large number of cryptographic primitives.
Outline of this work. We devise a core type system for condentiality, integrity and
authentication starting from pi-calculus processes, in which security is guaranteed via
ideal (restricted) channels. This simplied setting allows us to introduce important con-
cepts and basic types for secrecy and integrity, disregarding all the subtleties introduced
by cryptographic operations. We then consider a rather rich dialect of spi-calculus with
, , ::= terms
, , variable
, , , , , , , name
, , , ::= processes

. output
( ). input
0 stop
parallel
! replication
( : ) restriction
if = then else conditional
Table 1. Core calculus: terms and processes syntax
symmetric/asymmetric cryptography and digital signature. We show how the types for
cryptographic keys can be dened as an extension of the channel types of the pi-calculus:
the type transported by a secure channel can be seen as the type of the message encrypted
with a secure key. Finally, we add a system of effects to track linearity of nonce usage in
challenge-response protocols. Interestingly, the nal type-system is much simpler than
the ones in literature (e.g., [15,23,24]). We feel that this is mainly due to the benet of
combining in a uniform setting techniques deployed for different properties.
In our study we mix techniques and concepts from the literature, with the main aim
of dening a general setting where different contributions can be illustrated and under-
stood. In doing so, we have also borrowed concepts from the language-based security
literature (see, e.g., [34] for a survey), in particular for what concerns the dual treatment
of condentiality and integrity. It is worth mentioning that recent language-based secure
literature has extended imperative languages with cryptography allowing for the mod-
elling of cryptographic protocols in a language setting (see, e.g., [7,16,17,22,27,37]). It
is thus natural to try to bridge the language-based and the process-calculi settings and
take advantage from both of them. In summary, our work provides a general overview
of how type theory can be applied to reason on security protocols illustrating the main
results and techniques in literature; interestingly, it shows that existing type-systems can
be signicantly simplied by combining techniques originally deployed for verifying
different properties.
Note: Due to space constraints, we include in this chapter only the most interesting
proofs. A full version of this work is available at [19].
2. Secure Communication in the Pi-Calculus
We introduce a core calculus for reasoning about communication protocols without cryp-
tography. It is essentially a polyadic pi-calculus [31] with a typing annotation for re-
stricted names which will be useful to reason about security and has no semantic import.
In fact, to simplify the notation, types will be omitted when unimportant. This calculus
allows us to introduce in the simplest possible setting many important concepts, prop-
erties and proof techniques. In section 3, we will extend it with various cryptographic
primitives and we will show how these primitives can be statically checked so to provide
security.
Structural Equivalence

,

! !
( : ) ( : )
( : ) 0 0
0

( ) ( )
! !
( : ) ( :
) ( :
) ( : ) if =
( : ) ( ) ( : ) if / fn()
Reduction

. ( ). {

/ } (RED I/0)
if = then else (RED COND 1)
if = then else if = (RED COND 2)
(RED STRUCT)
(RED RES)

( : ) ( : )
(RED PAR)

Table 2. Structural Equivalence and Reduction
Syntax. The syntax of the calculus is given in Table 1. For the sake of readabil-
ity, we let

denote a sequence
1
, . . . ,
of terms and {

/ } the substitution
{
1
/
1
} . . . {
}. Intuitively, process

. outputs the tuple of messages

on channel and then behaves as ; ( ). receives a tuple of messages

(where
the arity of

and is the same) from channel and then behaves as {

/ }; 0 is
stuck; the parallel composition executes and concurrently; the replication !
behaves as an unbounded number of copies of in parallel; ( : ) generates a fresh
name (of type ) and then behaves as ; nally, if = then else behaves as
if is equal to or as otherwise. We will often omit the trailing 0 writing, e.g.,

in place of

.0.
We let fnfv() and fnfv() denote the free names and variables in term and
process , respectively. The notion of free names and variables is dened as expected:
all names and variables occurring in a term are free; the restriction ( :

) is a binder
for with scope and the input ( ). is a binder for with scope . We implicitly
identify processes up to renaming of bound names and variables.
Semantics. The semantics of the calculus is formalized in Table 2 in terms of a struc-
tural equivalence relation and a reduction relation . Structural equivalence is de-
ned as the least relation satisfying the rules reported in the rst part of Table 2. It is an
equivalence relation closed with respect to parallel composition, replication and restric-
tion, which essentially allows us to rearrange parallel compositions and restrictions in or-
der to bring processes that should interact close to each other, to unfold replications, and
to remove useless restrictions. Reduction is dened as the least relation on closed pro-
cesses satisfying the rules in the second part of Table 2. Communication is synchronous:
the output

. synchronizes with an input ( ). on the same channel and then
reduces to {

/ } (rule RED I/0). The equality test if = then else
reduces to if is equal to or to otherwise (rules RED COND 1 and 2). Moreover,
reduction relation preserves (RED STRUCT) and is closed with respect to restriction
(RED RES) and parallel composition (RED PAR). In the following, we let
hold
true if reduces in one or more steps to or if is structurally equivalent to .
2.1. Security Levels and Security Properties
In the literature on language-based security, it is common to study condentiality and
integrity together (see, e.g., [34]). Usually, the security level is a pair
specifying,
separately, the condentiality and integrity levels. We consider two possible levels: High
() and Low (). For example, denotes a high condentiality and high integrity
value, while a public (low condentiality) and high integrity one. Intuitively, high
condentiality values should never be read by opponents while high integrity values
should not be modied by opponents, i.e., when we receive high integrity data we expect
they originated at some trusted source.
HL
LL
LH
HH
An important difference between condentiality and integrity
levels is that they are contra-variant: while it is safe to consider a
public datum as secret, promoting low integrity to high integrity is
unsound, as any data from the opponent could erroneously be con-
sidered as coming from a trusted entity. Considering instead as low
integrity some high integrity data is harmless, as this basically re-
duces the assumptions we can make on them. More formally, the
condentiality and integrity preorders are such that
and
. We let
and
range over {, }, while we let range over the pairs
with
1
iff
1
and
1
, giving the standard four-point lattice depicted on the right.

Intuitively, moving up in the lattice is safe as both secrecy and integrity preorders are
respected.
As we mentioned above, our calculus is typed. The four points of the security lattice
are our four basic types and they are used for describing generic terms at the specied
security level.
Opponents. Processes representing opponents are characterized by type/level
meaning that they can read from and while they can modify and , reect-
ing the intuition that information may only ow up in the lattice. In particular, opponents
can only generate names of type , as formalized below:
Denition 1 (Opponent) A process is an opponent if all ( : ) occurring in are
such that = .
We will always assume that free names of processes are low condentiality and low
integrity, since they might be known to and originated by the opponent.
Level of types and terms. Later on, we will introduce more sophisticated types giving
additional information about how typed terms should be used. For the moment we do
not need to give more detail on types except that they always have an associated security
level. In particular, we write () to denote the associated security level. For the four
basic types we trivially have () = . Given () =
, we also write
C
() and
I
() to respectively extract from the condentiality and integrity levels
and
.
Similarly, given a mapping from terms to types, we denote with
() the level in
of a certain term formally dened as:
() =
{
(()) whenever dom()
otherwise
As above,
C,
() and
I,
() respectively denote the condentiality and integrity
level associated to in .
Secrecy. As mentioned above, secrecy refers to the impossibility for an opponent to
access/read some data . This property can be interpreted in two different ways, the latter
strictly stronger than the former: () the opponent should not learn the exact value of or
() the opponent should not deduce any information about . We give a small example
to illustrate: process .0 clearly violates both notions as is just sent on the network,
while process if =
then .0 clearly violates () as some information about is

actually leaked, in particular its equality with
, but () might still hold; for example if
is also secret then no intruder will be able to compute from the output . Property
() is usually called noninterference. For lack of space we will only focus on notion ().
Our denition of secrecy is in the style of [2]. A process preserves the secrecy of
a high condentiality name if cannot be computed by any opponent interacting with
. Notice that, whenever the opponent computes , he can also send it on a unrestricted
(public) channel. Of course the opponent should not know the secret in advance, for this
reason we only focus on secrets which are restricted names. For the sake of readability
we write the denition for channels of arity 1 (the extension to arity is immediate).
Denition 2 (Secrecy) preserves secrecy if, for all opponents , whenever
( : ) ( :

) (
) we have
C
()

C,
(), with = : , :

.
Notice that is always guaranteed to be a function thanks to implicit alpha renaming of
bound names. Intuitively, a process preserves secrecy if its names are always transmitted
on channels with at least the same condentiality level, even when interacting with an
arbitrary opponent . In particular, if is secret also the channel is required to be
secret, meaning it is one of the names in . Recall, in fact, that
C,
() returns for all
names not mapped by . Thus, if preserves secrecy then its secret names will never be
transmitted on unrestricted (public) channels.
As an example, process (d : HL) clearly breaks the secrecy of by sending
it on the unrestricted channel . Formally,
C
() =
=
C,
(), with
= d : HL. Process (b : HL) (d : HL) , instead, preserves secrecy.
Integrity. Formalizations of integrity in process calculi literature are, to the best of our
knowledge, not so common. We believe, however, that it is convenient to introduce a
formal denition of integrity at this point, as it will allow us to dually treat secrecy and
integrity guarantees provided by channels and cryptographic keys.
To formalize integrity we need to introduce the type C
] for channels at level

transporting data of type

. Since in the core calculus communication is symmetric, the
only interesting levels for channels are and , respectively representing trusted
and untrusted channels. We thus limit to those two levels and we let (C
]) = .
The notion of integrity is essentially dual to the one of secrecy: we require that any
data transmitted on a trusted channel in a position corresponding to high integrity data
will always be a high integrity name, i.e., a name originated from some trusted pro-
cess. Notice, to this purpose, that we have forbidden opponents to generate high integrity
names. The formal denition follows:
EMPTY

ENV
/ dom() = C
[

] implies =
, :
Table 3. Core calculus: well-formedness of .
Denition 3 (Integrity) preserves integrity if, for all opponents , whenever

( : C
HH
[
]) ( :

) (
) we have
I,
()

I
(
), with
= b : C
HH
[T
], a :

T.
We now give an example of a process which breaks the above property.
Example 1 Consider process ( : C
HH
[]) ((). ().). Intuitively, this
process reads from the untrusted channel a value and forwards it on the trusted chan-
nel . Since can be low integrity, this process violates the above property. Take, for
example, the opponent and the reduction:
( : C
HH
[]) ((). ().)
( : C
HH
[]) ((). (). )
( : C
HH
[]) ( (). 0)
( : C
HH
[]) (0 {/} 0)
In the last step, is sent on channel , which should only be used for transmitting high
integrity values, but is not restricted as it comes from the opponent: integrity does not
hold. Formally, this can be seen in process ( : C
HH
[]) ( (). 0) which
transmits over an unrestricted name . We have,
I,
() =
=
I
(), with
= b : C
HH
[LH].
2.2. A Core Type System
In this section we present a type system to statically enforce secrecy and integrity in the
pi-calculus.
Types and Environment. Our types are just levels (of the four point lattice) and channel
types, which we introduced above. Formally, type syntax is as follows:
::= C
] (1)
where is the type of data at such a level, and C
] is the type of channels at level

transporting data of type

. The typing environment is a set of bindings between
names/variables and their respective type . The well formedness of is dened by the
typing rules in Table 3. We require that does not contain multiple bindings for the same
value. Additionally, we only admit in (trusted) channels at level . As expected,
() = and (C
]) = .
Typing Terms. Types for terms are formalized in Table 4: they are the ones in plus the
ones derivable by subtyping. Intuitively, the subtyping relation
species when a
value of type can be used in place of a value of type
, thus making the type system

more permissive. Formally, is dened as the least preorder such that:
ATOM
: in
:
SUBSUMPTION
:

:
Table 4. Core calculus: typing of terms.
1

2
whenever
1

2
C
LL
[, . . . , ]
C
]
(2)
The rst condition means that rising the data security level is harmless.
C
LL
[, . . . , ] means that any untrusted data can be used as an untrusted channel
to transmit untrusted data. Since we forbid channels in , this is the only way an
untrusted channel can be typed. C
] means that channels can be considered as

generic data at their security level . For trusted channels this can never be reversed: once
a trusted channel is considered as a datum, it can never be used again as a channel. In
fact, . Notice that, as expected, subtyping respects the security level lattice.
Formally:
Remark 1 (Level Subtyping)
implies () (
).
Characterizing channel types. We point out some interesting properties for channel
types. First, if a term has a channel type of level , then this is precisely the type
specied in the typing environment, i.e., the channel type has not been derived via sub-
sumption. In fact, the only channel types derivable by subtyping are the ones at level
LL.
Proposition 1 (High Channels) : C
HH
[
] implies : C
HH
[
] is in .
Untrusted LL channels can only be used to transmit untrusted messages. This is a con-
sequence of the fact LL channels cannot be declared in and are only derived via sub-
sumption.
Proposition 2 (Low Channels) : C
LL
[
] implies

= LL, . . . , LL.
We also prove that LL and HH are the only admissible security levels for channels, i.e.,
channel types at level and are never derivable. This is a consequence of only
allowing HH channels and of only deriving LL ones.
Proposition 3 (Channel Levels) : C
] implies {LL, HH}.

Finally, a fundamental property of our type system is that the type of a channel of a given
arity is unique. This is a consequence of the three above results.
Corollary 1 (Uniqueness of Channel Types) If : C
] and : C
]
with
then C
] = C
].
The proof of these properties is simple and left as an exercise to the reader.
STOP

0
PAR

REPL

!
RES
, :
( : )
COND
: :

if = then else
IN
, :

: C
[

]
( ).
OUT

:

: C
[

]

.
Table 5. Core calculus: typing processes.
Typing Processes. Table 5 dictates how processes should deal with typed channels and
values. We use the concise notation

:

for denoting [1, ],
.
Rules STOP, PAR, REPL, RES and COND simply check that the subprocesses and terms
are well-typed under the same , enriched with : in case of RES. Intuitively, these
rules do not directly impose any restriction. The only interesting rules are, in fact, IN
and OUT which respectively state that terms received from and sent to the network are of
type

, as dictated by the channel type C
]. Notice that, since input binds the variables

, we add :

, i.e.,
1
:
1
, . . . ,
, in when typing the sequent process .

Example 2 Consider again process ( : C
HH
[]) ((). ().) of example 1.
We have seen it does not guarantee integrity, as data read from the untrusted channel
are forwarded on the trusted one . Intuitively, it does not type-check as is received as
LL (i.e., from the environment) and should be lowered to in order to be transmitted
over . Recall that we always assume free names such as to be of type LL, since they
can be thought of as under the control of the opponent. We let be : , : C
HH
[]
and we show that (). cannot be type-checked under . Notice, in fact, that after
type-checking the initial restriction, : C
HH
[] is added into . Notice also that, via
subsumption, from : and C
LL
[] we obtain : C
LL
[].
Formally, typing would proceed as follows (read it bottom-up):
IN
OUT
, : : : C
HH
[]
, : : C
LL
[]
().
The crucial part is that from : we can never prove : since .
The above example formally shows the importance of considering integrity levels contra-
variant, as previously discussed: a low-integrity variable can never be considered as high-
integrity. Below we will formally proof that typing ensures integrity, thus processes vio-
lating integrity, as the above one, can never type-check.
Example 3 Let us consider now a simple protocol where sends to a fresh mes-
sage of level HH on a channel of type C
HH
[HH]. The typing derivation for the process
modelling this protocol is shown below (rule names are omitted for lack of space):
: C
HH
[HH], : HH
: C
HH
[HH], : HH 0
: C
HH
[HH], : HH
: C
HH
[HH] ( : HH)
: C
HH
[HH], : HH
: C
HH
[HH], : HH 0
: C
HH
[HH] ()
: C
HH
[HH] ( : HH) ()
( : C
HH
[HH]) (( : HH) ())
Notice that the variable has type HH, so our type system guarantees that what is
received by is both at high condentiality and high integrity.
2.3. Properties of the Type System
The next lemmas state some standard properties of our type system. The strengthening
lemma states that removing from bindings relative to names not occurring free in the
judgment preserve typing. In fact, those names do not contribute in any way to derive the
judgment. We let fnfv() = and fnfv( : ) = fnfv() = {}. We write to
denote the three possible judgments , : and .
Lemma 1 (Strengthening) If , : and fnfv() then .
The weakening lemma states that extending preserves typing, as long as the extended
environment is well-formed. Intuitively, adding new (well-formed) bindings does not
compromise typing.
Lemma 2 (Weakening) and , : imply , : .
Finally, substituting variables with terms of the appropriate type has no effect on typing.
Lemma 3 (Substitution) If , : and : , then {/}.
Before proving that the type system enforces both secrecy and integrity, it is important to
show that it does not restrict opponents capabilities. Intuitively, an opponent is untyped
as it is not willing to follow any discipline we might want to impose to trusted, typed,
processes. However, our theorems are all based on typed processes. It is thus important
that the type-system is developed so to avoid any restriction on LL data and channels, so
that any opponent can be typed without actually restricting its capabilities. This is what
we prove:
Proposition 4 (Opponent typability) Let be an opponent and let fn() = { }. Then
: .
The proof of these properties is left as an exercise to the interested reader. We now
prove the fundamental result underlying type safety: typing is preserved by structural
congruence and reduction. Thanks to this result and to the previous proposition, we will
be guaranteed that when running a typed process in parallel with a (typed) opponent we
will always obtain a typed process. This will allow us to show that secrecy and integrity
are preserved at run-time.
Proposition 5 (Subject congruence and reduction) Let . Then
1. implies ;
2. implies .
Proof:
1. In order to deal with the symmetry of we prove a stronger fact: or
implies . We proceed by induction on the derivation of . We need the
following easy result:
implies . (3)
We just prove the interesting base cases (and their symmetric counterparts). The remain-
ing ones are all trivial and left as an exercise to the reader.
( : ) 0 0 We have ( : ) 0. This judgment can only be proved by RES,
which implies , : 0. By (3), , : . By Lemma 1 (Strengthening),
we obtain . Finally, by STOP, we get 0.
The result holds also for symmetric counterpart (i.e., 0 ( : ) 0), since we
can derive , : from by Lemma 2 (Weakening) and to conclude by
STOP and RES.
( : ) ( ) ( : ) if / () We know ( : ) ( ),
which implies , : and , : . By Lemma 1 (Strengthening), since
/ (), we get . By RES and PAR, we get ( : ) .
For the symmetric counterpart ( : ) ( : ) ( ), we have
and , : . By (3), we get , : . By Lemma 2 (Weakening), we
obtain , : . The thesis follows by PAR and RES.
( : ) ( :
) ( :
) ( : ) ( = ) The judgment ( : ) ( :
) can only be proved by RES, which implies , : , :
thus
, :
, : since is a set. Notice that the side condition = is crucial,

since we would otherwise have ( : ) ( :
) equivalent by -renaming (if

/ fn()) to ( : ) ( :
) {/} ( :
) ( : ) {/}, which is
equivalent, again by -renaming, to ( :
) ( : ) . This process would not

necessarily be well-typed since the type of has changed.
The remaining (inductive) cases are all trivial. For example, ,
is proved by noticing that and imply, by induction, that . From
, again by induction, we get the thesis . The symmetric counterparts of
these rules are the same as the original ones except that and are exchanged, so no
additional proof is needed.
2. The proof is by induction on the derivation of . Base cases RED COND 1 and 2
are trivially proved by observing that if = then else requires and
. Case RED I/O is proved by observing that Corollary 1 (Uniqueness of Channel
Types), IN, and OUT imply , :

and : C
] and

:

and
. By applying Lemma 3 (Substitution), we obtain {

/ } and, by PAR, we
get {

/ }.
The inductive cases are all trivial. We just mention that (RED STRUCT) is based on
item 1 of this lemma.
, , ::= terms
. . . as in Table 1
ek() encryption key
vk() verication key
{

}
s
sym encryption
{

}
a
asym encryption
[

]
digital signature
, , , ::= processes
. . . as in Table 1
case of { }
s
in sym decryption
case of { }
a
in asym decryption
case of [ ]
in signature check
Table 6. Syntax for cryptographic messages and cryptographic operations
Secrecy and Integrity by typing. We nally prove that well-typed processes preserve
secrecy and integrity.
Theorem 1 (Secrecy and Integrity for ) If : , then preserves both secrecy
and integrity.
Proof:
Let be an opponent. By Proposition 4 (Opponent typability) we have that fn() = { }
implies :

. Let fn() dom() = {
} be the free names of not occurring

in . Now let
= ,
: LL. From , we clearly have that
. By Lemma 2
(Weakening), we have that
and
. By PAR, we obtain
. We now
have two separate proofs for secrecy and integrity:
Secrecy Let
( : ) ( :

) (
). By Proposition 5 (Subject
congruence and reduction) we get
( : ) ( :

) (
) which implies
, : , :

.
, by repeatedly applying RES and nally by PAR.

Let
, : , :

. By rule OUT we necessarily have that
: C
] and
with
and thus
C
()

C
(
) by Remark 1 (Level Subtyping).

If
C
() = we have nothing to prove as we certainly have
C
()
C,:, :
(). Assume then

C
() = . This implies
C
(
) = . By Proposition 3
(Channel Levels), {LL, HH}, and by Proposition 2 (Low Channels) we are also
guaranteed that = HH since, otherwise,
would necessarily be LL. Then, Proposi-

tion 1 (High Channels) proves that : C
] is in
, thus also
C,:, :
() = ,
giving the thesis.
Integrity Let now
( : C
HH
[]) ( :

) (
). By Proposition 5
(Subject congruence and reduction) we get
( : C
HH
[]) ( :

) (
),
which implies
, : C
HH
[], :

.
, by repeatedly applying RES and nally

by PAR.
Let
, : C
HH
[], :

. Rule OUT requires
: C
] and
.
By Corollary 1 (Uniqueness of Channel Types), we obtain that C
] = C
HH
[], thus
=
. From
: we necessarily have that :
is in
with

and, by Remark 1 (Level Subtyping), (
) (). Notice that

I
() = implies
I
(
) = , as is the lowest possible level. Since

I,b:C
HH
[T
],a:
T
() =
I
(
) we
get the thesis.
Symmetric encryption
Asymmetric encryption ek()
Digital signature vk()
case

+ of
in {

/ } (DEC/CHECK)
Table 7. Semantics of cryptographic operations (extends Table 2)
3. Spi Calculus
Our study on types for cryptographic protocols is developed on a polyadic variant of
the spi-calculus [6]. This calculus extends the pi-calculus in order to explicitly reason
about protocols based on symmetric encryptions, asymmetric encryptions, and digital
signatures.
Syntax and semantics. We extend the syntax of the calculus by introducing () terms
that represent keys and ciphertexts and () processes that describe cryptographic oper-
ations, as shown in Table 6. Term ek() denotes the public encryption key correspond-
ing to the private key , and term vk() is the public verication key corresponding
to the signing key (hence has to be kept secret, while ek() and vk() can be
published); {

}
s
, {

}
a
, and [

]
denote, respectively, the symmetric and asym-

metric encryption and the digital signature of the tuple of terms

. Notice that we model
cryptographic schemes where encryption and verication keys can be recovered from the
corresponding decryption and signing keys, respectively. In other words, decryption and
signing keys can be seen as key-pairs themselves. We believe this approach provides a
more succinct theory but we could model as easily cryptographic schemes where neither
key can be retrieved from the other, as done for instance in the original presentation of
the spi-calculus [6].
In the following, we write to denote a name or a variable. It will also be con-
venient to write

to denote a generic encryption/signature term when its exact

nature is unimportant. We will also use the notation
+
and
to respectively de-
note encryption/signature keys and their decryption/verication counterparts, as speci-
ed in Table 7 together with the semantics of cryptographic operations. Intuitively, pro-
cess case of
in tries to decrypt or check the signature of with key
and behaves as {

/ } if it succeeds, i.e., when is

+, or gets stuck otherwise.

Example 4 Let us consider the Blanchet authentication protocol [11]. This protocol is
modelled in the spi-calculus as follows:
Protocol (
) (
) (Initiator Responder)
For the moment, let us ignore the typing annotations. We rst generate two fresh key
pairs for and , respectively, and then run the processes modelling the initiator and
the responder in parallel.
Initiator ( :
) {[, , ]
}
a
ek(
)
.(
).
case
of {
}
s
in 0
The initiator generates a fresh session key , signs and s identiers along with
, encrypts this signature with s encryption key, and outputs the resulting ciphertext
on the free channel , which represents the network. Hence waits for the response,
decrypts it using the session key , and concludes the protocol session. The process
modelling the responder is reported below:
Responder (
).case
of {
}
a
in case
of [
]
vk(
)
in
if =
then ( : HH) {}
s
The responder receives the challenge, decrypts the ciphertext and veries the enclosed
signature, checks that the rst signed message is her own identier, generates a fresh
message and sends it to the initiator encrypted under the received session key
4. Types and Integrity (Revised)

Types. We statically characterize the usage of cryptographic keys by extending the syn-
tax of types as follows:
::= . . . as in Equation 1 K
]
::= Sym Enc Dec Sig Ver
(4)
These types are close in spirit to the ones for channels. The type K
] describes keys
at security level that are used to perform cryptographic operations on terms of type
. Depending on the label , this type may describe symmetric, encryption, decryption,
signing, or verication keys.
Example 5 Let us consider the process illustrated in Example 4. Type
of the session
key is SymK
HH
[HH] as it is trusted ( = HH), symmetric ( = Sym) and transports
HH terms. The type
of s signing key
is SigK
HH
[LL, LL,
] and the type of

the corresponding (public) verication key vk(
) is VerK
LH
[LL, LL,
], since this
trusted, i.e., high integrity, key-pair is used to sign two LL identiers and a symmetric
session key of type
. The type
of s decryption key
is DecK
HH
[HH] and
the type of the corresponding encryption key ek(
) is EncK
LH
[HH]. This key-pair is
indeed used to encrypt a signature which is at high condentiality, since it contains a
secret key, and high integrity, since has generated it respecting all the types dictated
by the signing key.
Secrecy and Integrity. The denition of secrecy for cryptographic protocols is the same
as the one given in Section 2.1, i.e., the opponent should not be able to send high-
condentiality data on public channels. The integrity property, however, has to be revised
to take into account the cryptographic setting.
Intuitively, we say that is a high integrity term if it is either () a restricted name
bound to a high integrity type, as before, or () a ciphertext or a signature obtained from
a secure HH key, in which the integrity of the enclosed messages respects the integrity
level dictated by the key type. We achieve this by adapting the denition of
I,
() as
follows (as before, we focus on ciphertexts of arity 1, since the extension to an arbitrary
arity is immediate):
I,
() =
{
I
(()) whenever dom()
otherwise
I,
(ek()) =
I,
(vk()) =
I,
()
I,
(
+) =
if () = K
[] and
I,
()

I
()
otherwise
Intuitively, we want to ensure that high-integrity variables get replaced only by high-
integrity terms. This is formalized by the following denition, which extends Denition 3
(Integrity) so to deal with cryptographic operations.
Denition 4 (Integrity with Cryptography) preserves integrity if, for all oppo-
nents , whenever

( : C
HH
[]) ( :

) (
) or

(
+
: K
[]) ( :

) (
case
+ of
in
)
then
I,
()

I
() with = : C
HH
[],
+
: K
[], :

.
As already noticed, is always guaranteed to be a function thanks to the implicit alpha
renaming of bound names. The denition above considers only symmetric ciphertexts
and signatures, since
+
is required to be a name by restriction. Asymmetric ciphertexts
in general do not provide integrity guarantees, since they might have been generated by
the attacker. In the following, we will see that our type systemcan in some cases statically
determine whether or not a certain ciphertext comes from the attacker (for instance, if the
ciphertext was signed with a high-integrity key used to sign self-generated ciphertexts).
For the sake of simplicity, however, we preferred to exclude asymmetric ciphertexts from
the semantic denition of integrity, since we would otherwise need to explicitly annotate
decryptions that are supposed to be applied to high-integrity ciphertexts.
5. A Type System for Cryptographic Protocols
This section extends the type system studied in Section 2.2 to cryptographic protocols.
We take the fundamental ingredients of the type system for secrecy proposed by Abadi
and Blanchet in [3], showing how these ideas can be smoothly rened to also reason
about integrity properties.
Subtyping and Environment. Subtyping for keys is similar to the one for channels. For-
mally, the subtyping relation is dened as the least preorder such that:
. . . as in Equation 2
LL K
LL
[LL, . . . , LL]
K
]
(5)
EMPTY

ENV

/ dom() = K
[. . .], C
[. . .] = , {Sym, Dec, Sig}

, :

Table 8. Cryptographic calculus: well-formedness of
ENCKEY

: DecK
[

]

ek() : EncK
[

]
VERKEY

: SigK
[

]

vk() : VerK
[

]
SYMENC

: SymK
[

]
{

}
s
ASYMENC

: EncK
[

]
{

}
a
DIGSIG

: SigK
[

]
C
()

[

]
Table 9. Cryptographic calculus: extending Table 4 to keys and cryptography.

Keys of level can be used in place of terms of type and terms of type can be
used in place of keys of type K
[LL, . . . , LL]. We denote this extended subtyping
to distinguish it from the core one. As expected, the level of a key type is , i.e.,
(K
]) = . As for the core type system, we have:

Remark 2 (Level subtyping for
implies () (
).
The well-formedness of typing environments is dened in Table 8. Recall that we write
to denote a name or variable and we write
to denote the new type system. Since

encryption and verication keys are derived by their private counterparts, it is natural that
their types are also derived. We thus allow in only the types of symmetric, signing, and
decryption keys. As for channels, only trusted HH keys are kept in . Interestingly, as
we have already shown in the example, derived keys will assume more articulate levels
than just HH and LL, reecting their asymmetric nature.
Typing Terms. In Table 9 we give the typing rules for the new terms, namely derived
keys, encryptions and signatures. ENCKEY says that if a decryption key is of type
DecK
], then the corresponding encryption key ek() is of type EncK
]. No-
tice that the condentiality level is , since public keys are allowed to be known to the
attacker, while the integrity level is inherited from the decryption key; VERKEY does the
same for verication and signing keys.
Ciphertexts are typed by SYMENC and ASYMENC. Ciphertexts can be output on
public channels and consequently their condentiality level is . Their integrity level,
instead, is the one of the key. The type of encrypted messages

is required to be the
one specied in the type of key. Digital signatures are typed by DIGSIG. The only differ-
ence with respect to the encryption rules is that the obtained condentiality level is the
maximum of the condentiality levels of the signed messages

: these messages can be
reconstructed from a signature using the public verication key, thus it is important to
keep track of the condentiality level of what is signed.
SYM DEC

: SymK
[

] , :

case of { }
s
in
ASYM DEC

: DecK
[

] , :

I
() = , : LL
case of { }
a
in
SIGN CHECK

: VerK
[

] , :

C
() =
case of [ ]
in
NONCE CHECK

: :
in (
) ()
if = then
1
else
2
Table 10. Typing Rules for Processes
Characterizing Keys and Ciphertexts. We now review some important properties of
keys and ciphertexts. As we will see, these properties are very close, in spirit, to the
ones for channels (cf. section 2.2). As for high channels (Proposition 1), we show that
the type of trusted HH keys is always in , i.e., it can never be derived by a different
type. In fact, only LL and LH keys can be respectively derived via SUBSUMPTION or
ENCKEY/VERKEY.
Proposition 6 (High Keys for
: K
] implies : K
] in .
As for low channels (Proposition 2), keys of security level LL may only encrypt (or sign)
messages of type LL.
Proposition 7 (Low Keys for
: K
LL
[
] implies

= LL, . . . , LL.
Concerning the security level of keys, we have to make a distinction between private and
public keys. Similarly to channels (Proposition 3), private keys can only be derived by
ATOM or SUBSUMPTION, thus they can only assume levels LL and HH.
Proposition 8 (Private Keys for
) If
: K
] and {Sym, Sig, Dec}

then {LL, HH}.
Public encryption/verication keys can only be derived via SUBSUMPTION, ENCKEY or
VERKEY, but never from ATOM, from which the following result:
Proposition 9 (Public Keys for
) If
: K
] and {Enc, Ver} then

{LL, LH}.
Similarly to channels, the type of HH symmetric, decryption and signature keys is
unique. For LL such keys, instead, we are not guaranteed of the uniqueness of as un-
trusted keys can be indifferently used as symmetric, decryption and signature keys. The
transported type is instead guaranteed to be , . . . , . We could also prove that the
type of encryption and verication keys is unique if we x the level to be . In fact,
being them public, they can also be typed at level , reecting their asymmetric nature.
Since the latter property is not used in the proofs, we just state the former.
Proposition 10 (Uniqueness of Key Types for
) If
: K
] and
] with ,
{Sym, Sig, Dec} and
then =
and

=

. If
=
= HH, we also have =
.
Finally, we characterize the type of encrypted (or signed) messages. Their type is dic-
tated by the type of the private key, except for messages encrypted with asymmetric
keys, which may also be of type if the ciphertext is low-integrity, e.g., received on an
untrusted channel. In fact, the opponent can himself generate messages encrypted with
honest principals public keys. For signatures we are also guaranteed that their conden-
tiality level is greater than or equal to the maximum condentiality level of the signed
messages. This is important to preserve the secrecy of signed terms.
Proposition 11 (Payload Type for
) The following implications hold:

1.
{

}
s
: and
: SymK
] imply

:

.
2.
{

}
a
ek()
: and
: DecK
] imply

:

or
I
() =
and

: .
3.
[

]
: and
: SigK
] imply

:

and
C
(

C
().
Typing Processes. We nally extend the type system with the rules for processes per-
forming cryptographic operations, as shown in Table 10. SYM DEC says that processes
of the form case of { }
s
in , where is a symmetric key of type SymK
],
are well-typed if can be typed and is well-typed in an environment where variables
are given type

. This is sound since our type system guarantees that at run-time vari-
ables will only be replaced by values of type

. In fact, if the decryption succeeds, then
is a ciphertext of the form {

}
s
; since this term can only be typed by SYMENC

and has type SymK
], we know that

have types

.
ASYM DEC is close in spirit, but in the case of asymmetric cryptography we need
to take into account that the encryption key is known to the attacker and therefore the
ciphertext {

}
a
ek()
might come from the adversary meaning that

could be of type
LL. This might seem to be strange, since {

}
a
can only be typed by ASYMENC and
must have the type specied in the type of the encryption key ek(). However, ek()
can be given type EncK
] by ENCKEY as well as EncK
[LL, . . . , LL] via the

subtyping relation EncK
EncK
[LL, . . . , LL], which allows

the attacker to type public encryption (and verication) keys. Since we cannot always
statically predict if will be instantiated, at run-time, to values of type

or values
of type LL, we may have to type-check the continuation process twice, the rst time
under the assumption that the ciphertext comes from a honest participant, the second
time under the assumption that the ciphertext comes from the attacker. In contrast to the
type system proposed by Abadi and Blanchet in [3], where the continuation process is
type-checked twice in any case, in our type system this happens only if the ciphertext
is at low integrity, i.e.,
I
() = . As stated in Proposition 11 (Payload Type for
),
if the ciphertext is at high integrity, we know that the type of encrypted messages is
precisely the one specied in the key type and therefore we can simply type-check the
continuation process under this typing assumption. This shows how combining integrity
and condentiality properties increases the precision of the analysis allowing us, e.g.,
to type-check processes based on the encrypt-then-sign paradigm, where the integrity of
the ciphertext is guaranteed by digital signature. An application of this rule is shown in
Example 7.
SIGN CHECK is similar to SYM DEC but applies to processes performing the veri-
cation of a signature. The condition
C
() =
= is crucial for the soundness

of our type system that combines condentiality and integrity, since it avoids that pro-
cesses use keys to verify a signature that transports high condentiality data. In fact,
that would downgrade the level to compromising secrecy.
Finally, NONCE CHECK is an additional rule, borrowed from [3] and adapted to t
our subtyping relation, that is typically used to type equality checks involving a nonce.
Intuitively, since a name can never be equal to a term which is typed at a level
which is not greater than or equal to the one of , in such a case we can ignore the then
branch of the equality test and we do not need to type-check it. This rule allows us to
prune one of the typing branches introduced by ASYM DEC in the case the type of some
of the messages in the ciphertext sufces to determine that the ciphertext does not come
from the attacker. An application of this rule is illustrated in Example 8.
Example 6 We show that the Blanchet protocol of Example 4 and Example 5 is well
typed, i.e., : LL, : LL, : LL
Protocol. We will prove that this guarantees

secrecy and integrity of both the session key sent by to and the message sent by
to . In the following, we focus on the typing rules applied for proving this judgment
and illustrate how they modify the typing environment.
Rules Applied
Protocol
RES : LL, : LL, : LL (
: DecK
HH
[HH])
RES . . . ,
: DecK
HH
[HH] (
: SigK
HH
[LL, LL,
])
PAR . . . ,
: SigK
HH
[LL, LL,
] (Initiator Responder)
where
is SymK
HH
[HH]. The two restrictions just introduce the bindings
and
. The same is then used to independently type the initiator and the responder.
Rules Applied
Initiator
RES ( : SymK
HH
[HH])
OUT . . . , : SymK
HH
[HH] {[, , ]
}
a
ek(
IN (
)
ASYM DEC . . . ,
: LL case
of {
}
s
in 0
STOP . . . ,
: HH 0
In the initiator process, the restriction of the session key is typed by RES, which intro-
duces the type binding : SymK
HH
[HH]. The output of {[, , ]
}
a
ek(
)
is typed
by OUT: in order to apply this rule, we have to prove that [, , ]
is of type
(DIGSIG) and {[, , ]
}
a
ek(
)
is of type (ASYMENC) and thus by sub-
sumption. Notice that the ciphertext has to be given type since the type of in is in-
deed . The input of the response
is typed by IN, which introduces the type binding
: . The decryption of the ciphertext is typed by SYM DEC, which introduces the
type binding
: HH, since HH is the type transported by key . Process 0 is nally

typed by STOP.
Rules Applied
Responder
IN (
).
SYM DEC . . . ,
: LL case
of {
}
a
in
SIGN CHECK . . . ,
: LL / . . . ,
: case
of [
]
vk(
)
in
COND . . . ,
: LL,
: LL,
if =
then
RES ( : HH)
OUT . . . , : HH {}
s
In the responder process, the input of the challenge is typed by IN, which introduces the
type binding
: . The decryption of this message is typed by ASYM DEC: Since the

ciphertext is of low condentiality and we cannot statically determine if the ciphertext
originates from the attacker or not, we have to type the continuation process twice, under
the assumptions
: and
: . The two typing derivations are, however, the

same since
occurs only in the following signature check, which is typed by SIGN

CHECK independently of the type of
. This rule introduces the bindings
: ,
:
,
, as specied in the type of
. The equality test is typed by COND and the

generation of message by RES. We nally type-check process {}
s
by OUT,
showing that {}
s
is of type by ASYMENC and subsumption.

Example 7 As previously discussed, in our type system the process after an asymmetric
decryption has to be type-checked twice only if the ciphertext is at low integrity. If the
ciphertext is instead at high integrity, we type-check the continuation process only once,
with the type information specied in the key, thus gaining precision in the analysis. We
illustrate this technique on the following protocol:

[{}
a
ek(
)
]

{}
s

sends message , encrypted and then signed, to . forwards this message to ,
after encrypting it with a symmetric-key. The goal of this protocol is to guarantee the
condentiality and integrity of . Notice that the two messages constitute different, but
in a sense equivalent, cryptographic implementations of the (abstract) protocol shown in
Example 3, which is based on ideal secure pi-calculus channels.
For typing this protocol, we give
type DecK
[],
type SigK
[],
and the key shared between and type SymK
[]. Notice that ciphertext

{}
a
ek(
)
is typed at level since it has been generated with the high integrity en-
cryption key ek() of type EncK
[]. It can thus be signed with key
. The ob-
tained term is of type LH LL and can be sent on the network.
Intuitively, knows that this ciphertext comes from , since only knows the
signing key
and this key is only used in the protocol to sign encryptions of messages
of level . Our type-system elegantly deals with this form of nested cryptography by
giving the ciphertext {}
a
ek(
)
obtained after signature verication type , as spec-
ied in the vk(
) type VerK
[]. This allows us to give to decrypted message

type HH, as specied by the type of
. Notice that the high-integrity of the ciphertext,

achieved via digital signature, allows us to type-check the continuation process once,
with bound to the correct type HH. can thus encrypt with symmetric key of
type SymK
[]. In the type system presented in [3], this protocol would not type-
check since the process following the decryption would be type-checked a second time
with : LL. This would forbid the encryption with since LL HH.
Example 8 We now illustrate an interesting application of rule NONCE CHECK, which
allows us to prune one of the typing branches introduced by ASYM DEC, in case the
type of some of the decrypted messages sufces to determine that the ciphertext does not
come from the attacker. Let us consider the Needham-Schroeder-Lowe protocol:

,}
a
ek(
)
{
,}
a
ek(
)

{
}
a
ek(
)
For the sake of simplicity, our type system does not support types describing multiple
usages of the same key. For type-checking this protocol, we have thus to assume that the
rst and the third ciphertext are encrypted using two different keys ek(
) and ek(
).
encrypts a fresh nonce
with s public key and later receives a ciphertext

encrypted with his own public key containing
, s nonce
, and s identier.
Let the two nonces
be given type and s identier type . Suppose the

decryption of the second ciphertext binds these values to variables
, and
,
respectively. Notice now that typing the decryption of the second message requires to
type the continuation process twice, once with the expected payload types , ,
and once with types , , , to account for an encryption performed by the attacker.
After decryption, however, performs a nonce check by comparing
with
. By
rule NONCE CHECK, we prune the case of
having type , since and the type

of the nonce
are incomparable. Intuitively, the type system ensures that variables

of type can only be instantiated to values of type and therefore an equality
check between a name of type and a variable of type will always fail at run-time,
since .
Exercise 1 Model the Needham-Schroeder-Lowe protocol in the spi-calculus such that
the resulting process type-checks. Give the two nonces type and provide suitable
typing annotations for keys. (Hint: Pay attention to the type of
in the second encryp-

tion.)
Exercise 2 Extend the type system so to support multiple usages of the same key. This
can be done by introducing the following type:
K
1
+. . . +

]
This type describes keys used to encrypt tagged payloads msg
) of type

, which
is close in spirit to the tagged unions used in [23,24]. The calculus has to be ex-
tended with a term of the form {msg
(

)}
a
and a decryption primitive of the form

case of {msg
( )}
a
in , which checks at run-time that msg
is the tag of the

messages encrypted in .
Properties of the Type System. We leave as an exercise to the interested reader the
proof of strengthening, weakening, substitution, and opponent typability. We now prove
subject congruence and subject reduction.
Proposition 12 (Subject Congruence and Reduction for
) Let
. Then
1. implies
;
2. implies
.
Proof:
1. The proof of subject congruence is the same as the one of Proposition 5 (Subject con-
gruence and reduction)(1) as is unchanged and the typing rules for processes related
by are also unchanged.
2. For proving subject reduction, we have to consider the typing rules introduced in
Table 10 and the new reduction rules of Table 7.
For the NONCE CHECK rule, we know that
if = then
1
else
2
,

: , () =
, (
) (), and

2
. We prove that if =
then
1
else
2

1
, i.e., by RED COND 1 = , which immediately proves the
thesis since

2
. Let us assume by contradiction that = . Thus
: , and
() =
which imply
. By Remark 2 (Level subtyping for
), (
) (),
which contradicts our hypothesis (
) ().
We now consider the reduction rule of Table 7
case

+ of
in {

/ }
By hypothesis,
case

+ of
in . The three rules for proving this

judgment are SYM DEC, ASYM DEC and SIGN CHECK. They all require
+ :
and
: K
] and , :

, with = Sym, Dec, Ver, respectively. We

examine the three different cases:
Symmetric decryption. By Proposition 11 (Payload Type for
)(1), we have
:

. Since , :

, by the substitution lemma, we obtain
{

/ }, as
desired.
Asymmetric decryption. Rule ASYM DEC additionally requires variables to be typed
, i.e., , : LL
, when
I
() = . By Proposition 11 (Payload Type for
)(2),
we know that

:

or
I
() =

: LL. Since , :

and
, : LL
when
I
() = , in both cases we can apply the substitution lemma
and obtain
{

/ }, as desired.
Sign check. We cannot directly apply Proposition 11 (Payload Type for
)(3) since
= Ver, i.e.,
= vk() and
vk() : VerK
]. Proposition 9 (Public Keys

for
) tells us that {, }.
If = ,
vk() : VerK
] can only derive from VERKEY, which implies
: SigK
]. By Proposition 11 (Payload Type for
)(3) we have

:

. By
the substitution lemma, we obtain
{

/ }, as desired.
If, instead, = , by Proposition 7 (Low Keys for
) we must have

= LL, . . . , LL,
and the judgment might derive either from VERKEY or from SUBSUMPTION. Anyway,
at some point of the derivation of
vk() : VerK
] we know it has been

applied VERKEY as it is the only rule for typing term vk(). This implies
:
SigK
]. Thus, by Proposition 11 (Payload Type for
)(3) we have
and
C
() =
C
(
). Now recall that rule SIGN CHECK requires that

C
() =
implies
= . Since we have taken
= we know that
C
() = . From
C
() =
C
(
) we get
,
C
(
) = which implies (

and also
(since we always have
()). From
and
SUBSUMPTION we thus get

: LL. By the substitution lemma, we obtain
{/}, as desired.
Secrecy and Integrity of cryptographic protocols. The following lemma relates the pre-
viously dened semantic characterization of integrity to the notion of integrity captured
in the type system: the integrity level of a typed message is always bounded by the in-
tegrity level of its type. In particular, messages with a high integrity type are shown to be
at high integrity. In other words, the type system provides a sound overapproximation of
the integrity level of messages.
Lemma 4 (Integrity)
: implies
I,
()

I
().
The proof is left as an exercise to the reader. We can nally show that our type system
statically enforces secrecy and integrity.
Theorem 2 (Secrecy and Integrity for
) Let
with img() = {}. Then

preserves both secrecy and integrity.
Proof:
As for Theorem 1 (Secrecy and Integrity for ) we pick an opponent and we easily
show that by extending with the free names of which are missing we obtain a
such that
. The proof of secrecy follows exactly the one of Theorem 1

(Secrecy and Integrity for ). We thus focus on the integrity property. We rst consider
the following reduction:

(
+
: K
[]) ( :

) (
case
+ of
in
)
If
I
() = we have nothing to prove. Let thus
I
() = . By Proposition 12 (Subject
Congruence and Reduction for
)(2) we get
(
+
: K
[]) ( :

) (
case
+ of
in
)
Let
,
+
: K
[], :

. By repeatedly applying RES and nally by PAR
we have:
case
+ of
in
and
+ : for some .
Now notice that
+
must be an atomic term since it is restricted, i.e., it cannot be ek()
and thus
+ = {}
a
+
, and by
we have {Sym, Dec, Sig}. Thus,
+ : implies

+
:
], with
= Sym or
= Sig when
+ is a symmetric encryption or a digital signature, respectively.

Since

+
: K
[], Proposition 10 (Uniqueness of Key Types for
)
proves that =
, i.e., the in the restriction is coherent with the cryptographic opera-

tion. Therefore by Proposition 11 (Payload Type for
) we get
: . Lemma 4
(Integrity) nally gives
I,
()

I
().
The proof for the other reduction:

( : C
HH
[]) ( :

) (
)
follows exactly the same steps as the one of Theorem 1 (Secrecy and Integrity for )
to derive that
: . By Lemma 4 (Integrity) we directly obtain

I,
()
I
().
6. Authentication Protocols
In this section, we extend our type system in order to statically verify authentication
protocols. Following the terminology introduced in [15], these protocols enable a party,
called the claimant, to authenticate herself and possibly some messages with another
party, called the verier. In particular, we focus on a variant of the agreement prop-
erty [28] that is well-suited to reason about authentication in cryptographic protocols
based on nonce handshakes. The type system combines the main ideas of the type and ef-
fect systems for authentication protocols [23,24,30,15,8] with a more elegant formalism
borrowed from the type systems for authorization policies [21,10].
6.1. Authentication
In this chapter, we consider the strongest of the authentication denitions proposed by
Gavin Lowe in [28], namely agreement. Intuitively,
a protocol guarantees to a verier agreement with a claimant on a set of data
items if, whenever (acting as verier) completes a run of the protocol, appar-
ently with claimant , then has previously been running the protocol, apparently
with , and was acting as claimant in his run, and the two agents agreed on the data
values corresponding to all the variables in , and each such run of corresponds
to a unique run of .
In [28], the verier and claimant are called initiator and responder, respectively. This
property is formalized by annotating the point in the protocol where the claimant starts
the authentication session (begin assertion) and the point in the protocol where the veri-
er accepts the authentication request (end assertion). These annotations are also known
as correspondence assertions [38].
In this chapter, we focus on a variant of correspondence assertions introduced in
[15], which is well-suited to reason about authentication protocols based on nonce hand-
shakes. A nonce handshake is composed of two messages, the challenge sent by the
verier to the claimant and the response sent by the claimant to the verier. Both the
challenge and the response contain a random value (called nonce) freshly generated by
the verier: the nonce guarantees the freshness of the response, which entails the fresh-
ness of the authentication request. Of course, both the challenge and the response may
contain, possibly encrypted or signed, other messages as well.
The syntax of processes is extended as follows:
, , , ::= . . . (as in Table 6)
begin
(

;

) begin assertion
end
(

;

) end assertion
The begin and end assertions have three fundamental components: () the messages

sent in the challenge, () the messages

sent in the response, and () the nonce .
The agreement property is formalized as follows:
Denition 5 (Agreement) A process guarantees agreement if whenever ( :
) end
;

) , we have that begin
;

)
for some
and ( :

)
guarantees agreement.
Here and throughout this chapter we assume that replications are guarded and, in partic-
ular, they are never of the form ! with ( :

) end
;

) . Otherwise the
denition above would not be well-founded due to the unbounded number of top-level
end assertions possibly introduced in the process via structural equivalence. We rene the
notion of opponent by disallowing the presence of begin and end assertions. The former
would break opponent typability, while the latter would vacuously break the agreement
property even for safe protocols.
Denition 6 (Opponent) A process is an opponent if it contains neither begin nor
end assertions and all ( : ) occurring therein are such that = .
We are interested in processes that guarantee agreement in the presence of arbitrary op-
ponents. This property, called robust agreement, is stated below.
Denition 7 (Robust Agreement) A process guarantees robust agreement if for every
opponent and process such that
, guarantees agreement.
Example 9 Let us consider again the Blanchet protocol of Example 4. This protocol is
based on a nonce handshake between and , where sends in the challenge a fresh
session key that is used by to encrypt message in the response. We decorate the
code of the initiator as follows:
Initiator ( :
) {[, , ]
}
a
ek(
)
.(
).
case
of {
}
s
in end
(, ;
)
For the moment let us ignore the typing annotation. The end
(, ;
) assertion says
that concludes an authentication session where he has sent the two identiers and
in the challenge and received message
in the response. The session key guarantees

the freshness of the authentication request, since each authentication session relies on a
different key. In other words, in this protocol the session key plays the role of the nonce.
The process modelling the responder is reported below:
Responder (
).case
of {
}
a
in case
of [
]
vk(
)
in
if =
then ( : ) begin
; ) {}
s
The begin
; ) assertion says that conrms the reception of the identiers
and declares the intention to authenticate the message sent in the response.
The session key
received in the challenge is supposed to guarantee the freshness of

the authentication request.
, ::= fresh() Chal
(

) Resp
(

) =
::= . . . as in Equation 4
K
()
[ :

] (scope of , is

, fnfv(

) {, }, and .fresh()

)
::= :
::=
1
, . . . ,
Notation: dom(
1
, . . . ,
) = dom(
1
) . . . dom(
), dom( : ) = {}, dom() =

eff(
1
, . . . ,
) = eff(
1
) . . . eff(
), eff( : ) = , eff() = {}
types(
1
, . . . ,
) = types(
1
) . . . types(
), types( : ) = { : }, types() =
.
Table 11. Syntax of Types
6.2. Type System
Following [21,10], the typing environment is dened as a list of effects and type bindings.
The syntax of effects and types is shown in Table 11.
The effects are similar to the ones used in [30,15,8]. The effect fresh() witnesses
that is a fresh nonce, i.e., it is restricted and it does not occur in any of the active
end assertions. The effect Chal
(

) witnesses a challenge to authenticate messages

with a fresh nonce . In particular, if Chal
(

) belongs to the effect associated to a
particular protocol point, then we know that at run-time, whenever that protocol point is
reached, a party has sent (or is allowed to send) a challenge to authenticate

with nonce
. Similarly, the effect Resp
(

) witnesses a response to authenticate messages

with nonce . Finally, = witnesses that is equal to . Intuitively, the restric-

tion of nonce justies fresh() and Chal
(

). The latter justies a begin
(

;

)
assertion, which in turn justies Resp
(

). The effects fresh(), Chal
(

), and
Resp
(

) together justify the assertion end
(

;

), which annotates the end of a
challenge-response protocol based on nonce where

have been sent in the challenge
and

in the response.
We introduce the new key type K
()
[ :

] that, besides the type of encrypted
messages, describes their role in the challenge-response protocol. In particular, this type
describes keys of security level that are used to encrypt a tuple of type

such that
the effects

are justied. The scope of , is

, where is a binder for the (symmetric,
encryption, or verication) key itself. We require that key types are closed (i.e., they
do not contain free names or free variables) and do not contain fresh effects, since the
freshness of a nonce is an information that is just used locally to type-check the process
generating that nonce. In the following, we use K
] as an abbreviation for K
()
[ :
]. The subtyping relation is extended as expected:

. . . as in Equation 5
K
()
[ . . . . . . ]
K
()
[
1
: , . . . ,
: ]
Keys of level can be used in place of values of type and, conversely, values of type
can be used in place of keys that are supposed to encrypt messages for which
no effect is justied, i.e., without providing any authentication guarantee.
EMPTY

A-ENV

/ dom()
= C
[. . .], K
()
[ . . . . . . ] = , {Sym, Dec, Sig}
, :

A-EFF

fnfv() dom()
,

Table 12. Well-formedness of Environments
The typing rules for the well-formedness of environments are shown in Table 12.
A-ENV is the natural extension of ENV, while A-EFF says that an effect is well-formed
if its free names and variables are bound in the typing environment.
Example 10 Let us consider again the Blanchet protocol described in Example 9. The
types
and
of
and
are reported below:
DecK
[]
SigK
()
[
: ,
: ,
Chal
)]
SymK
()
[
: Resp
)]
The two key-pairs are not revealed to and do not come from the attacker, hence their
security level is . The type
says that the responders key pair is used by well-typed

parties only for encrypting messages at high condentiality and high integrity, that is the
signature generated by the initiator. The type
says that the initiators key pair is only

used to sign triples composed of two public and low integrity identiers
and
and a
session key
of type
and that the resulting signature constitutes a challenge from
to
in a handshake whose freshness is guaranteed by the freshness of the session key
. Finally, the type
says that the session key is condential and high-integrity, it is

only used to encrypt a secret and high-integrity message
, and the resulting ciphertext

constitutes a response to authenticate
in a handshake whose freshness is guaranteed

by the freshness of the session key itself.
Typing Terms. The typing rules for terms are reported in Table 13. These rules are
similar to the rules of Table 4. The main difference is that we check, before encrypting
with a key of type K
()
[ :

], that the effects

{

/ ,
/} occur in
the typing environment (cf. A-SYMENC, A-ASYMENC, A-SIGN). This is crucial for the
soundness of the type system since the type of the key allows us to statically transfer
effects from the sender to the receiver. As a matter of fact, the typing rules for decryption
and signature verication extend the typing environment with the effects indicated in the
key type. Notice that the key
replacing the variable is the key available to both the

sender and the receiver, i.e., the symmetric key, the encryption key, or the verication
key.
Characterizing Keys and Ciphertexts. We now see how the properties of keys and ci-
phertexts stated for type system
can be smoothly extended to type system
. We
rst extend Proposition 6 (High Keys for
) to dependent key types.

A-ATOM

: in

:
A-SUBSUMPTION

:
A-ENCKEY

: DecK
()
[ :

]

ek() : EncK
()
[ :

]
A-VERKEY

: SigK
()
[ :

]

vk() : VerK
()
[ :

]
A-SYMENC

: SymK
()
[ :

]

{

/ , /} eff()

{

}
s
A-ASYMENC

: EncK
()
[ :

]

{

/ , /} eff()

{

}
a
A-SIGN

: SigK
()
[ :

]

C
()

{

/ , vk()/} eff()

[

]
Notation:
1
, . . . ,
eff() iff [1, ],
eff().
Table 13. Typing Rules for Terms
Proposition 13 (High Keys for
: K
()
[ :

] implies :
K
()
[ :

] is in .
We then extend Proposition 7 (Low Keys for
) by stating that low-level keys do not

provide any authentication guarantees.
Proposition 14 (Low Keys for
: K
()
[ :

] implies

=
, . . . , and

= .
The next two lemmas are the direct counterpart of Proposition 8 (Private Keys for
)
and Proposition 9 (Public Keys for
).
Proposition 15 (Private Keys for
: K
()
[ :

] with
{Sym, Sig, Dec} implies {, }.
Proposition 16 (Public Keys for
: K
()
[ :

] with {Enc, Ver}
implies {, }.
An important property of our type system is that channels as well as private keys have a
unique type. Additionally, the typing of channels does not depend on effects.
Proposition 17 (Uniqueness of Channel types for
) If
: C
] and
: C
] with types() = types(
) and
then C
] = C
].
Proposition 18 (Uniqueness of Key Types for
) If
: K
()
[ :

] and

()
[ :

] with {Sym, Sig, Dec} and
then =
, and

=

. When =
= , we also have =
.
Finally, we characterize the type of encrypted (or signed) messages, in the same style as
). Notice that the effects in the key type must belong

to the typing environment used to type-check the ciphertext (or the signature).
) The following implications hold:

1. If
{

}
s
: and
: SymK
()
[ :

], then

:

and
{/,

/ } eff().
2. If
{

}
a
ek()
: and
: DecK
()
[ :

], then
and

{ek()/,

/ } eff(), or
I
() = and

: .
3. If
[

]
: and
: SigK
()
[ :

], then

:

and
{vk()/,

/ } eff() and
C
() =
C
().
Typing Processes The typing rules for processes are reported in Table 14. The main
difference with respect to the rules of Table 10 is the part related to the effects, since the
type bindings are managed in the same way.
A-STOP checks the well-formedness of the typing environment. A-PAR says that
the parallel composition is well typed in the typing environment if and are
well-typed in typing environments obtained from by partitioning the freshness effects.
This is crucial to ensure that each nonce is used in at most one end assertion. In addition,
the typing environment used to type-check also contains the response effects justied
by the top-level begin assertions in (and vice-versa). This technical detail is important,
since the begin assertions do not have a continuation process and the response effect
they justify has to be propagated to the processes in parallel composition. Function
returns the response atomic effects justied by the top-level begin assertions in but the
effects containing names restricted in . Function
returns the projection of to type

bindings and effects in .
A-REPL checks that the typing environment contains no fresh effects, since we want
to prevent multiple end assertions with the same nonce. A-RES says that the restriction
( : ) justies the effects Chal
(

), fresh() in the continuation process . Notice
that the type system is not syntax-directed since A-RES can add an arbitrary prex of
Chal
(

), fresh() to the typing environment and the

s are non-deterministically
chosen.
A-IN, and A-OUT do not modify the effects. A-SYMDEC, A-ASYMDEC, A-
SIGCHECK say that the decryption (or signature verication) case of
in
with a key of type K
()
[ :

] justies the effect

{
/, / } in the continuation
process , where, as discussed before,
is the key available to both the sender and the

receiver, i.e., the symmetric key, the encryption key, and the verication key, respectively.
A-COND type-checks the equality test if = then , justifying in the typing
environment of the continuation process the equality = . A-BEGIN type-checks the
begin assertion begin
(

;

), requiring that the terms

have indeed been received
in a challenge with nonce (i.e., Chal
(

) belongs to the typing environment). Sim-
ilarly, A-END type-checks the end assertion end
(

;

), requiring that the terms

have been sent in a challenge with nonce , the terms

have been received in a response
with nonce , and is fresh (i.e., the typing environment contains the effects Chal
(

),
Resp
(

), and fresh() as well as effects proving the equality between and ).
A-STOP

0
A-PAR
= eff()
= { eff() . = fresh()}

A-REPL

.fresh() eff()

!
A-RES
, : ,
Chal
(

), fresh()

( : )
A-IN
, :

: C
[

]

( ).
A-OUT

: C
[

]

.
A-SYMDEC

: SymK
()
[ :

] , :

,

{/, / }
case of { }
s
in
A-ASYMDEC

: DecK
()
[ :

]
, :

,

{ek()/, / }

I
() = , :
case of { }
a
in
A-SIGCHECK

: VerK
()
[ :

]
, :

,

{/, / }

C
() =
case of [ ]
in
A-COND

, =
if = then else
A-NONCE CHECK

: () =
) ()
if = then
1
else
2
A-BEGIN
Chal
(

) eff() fnfv(

) dom()
begin
(

;

)
A-END
=
fresh(), Chal
(

), Resp
(

) eff()
end
(

;

)
Notation:
= {Resp
(

) s.t. begin
(

;

)
}.
= ; (, : )
, : ; (, )
if / ; (, )
, if .

iff is a, possibly empty, prex of
.
=
is the smallest equivalence relation on terms such that if = then =
.
Table 14. Typing Rules for Processes.
Example 11 We prove that the Blanchet protocol is well typed, i.e., : , : , :

Protocol. In the following, we illustrate the typing derivation, focusing just on

the effects and omitting the type bindings, since the latter are exactly as in Example 6.
Rules Applied eff()
Protocol
A-RES (
)
A-RES (
)
A-PAR (Initiator Responder)
The two restrictions do not involve nonces, so they do not increase the effect.
Rules Applied eff()
Initiator
A-RES ( :
)
A-OUT fresh(), Chal
(, ) {[, , ]
}
a
ek(
A-IN (
)
A-SYMDEC case
of {
}
s
in
A-END . . . , Resp
) end
(, ;
)
In the initiator process, the restriction of the session key is typed by A-RES, which
introduces the effects fresh() and Chal
(, ). The output of {[, , ]
}
a
ek(
)
is
typed by A-OUT: in order to apply this rule, we have to prove that [, , ]
is of type
(A-SIGN) and {[, , ]
}
a
ek(
)
is of type (A-ASYMENC) and thus by
subsumption. This requires that Chal
(, ) belongs to the current typing environment,

since the signing key has type SigK
()
[
: ,
: ,
Chal
)].
The input of the response
is typed by A-IN, which does not change the effects. The

decryption of the ciphertext is typed by A-SYMDEC, which introduces the response
effect Resp
) obtained from the type SymK
()
[
: Resp
)] of the
session key after replacement of the variables and
by and
, respectively. Since
the typing environment contains the effects fresh(), Chal
(, ), and Resp
), the
assertion end
(, ;
) can be typed by A-END.

Rules Applied eff()
Responder
A-IN (
).
A-ASYMDEC case
of {
}
a
in
A-SIGCHECK case
of [
]
vk(
)
in
A-COND Chal
) if =
then
A-RES . . . , =
( : )
A-BEGIN begin
; )
A-OUT . . . , Resp
() {}
s
In the responder process, the input of the challenge and the decryption do not mod-
ify the effect. A-SIGCHECK introduces the effect Chal
), as specied in the
type VerK
()
[
: ,
: ,
Chal
)] of vk(
). The equality
test is typed by A-COND and the generation of the message to authenticate by A-RES.
Since the typing environment contains the effect Chal
), we can type-check
begin
; ) by A-BEGIN. Rule A-Par allows us to exploit the effect Resp
()
derived from the begin assertion when typing {}
s
. A-OUT is applied by showing

that {}
s
is of type (by A-ASYMENC and subsumption), which in turn requires

that the effect Resp
() belongs to the current typing environment.

Exercise 3 Model and type-check the Needham-Schroeder-Lowe protocol annotated as
follows:

{
,}
a
ek(
)
begin
(; , ek(
),
)
{
,}
a
ek(
)

end
(; , ek(
),
)
begin
(, ek(
),
; )
{
}
a
ek(
)
end
(, ek(
),
; )
These assertions model mutual authentication between and on the two nonces
and
. Notice that the public encryption key ek(
) takes the role of s identier in

the correspondence assertions, since s identier is not sent in the second message and
in our type system the dependent key types must be closed (i.e., the effects occurring
therein can solely depend on encrypted terms and encryption keys). In fact, in the second
ciphertext is identied via his own public key.
6.3. Properties of the Type System
We extend the strengthening lemma to effects by showing that removing duplicate ef-
fects as well as effects containing names or variables not occurring in preserves the
typability of .
Lemma 5 (Strengthening for
) The following properties hold:

1. If , : ,
and fnfv() fnfv(
), then ;
.
2. If , ,
and eff(,
), then ,
.
3. If , ,
and fnfv() fnfv(), then ,
.
The weakening lemma allows us to arbitrarily extend the typing environment as long as
we do not introduce fresh atomic effects. Extensions with fresh atomic effects would, for
instance, prevent us from type-checking replications.
Lemma 6 (Weakening for
) The following properties hold:

1. If ,
and , : ,
then , : ,
.
2. If ,
and , ,
and . = fresh() then , ,
.
The substitution lemma is stated below. Notice that the substitution applies also to the
typing environment because of dependent types and effects.
Lemma 7 (Substitution for
) If
: , then , : ,
implies
,
{/}
{/}.
The proofs of these properties and the proof of opponent typability are left as an exercise
to the interested reader. An important property of our type system is that removing fresh
effects from the typing environment does not affect the typing of terms. This property is
used in the proof of subject reduction.
Lemma 8 (Fresh and Terms) If , fresh(),
: then ,
: .
Proof:
By induction on the derivation of , fresh(),
: and in the proof of the A-

SYMENC, A-ASYMENC and A-SIGN cases by observing that, by syntactic restriction,
: K
()
[ :

] implies .fresh()

.
Finally, we show that type bindings and effects can be swapped as long as the well-
formedness of the typing environment is preserved.
Lemma 9 (Exchange) If , ,
and dom() fnfv(
) = , then
,
, ,
.
With this setup in place, we can nally prove subject congruence and subject reduction.
We have, however, to make an important change in the semantics of the calculus, i.e., we
remove rule ( : ) ( :
) ( :
) ( : ) from the denition of the

structural equivalence relation. When the type system is dependent, this rule is problem-
atic since
might depend on , thus breaking subject congruence. A common solution

to this problem is indeed to forbid the exchange of restrictions (see, e.g., [24,10]). An
alternative solution is possible when the type annotations capture all the dependencies
introduced in the typing environment: in this case, we can keep the rule and additionally
require / fn(
) (cf. [23]). This is not possible in our type system since the challenge
effects introduced by A-RES are not captured by the typing annotations.
Proposition 20 (Subject Congruence and Reduction for
) Let
. Then
1. implies
;
2. implies
.
Proof:
1. The only interesting case is when ( : ) ( ) ( : ) with / fn().
We have , : ,
, with
Chal
(

), fresh(), which can only be
proved by A-PAR. We thus have (, : ,
and (, : ,
, with
= eff(,
) and
= { eff(,
) . = fresh()}.
Since / fn(), by applying Lemma 5 (Strengthening for
) (3), we get
, ( : )
. Notice that ( : ) removes fromall the response effects

with occurrences of .
Since / fn() and thus / fn(), we can apply Lemma 9 (Exchange) to get
, , : ,
. By A-RES, we obtain
( : ) . By A-PAR,
we nally get
( : ) .
Conversely,
( : ) can only be proved by A-PAR, which implies
, ( : )
and
( : ) , with
= eff() and
= { eff() . = fresh()}.
The judgment
( : ) can only be proved by A-RES, which implies
, , : ,
, with
Chal
(

), fresh().
Since / fn(), we have / fn(). Therefore, by Lemma 9 (Exchange), we also
have
, : ,

Since / fn(), we can apply Lemma 6 (Weakening for
) to add : and
Chal
(

) and ( : ) to the typing environment used to type-check , thus
obtaining
, : ,
{Chal
(

)}
,
from
, ( : )
.
Notice that fresh() is possibly used for typing , but it is not used when typing
. We can therefore apply A-PAR to get , : ,
. By A-RES, we nally
obtain
( : ) .
2. The proof is by induction on the derivation of and by case analysis of the last
applied rule. We prove the interesting cases below:
(RED RES) Straightforward, by A-RES and induction hypothesis.
(RED PAR) We know that is derived from and we have
. This typing judgment can only be proved by A-PAR, which implies
and
with
= eff() and
= {
eff() . = fresh()}.
By induction hypothesis,
. By an inspection of rule A-BEGIN and

by observing that
implies , we can easily see that and

fn() dom(). By Lemma 6 (Weakening for
), we get
. By
A-PAR, we nally obtain
.
RED I/O We have

. ( ). {

/ } and

. ( )..
Since this typing judgment can only by proved by A-PAR and

. =
( ). = , we have

. and
( )..
By A-Out, we must have

:

with
: C
] and
.
By A-IN and Proposition 17 (Uniqueness of Channel types for
), we must have
: C
] and
, :

.
Since
= { eff() . = fresh()} and
, by Lemma 8 (Fresh and Terms) and Lemma 6 (Weakening for
) we obtain

:

. By Lemma 7 (Substitution for
),
{

/ }.
As before, we can see that fn() dom() and fnfv() dom(). By Lemma 6
(Weakening for
), we get
and
{

/ }. By PAR,
we get
{

/ }.
(RED DEC/CHECK) We have case

+ of
in {

/ }.
By hypothesis,
case

+ of
in . The three rules for prov-

ing this judgment are A-SYMDEC, A-ASYMDEC and A-SIGCHECK. They all
require
+ : and
: K
()
[ :

] and , :
,

{
/, / }
, with = Sym, Dec, Ver and
= ,
+
,
, re-
spectively.
We examine in detail the case of symmetric decryption, which follows similarly
to the corresponding case in the proof of Proposition 12 (Subject Congruence and
Reduction for
). The proof for the other cases is similar.

Symmetric decryption By Proposition 19 (Payload Type for
)(1), we have

:

and

{/,

/ } eff().
Since , :

,

{
/, / }
, by Lemma 7 (Substitution for
) we
obtain ,

{/,

/ }
{

/ }.
Since

{/,

/ } eff(), by Lemma 5 (Strengthening for
) (2) we obtain

{

/ }.
We can nally state the main result of our analysis technique, i.e., well-typed processes
guarantee robust agreement.
Theorem 3 (Robust Agreement) Let
with img() = {}. Then guaran-

tees robust agreement.
Proof:
We have to prove that for every and opponent such that
, guarantees
agreement.
As for Theorem 1 (Secrecy and Integrity for ), we can show that by extending
with the free names of that are missing we obtain a
such that
.
By Proposition 20 (Subject Congruence and Reduction for
), we have
.
If ( :

) end
(

;

)
, then Chal
(

), Resp
(

) and fresh() belong
to the typing environment used to type-check the end assertion (cf. rule A-END). The
presence of the fresh effect implies . The presence of the response effect implies
begin
;

)
for some

. We must have that Chal
) belongs
to the typing environment used to type-check the begin assertion. Since the s are pair-
wise distinct (otherwise the typing environment used to type-check the end assertion
would not be well-formed), we have that the two challenge effects derive from the same
restriction and are thus the same, implying

=

.
We also know that there are no other occurrences of end
(

;

) in
, since each
of them would require a typing environment containing fresh(), but the typing rule for
parallel composition requires that the typing environments of the two parallel processes
do not share any single fresh effect. This implies that guarantees agreement.
Exercise 4 Extend the type system with dependent channel types of the form C
()
[ :
] and show that such an extension preserves the properties studied in this section.
References
[1] M. Abadi. Secrecy by typing in security protocols. Journal of the ACM, 46(5):749786, 1999.
[2] M. Abadi and B. Blanchet. Secrecy types for asymmetric communication. In Proc. 4th International
Conference on Foundations of Software Science and Computation Structures (FOSSACS), volume 2030
of Lecture Notes in Computer Science, pages 2541. Springer, 2001.
[3] M. Abadi and B. Blanchet. Secrecy types for asymmetric communication. In Proc. 4th International
Conference on Foundations of Software Science and Computation Structures (FOSSACS), volume 2030
of Lecture Notes in Computer Science, pages 2541. Springer-Verlag, 2001.
[4] M. Abadi and B. Blanchet. Secrecy types for asymmetric communication. Theoretical Computer Sci-
ence, 298(3):387415, 2003.
[5] M. Abadi and B. Blanchet. Analyzing security protocols with secrecy types and logic programs. Journal
of the ACM, 52(1):102146, 2005.
[6] M. Abadi and A. D. Gordon. A calculus for cryptographic protocols: The spi calculus. Information and
Computation, 148(1):170, 1999.
[7] A. Askarov, D. Hedin, and A. Sabelfeld. Cryptographically-masked ows. Theoretical Computer Sci-
ence, 402(2-3):82101, August 2008.
[8] M. Backes, A. Cortesi, R. Focardi, and M. Maffei. A calculus of challenges and responses. In Proc.
5th ACM Workshop on Formal Methods in Security Engineering (FMSE), pages 101116. ACM Press,
2007.
[9] M. Backes, C. Hritcu, and M. Maffei. Type-checking zero-knowledge. In 15th ACM Conference on
Computer and Communications Security (CCS 2008), pages 357370. ACM Press, 2008.
[10] J. Bengtson, K. Bhargavan, C. Fournet, A. D. Gordon, and S. Maffeis. Renement types for secure
implementations. In Proc. 21th IEEE Symposium on Computer Security Foundations (CSF), pages 17
[11] B. Blanchet. Automatic verication of security protocols: formal model and computational model, 2008.
Habilitation thesis.
[12] C. Bodei, M. Buchholtz, P. Degano, F. Nielson, and H. R. Nielson. Static validation of security protocols.
Journal of Computer Security, 13(3):347390, 2005.
[13] M. Bugliesi, R. Focardi, and M. Maffei. Authenticity by tagging and typing. In Proc. 2nd ACM Work-
shop on Formal Methods in Security Engineering (FMSE), pages 112. ACM Press, 2004.
[14] M. Bugliesi, R. Focardi, and M. Maffei. Analysis of typed-based analyses of authentication protocols.
In Proc. 18th IEEE Computer Security Foundations Workshop (CSFW), pages 112125. IEEE Computer
Society Press, 2005.
[15] M. Bugliesi, R. Focardi, and M. Maffei. Dynamic types for authentication. Journal of Computer Secu-
rity, 15(6):563617, 2007.
[16] M. Centenaro and R. Focardi. Information ow security of multi-threaded distributed programs. In
ACM SIGPLAN PLAS08, pages 113124, June 8 2008.
[17] M. Centenaro, R. Focardi, F. Luccio, and G. Steel. Type-based Analysis of PIN Processing APIs. In
14th European Symposium on Research in Computer Security (ESORICS09), LNCS, September 2009.
To appear.
[18] P. Cousot and R. Cousot. Abstract interpretation: a unied lattice model for static analysis of programs
by construction or approximation of xpoints. In Proc. 4th Symposium on Principles of Programming
Languages (POPL), pages 238252. ACM Press, 1977.
[19] R. Focardi and M. Maffei. Types for security protocols. Technical Report CS-2010-3, Univer-
sity of Venice, 2010. Available at http://www.lbs.cs.uni-saarland.de/resources/
types-security.pdf.
[20] C. Fournet, A. D. Gordon, and S. Maffeis. A type discipline for authorization policies. In Proc. 14th
European Symposium on Programming (ESOP), Lecture Notes in Computer Science, pages 141156.
Springer-Verlag, 2005.
[21] C. Fournet, A. D. Gordon, and S. Maffeis. A type discipline for authorization in distributed systems. In
Proc. 20th IEEE Symposium on Computer Security Foundations (CSF), pages 3145. IEEE Computer
Society Press, 2007.
[22] C. Fournet and T. Rezk. Cryptographically sound implementations for typed information-ow security.
In POPL08, pages 323335. ACM Press, 2008.
[23] A. D. Gordon and A. Jeffrey. Authenticity by typing for security protocols. Journal of Computer
Security, 11(4):451519, 2003.
[24] A. D. Gordon and A. Jeffrey. Types and effects for asymmetric cryptographic protocols. Journal of
Computer Security, 12(3):435484, 2004.
[25] A. D. Gordon and A. Jeffrey. Secrecy despite compromise: Types, cryptography, and the pi-calculus. In
Proc. 16th International Conference on Concurrency Theory (CONCUR), volume 3653, pages 186201.
Springer-Verlag, 2005.
[26] C. Haack and A. Jeffrey. Timed spi-calculus with types for secrecy and authenticity. In Proc. 16th
International Conference on Concurrency Theory (CONCUR), volume 3653, pages 202216. Springer-
Verlag, 2005.
[27] P. Laud. On the computational soundness of cryptographically masked ows. In POPL08, pages 337
348. ACM Press, January 10-12 2008.
[28] G. Lowe. A Hierarchy of Authentication Specications. In Proc. 10th IEEE Computer Security
Foundations Workshop (CSFW), pages 3144. IEEE Computer Society Press, 1997.
[29] M. Maffei. Tags for multi-protocol authentication. In Proc. 2nd International Workshop on Security
Issues in Coordination Models, Languages, and Systems (SECCO 04), Electronic Notes on Theoretical
Computer Science, pages 5563. Elsevier Science Publishers Ltd., 2004.
[30] M. Maffei. Dynamic Typing for Security Protocols. PhD thesis, Universita Ca Foscari di Venezia,
Dipartimento di Informatica, 2006.
[31] R. Milner. The polyadic pi-calculus: a tutorial. In Logic and Algebra of Specication, pages 203246,
1993.
[32] J. Morris. Protection in programming languages. Communications of the ACM, 16(1):1521, 1973.
[33] F. Nielson, H. R. Nielson, and C. Hankin. Principles of Program Analysis. Springer, 1999.
[34] A. Sabelfeld and A. Myers. Language-based information-ow security. IEEE Journal on Selected Areas
in Communications, 21(1):519, January 2003.
[35] E. Sumii and B. Pierce. A bisimulation for dynamic sealing. Theoretical Computer Science, 375(1-
3):169192, 2007.
[36] E. Sumii and B. C. Pierce. Logical relations for encryption. Journal of Computer Security, 11(4):521
554, 2003.
[37] J. Vaughan and S. Zdancewic. A cryptographic decentralized label model. In IEEE Symposium on
Security and Privacy, pages 192206. IEEE Computer Society, 2007.
[38] T. Y. C. Woo and S. S. Lam. A lesson on authentication protocol design. Operation Systems Review,
28(3):2437, 1994.
Protocol Composition Logic
Anupam DATTA
a
, John C. MITCHELL
b
, Arnab ROY
c
and
Stephan Hyeonjun STILLER
b
a
CyLab, Carnegie Mellon University
b
Department of Computer Science, Stanford University
c
IBM Thomas J. Watson Research Center
Abstract. Protocol Composition Logic (PCL) is a logic for proving authentication
and secrecy properties of network protocols. This chapter presents the central con-
cepts of PCL, including a protocol programming language, the semantics of pro-
tocol execution in the presence of a network attacker, the syntax and semantics of
PCL assertions, and axioms and proof rules for proving authentication properties.
The presentation draws on a logical framework enhanced with subtyping, setting
the stage for mechanizing PCL proofs. and gives a new presentation of PCL se-
mantics involving honest and unconstrained principals. Other papers on PCL pro-
vide additional axioms, proof rules, and case studies of standardized protocols in
common use.
1. Introduction
Protocol Composition Logic (PCL) [5,6,7,8,9,10,11,12,17,18,23,38,39] is a formal logic
for stating and proving security properties of network protocols. The logic was originally
proposed in 2001 and has evolved over time through case studies of widely-used proto-
cols such as SSL/TLS, IEEE 802.11i (WPA2), and variants of Kerberos. In typical case
studies, model checking [31,30,36] is used to nd bugs in a protocol design. After bugs
found using model checking are eliminated, PCL can be used to nd additional problems
or prove that no further vulnerabilities exist. While model checking generally only ana-
lyzes protocol execution up to some nite bound on the number of protocol participants,
PCL is designed to reason about the unbounded set of possible protocol executions.
While the version of PCL considered in this chapter is based on a symbolic computation
model of protocol execution and attack, variants of PCL have been developed and proved
sound over conventional cryptographic computational semantics [11,12,37,38,40].
The central research question addressed by PCL is whether it is possible to prove
properties of practical network security protocols compositionally, using direct reason-
ing that does not explicitly mention the actions of a network attacker. Intuitively, direct
reasoning means that we draw conclusions about the eect of a protocol from the in-
dividual steps in it, without formulating the kind of reduction argument that is used to
derive a contradiction from the assumption that the protocol is vulnerable to attack. For
example, an axiom of PCL says, in eect, that if a principal creates a nonce (unguessable
random number), and another principal receives a message containing it, then the rst
principal must have rst sent a message containing the nonce.
IOS Press, 2011
doi:10.3233/978-1-60750-714-7-182
182
The PCL assertions about protocols are similar to Hoare logic [24] and dynamic
logic [21], stating before-after conditions about actions of one protocol participant. In
conventional terminology adopted by PCL, a thread is an instance of a protocol role
executed by a principal, such as Alice executing the client role of SSL. The PCL formula
[actseq]
T
states that if thread T starts in a state where precondition is true, then
after actions actseq are executed by T, postcondition must be true in any resulting
state. While this formula only mentions the actions actseq of thread T, states which
are reached after T executes actseq may arise as the result of these actions and any
additional actions performed by other threads, including arbitrary actions by an attacker.
PCL preconditions and postconditions may include any of a number of action pred-
icates, such as Send(T, msg), Receive(T, msg), NewNonce(T, msg), Dec(T, msg
encr
, K),
Verify(T, msg
signed
, K), which assert that the named thread has performed the indicated
action. For example, Send(T, msg) holds in a run if thread T sent the term msg as a mes-
sage. One class of secrecy properties can be specied using the predicate Has(T, msg),
which intuitively means that msg is built from constituents that T either generated or re-
ceived in messages that do not hide parts of msg from T by encryption. One formula that
is novel to PCL is Honest(Pname), which asserts that all actions of principal Pname are
actions prescribed by the protocol. Honest is used primarily to assume that one party has
followed the prescribed steps of the protocol. For example, if Alice initiates a transaction
with Bob and wishes to conclude that only Bob knows the data she sends, she may be
able to do so by explicitly assuming that Bob is honest. If Bob is not honest, Bob may
make his private key known to the attacker, allowing the attacker to decrypt intercepted
messages. Therefore, Alice may not have any guarantees if Bob is dishonest.
In comparison with a previous generation of protocol logics such as BAN logic [4],
PCL was also initially designed as a logic of authentication. Furthermore, it involves an-
notating programs with assertions, does not require explicit reasoning about the actions
of an attacker, and uses formulas for freshness, for sending and receiving messages, and
for expressing that two agents have a shared secret. In contrast to BAN and related logics,
PCL avoids the need for an abstraction phase because PCL formulas contain the proto-
col programs. PCL also addresses temporal concepts directly, both through modal formu-
las that refer specically to particular points in the execution of a protocol, and through
temporal operators in pre- and post-conditions. PCL is also formulated using standard
logical concepts (predicate logic and modal operators), does not involve jurisdiction
or belief, and has a direct connection with the execution semantics of network proto-
cols that is used in explicit reasoning about actions of a protocol and an attacker, such as
with Paulsons inductive method [34] and Schneiders rank function method described
in Chapter Security analysis using rank functions in CSP and [42].
An advantage of PCL is that each proof component identies not only the local
reasoning that guarantees the security goal of that component, but also the environmental
conditions that are needed to avoid destructive interference from other protocols that
may use the same certicates or key materials. These environment assumptions are then
proved for the steps that require them, giving us an invariant that is respected by the
protocol. In formulating a PCL proof, we therefore identify the precise conditions that
will allow other protocols to be executed in the same environment without interference.
In this book chapter, we explain the use of PCL using the simplied handshake
protocol used in other chapters. We present PCL syntax and its symbolic-execution se-
mantics in a semi-formal way, as if we were encoding PCL in a logical framework. The
A. Datta et al. / Protocol Composition Logic 183
A B :
_
A, B, k
sk(A)
_
a
pk(B)
B A : s
s
k
Figure 1. Handshake protocol, in arrows-and-messages form
logical framework we use is a typed language of expressions which includes a form of
subtyping that allows us to make implicit conversions between related types. For exam-
ple, dierent types of keys are subtypes of the type key of all keys. While PCL includes
formal axioms and proof rules for proving properties of protocols, there is a portion of
the logic (the entailment relation between precondition/postcondition formulas) that is
not formalized. However, when PCL is encoded in a logical framework, this unformal-
ized portion of PCL is handled by the underlying logic of the logical framework. Finally,
it should be noted explicitly that PCL is a logical approach that has been developed in
dierent ways in dierent papers, as part of both a basic research project to nd eective
ways of proving properties of protocols, and as part of an ongoing eort to carry out case
studies on practical protocols, each of which may require dierent cryptographic func-
tions or make dierent infrastructure assumptions. Therefore, this chapter is intended to
explain PCL, show how its syntax and semantics may be dened, describe representative
axioms and proof rules, and show how they are used for sample protocols. This chapter
is not a comprehensive presentation of all previous work on PCL or its applications.
2. Example
2.1. Sample protocol
The running example protocol used in this book is a simple handshake protocol between
two parties. This is shown using a common arrows-and-messages notation in Figure 1.
Note that we use msg
K
for the digital signature of msg with the signing key K. For
protocols that assume a public-key infrastructure, we write pk (Alice) for Alices pub-
lic encryption key, dk (Alice) for the corresponding private key known only to Alice,
sk (Alice) for Alices private signing key, and vk (Alice) for the corresponding publicly
known signature verication key. When needed, (m
1
, . . . , m
n
) is a tuple of length n.
As discussed in other chapters, this protocol is vulnerable to attack if the identity
of the intended responder, B, is omitted from the rst message. We will focus on the
corrected protocol because the primary purpose of PCL is to prove security properties of
correct protocols. However, we will also discuss how the proof fails if B is omitted from
the rst message. The way that the proof fails for an insecure protocol can often be used
to understand how the protocol may be vulnerable to attack.
2.2. Expressing the protocol in PCL
Since PCL is a logic for proving the correctness of a protocol from its denition, we must
express the protocol explicitly, with enough detail to support a rigorous proof. In PCL,
we express the protocol as a set of programs, in a high-level language, one program for
each participant in the protocol.
The PCL proof system allows us to reason about each program, called a protocol
role, individually and to combine properties of dierent roles. Because each of the opera-
tions used to construct, send, receive, or process an incoming message may be important
to the correctness of a protocol, we represent each of these steps as a separate action.
One way to understand why a more detailed representation of the protocol is needed
is to look back at Figure 1, and think about what is clear from the gure itself and what
needs to be claried in English. For example, the English description says, the initiator
A creates a fresh session key k, but there is nothing in Figure 1 that indicates whether k
is created by A, or known previously to both parties. The same gure would be used for
a protocol in which A and B both know k in advance and B only accepts the rst message
if the shared value k is sent. Part of the rigor of PCL is that we use a precise protocol
language that unambiguously determines the set of possible protocol runs.
The handshake protocol in Figure 1 has two roles, the Init role for the initiator
and the Resp role for responder in the protocol. These roles are written out in detail
in Figure 2. While we will later introduce syntactic sugar that simplies some of the
notation, Figure 2 shows every cryptographic action and every step in the construction
and manipulation of each message explicitly. Instead of assuming that a received message
has a specic format, for example, the responder role uses projection functions (
1
,
2
,
. . . ) on tuples to separate a message into parts.
For clarity, we write many actions in the form oc := exp, where the form on the
right-hand side of the assignment symbol := determines the value stored in location oc.
The assignable locations used in a role are local to that role, but may be used to compute
values sent in messages. We write !oc for the value stored in location oc. Since all of
our roles are straight-line programs, it is easy to choose locations so that each location
is assigned a value only once in any thread; in fact we make this a requirement. This
single-assignment requirement simplies reasoning about a protocol role.
For each pair of principals A and B, the program executed by initiator A to commu-
nicate with intended responder B is the sequence of actions Init(A, B) shown in Figure 2.
In words, the actions performed by the initiator are the following: choose a new nonce
and store it in local storage location k, sign the message (A, B, !k) containing the princi-
pal names A and B, and send the encryption of this message. Because digital signatures
do not provide condentiality, we assume that there is a function unsign that returns the
plaintext of a signed message. In this handshake protocol, the receiver uses parts of the
plaintext to identify the verication key of the sender and verify the signature. We call a
principal executing a role a thread.
If principal B executes the responder role Resp(B), the actions of the responder
thread are exactly the actions given in Figure 2. Specically, the responder thread re-
ceives a message enca that may be an encrypted message created by an initiator thread.
In order to determine whether the message has the correct form to be an initiators mes-
sage, the responder decrypts the message with its private decryption key dk (B) and then
extracts the plaintext from what it expects to be a signed message. If decryption fails, or
if the result of decryption does not have the correct form to have the plaintext removed
from a signed message, then the thread stops at the action that fails and does not pro-
ceed further. If possible, the responder thread then retrieves the rst, second, and third
components of the triple that is the message plaintext, and veries the digital signature
using the principal name A sent in the message. If the signature veries, and the sec-
ond component of the plaintext tuple matches the responders principal name, then the
responder generates a new nonce s, encrypts it under k, and sends the result. An assert
Init(A, B : principal_name) =
k :=newnonce;
siga :=sign (A, B, !k), sk (A) ;
enca :=enc !siga, pk (B) ;
send !enca;
encb :=receive;
s :=sd !encb, !k;
Resp(B : principal_name) =
enca :=receive;
siga :=dec !enca, dk (B) ;
texta :=unsign !siga;
idA:=
1
!texta;
idB:=
2
!texta;
k:=
3
!texta;
assert: !texta=(!idA, !idB, !k);
verify !siga, vk (!idA) ;
assert: !idB=B;
s :=newnonce;
encb :=se !s, !k;
send !encb;
Figure 2. Explicit presentation of handshake protocol

action assert: msg =msg
, such as the one used to check idB, succeeds only if the two
messages are equal.
Roles are typically parameterized by the names of principals relevant to execution
of the role, such as parameters A and B in Figure 2. When a role is dened, the rst
argument is treated as the principal who executes the role. The dierence between the
rst parameter and the other parameters is that private keys associated with the rst
parameter may be used in the actions of the role. Technically, the information available
to each role is limited to its role parameters, values explicitly named in the role, and the
result of applying allowed key functions such as dk(), which names a private decryption
key. Visibility to key functions is determined by a part of the protocol denition called its
setup assumptions. Our formalization of setup assumptions is described in Section 3.1.
While Figure 2 is completely precise, it is sometimes convenient to adopt abbre-
viations and notational conventions that make the roles easier to read. For example,
Figure 3 uses a few syntactical simplications to dene the same roles as Figure 2.
Specically, we use a pattern-matching form (idA, idB, k) :=texta to set three loca-
tions to the three components of a tuple, as abbreviation for the three assignments us-
ing projection functions given in Figure 2 and the subsequent structural assertion that
texta is a tuple of arity 3. We also omit ! and write oc instead of !oc in expressions.
Since all identiers are typed, and the type of locations is dierent from other types,
this is unambiguous; occurrences of ! can always be inserted mechanically based on the
types of expressions. Some papers on PCL use a form match texta as (A, B, k)
that combines structural checks and assignment. While succinct, a potentially confus-
ing aspect of match is that its eect depends on the context: because A and B are pre-
viously dened, this example match is an assert about them, while because k is not
previously dened, the example match sets k to the third component of texta. Thus,
writing match texta as (A, B, k) in the middle of Resp(B) would be equivalent to
assert:
1
texta = A; assert:
2
texta = B; k :=
3
texta, together with a structural as-
sertion for checking the arity of texta (see above). For simplicity, we will avoid match
in this presentation of PCL, although protocols written using match may be understood
using this presentation of PCL as just explained.
Init(A, B : principal_name) =
k :=newnonce;
siga :=sign (A, B, k), sk (A)
enca :=enc siga, pk (B)
send enca;
encb :=receive;
s :=sd encb, k;
Resp(B : principal_name) =
enca :=receive;
siga :=dec enca, dk (B) ;
texta :=unsign siga;
(idA, idB, k) :=texta;
verify siga, vk (idA) ;
assert: idB=B;
s :=newnonce;
encb :=se s, k
send encb;
Figure 3. Explicit presentation of handshake protocol, with abbreviations

Auth
Resp
: true[Resp(B)]
T
Honest(idA
[T]
) idA
[T]
B
: T
.pname = idA
[T]
Send(T
, enca
[T]
) Receive(T, enca
[T]
)
Receive(T, enca
[T]
) Send(T, encb
[T]
)
Figure 4. Property Auth

Resp
2.3. The protocol attacker
A protocol determines a set of runs, each with a sequence of actions by one or more
principals. Since we are concerned with the behavior of protocols under attack, not all of
the principals are assumed to follow the protocol. More specically, we dene a run of a
protocol by choosing some number of principals, assigning one or more roles to each of
them, choosing keys, and considering the eect of actions that may or may not follow the
roles. If a principal follows the roles assigned to it, then we consider the principal honest.
The attacker is represented by the set of dishonest principals, which may act arbitrarily
using the cryptographic material assigned to them.
2.4. Authentication properties
Our formulation of authentication is based on the concept of matching conversations [3].
This requires that whenever Alice and Bob accept each others identities at the end of
a run, their records of the run match, i.e., each message that Alice sent was received by
Bob and vice versa, each send event happened before the corresponding receive event,
and the messages sent by each principal appear in the same order in both the records.
An example of such an authentication property formalized as the PCL modal formula
Auth
Resp
is shown in Figure 4. Note that the last line on the right of Auth
Resp
seems
trivial; while not important for authentication, we are leaving it in to illustrate that PCL
can prove ordering properties of individual roles (whose veracity really follows from
honesty). (An analogous property Auth
Init
can be dened easily.)
Intuitively, Auth
Resp
says that starting from any state (since the precondition is true),
if B executes the actions in the responder role purportedly with idA, then B is guaranteed
that idA was involved in the protocol at some point (purportedly with B) and messages
were sent and received in the expected order, provided that idA is honest (meaning that
she always faithfully executes some role of the protocol and does not, for example, send
out her private keys) and is a dierent principal from B.
3. Syntax
The syntax for expressing the roles of a protocol, PCL assertions for reasoning about
them, and a symbolic framework for modeling protocol execution, may all be presented
as a single typed language. We present this language as a set of type names, subtype
relations, and typed constants (symbols that are used to write expressions) in a logical
framework with explicit typing and subtyping. Through subtyping, we are able to con-
sider dierent types of keys as subtypes of the type key of keys, for example, and sim-
ilarly consider key a subtype of the type message of messages that may be sent on the
network.
3.1. Protocols, roles, and setup assumptions
Protocols. A protocol is dened by a set of roles and setup assumptions. In Table 2, we
dene the type protocol of protocols as a set of parameterized roles (discussed below),
using the logical framework described in section 3.2. The set of protocol executions
are then dened using a set of instantiated roles and an initial state satisfying the setup
assumptions.
Roles. A role is a sequence of actions, divided into subsequences that we refer to as
basic sequences. The division of roles into basic sequences allows the protocol analyst to
express when a thread may proceed internally, and when a thread may pause and possibly
fail to continue. As dened in Table 2, a basic sequence is a sequence of actions. A role
may have one or more parameters that are instantiated for each thread that executes the
role. These parameters generally include the name of the principal executing the role and
the names of other principals with whom execution of this role involves communicating.
Setup assumptions. The initial conditions that must be established before a protocol can
be executed are called setup assumptions. In this chapter, we consider initialization con-
ditions that determine the set of keys that may be used by each principal in the roles
they execute. For example, a protocol may assume that each principal has a public key-
pair, and that the public key of this pair is known to every other principal. Additional
assumptions about protocol execution may also be stated in PCL preconditions.
The key assumptions we consider in this book chapter are expressed by giving a set
of functions that are used to name keys, and specifying which principals have access to
each key. The key assumptions may also restrict the ways that keys provided by setup
assumptions can be sent by honest principals.
Every PCL key belongs to one of ve disjoint types: sym_key for symmetric keys,
asym_enc_key for asymmetric encryption keys, asym_dec_key for asymmetric de-
cryption keys, sgn_key for signing keys, and ver_key for signature verication keys.
The technical machinery for restricting use of certain setup keys involves an ad-
ditional type conf_key of condential keys that cannot be released by honest prin-
cipals, and condential subtypes of each of the ve key types. For example, the type
conf_asym_dec_key of condential asymmetric decryption keys is a subtype of both
asym_dec_key and conf_key. Similarly, the type conf_sgn_key of condential sign-
ing keys is a subtype of both sgn_key and conf_key. More generally, any condential
key type conf_xyz_key is a subtype of both the corresponding unrestricted key type
xyz_key and conf_key.
The specic setup assumptions we use for the example protocols considered in this
chapter provide public-key encryption and signature infrastructure. These assumptions
are expressed using the following key functions (mapping principal names to various
types of keys), key-pair relations, and key possession properties (stating which principals
have access to which keys):
pk : principal_name asym_enc_key
dk : principal_name conf_asym_dec_key
sk : principal_name conf_sgn_key
vk : principal_name ver_key
Pname : AKeyPair(pk (Pname) , dk (Pname)) SKeyPair(sk (Pname) , vk (Pname))
(T, Pname) : Setup(T, pk (Pname))
(T, Pname) : T.pname = Pname Setup(T, dk (Pname))
(T, Pname) : T.pname = Pname Setup(T, sk (Pname))
(T, Pname) : Setup(T, vk (Pname))
These specications are used to choose and distribute keys in the setup phase of protocol
execution. Note that for the form of public-key infrastructure expressed here, an honest
principal Princ will be prevented fromsending dk (Princ.pname) or sk (Princ.pname)
in any message. (This restriction on behavior of honest principals will be enforced by
a syntactic condition on roles.) It is possible to change the setup assumptions to allow
an honest principal to send the decryption key of its asymmetric key-pair by changing
the type of dk () above. However, since many protocols do not send messages that re-
veal these keys, we usually nd it convenient to make this assumption from the outset
and eliminate the need to prove separately that the protocol preserves condentiality of
selected keys. It is possible to carry such proofs out in PCL if desired.
Setup assumptions for symmetric keys can be expressed similarly, as needed for pro-
tocols that may require shared symmetric keys. For example, one form of key setup as-
sumptions for Kerberos can be expressed by stating that there is a symmetric key ckdc(X)
for each client X, known to X and the Key-Distribution Center (KDC), a symmetric key
stgs(Y) for each server Y, known to Y and the Ticket-Granting Service (TGS), and a key
shared between the KDC and the TGS. While other forms of setup assumptions are pos-
sible in principle, the present formulation using a set of key functions (and key constants)
and a set of sharing assumptions is sucient for many protocols.
3.2. Logical framework
A logical framework is a framework that provides a uniform way of encoding a logical
language, its inference rules, and its proofs [22]. Without going into detail about logical
frameworks and their use in formalizing specic logical systems, we discuss a specic
framework briey because it allows us to dene the syntax, core aspects of the symbolic
model of protocol execution, and the proof system of PCL succinctly and precisely.
The logical framework we use is a typed language of expressions that includes pair-
ing, functions (to represent variable binding, as in quantied formulas), nite lists, and
nite sets. We also assume a form of subtyping that is similar to order-sorted algebra
[19]. This provides a convenient formalism for giving every expression a type, but allow-
ing expressions of one type to be used as expressions of another without syntactic con-
version functions. The logical framework we use, which might be called an order-sorted
logical framework, has the following grammar:
type ::= basic_type type . . . type type type List(type) Set
n
(type)
term ::= f ct_symb : type variable : type
(term
1
. . . term
n
)
i
term
variable : type
v
. term term term
1
. . . term
n
(n = 0, 1, 2, ...)
. . .
In words, types are built from basic type names (chosen below for PCL) using product
types (tuples), function types, and types of nite lists and nite sets. Terms, also called
expressions, are either basic constants (symbols chosen below for PCL), lambda ex-
pressions, function application, or additional forms for dening or using nite lists or
nite sets.
The logical framework we use has standard typing rules. For example, writing
term : type to mean a term has a specic type, if f : type
1
type
2
and x : type
1
,
then f x : type
2
. A lambda expression var:type
v
. exp denes the function that, given
argument var, has value exp. If var has type type
v
and term has type type
t
, then
(var : type
v
. term) has type type
v
type
t
. We will not use lambda expressions in PCL,
except that lambda is used as a binding operator to express parameterization (of protocol
roles) and quantication (for assertions).
We use two operator families, tupling ((, . . . , )) and projection (
i
), to construct
and deconstruct tuple () types. For instance,
_
message1, message2, message3
_
is
a triple of messages. To extract the third component from it, we write
3
_
message1,
message2, message3
_
. We use the element symbol to also denote membership in a
list and the operator : for concatenation of elements of a list type.
We write type
1
type
2
to indicate that type
1
is a subtype of type
2
. In this case, an
expression of type type
1
can be used as an expression of type type
2
.
A particular detail that we adopt from order-sorted algebra [19] for convenience is
the use of type retracts. If type
1
type
2
, then an expression of the supertype type
2
can
sometimes be used as an expression of the subtype type
1
, which is the opposite of what
is normally associated with subtyping. However, this is semantically reasonable if we
regard the retracted expression of the smaller type as the result of applying a cast (as
in common programming languages) mapping the supertype to the subtype. Intuitively,
the meaning of this retract (or cast) is to check the value of the expression, and leave the
value of the expression unchanged if it is semantically of the smaller type and otherwise
disallow the operation containing the expression with the retract.
3.3. PCL types and subtyping
The PCL types are presented in Table 1. For clarity and exibility, we use separate types
for nonces (unguessable fresh values generated during protocol execution), and dierent
types of keys. A principal_name is a name given to a principal who may execute one
or more roles of a protocol, a role_name is a name of a role, used to distinguish between
dierent roles of a protocol, actions are steps executed during a run of protocol. We
use thread_ids to give each thread (principal executing a sequence of actions) a unique
identier. Each thread may assign values to local variables that we give type location,
so that we may distinguish assignable variables from logical variables (program con-
stants) whose values are not changed by actions of principals. The type of messages
includes nonces, keys, the result of cryptographic operations, and any other values that
may be sent from one thread to another. Types action_formula, nonmodal_formula,
modal_formula, formula, and statement are dierent types of assertions about pro-
Table 1. PCL Types
type name meta-variables
nonce N
1
, N
2
, . . .
sym_key, conf_sym_key K
1
, K
2
, . . .
asym_enc_key, conf_asym_enc_key K
1
, K
2
, . . .
asym_dec_key, conf_asym_dec_key K
1
, K
2
, . . .
sgn_key, conf_sgn_key K
1
, K
2
, . . .
ver_key, conf_ver_key K
1
, K
2
, . . .
conf_key K
1
, K
2
, . . .
key K
1
, K
2
, . . .
principal_name Pname
1
, Pname
2
, . . . ; X
1
, Y
2
, . . . ; A
1
, B
2
, . . .
role_name rname
1
, rname
2
, . . .
action act
1
, act
2
, . . .
thread_id tid
1
, tid
2
, . . .
location oc
1
, oc
2
, . . .
message msg
1
, msg
2
, . . .
action_formula af
1
, af
2
, . . .
nonmodal_formula
1
,
2
, . . . ;
1
,
2
, . . .
modal_formula
1
,
2
, . . . ;
1
,
2
, . . .
formula fml
1
, fml
2
, . . .
statement stm
1
, stm
2
, . . .
Table 2. PCL Type abbreviations
type name : abbreviation meta-variables
thread : principal_name role_name T
1
, T
2
, . . .
List(principal_name) thread_id
principal : principal_name List(key) Princ
1
, Princ
2
, . . .
actionseq : List(action) actseq
1
, actseq
2
, . . .
basicseq : List(action) basicseq
1
, basicseq
2
, . . .
role : role_name List(basicseq) role
1
, role
2
, . . .
protocol : Set
n
(List(principal_name) role) /
1
, /
2
, . . .
event : thread_id action ev
1
, ev
2
, . . .
store : thread_id location message st
1
, st
2
, . . .
run : Set
n
(principal) Set
n
(thread) F
1
, F
2
, . . .
List(event) store
tocols and their execution. The types used in PCL are either basic types given in the
table, or composite types constructed from them using the four operators , , List(),
and Set
n
(). The binary inx constructors and create product types and functional
mappings, respectively; the unary constructors List() and Set
n
() create lists and nite
sets, respectively.
PCL also uses type abbreviations, presented in Table 2. These are non-constructive
denitions, also known as syntactic sugar. An example of a composite type is
thread, which is constructed from the basic types principal_name, role_name, and
thread_id using the two type constructor operators and List().
The subtype relation is a partial order: it is reexive, transitive, and antisymmetric.
PCL uses the following subtype relationships:
conf_sym_key sym_key key
conf_asym_enc_key asym_enc_key key
conf_asym_dec_key asym_dec_key key
conf_sgn_key sgn_key key
conf_ver_key ver_key key
conf_sym_key, conf_asym_enc_key, . . . , conf_ver_key conf_key
conf_key key
principal_name, nonce, key,
n
i=1
message message
action_formula nonmodal_formula
nonmodal_formula, modal_formula formula
Here, n may be any non-negative integer. Some clarication may be useful regarding
product types:
0
i=1
message denotes the empty product type for message; its only mem-
ber is ( ):message; thus the empty tuple ( ) is a message.
The types dened in this section include types used in writing PCL protocols, types
used in writing assertions about them, and types used in dening the symbolic execution
semantics of protocols. The type protocol itself is used to characterize the denition of
a protocol. As it appears in Table 2, the type protocol consists of a set of parameterized
roles. We call a function List(principal_name) role from principal names to roles
a parameterized role, and the result of applying a parameterized role to a list of principal
names a role instantiation. The rst argument is assumed to be the principal executing
the role; this is relevant to determining which keys can be used in executing the role.
Although a protocol may also specify setup assumptions, we consider them a separate
set of typed constants and formulas that is not part of the type protocol.
Although basicseq and actionseq are both lists of actions, we use the two types
dierently. In the semantics section we dene honesty of principals by requiring hon-
est principals to execute zero or more basic sequences. In eect, PCL reasons about
an abstraction of the protocol in which each basic sequence, once started by an honest
principal, runs to completion. An implementation may respect this abstraction by testing
whether the conditions exist to nish the basic sequence before performing any exter-
nally visible action (such as sending a message) of that sequence. We consider the divi-
sion of a role into basic sequences part of the denition of the PCL model of the protocol,
but impose a restriction on receive actions. Because we assume progress within a basic
sequence, and a receive action may block waiting for a message from the network, a
receive actions may only occur as the rst action of the basic sequence. In gures, we
use blank lines to indicate boundaries between basic sequences.
3.4. Protocol actions and roles
As indicated by the types in Table 2, protocols are dened using lists of actions. These
actions, as illustrated by example in Section 2, create, send, and receive messages. PCL
constants and functions for naming messages, and actions are listed in Tables 3 and 4,
resp. User-friendly PCL notation for cryptographic functions is given in Table 5.
The terms used in PCL messages are taken modulo a set of equations axiomatized
in Table 6. (There are also equivalences induced by stores, which are mappings from
assignable variables of type location, as discussed in the section on semantics below.) In-
stead of the functional notation based on the presentation of PCL in a logical framework
with subtyping, we use what we refer to as PCL syntax, presented in Table 7.
There are some details about the relationship between nonces and dynamically gen-
erated keys that merit discussion. In principle, there are several ways that cryptographic
Table 3. Constant symbols in PCL
symbol type
ky
1
, ky
2
, . . . ; k
1
, k
2
, . . . key
Alice, Bob, Charlie, . . . ; A, B, C, . . . principal_name
Init, Resp, . . . role_name
1, 2, . . . thread_id
x, y, siga, encb, texta, idB, k, s, . . . location
, a, ca, hello, . . . (all strings) message
true, false nonmodal_formula
Table 4. Function symbols for PCL actions
function symbol type
! location message
encmsg message asym_enc_key message
decmsg message asym_dec_key message
semsg message nonce message
semsg message sym_key message
sdmsg message nonce message
sdmsg message sym_key message
sgnmsg message sgn_key message
unsgnmsg message message
send message action
receive location action
newnonce location action
enc location message asym_enc_key action
dec location message asym_dec_key action
se location message nonce action
se location message sym_key action
sd location message nonce action
sd location message sym_key action
sign location message sgn_key action
unsign location message action
verify message ver_key action
assign location message action
assert message message action
operations could be modeled using symbolic computation. Cryptographic keys must be
generated using some source of randomness. For dynamically generated keys, we sepa-
rate randomness from key generation. We consider nonce generation n :=newnonce as
a symbolic version of choosing a bitstring uniformly at random from bitstrings of appro-
priate length. A nonce n may then be used as an unguessable value or as a random seed
to various deterministic key generation algorithms.
Encryption and signature algorithms typically apply a key generation algorithm
(KeyGen) to deterministically transform a bitstring chosen from one probability distri-
bution to a bitstring chosen from a distribution appropriate for the encryption/signature
algorithm. For symmetric key operations the KeyGen algorithm generates just one key;
Table 5. Fully functional syntax vs. PCL syntax for cryptographic functions
Fully functional syntax PCL syntax Description
encmsg(msg, K) msg
a
K
Asymmetric encryption
decmsg(msg
encr
, K)
_
msg
encr
_
a
K
Asymmetric decryption
semsg(msg, N) msg
s
N
Symmetric encryption by nonce
semsg(msg, K) msg
s
K
Symmetric encryption by pre-shared key
sdmsg(msg
encr
, N)
_
msg
encr
_
s
N
Symmetric decryption by nonce
sdmsg(msg
encr
, K)
_
msg
encr
_
s
K
Symmetric decryption by pre-shared key
sgnmsg(msg, K) msg
K
Signature
unsgnmsg(msg
signed
) msg
signed
Stripping o the signature

Table 6. Equations in PCL
Equation Types of variables used in equation
i
(v
1
, v
2
, . . . , v
i1
, v
i
, v
i+1
, . . . , v
k
) = v
i
[k N
+
, i 1, 2, . . . , k; v
1
: type
1
, v
2
: type
2
, . . . , v
k
: type
k
]
_
msg
a
K
1
_
a
K
2
= msg [K
1
: asym_enc_key, K
2
: asym_dec_key, msg: message,
where (K
1
,K
2
) is an asymmetric encryption-decryption keypair]
_
msg
s
N
_
s
N
= msg [N: nonce, msg: message]
_
msg
s
K
_
s
K
= msg [K: sym_key, msg: message]
msg
K
= msg [K: sgn_key, msg: message]

for public key algorithms the KeyGen algorithm generates two keys one public, one
private.
We will only consider dynamic generation of symmetric encryption keys in this
chapter. For protocols with dynamically generated symmetric keys, the role that gen-
erates a key may send a nonce, relying on the receiving role to apply the same
KeyGen algorithm to the nonce as the role that generated the nonce. Since the op-
erations of key generation and encryption/decryption always go together, we can
model this situation symbolically by having composite encryption/decryption operations,
[ :=se , N]/[ :=sd , N], that rst apply KeyGen and then encrypt/decrypt. As a result,
these encryption and decryption functions use a nonce instead of key to encrypt or de-
crypt a message.
Many protocols like Kerberos use pre-shared symmetric keys that are not sent
around in the protocol. To model such protocols, in a way that is consistent with our treat-
ment of dynamically-generated keys, we assume separate encryption/decryption opera-
tions that do not incorporate KeyGen. The threads themselves are congured with these
keys according to protocol requirements. For example, in Kerberos, there are three types
of symmetric keys: shared between two principals in Client and KAS roles, in KAS and
TGS roles, and in TGS and Server roles. Since a principal can be operating in any one
of these roles with another principal in any one of the peer roles, we have to explicitly
specify the relation in the symbolic representation of the key. In one of our earlier papers
[38,37] we denoted these keys as k
ck
X,Y
, k
kt
X,Y
and k
ts
X,Y
respectively, between the two prin-
cipals X and Y. Such pre-shared symmetric keys have a type that allows them to be used
internally by threads but not sent on the network by honest principals.
Syntactic restrictions on roles. The type system places a number of restrictions on the
syntax of roles. For example, events and stores are used in the semantics of protocol ex-
Table 7. Fully functional syntax vs. PCL syntax for actions
fully functional syntax PCL syntax Description
!(oc) !oc Contents of assignable location
send(msg) send msg Send message
receive(oc) oc :=receive Receive message and store in oc
newnonce(oc) oc :=newnonce Generate nonce and store in oc
enc(oc, msg, K) oc :=enc msg, K Asymmetric encrypt and store in oc
dec(oc, msg
encr
, K) oc :=dec msg
encr
, K Asymmetric decrypt and store in oc
se(oc, msg, N) oc :=se msg, N Symmetric encrypt and store in oc
se(oc, msg, K) oc :=se msg, K Symmetric encrypt and store in oc
sd(oc, msg
encr
, N) oc :=sd msg
encr
, N Symmetric decrypt and store in oc
sd(oc, msg
encr
, K) oc :=sd msg
encr
, K Symmetric decrypt and store in oc
sign(oc, msg, K) oc :=sign msg, K Sign message and store in oc
unsign(oc, msg
signed
) oc :=unsign msg
signed
Store plaintext of signed message in oc
verify(msg
signed
, K) verify msg
signed
, K Verify signed message
assign(oc, msg) oc:=msg Assign to storable oc
assert(msg
1
, msg
2
) assert: msg
1
=msg
2
Equality check
ecution and cannot occur in roles because of the typing discipline. Due to typing con-
straints (specically, location message), a location itself is not a message, but the
contents of a location are a message. Therefore, if a protocol sends a message that de-
pends on the contents of a location oc, the role must use !oc to refer to the contents
of the location. In addition, we impose the following restrictions on roles, beyond what
follows from typing and subtyping:
No free variables. A parameterized role of type List(principal_name) role
appearing in a protocol must not have any free variables. In particular, all keys
must be key constants, key expressions such as pk (Pname) for principal names
that are either constants or parameters of the role, or keys received in messages.
Single-assignment. Each location must be a location constant, assigned to only
once, and used only after it has been assigned. Since roles are given by loop-free
programs, location names can easily be chosen to satisfy the single-assignment
condition.
Key condentiality. If K has type conf_key, then K cannot occur in any assign-
ment action oc:=K or in any expression (or argument to any action) except as an
argument that is required to have type key.
Local store operations. The ! operator may occur in roles, to obtain the value
stored in a location. However, ! may not be used outside of roles. The reason
is that because locations are local to threads, !oc is ambiguous unless this ex-
pression occurs in a role assigned to a specic thread. The Sto(, ) function (in
Table 8) has a thread parameter and may occur in formulas but not in roles.
The key condentiality condition given above allows a role to encrypt a message with a
condential key and send it, as in the sequence of actions oc :=enc msg, K; send !oc.
The reason this conforms to the syntactic key condentiality condition is that encs argu-
ment signature is location message asym_enc_key; i.e., the third argument is re-
quired to have a key type. Semantically, this preserves condentiality of the key because
encrypting a message with a key does not produce a message from which the key can be
recovered. The key condentiality condition does not allow oc :=enc K
1
, K
2
, in which
a condential key K
1
is encrypted under another key, because the contents of oc could
then be used to construct a message that is sent. In other words, the key condentiality
condition is designed to be a conservative syntactic restriction on roles (to be followed
by honest principals) that prevents export of condential keys.
Further abbreviations. For most product types, we use record notation, such as
record.recordelement, to access components of a pair. This aids readability because
we can write T.rpars, using the potentially meaningful abbreviation .rpars (for role
parameters) instead of
3
T. The abbreviations we use are:
T.pname :=
1
T, T.rname :=
2
T, T.rpars :=
3
T, T.tid :=
4
T
Princ.pname :=
1
Princ , Princ.klist :=
2
Princ
role.rname :=
1
role, role.bseqs :=
2
role
ev.tid :=
1
ev, ev.act :=
2
ev
F.pset :=
1
F, F.tset :=
2
F, F.elist :=
3
F, F.st :=
4
F
The key functions are similarly projection functions that select keys out of the list of keys
associated with the principal. Here, Princ refers to the contextually unique principal
with principal_name Pname (that principals dier in their principal names is a condi-
tion on feasibility of runs, to be dened later), and we use (1-based) numbered indices in
record notation for list members for legibilitys sake:
pk (Pname) = Princ.klist.1 dk (Pname) = Princ.klist.2
sk (Pname) = Princ.klist.3 vk (Pname) = Princ.klist.4
Of course, this last set of denitions related to keys needs to be adapted to the respective
setup assumptions. For role parameters we may also use indices:
T.rpars = (T.rpars.1, T.rpars.2, . . .)
3.5. PCL assertions
The syntax of PCL assertions is presented in Table 8. Quantiers are regarded as function
symbols of specic types, presented in Table 9. Relying on lambda abstraction from the
underlying logical framework, we normally write, for example,
key
K : stm instead of
key
(K.stm).
4. Semantics
This section presents the semantics of PCL. In outline, protocol execution determines a
set of runs, each comprising a list of events that occur in the run. The semantics of for-
mulas then determines which formulas are true for each run. Our semantics of protocols
is based on the symbolic model [14,32], commonly called the Dolev-Yao model. In this
model, an honest party or an adversary can only produce a symbolic expression repre-
senting a signature or decrypt an encrypted message if it possesses the appropriate key;
the model does not involve bitstrings, probability distributions, or partial knowledge.
Recall that a protocol run F =
_
S
princ
, S
th
, eventlist, store
_
consists of a nite set of
principals, a nite set of threads, a nite list of events, and a store mapping assignable
locations to the values they contain (see Table 2). Only certain combinations of princi-
pals, threads, events, and store form a run that could occur as an execution of a protocol.
Table 8. Function symbols for PCL assertions
function symbol PCL notation type
Sto thread location message
Send thread message action_formula
Receive thread message action_formula
NewNonce thread message action_formula
Enc thread message key action_formula
Dec thread message key action_formula
Se thread message nonce action_formula
Se thread message key action_formula
Sd thread message nonce action_formula
Sd thread message key action_formula
Sign thread message key action_formula
Unsign thread message action_formula
Verify thread message key action_formula
Assign thread message action_formula
Assert thread message message action_formula
inx action_formula action_formulanonmodal_formula
Fresh thread message nonmodal_formula
Has thread message nonmodal_formula
FirstSend thread message message nonmodal_formula
Atomic message nonmodal_formula
inx message message nonmodal_formula
= inx message message nonmodal_formula
= inx thread thread nonmodal_formula
Start thread nonmodal_formula
Honest principal_name nonmodal_formula
nonmodal_formula nonmodal_formula
inx nonmodal_formula nonmodal_formulanonmodal_formula
Modal [actseq]
T
nonmodal_formula actionseq thread nonmodal_formula
modal_formula
= /: F = fml protocol run formula statement
Table 9. Quantiers in PCL
quantiers type
run
(run statement) statement
thread
(thread statement) statement
principal_name
(principal_name statement) statement
key
(key statement) statement
message
(message statement) statement
type
(type formula) formula (for all types type)
We therefore dene the set of feasible runs of a protocol to characterize the well-formed
runs in our model of protocol execution and attack. After preliminary denitions in Sub-
section 4.1, we dene the semantics of protocols in Subsection 4.2. Subsection 4.3 gives
an inductive denition of the semantic relation / : F = , stating that the formula
holds on a feasible run F of protocol /.
4.1. Preliminary denitions
Properties of runs. Recall that each thread T S
th
of a run F =
_
S
princ
, S
th
, eventlist, store
_
has the form T = (Pname, rname, princ_list, tid) consisting of a principal name, a role
name, a list of principal_name parameters, and a thread id. The role name T.rname
must name a role of protocol /, where each role denes a sequence of actions. The
events in the event list eventlist are pairs (tid, act) of actions by specic threads. We
require that the actions in an eventlist do not contain locations (except in positions that
require type location). We also require that the contents of assignable locations in the
store do not contain locations either. We dene runs in this way so that actions and stored
values may be compared syntactically (as in the semantics of formulas) without relying
on stores of the run.
For any run F, we dene the set GenMsg
F
(tid) of messages that thread tid can
send out in run F without performing additional explicit actions. Our protocol program-
ming language has operations such as encryption, decryption, and creating or verifying
signatures as explicit actions in the run. This allows us to state formulas expressing which
actions occurred and which did not; if no decryption occurred, for example, then no prin-
cipal has the decrypted message. On the other hand, we treat pairing and projection as
implicit operations a thread can send a tuple or projection of values it has received or
constructed, without an explicit tupling or projection action in the thread.
We let GenMsg
F
(tid) be the smallest set satisfying the following conditions, where
T is the unique thread with thread_id tid:
1. Base cases:
strings:
, a, ca, hello, . . . (all strings) GenMsg
F
(tid)
principal names:
PrincF.pset Princ.pnameGenMsg
F
(tid)
own keys:
T.pname = Princ.pname KPrinc.klist KGenMsg
F
(tid)
other principals keys:
For all PrincF.pset :
Setup(T, pk (Princ.pname)) pk (Princ.pname) GenMsg
F
(tid)
Setup(T, dk (Princ.pname)) dk (Princ.pname) GenMsg
F
(tid)
Setup(T, sk (Princ.pname)) sk (Princ.pname) GenMsg
F
(tid)
Setup(T, vk (Princ.pname)) vk (Princ.pname) GenMsg
F
(tid)
stored messages:
F.st(tid, oc) dened F.st(tid, oc) GenMsg
F
(tid)
2. Inductive cases:
tupling:
msg
1
GenMsg
F
(tid)msg
2
GenMsg
F
(tid). . . msg
k
GenMsg
F
(tid)
_
msg
1
, msg
2
, . . . , msg
k
_
GenMsg
F
(tid)
projection:
(. . . , msg, . . .) GenMsg
F
(tid) msgGenMsg
F
(tid)
We dene the so-called Dolev-Yao closure of a set of messages. Although we do
not use the Dolev-Yao closure to dene the set of runs, we do use it to characterize the
semantics of the Has predicate and to establish soundness of the proof system. The ca-
pability of the Dolev-Yao attacker are characterized by a deduction system. In the fol-
lowing rules, we use msg : DY to indicate that message msg is in the Dolev-Yao closure.
The following ten inference rules characterize the Dolev-Yao attacker of protocols with
asymmetric encryption, symmetric encryption, and signatures.
decryption keypair. Note that signing a messages does not hide the plaintext (that is, no
ver_key is needed to see the unsigned message).
Given a set M of messages, we dene the set DolevYao(M) of messages that a sym-
bolic Dolev-Yao [14] attacker can generate from M as follows:
msg
0
DolevYao(M) i msg
0
: DY can be derived using the inference rules above
from the following hypotheses:
(1) msg : DY (for all msg M)
(2) N : DY (for all N M)
(3) K : DY (for all K M)
Messages and protocol state. Our protocol programming language uses assignable lo-
cations to receive messages and perform internal actions such as encryption or decryp-
tion. If a protocol sends a message that depends on the contents of a location oc, then the
syntax of the role must use !oc to refer to the contents of the location, and the result is to
send the contents of the location, written as F.st(tid, oc) for run F and thread_id
tid.
For simplicity, we use the notation F[msg] to refer to the meaning of message msg
in run F. Since we are using a symbolic semantics of protocols and their properties, the
meaning of an expression that appears in a formula is a symbolic expression, but without
locations or dependence on stores. The symbolic meaning F[msg] has a straightforward
inductive denition, with
F[Sto(T, oc)] = F.st(tid, oc)
as one base case. Since the other base cases and all inductive cases are trivial, the mean-
ing of a message is the result of substituting values for locations. For actions, which
may contain !oc, we write [
oc.F.st(tid,oc)
!
]act, where the substitution of a lambda ex-
pression for ! indicates the result of replacing ! by an explicit function and performing
-reduction to obtain an expression for the value stored in a given location.
msg
i
: DY
The side condition AKeyPair(K
, K) above means that (K
,K) is an asymmetric encryption-

_
msg
1
, . . . , msg
n
_
: DY
_
msg
1
, . . . , msg
n
_
: DY
msg : DY
K : sgn_key
msg
1
, . . . , msg
n
: DY
msg
K
: DY
K : sgn_key
msg
K
: DY
msg : DY
K : sym_key
msg : DY K : DY
msg
s
K
: DY
K : sym_key
msg
s
K
: DY K : DY
msg : DY
N : nonce
msg : DY K : DY
msg
s
N
: DY
N : nonce
msg
s
N
: DY N : DY
msg : DY
AKeyPair(K,K)
msg : DY N : DY
msg
a
K
: DY
K : asym_enc_key
msg
a
K
: DY K : DY msg : DY K : DY
Since threads generate new nonces and keys, we need a denition that allows us to
see which symbols are not new relative to a run F
prev
=
_
S
princ
, S
th
, eventlist, store
_
. Be-
fore giving this denition, we need some other denitions, concerning the - (congru-
ence-) and the - (subterm-) relations:
Canonical form of messages: The equations in Table 6 form a conuent and ter-
minating rewrite system, when oriented from left to right. The result of applying
these rewrites to a message, until termination, is called the canonical form of the
message.
: We use the notation msg
1
msg
2
to express that the messages msg
1
and msg
2
are equal modulo the equational theory presented in Table 6, or equivalently, msg
1
and msg
2
have the same canonical form. (We use instead of = to avoid confusion
with nonmodal_formulas.)
: We write msg
1
msg
2
to indicate that the canonical form of msg
1
is a subterm
of the canonical form of msg
2
.
Using the -relation, we can now say key K occurs in F if:
K Princ.klist for some Princ occurring in S
princ
,
K occurs in some role obtained by applying the parameterized role named
T.rname to its role parameters T.rpars for thread T S
th
,
K msg for some msg in eventlist,
K msg for some ((tid, oc), msg) F.st
The denition of nonce N occurs in F is analogous.
Finally, we give a number of auxiliary denitions that we will need later to state the
semantics of the Honest formula and of modal_formulas:
F
1
: F
2
: . . . : F
n
: We say that F
1
: F
2
: . . . : F
n
is a division of run F if:
F
i
.pset = F.pset for 1 i n,
F
i
.tset = F.tset for 1 i n,
F
i
.elist is an initial segment of F
i+1
.elist for 1 i < n,
F
i
.st contains only the mappings dened by F
i
.elist, for 1 i n.
The run components are cumulative because this simplies our formalism overall.
events
T
: The projection events
T
of eventlist events onto a thread T is the
subsequence of events ev from events with ev.tid = T.tid.
dierence: If events
1
is an initial segment of events
2
, their dierence (events
2
\
events
1
) is the sequence of events such that events
1
: (events
2
\ events
1
) =
events
2
.
matching: We say that an event ev matches an action act in run F if
ev.act [
loc.F.st(ev.tid,loc)
!
]act. A list of events matches a list of actions if
both lists are of equal length and corresponding elements match.
4.2. Feasibility of runs
The set of feasible runs of a protocol / is dened inductively. Recall that a run F
consists of a nite set of principals, a nite set of threads, a list of events and a store.
Intuitively, the base case of the inductive denition imposes conditions on the initial
conguration before protocol execution begins. For example, the principal names and
thread identiers must be unique and each threads role name must be one of the roles of
protocol /. The list of events and the store of the run are initially both empty.
The inductive case of the denition describes how one feasible run F
prev
can be
extended to form another feasible run F, by an action performed by one of the threads.
Generally, an action may occur only when certain conditions are satised. An action has
the eect of appending the associated event to the list of events in F
prev
and possibly
extending the store to record values assigned to additional locations.
The condition for a thread tid to send a message in run F is that the message
should be generable by the thread following the denition of GenMsg
F
(tid) presented
earlier. When a message is sent, all occurrences of !oc indicating the contents of a
local storage location in the message are replaced by the concrete message stored at that
location, i.e., F.st(tid, oc). The conditions for the key generation actions ensure that
the keys are fresh. An encryption action is possible only if the plaintext message and the
encryption key are generable by the thread performing the action, whereas decryption
succeeds only if the encrypted message and the decryption key are generable. Similarly,
signature generation requires both the message and the signing key to be generable by
the thread. Finally, an assignment action succeeds if the message that is being assigned
to a location is generable by the thread, and an equality test on messages succeeds if the
two messages are equal modulo the equational theory of the message algebra.
For convenience, we write F.pnames for the set of principal names and F.tids
for the set of thread ids in F =
_
S
princ
, S
th
, . . .
_
, i.e., F.pnames = pn Princ S
princ
:
Princ.pname = pn and F.tids = tid TS
th
: T.tid = tid.
Base case. An empty run F =
_
S
princ
, S
th
, ( ),
_
is feasible for any protocol /, where
( ) is the empty sequence of events and and is the empty store, provided all of the
following conditions are met:
All principals in set S
princ
dier in their principal_name:
_
Pname
i
, keylist
i
_
,
_
Pname
j
, keylist
j
_
S
princ
:
Pname
i
= Pname
j
keylist
i
= keylist
j
The keylist for each principal in S
princ
has the keys named in the setup assumptions,
each of the type specied in the setup assumptions. For the setup assumptions used for
protocols in this book chapter, this means:
pk (Princ.pname) = Princ.klist.1 : asym_enc_key
dk (Princ.pname) = Princ.klist.2 : conf_asym_dec_key
sk (Princ.pname) = Princ.klist.3 : conf_sgn_key
vk (Princ.pname) = Princ.klist.4 : ver_key
AKeyPair(pk (Princ.pname) , dk (Princ.pname))
SKeyPair(sk (Princ.pname) , vk (Princ.pname))
All threads dier in their thread_ids:
T
i
, T
j
S
th
: (T
i
T
j
) T
i
.tid T
j
.tid
Every parameterized role of any thread (instantiated with the respective role param-
eters) is in protocol /:
TS
th
: prm_role/: (prm_role(T.rpars)).rname = T.rname
The set of principal_names in S
princ
is exactly the set of principals of threads in
S
th
:
F.pnames = Pname TS
th
: T.pname = Pname
Table 10. Feasibility of runs conditions (inductive case)
act newassgns conditions
oc :=receive ((tid, oc), msg) msg was sent out previously:
tid
: (tid
, send msg) eventlist

send msg msg GenMsg
F
(tid)
oc :=newnonce ((tid, oc), N) N: nonce does not occur in F.
oc :=enc msg, K
_
(tid, oc), msg
a
K
_
K : asym_enc_key GenMsg
F
(tid)
msg GenMsg
F
(tid)
oc :=dec msg
a
K
, K ((tid, oc), msg) K : asym_dec_key GenMsg

F
(tid)
((K
,K) is an asymmetric encr.-decr. keypair)

msg
a
K
GenMsg
F
(tid)
oc :=se msg, N
_
(tid, oc), msg
s
N
_
N : nonce GenMsg
F
(tid)
msg GenMsg
F
(tid)
oc :=se msg, K
_
(tid, oc), msg
s
K
_
K : sym_key GenMsg
F
(tid)
msg GenMsg
F
(tid)
oc :=sd msg
s
N
, N ((tid, oc), msg) N : nonce GenMsg
F
(tid)
msg
s
N
GenMsg
F
(tid)
oc :=sd msg
s
K
, K ((tid, oc), msg) K : sym_key GenMsg
F
(tid)
msg
s
K
GenMsg
F
(tid)
oc :=sign msg, K
_
(tid, oc), msg
K
_
K : sgn_key GenMsg
F
(tid)
msg GenMsg
F
(tid)
oc :=unsign msg
K
((tid, oc), msg) msg
K
GenMsg
F
(tid)
verify msg
K
, K K : ver_key GenMsg
F
(tid)
((K
,K) is a sig.-verif. keypair)

msg
K
GenMsg
F
(tid)
oc:=msg ((tid, oc), msg) msg GenMsg
F
(tid)
assert: msg
1
=msg
2
msg
1
GenMsg
F
(tid) msg
2
GenMsg
F
(tid)
msg
1
msg
2
.
Inductive case. If F
prev
=
_
S
princ
, S
th
, eventlist, store
_
is a feasible run for protocol /, then
F =
_
S
princ
, S
th
, eventlist :(tid, act), store newassgns
_
is a feasible run for /, where
the symbol : indicates list concatenation, tid F.tids, and tid, act, and newassgns
satisfy the conditions shown in Table 10.
Finally, a quick note on how the attacker is modeled: the attacker is a principal who
executes a thread but does not necessarily follow the action sequence required by the
notion of honesty (to be dened below in Section 4.3).
4.3. Truth of statements
In this section, we present an inductive denition of the semantic relation / : F =
stating that the formula holds on a feasible run F of protocol /.
Truth of statements involving nonmodal formulas is dened as follows:
/: F = Send(T, msg): (1) T is a thread of F. (2) T executed a send msg
action such
that F[msg] msg
.
/: F = Receive(T, msg): (1) T is a thread of F. (2) T executed a oc :=receive action
such that F[msg] F.st(T.tid, oc).
/: F = NewNonce(T, msg): (1) T is a thread of F. (2) T executed a oc :=newnonce
action such that F[msg] F.st(T.tid, oc).
/: F = Enc(T, msg, K): (1) T is a thread of F. (2) T executed a oc :=enc msg
, K
action
such that F[msg] msg
and F[K] K
.
/: F = Dec(T, msg
encr
, K): (1) T is a thread of F. (2) T executed a oc :=dec msg
encr
, K
action such that F[msg

encr
] msg
encr
and F[K] K
.
/: F = Se(T, msg, N): (1) T is a thread of F. (2) T executed a oc :=se msg
, N
action
and F[N] N
.
/: F = Se(T, msg, K): (1) T is a thread of F. (2) T executed a oc :=se msg
, K
action
and F[K] K
.
/: F = Sd(T, msg
encr
, N): (1) T is a thread of F. (2) T executed a oc :=sd msg
encr
, N

encr
] msg
encr
and F[N] N
.
/: F = Sd(T, msg
encr
, K): (1) T is a thread of F. (2) T executed a oc :=sd msg
encr
, K

encr
] msg
encr
and F[K] K
and F[K] K
.
/: F = Sign(T, msg, K): (1) T is a thread of F. (2) T executed a oc :=sign msg
, K
action such that F[msg] msg
and F[K] K
.
/: F = Unsign(T, msg
signed
): (1) T is a thread of F. (2) T executed a oc :=unsign msg
signed
signed
] msg
signed
.
/: F = Verify(T, msg
signed
, K): (1) T is a thread of F. (2) T executed a verify msg
signed
, K

signed
] msg
signed
and F[K] K
.
/: F = Assign(T, msg): (1) T is a thread of F. (2) T executed a oc:=msg
action such
that F[msg] msg
.
/: F = Assert(T, msg
1
, msg
2
): (1) T is a thread of F. (2) T executed an assert: msg
1
=
msg
2
1
] msg
1
as well as F[msg
2
] msg
2
.
/: F = af
1
af
2
: (1) /: F = af
1
and /: F = af
2
are both true. (2) Both af
1
and af
2
are
action_formulas (Send, Receive, NewNonce, . . . ), not necessarily of the same type. (3)
There exist (send, receive, newnonce, . . . ) actions, labeled act
1
and act
2
, in (possibly
distinct) threads tid
1
and tid
2
corresponding to af
1
and af
2
, respectively (with cor-
respondence as naturally dened in accordance with the truth conditions of the respec-
tive (Send, Receive, NewNonce, . . . ) action_formulas above), such that (tid
1
, act
1
)
occurs before (tid
2
, act
2
) within F.elist.
/: F = Fresh(T, msg): (1) T is a thread of F. (2) /: F = NewNonce(T, msg) is true. (3)
msg
: (/: F = Send(T, msg
)) F[msg] F[msg
].
/: F = Has(T, msg): (1) T is a thread of F. (2) F[msg] DolevYao(GenMsg
F
(T.tid)),
where Princ is the principal executing thread tid.
/: F = FirstSend(T, msg
1
, msg
2
): (1) T is a thread of F. (2) F[msg
1
] F[msg
2
]
(/ : F = Send(T, msg
2
)). (3) For all messages msg
3
such that F[msg
1
] msg
3
and
_
T.tid, send msg
3
_
F.elist, there must be an earlier event
_
T.tid, send msg
2
_
with
F[msg
2
] msg
2
. In words, while T need not be the rst thread to send out a message
containing msg
1
, the rst send by T containing msg
1
must be a send of msg
2
.
/: F = Atomic(msg): F[msg] is -congruent to an atomic message. An atomic message
is one in which neither of tupling, projection, encryption, decryption, signing, or unsigning
occurs; i.e., the canonical form of F[msg] is atomic.
/: F = msg
1
msg
2
: F[msg
1
] F[msg
2
].
/: F = msg
1
= msg
2
: F[msg
1
] F[msg
2
].
/: F = T
1
= T
2
: T
1
and T
2
are identical.
/: F = Start(T): (1) T is a thread of F. (2) thread T did not execute any actions:
act: (T.tid, act) F.elist.
/: F = Honest(Pname): (1) Pname is a principal_name of F: Pname F.pnames. (2)
For any thread T of Pname, let role be the unique role with role.rname = T.rname.
There must be some k 0 such that [basicseq
1
; basicseq
2
; . . . ; basicseq
k
] is an ini-
tial sequence of role.bseqs and F.elist
T
matches (basicseq
1
: basicseq
2
: . . . :
basicseq
k
), the concatenation of these basic sequences of the role. In other words, each
thread of principal has executed precisely some number of basic sequences of its des-
ignated role. In particular, no thread can deviate from or stop in the middle of a basic se-
quence. (3) The canonical forms of all messages that Pname sent out may only have keys
of type conf_key in positions that require type key. In other words, conf_keys are only
used for encryption or signing messages, not as the payload. (This is guaranteed by the
syntactic condition on conf_key in roles.)
/: F = : /: F = is not true.
/: F = : /: F = and /: F = are both true.
/: F =
type
v: fml: For all ground instances a of v : type we have /: F = [
a
v
]fml, where
[
a
v
]fml is the formula obtained by substituting all occurrences of v in fml by a.
Truth of statements involving modal formulas is dened as follows:
/: F = [actseq]
T
: For all divisions (F
1
: F
2
: F
3
) of run F, the following holds: If
/: F
1
= is true, and ((F
2
.elist)
T
\ (F
1
.elist)
T
) matches actseq, then /: F
2
=
is true.
1
As usual, we employ . . . . . ., . . . . . ., and . . . as syntactic shortcuts for
(. . . . . .), . . . . . ., and . . ., respectively.
5. Proof system
This section describes some of the axioms and inference rules of PCL. The portion of the
PCL proof system that is presented here is sucient to prove authentication properties
of the sample protocols considered in Sections 2 and 6. While we do not present secrecy
axioms and proofs in this chapter, sample secrecy axioms and proofs are developed in
other papers on PCL (e.g., [38,39]).
The PCL axioms and proof roles formalize reasoning about protocols, using PCL
assertions. Like Hoare logic, the axioms are generally formulas about a given action,
and many inference rules let us prove something about a sequence of actions from as-
sertions about a shorter sequence of actions. If we want to use a formula [actseq]
T

with postcondition to prove a similar formula [actseq]
T

with postcondition
, it
suces to prove that
. We do not give formal proof rules for deducing implica-

tions between preconditions or postconditions. In this sense, PCL could be considered a
semi-formalized logic for proving properties of protocols. However, two points should be
considered. First of all, the formulas used in preconditions and postconditions are logi-
cally simpler than modal formulas. As a result, PCL reduces formal reasoning about pro-
tocols to reasoning about the precondition-postcondition logic. Second, the presentation
of PCL given in this chapter shows how PCL may be presented in a logical framework
(or meta-logic). When PCL is embedded in a meta-logic, the axioms and proof rules
given here essentially reduce proofs about protocols to proofs about preconditions and
postconditions in the meta-logic. Therefore, PCL provides an approach (not fully devel-
oped in this chapter) for fully formal proofs of security properties of protocols, using a
metalogic supporting the formal syntax and symbolic semantics development presented
in this chapter.
1
It is intentional that F
3
does not appear in this denition.
For brevity in some of the proof rules, we will write Sto(T,oc) as oc
[T]
. In case
there is some possible confusion, here is a summary of dierent forms associated with
locations and their values:
In protocol actions, !oc is the content of location oc in the current thread.
In formulas, Sto(T,oc) is the content of location oc in the local store of thread
T, with oc
[T]
being an abbreviation for Sto(T,oc).
In the semantics of formulas, the symbolic meaning F[msg] of a message depends
on the store of the run, with F[Sto(T, oc)] = F.st(tid, oc) as one base case.
For convenience, we then extend Sto(T, ) to messages, with Sto(T,msg) being the
message obtained by replacing any subexpression !oc depending on the store with
Sto(T,oc).
The soundness theorem for the proof system is proved by induction on the length of
proof: all instances of the axioms are valid formulas and all proof rules preserve validity.
We state the soundness theorem upfront and give proof sketches for a few representative
axiom and rule schemas while presenting them.
We write - if is provable from the formulas in and any axiom or rule schema
of the proof system except the honesty rule HON. We write -
/
if is provable
from the formulas in , the basic axioms and inference rules of the proof system and the
honesty rule just for protocol /. We write =
/
if for any feasible run F of protocol /
the following holds: If /: F = , then /: F = . We write = if for any protocol /,
we have =
/
. Here, is a non-modal formula (typically, a formula proved using the
honesty rule) and is either a modal formula or a non-modal formula.
Theorem 5.1 If -
/
, then =
/
. Furthermore, if - , then = .
Because of the undecidability of protocol properties expressible in PCL (see [15,16])
and the fact that invalid formulas can be enumerated by enumerating nite runs, it is
not possible for the PCL proof system to be semantically complete. Therefore, we have
developed PCL by adding new PCL predicates, axioms, and rules as needed to handle
dierent classes of protocols and properties.
5.1. Axiom Schemas
The axiom schemas presented below can be divided up into the following categories:
AA0AA4 state properties that hold in a state as a result of executing (or not execut-
ing) certain actions; AN1AN4 capture properties of nonces; KEY states which thread
possesses what key, in eect, axiomatizing protocol setup assumptions, while HAS ax-
iomatizes the Dolev-Yao deduction rules; SEC captures the hardness of breaking public
key encryption while VER states that signatures are unforgeable; IN (and NIN) provide
reasoning principles for when one message is contained in (and not contained in) an-
other; P1 and P2 state that the truth of certain predicates is preserved under specic fur-
ther actions; and FS1 and FS2 support reasoning about the temporal ordering of actions
performed by dierent threads based on the fresh nonces they use.
Axiom schemas AA0. These are axiom schemas which infer term structure from term
construction actions (k refers to the unique encr./sig. key for decr./verif. key k):
true [actseq; oc :=enc msg, K; actseq
]
T
Sto(T, oc) = Sto(T, msg)
a
Sto(T,K)
true [actseq; oc :=dec msg, K; actseq
]
T
Sto(T, msg) = Sto(T, oc)
a
Sto(T,K)
true [actseq; oc :=se msg, N; actseq
]
T
s
Sto(T,N)
true [actseq; oc :=se msg, K; actseq
]
T
s
Sto(T,K)
true [actseq; oc :=sd msg, N; actseq
]
T
s
Sto(T,N)
true [actseq; oc :=sd msg, K; actseq
]
T
s
Sto(T,K)
true [actseq; oc :=sign msg, K; actseq
]
T
Sto(T,K)
true [actseq; oc :=unsign msg; actseq
]
T
true [actseq; verify msg

signed
, K; actseq
]
T
Sto(T, msg
signed
) = Sto(T, msg
signed
)
Sto(T,K)
true [actseq; oc:=msg; actseq
]
T
true [actseq; assert: msg
1
=msg
2
; actseq
]
T
Sto(T, msg
1
) = Sto(T, msg
2
)
Axiom schemas AA1. These are axiom schemas which state that after an action has
occurred, the predicate asserting that the action has taken place is true:
true [actseq; send msg; actseq
]
T
Send(T, Sto(T, msg))
true [actseq; oc :=receive; actseq
]
T
Receive(T, Sto(T, oc))
true [actseq; oc :=newnonce; actseq
]
T
NewNonce(T, Sto(T, oc))
true [actseq; oc :=enc msg, K; actseq
]
T
Enc(T, Sto(T, msg), Sto(T, K))
true [actseq; oc :=dec msg, K; actseq
]
T
Dec(T, Sto(T, msg), Sto(T, K))
true [actseq; oc :=se msg, N; actseq
]
T
Se(T, Sto(T, msg), Sto(T, N))
true [actseq; oc :=se msg, K; actseq
]
T
Se(T, Sto(T, msg), Sto(T, K))
true [actseq; oc :=sd msg, N; actseq
]
T
Sd(T, Sto(T, msg), Sto(T, N))
true [actseq; oc :=sd msg, K; actseq
]
T
Sd(T, Sto(T, msg), Sto(T, K))
true [actseq; oc :=sign msg, K; actseq
]
T
Sign(T, Sto(T, msg), Sto(T, K))
true [actseq; oc :=unsign msg; actseq
]
T
Unsign(T, Sto(T, msg))
true [actseq; verify msg
signed
, K; actseq
]
T
Verify(T, Sto(T, msg
signed
), Sto(T, K))
true [actseq; oc:=msg; actseq
]
T
Assign(T, Sto(T, msg))
true [actseq; assert: msg
1
=msg
2
; actseq
]
T
Assert(T, Sto(T, msg
1
), Sto(T, msg
2
))
Proof: The soundness of axiom schemas AA1 follows from the semantics of the relevant
actions and action_formulas. For example, the semantics of the action_formula
Receive species that the relevant thread must have executed a corresponding receive
action, which is given by the way the axiom schema is stated. Furthermore, there is a
single-assignment condition on locations which ensures that the value of Sto(T, oc)
(namely the contents of the store for location oc in thread T) is really what was received;
that is, the contents of oc could not have been overwritten by another message.
Axiom schemas AA2. These are axiom schemas which state that if a thread has not
performed any action so far then a predicate asserting any action has taken place is false:
Start(T) [ ]
T
Send(T, msg)
Start(T) [ ]
T
Receive(T, msg)
Start(T) [ ]
T
NewNonce(T, msg)
Start(T) [ ]
T
Enc(T, msg, K)
Start(T) [ ]
T
Dec(T, msg, K)
Start(T) [ ]
T
Se(T, msg, N)
Start(T) [ ]
T
Se(T, msg, K)
Start(T) [ ]
T
Sd(T, msg, N)
Start(T) [ ]
T
Sd(T, msg, K)
Start(T) [ ]
T
Sign(T, msg, K)
Start(T) [ ]
T
Unsign(T, msg)
Start(T) [ ]
T
Verify(T, msg, K)
Start(T) [ ]
T
Assign(T, msg)
Start(T) [ ]
T
Assert(T, msg
1
, msg
2
)
Axiom schemas AA3. These axiom schemas allow us to prove that certain messages
are not sent. Note that in this axiom schema and in some other cases below, the sym-
bol > separates the schema part from the axiom (or rule) part: For example,
actseq . . . : > [actseq]
T
means that every instance of [actseq]
T
in which
actseq satises the given condition is an axiom instance of the axiom schema.
actseq that do not contain a send action : > Send(T, msg) [actseq]
T
Send(T, msg)
Send(T, msg) [send msg
]
T
Sto(T, msg
) msg Send(T, msg)

actseq that do not contain a sign action : > Sign(T, msg, K) [actseq]
T
Sign(T, msg, K)
Sign(T, msg, K) [loc :=sign msg
, K
]
T
(Sto(T, msg
) msg Sto(T, K
) K
Sign(T, msg, K))
Axiom schemas AA4 These axiom schemas state that if one action occurs after another,
they are related in the same temporal order:
true [send msg
a
; actseq; send msg
b
]
T
Send(T, Sto(T, msg
a
)) Send(T, Sto(T, msg
b
))
true [send msg
a
; actseq; oc
b
:=receive]
T
Send(T, Sto(T, msg
a
))Receive(T, Sto(T, oc
b
))
true [send msg
a
; actseq; oc
b
:=newnonce]
T
Send(T, Sto(T, msg
a
))NewNonce(T, Sto(T, oc
b
))
true [oc
a
:=receive; actseq; send msg
b
]
T
Receive(T, Sto(T, oc
a
))Send(T, Sto(T, msg
b
))
true [oc
a
:=receive; actseq; oc
b
:=receive]
T
a
b
))
true [oc
a
:=receive; actseq; oc
b
:=newnonce]
T
a
b
))
true [oc
a
:=newnonce; actseq; send msg
b
]
T
NewNonce(T, Sto(T, oc
a
))Send(T, Sto(T, msg
b
))
true [oc
a
:=newnonce; actseq; oc
b
:=receive]
T
a
b
))
true [oc
a
:=newnonce; actseq; oc
b
:=newnonce]
T
a
b
))
similarly for other action_formulas
Proof: The semantics of -nonmodal_formulas is dened by the temporal order be-
tween the indicated newnonce, send, or receive (or other) actions. However, the re-
quired order is guaranteed by any explicit action sequence that lists the actions explicitly
in this order.
Axiom schema AN1. The thread generating a given nonce is unique:
NewNonce(T
1
, msg) NewNonce(T
2
, msg) T
1
= T
2
Axiom schema AN2. Only the generating thread has the nonce just after generation:
true [actseq; oc :=newnonce]
T
Has(T
, Sto(T, oc)) T = T
Axiom schema AN3. A nonce is fresh just after generation:

true [actseq; oc :=newnonce]
T
Fresh(T, Sto(T, oc))
Proof: The semantic conditions on Fresh(T, Sto(T, oc)) require that thread T exe-
cuted a corresponding newnonce action and never sent out any message containing
the new nonce. The former holds because oc :=newnonce is listed as an action executed
by thread T in the modal formula; and the latter holds because this action is listed as the
only action executed by thread T.
Axiom schema AN4. A thread has a fresh nonce only if it generated it:
Fresh(T, msg) NewNonce(T, msg)
Axiom schemas KEY. The axiom schemas for possession and secrecy of keys dis-
tributed according to the protocol setup assumptions depend on the setup assump-
tions. For any key function xk, if the setup assumptions include the specication
(T, Pname) : T.pname = Pname Setup(T, xk(Pname)), stating that xk(Pname)
is known to threads of that principal, then we take all instances of the schema
Has(T, xk(T.pname)) as axioms. Similarly, if the setup assumptions include the speci-
cation (T, Pname) : Setup(T, xk(Pname)), stating that xk(Pname) is known to threads of
all principals, then we take all instances of the schema Has(T, xk(Pname)) as axioms. We
also take secrecy formulas as axiom schemas for each key that is known to the principal
that owns it but not known to others. For the setup assumptions used for protocols in this
chapter (given in Section 3.1), we therefore have the following axiom schemas about key
possession and secrecy:
Has(T, pk (Pname))
Has(T, dk (T.pname))
Has(T, sk (T.pname))
Has(T, vk (Pname))
Has(T, dk (Pname)) Honest(Pname) T.pname = Pname
Has(T, sk (Pname)) Honest(Pname) T.pname = Pname
Axiom schema HAS. The axiom schemas for the Has predicate are partly based on
Dolev-Yao deduction rules:
msg that are strings: , a, ca, hello, . . . : > Has(T, msg)
Has(T, Pname)
NewNonce(T, N) Has(T, N)
Receive(T, msg) Has(T, msg)
Has(T, ( ))
k N : > Has(T, msg
1
) Has(T, msg
2
) . . . Has(T, msg
k
) Has(T,
_
msg
1
, msg
2
, . . . , msg
k
_
)
k N : > Has(T,
_
msg
1
, msg
2
, . . . , msg
k
_
) Has(T, msg
1
) Has(T, msg
2
) . . . Has(T, msg
k
)
K: asym_enc_key : > Has(T, msg) Has(T, K) Has(T, msg
a
K
)
(K, K
) such that (K, K
) is an asymmetric encryption-decryption key pair : >

Has(T, msg
a
K
) Has(T, K
) Has(T, msg)
N: nonce : > Has(T, msg) Has(T, N) Has(T, msg
s
N
)
K: sym_key : > Has(T, msg) Has(T, K) Has(T, msg
s
K
)
Has(T, msg
s
N
) Has(T, N) Has(T, msg)
Has(T, msg
s
K
) Has(T, K) Has(T, msg)
K: sgn_key : > Has(T, msg) Has(T, K) Has(T, msg
K
)
Has(T, msg
K
) Has(T, msg)
Axiom schema SEC. For protocols with condential private keys, i.e., dk (A) declared
in the setup assumptions, the only principal which can decrypt with its own private key
is the principal itself, provided it is honest:
Honest(B) Dec(T, msg
a
pk(B)
, dk (B)) T.pname = B
Axiom schema VER. For protocols with condential signing keys, i.e., sk (A) declared
in the setup assumptions, the only principal which can sign with its own signing key is
the principal itself, provided it is honest:
Honest(A)Verify(T, msg
sk(A)
, vk (A)) T
: T
.pname = ASign(T
, msg, sk (A))
Proof: Let F be any run. If F = Verify(T, msg
sk(A)
, vk (A)), then by denition T exe-
cuted a verify msg
signed
, K

sk(A)
] msg
signed
and F[vk (A)]
K
. By the verify-clause in the denition of feasibility of runs, we know that msg
signed
must have been of the form msg
1
1
with msg
1
1
GenMsg
F
(T.tid). Because of
msg
1
1
= msg
signed
F[msg
sk(A)
], it follows that msg
1
msg and K
1
sk (A).
Let F
1
be the minimum-length run such that F = F
1
: F
2
and msg
1
1
msg
C

GenMsg
F
1
(T
2
.tid) for some thread T
2
and containing message msg
C
. By the way Gen-
Msg is dened, there has to be such a rst time. By analyzing the set of possible last
actions in F
1
, it follows that the last action in F
1
is some oc
2
:=sign msg
2
, K
2
action
such that msg
1
1
F.st(T
2
.tid, oc
2
) = msg
2
K
2
(stored messages clause, GenMsg
denition; sign-clause, feasibility of runs). That the rst time cant have been immedi-
ately after something else (projection, receive, . . . ) can be shown rigorously through an
inductive argument; for instance it couldnt have been a receive action for a message
containing msg
1
1
because then there must have been an earlier corresponding send
action, contradicting minimality of F
1
.
The oc
2
:=sign msg
2
, K
2
action could only have been executed by thread T
2
if at that time it was the case that K
2
GenMsg
F
(T
2
.tid). We also know that
msg
2
msg and K
2
sk (A) (because of msg
1
msg and K
1
sk (A) (both estab-
lished above) and msg
2
K
2
msg
1
1
). Thus, from the action execution we rst get
F = Sign(T
2
, msg
2
, K
2
), which leads us to F = Sign(T
2
, msg, sk (A)) (transitivity of con-
gruence relations and truth conditions of the Sign predicate).
From (1) sk (A) K
2
GenMsg
F
(T
2
.tid), (2) Honest(A) (here, nally honesty
comes into play), and (3) sk (A) : conf_sgn_key (from our setup assumptions), it fol-
lows that T
2
.pname = A. Existential abstraction leads to the consequent of part of the
axiom schema whose proof we are hereby concluding.
Axiom schema IN. This axiom schema provides reasoning principles for when one mes-
sage is contained in another:
msg msg
msg msg
a
K
K msg
a
K
msg msg
s
K
K msg
s
K
msg (. . . , msg, . . .)
msg msg
s
N
N msg
s
N
msg msg
K
K msg
K
Axiom schema NIN. This axiom schema provides reasoning principles for when one
message is not contained in another:
msg is atomic : > msg
msg msg
msg
msg msg
1
msg msg
2
. . . msg msg
n
msg
_
msg
1
, msg
2
, . . . , msg
n
_
msg
_
msg
1
, msg
2
, . . . , msg
n
_
msg
msg msg
K msg
msg
a
K
msg
msg
a
K
msg
msg msg
N msg
msg
s
N
msg
msg
s
N
msg
msg msg
K msg
msg
s
K
msg
msg
s
K
msg
msg msg
K msg
msg
K
msg
msg
K
Axiom schema P1. The predicates Has, Sign, NewNonce, and FirstSend are preserved
across actions:
that are of type Has, Sign, NewNonce, or FirstSend : > [actseq]
T

Axiom schema P2.1. The freshness of a message is preserved across non-send actions:
actseq that do not contain a send action : > Fresh(T, msg) [actseq]
T
Fresh(T, msg)
Axiom schema P2.2. The freshness of a message is preserved across a send action that
does not send something containing the message:
Fresh(T, msg) [send msg
]
T
msg Sto(T, msg
) Fresh(T, msg)
Axiom schema FS1. A nonce is sent rst when it is fresh and the rst send action with
a message containing the nonce occurs:
Fresh(T, msg
1
) [send msg
2
]
T
(msg
1
Sto(T, msg
2
)
NewNonce(T, msg
1
)FirstSend(T, msg
1
, Sto(T, msg
2
)))
Proof: For the action_formula FirstSend to hold, two conditions must be fullled:
(1) msg
1
Sto(T, msg
2
). (2) There is an instance of thread T sending out Sto(T, msg
2
)
such that this is the rst instance of any message being sent out such that msg
1
is a part
of it. Condition (1) holds by the way the axiom schema is stated. Condition (2) holds
because before the send action, msg
1
was fresh.
Axiom schema FS2. If a thread rst sent a nonce msg
1
as part of msg
2
and another thread
received a msg
3
containing msg
1
, then the receive action occurred after the send action:
((NewNonce(T
1
, msg
1
) FirstSend(T
1
, msg
1
, msg
2
))
(T
1
T
2
msg
1
msg
3
Receive(T
2
, msg
3
))
Send(T
1
, msg
2
) Receive(T
2
, msg
3
)
Proof: T
1
is the thread in which msg
1
originates and msg
2
is the rst term sent to the
adversary that contains msg
1
. Therefore no message containing msg
1
is in the Dolev-Yao
closure of the adversary before the send event Send(T
1
, msg
2
). Since T
2
is dierent from
T
1
, msg
1
cannot have been originated in it. Therefore, since T
2
knows the message msg
3
which contains msg
1
, it must have received a message msg from the adversary contain-
ing msg
1
. As observed before, this is only possible after T
1
sent out msg
2
. Therefore
Send(T
1
, msg
2
) Receive(T
2
, msg
3
) is true in this F.
5.2. Rule Schemas
The rule schemas include generic rules G1G4 for reasoning about program pre-
conditions and postconditions, a sequencing rule SEQ, and a novel honesty rule HON
for establishing protocol invariants in the presence of adversaries.
Rule schema G1. Conjunction of post-conditions:
[actseq]
T

1
[actseq]
T

2
[actseq]
T

1

2
Rule schema G2. Disjunction of pre-conditions:
1
[actseq]
T

2
[actseq]
T

1

2
[actseq]
T

Rule schema G3. Strengthening pre-conditions and weakening post-conditions:
[actseq]
T

[actseq]
T


Rule schema G4. True non-modal formulas spawn modal formulas as their post-
condition:
[actseq]
T

Rule schema SEQ. Stringing together two action sequences if post-condition of the for-
mer and pre-condition of the latter agree:
1
[actseq]
T

2

2
[actseq
]
T

3
1
[actseq : actseq
]
T

3
Proof: Assume that the premises are valid and that for a given division (F
1
: F
2
: F
3
)
of run F, the following hold:
1. /: F
1
=
1
2. (F
2
.elist
T
\ F
1
.elist
T
) matches actseq : actseq
Then, it is possible to nd a division (F

1
: F
2
: F
2
) of run F
2
such that:
1. (F
2
.elist
T
\ F
1
.elist
T
) matches actseq.
2. (F
2
.elist
T
\ (F
1
: F
2
).elist
T
) matches actseq
.
Then by the rst premise we get /: F
2
=
2
, and therefore by the second premise we
get /: F
2
=
3
. That is, /: F
2
=
3
.
Rule schema HON. The honesty rule is an invariance rule for proving properties about
the actions of principals that execute roles of a protocol, similar in spirit to the basic in-
variance rule of LTL [27] and invariance rules in other logics of programs. The honesty
rule is often used to combine facts about one role with inferred actions of other roles. For
example, suppose Alice receives a signed response from a message sent to Bob. Alice
may use facts about Bobs role to infer that Bob must have performed certain actions
before sending his reply. This form of reasoning may be sound if Bob is honest, since
honest, by denition in our framework, means follows one or more roles of the proto-
col. The assumption that Bob is honest is essential because the intruder may perform
action sequences that do not conform to the protocol roles.
To a rst approximation, the honesty rule says that if a property holds before each
role starts, and the property is preserved by any sequence of actions that an honest prin-
cipal may perform, then the property holds for every honest principal. An example prop-
erty that can be proved by this method is that if a principal sends a signed message of
a certain form, the principal must have received a request for this response. The proof
of such a property depends on the protocol. For this reason, the antecedent of the hon-
esty rule includes a set of formulas constructed from the set of roles of the protocol in a
systematic way.
One semantic assumption that is eectively built into the honesty rule is that every
honest thread that starts a basic sequence complete all of the actions in the basic se-
quence. We therefore formulate the honesty rule to prove properties that hold at the end
of every basic sequence of every role.
The division of a role into basic sequences is part of the protocol specication the
protocol designer, or the protocol analyst who takes a protocol description and formu-
lates the protocol in PCL, may choose how to partition the actions of a role into basic
sequences. PCL then reasons about the protocol as if any honest principal that starts a
basic sequence does so in a way that allows each projection of a message into parts,
each assert, and each cryptographic operation to succeed. An actual implementation of
a protocol may respect this abstraction by rst determining whether the conditions exist
to complete a basic sequence, and then proceeding with visible actions (such as sending
messages) only under these conditions. If the conditions do not allow the basic sequence
to complete, then the implementation may locally roll back to a state as if the basic
sequence never started. Put another way, we reason about the set of protocol executions
by assuming atomicity of basic sequences of actions. Since a protocol may be formulated
with any desired partition of roles into basic sequences, this is not a limitation of PCL,
but a feature that allows atomicity assumptions to be used in protocol proofs.
Note that all elements of a protocol / are of type List(principal_name) role.
We now state the honesty rule:
Start(T) [ ]
T
p/ : basicseq(p(T.rpars)).bseqs : > [basicseq]
T

Honest(T.pname)
(Here, we assume that the role parameters in T.rpars are all distinct symbols.) Note
that the universal quantiers in this rule expand to a nite conjunction, and thus the rule
can be applied in a nite proof. An example is given in the next section.
Proof: This soundness proof is similar in spirit to the proof of SEQ. Consider a run F
and a thread T, such that the premises hold. Since T belongs to an honest principal, T
must have performed a sequence of actions which is a (possibly empty) concatenation
of basic sequences of some instantiated role p(T.rpars). Let these basic sequences be
basicseq
1
, basicseq
2
, , basicseq
k
(in the order executed). Then it is possible to
nd a division (F
0
: F
1
: . . . : F
k
) of run F, such that F
0
.elist
T
is empty, and for
all i 1, 2, . . . , k, the list of events (F
i
.elist
T
\ F
(i1)
.elist
T
) matches the action
sequence basicseq
i
.
By the rst premise we have /: F
0
= . By successively applying all parts of the
second premise, we rst get /: F
1
= , then /: F
2
= , and nally /: F
k
= . The
latter is identical to /: F = , quod erat demonstrandum.
6. Analysis of the Handshake Protocol
In this section, we present the PCL authentication proof for the handshake protocol in-
troduced in Section 2 and written out formally in Table 2. We also discuss how the proof
fails for the faulty version of the sample protocol.
6.1. Properties
Our formulation of authentication is based on the concept of matching conversations [3]
and is similar to the idea of proving authentication using correspondence assertions [45].
The same basic idea is also presented in [13] where it is referred to as matching records of
runs. Intuitively, this form of authentication requires that whenever Alice and Bob com-
plete their roles, their views of the run must match in the sense that both have the same
record of the actions that occurred and the temporal order between them. More speci-
cally, each message that Alice sent was received by Bob and vice versa, each send event
happened before the corresponding receive event, and so on. In general, authentication
properties are formulated and proved for both the initiator and the responder. However,
in this chapter, we prove authentication from the responders point of view only because
of space constraints. The authentication property Auth
Resp
is dened in Figure 4.
The actions in the modal formula Auth
Resp
are the actions of the responder role of
the protocol. In this example, the precondition is simply true. The postcondition assumes
that idA is honest, so that she faithfully executes portions of some role of the protocol
and does not, for example, send out her private keys. Under this assumption, the postcon-
dition means that after executing the actions in the initiator role purportedly with idA, B
is guaranteed that idA was involved in the protocol and messages were sent and received
in the expected order.
We also show here a secrecy property for this protocol, but omit proofs. A proof sys-
tem to analyze secrecy properties has been developed for an earlier syntax and semantics
of PCL [38,39] but is not covered in this chapter.
Secrecy
Init
: true[Init(A, B)]
T
(Honest(A) Honest(B) A B
Has(T
, k) T
.pname = A T
.pname = B)
(An analogous property Secrecy
Resp
can be dened easily.) The secrecy formula above
asserts that if A completes an initiator role, purportedly with B, then if B is honest, it
is guaranteed that the only threads which can have k belong to principals A or B only.
Similar secrecy properties can be formulated for nonce s as well.
6.2. Proof of Auth
Resp
The main idea of the proof is that the responder veries a signature using the public
verication key of the initiator. If the initiator is assumed honest, then by a basic property
of signatures captured in one of the PCL axioms, the initiator must have signed the
veried message. Using the honesty rule to consider all possible action sequences that
allow an honest thread to sign a message, we show that if the initiator signed the veried
message, then the initiator must have done specic actions in a specic order that lets us
complete the proof.
The main steps
2
of the formal proof are presented in Table 11, with uses of
rule schema G left implicit. The formal proof uses expressions such as T.pname
(=T.rpars.1) and T.rpars.2 for principals. For any thread T, the principal T.pname
is the principal who executes this thread. In addition, if T is executed by an honest prin-
cipal, then T.rpars.1 and T.rpars.2 are the principals supplied as rst and second
parameters to the parameterized role associated with this thread. While for the formal
proof it is technically precise (and convenient) to use T.rpars.1 and T.rpars.2, note
that we often refer to these parameters as A (the initiator) and B (the intended responder).
Using this terminology, the proof can be divided into three parts.
Lines (1)(3): We show that certain actions were performed by B in the responder
role. Specically, we show that B veried As signature siga. We then use the
signature verication axiom (VER) to prove that, if honest, A must have signed
this message.
In lines (4)(5), the honesty rule is used to prove that since A signs a message of
the indicated form, she rst sent k as part of the rst message of the protocol.
2
A full proof together with a sample execution trace for the handshake protocol can be found here: http:
//seclab.stanford.edu/pcl/papers/2010-06_execution-trace_and_full-proof.pdf
1. For the second basic sequence of Init and the rst basic sequence of Resp
(which is the full role), there is no signing action, so we can prove
3
(writing
N&FS(. . .) for NewNonce(. . .) FirstSend(. . .)):
(AA3:) Sign(. . .)[basicseq]Sign(. . .)
(P1:) Sign(. . .) N&FS(. . .)[basicseq]Sign(. . .) N&FS(. . .)
We use G3 on both separately (by weakening the post-conditions), and then
we combine the results using G2:
Sign(. . .) N&FS(. . .)[basicseq]Sign(. . .) N&FS(. . .)
2. For the rst basic sequence of Init, we prove the following:
(AA1, AN3, P2.1, FS1, IN, SEQ:) true[basicseq]Sign(. . .) N&FS(. . .)
(G3:) Sign(. . .) N&FS(. . .)[basicseq]Sign(. . .) N&FS(. . .)
Finally, in lines (7)(8), we again reason about actions executed by B in order
to deduce that the the rst message was sent by A before it was received by B.
Combining the assertions, we show that the authentication property holds: If B
has completed the protocol as a responder, apparently with A, then A must have
sent the rst message (intended for B), and then B sent the second message to A.
In many cases, attempting to prove incorrect security properties in PCL may suggest
ways that a protocol may be repaired to achieve the desired property. If we attempt to
carry out the proof shown in Table 11 for the awed protocol discussed in section 2.1 (and
in other chapters of this book), the attempt fails. In the failed attempt, the closest formula
we can prove using the honesty rule fails to suciently link the Initiator and Responder.
Specically, the provable version of (4) asserts that any honest message signer will rst
send the signed message under a specic encryption key (written pk (T
all
.rpars.2)):
Honest(T
all
.pname) Sign(T
all
,
_
T
all
.pname, k
[T
all
]
_
, sk (T
all
.pname))
NewNonce(T
all
, k
[T
all
]
)
FirstSend
_
T
all
, k
[T
all
]
,
_
_
T
all
.pname, k
[T
all
]
_
sk(T
all
.pname)
_
a
pk(T
all
.rpars.2)
_
However, when we proceed with this formula, the analog of line (5) has an encryption
key in the message sent by the initiator that is not linked to T:
true [Resp(T.pname)]
T
Honest(idA
[T]
)
T
: T
.pname = idA
[T]
NewNonce(T
, k
[T]
)
FirstSend
_
T
, k
[T]
,
_
_
idA
[T]
, k
[T]
_
sk(idA
[T]
)
_
a
pk(T
.rpars.2)
_
Instead of proving that the honest principal idA
[T]
encrypted the message for thread T
(= T.rpars.1), we can only conclude that some thread T
encrypted the signed message

for some unconstrained role parameter T
.rpars.2 of that thread that could be dierent

from the responder. In other words, because the initiator does not include the identity of
the intended responder in the signed message, the responder that receives this message
cannot deduce that the message was intended (encrypted) for him. This failure of the
proof also suggests the attack scenario in which an initiator executing role Init(A, C)
encrypts the signed message for C, who turns out to be dishonest. Dishonest C then
decrypts As message and re-encrypts it for B. When responder B receives this message,
the responder has no guarantee that A intended (encrypted) the message for B.
3
Note that the implication we are proving is interesting only for Init; it is trivially true for Resp. Because
the honesty rule is used to prove authentication when communicating with any honest principal executing any
combination of roles, the honesty rule requires us to consider all roles in the proof.
AA0 true [Resp(T.pname)]
T
siga
[T]
=
_
idA
[T]
, T.rpars.1, k
[T]
_
sk(idA
[T]
)
(1)
AA1, (1) true [Resp(T.pname)]
T
Verify
_
T,
_
idA
[T]
, T.rpars.1, k
[T]
_
sk(idA
[T]
)
, vk
_
idA
[T]
__
(2)
VER, (2) true [Resp(T.pname)]
T
Honest(idA
[T]
)
T
: T
.pname = idA
[T]
Sign
_
T
,
_
idA
[T]
, T.rpars.1, k
[T]
_
, sk
_
idA
[T]
__
(3)
AA2, AA1, AN3, Honest(T
all
.pname) Sign(T
all
,
_
T
all
.pname, T
all
.rpars.2, k
[T
all
]
_
, sk (T
all
.pname))
P2.1, FS1, IN, SEQ, NewNonce(T
all
, k
[T
all
]
)
AA3, P1, HON FirstSend
_
T
all
, k
[T
all
]
,
_
_
T
all
.pname, T
all
.rpars.2, k
[T
all
]
_
sk(T
all
.pname)
_
a
pk(T
all
.rpars.2)
_
(4)
(3), (4) true [Resp(T.pname)]
T
Honest(idA
[T]
)
T
: T
.pname = idA
[T]
NewNonce(T
, k
[T]
)
FirstSend
_
T
, k
[T]
,
_
_
idA
[T]
, T.rpars.1, k
[T]
_
sk(idA
[T]
)
_
a
pk(T.rpars.1)
_
(5)
AA0, AA1, IN, (1) true [Resp(T.pname)]
T
k
[T]
_
idA
[T]
, T.rpars.1, k
[T]
_
sk(idA
[T]
)
_
a
pk(T.rpars.1)
Receive
_
T,
_
_
idA
[T]
, T.rpars.1, k
[T]
_
sk(idA
[T]
)
_
a
pk(T.rpars.1)
_
(6)
FS2, AA0, true [Resp(T.pname)]
T
Honest(idA
[T]
) T
: (T
.pname = idA
[T]
(T
T
(1), (5), (6) Send(T
, enca
[T]
) Receive(T, enca
[T]
))) (7)
AA4, (7) true [Resp(T.pname)]
T
Honest(idA
[T]
) idA
[T]
T.pname T
: T
.pname = idA
[T]
Send(T
, enca
[T]
) Receive(T, enca
[T]
)
Receive(T, enca
[T]
) Send(T, encb
[T]
) (8)
Table 11. Formal proof of Auth
resp
7. Protocol Composition
Principals may participate in multiple protocols in parallel (e.g. SSL and IPSec), pos-
sibly using the same keys. In this section, we dene parallel composition of protocols
and present a sound method for modular reasoning about their security. Because most of
the reasoning principles used in PCL are simple local reasoning about the actions of a
thread executing a role of a protocol, such steps are independent of the protocol that uses
this role. As a result, some properties proved using PCL are preserved when additional
roles are added to the protocol, or if additional actions are added to the end of one or
more roles. The one exception to this characterization, and it is a big one, is the honesty
rule, which is used to prove properties of one thread based on properties of other honest
threads. Therefore, the composition principles of PCL revolve around properties of the
honesty rule and its use. For simplicity, we only consider parallel composition, which in-
volves adding new roles, and leave the details of sequential composition, which involves
extending individual roles with actions of another role, to other presentations.
Two protocols /
1
, /
2
have compatible setup assumptions if the same setup condi-
tions are given in both protocols for every key function that is common to both. For
example, /
1
may assume public keys, and /
2
may assume shared symmetric keys (of
dierent names). Alternately, both may use the same setup assumptions. However, two
protocols do not have compatible setup assumptions if one assumes a key is condential
and the other allows the key to be sent by honest principals.
Lemma 7.1 If /
1
, /
2
have compatible setup assumptions, then the PCL assertions prov-
able about /
i
are unchanged if the setup assumptions of /
i
are replaced by the union of
the setup assumptions of /
1
and /
2
.
Denition (Parallel Composition) If /
1
, /
2
have compatible setup assumptions, then
their parallel composition /
1
/
2
is dened by the union of their roles and the union of
their setup assumptions.
For example, consider the protocol obtained by parallel composition of two versions
of a standard protocol, such as SSL 2.0 and SSL 3.0. By the denition above, a prin-
cipal running their parallel composition may simultaneously engage in sessions of both
protocols. Clearly, a property proved about either protocol individually might no longer
hold when the two are run in parallel, since an adversary might use information acquired
by executing one protocol to attack the other. Since all the axioms and inference rules
in Section 5 except the honesty rule are protocol-independent, the only formulas used in
the proof of one protocol that might no longer be sound for a composition involving that
protocol are formulas proved using the honesty rule, i.e., the protocol invariants. In order
to guarantee that the security properties of the individual protocols are preserved under
parallel composition, it is therefore sucient to verify that each protocol respects the
invariants of the other. This observation suggests the following four-step methodology
for proving properties of the parallel composition of two protocols.
1. Prove separately the security properties of protocols /
1
and /
2
.
-
/
1

1
and -
/
2

2
2. Identify the set of invariants used in the two proofs,
1
and
2
. The formulas
included in these sets will typically be the formulas in the two proofs which
were proved using the honesty rule. The proofs from the previous step can be
decomposed into two parts the rst part proves the protocol invariants using
the honesty rule for the protocol, while the second proves the protocol properties
using the invariants as hypotheses, but without using the honesty rule. Formally:
-
/
1

1
and
1
-
1
and -
/
2

2
and
2
-
2
3. Notice that it is possible to weaken the hypotheses to
1

2
. The proof of the
protocol properties is clearly preserved under a larger set of assumptions.
1

2
-
1
and
1

2
-
2
4. Prove that the invariants,
1

2
, hold for both protocols. This step uses the
transitivity of entailment in the logic: if -
/
and - , then -
/
. Since -
/
1

1
and -
/
2

2
were already proved in step 1, in this step it is sucient to show that
-
/
1

2
and -
/
2

1
. By Lemma 7.2 below, we therefore have -
/
1
/
2

1

2
. From
this and the formulas from step 3, we can conclude that the security properties of
/
1
and /
2
are preserved under their parallel composition.
-
/
1
/
2

1
and -
/
1
/
2

2
Lemma 7.2 If -
/
1
and -
/
2
, then -
/
1
/
2
, where the last step in the proof of in
both /
1
and /
2
uses the honesty rule and no previous step uses the honesty rule.
Proof: Following the consequent of the honesty rule, must be of the form
Honest(T.pname) for some formula . Suppose that can be proved for both /
1
and /
2
using the honesty rule. By the denition of the honesty rule, for i = 1, 2 we have
-
/
i
Start(T) [ ]
T
, and for all p /
i
and for all basicseq (p(T.rpars)).bseqs we
have -
/
i
[basicseq]
T
. Every basic sequence basicseq of a role in /
1
/
2
is a basic
sequence of a role in /
i
for i = 1, 2. It follows that -
/
1
/
2
[basicseq]
T
and, therefore,
by the application of the honesty rule, -
/
1
/
2
Honest(T.pname) . |
Theorem 7.3 If -
/
1
and -
/
2
and - , then -
/
1
/
2
.
8. Related Work
Avariety of methods and tools have been developed for analyzing the security guarantees
provided by network protocols. The main lines of work include specialized logics [4,44,
20], process calculi [1,2,25,35] and tools [28,43], as well as theorem-proving [34,33] and
model-checking methods [26,31,36,41] using general purpose tools. (The cited papers
are representative but not exhaustive; see [29] for a more comprehensive survey.)
There are several dierences among these approaches. While most model-checking
tools can only analyze a nite number of concurrent sessions of a protocol, some of the
logics, process calculi, and theorem-proving techniques yield protocol security proofs
without bounding the number of sessions. With the exception of the BAN family of log-
ics [4], most approaches involve explicit reasoning about possible attacker actions. Fi-
nally, while security properties are interpreted over individual traces in the majority of
these methods, in the process calculi-based techniques, security is dened by an equiva-
lence relation between a real protocol and an ideal protocol, which is secure by construc-
tion. Inspite of these dierences, all of these approaches use the same symbolic model of
protocol execution and attack. This model seems to have developed from positions taken
by Needham-Schroeder [32], Dolev-Yao [14], and subsequent work by others.
PCL shares several features with BAN [4], a specialized protocol logic. It is de-
signed to be a logic for authentication, with relevant secrecy concepts. Both logics an-
notate programs with assertions and use formulas for concepts like freshness, sees,
said, and shared secret. Furthermore, neither logic requires explicit reasoning about
the actions of an attacker.
On the other hand, PCL diers from BAN on some aspects since it addresses known
problems with BAN. BAN had an abstraction step in going from the program for the
protocol to its representation as a logical formula. PCL avoids the abstraction phase
since formulas contain the program for the protocol. PCL uses a dynamic logic set-up:
after a sequence of actions is executed, some property holds in the resulting state. It is
formulated using standard logical concepts: predicate logic and modal operators, with
more or less standard semantics for many predicates and modalities. Temporal operators
can be used to refer specically to actions that have happened and the order in which
they occurred. Formulas are interpreted over traces and the proof system is sound with
respect to the standard symbolic model of protocol execution and attack. On the other
hand, BAN was initially presented without semantics. Although subsequently, model-
theoretic semantics was dened, the interpretation and use of concepts like believes
and jurisdiction remained unclear. Finally, PCL formulas refer to specic states in the
protocol. For example, something may be fresh at one step, but no longer fresh later. In
contrast, BAN statements are persistent, making it less expressive.
PCL also shares several common points with the Inductive Method [34]. Both meth-
ods use the same trace-based model of protocol execution and attack; proofs use induc-
tion and provable protocol properties hold for an unbounded number of sessions. One
dierence is the level of abstraction. Paulson reasons explicitly about traces including
possible intruder actions whereas basic reasoning principles are codied in PCL as ax-
ioms and proof rules. Proofs in PCL are signicantly shorter and do not require any ex-
plicit reasoning about an intruder. Finally, while Paulsons proofs are mechanized using
Isabelle, most proofs in PCL are currently hand-proofs, although the steps needed to
automate PCL in a meta-logic are described in this chapter.
9. Conclusions
Protocol Composition Logic (PCL), summarized and illustrated by example in this chap-
ter, is a formal logic for stating and proving security properties of network protocols.
PCL uses direct reasoning, in the sense that our proof steps reason directly about the
eects of successive protocol steps. PCL proof steps also reason only about the actions
of explicit threads and honest protocol participants. Because of the way that PCL ax-
ioms and rules are proved sound for reasoning about a semantic model that includes an
attacker, there is no need to consider the attacker explicitly in the proof system.
A distinctive goal of PCL is to support compositional reasoning about security pro-
tocols. For example, PCL allows proofs of key-distribution protocols to be combined
with proofs for protocols that use these keys. While the logic was originally developed
for the symbolic Dolev-Yao model of protocol execution and attack used in this chap-
ter, a variant of the logic with similar reasoning principles has also been developed for
the computational model used by cryptographers.
Based on approximately ten years of experience with successive versions of the
logic, PCL appears to scale well to industrial protocols of ve to twenty messages, in
part because PCL proofs appear to be relatively short (for formal proofs). The logic has
been successfully applied to a number of industry standards including SSL/TLS, IEEE
802.11i (marketed as WPA2), and Kerberos V5.
While PCL could be considered a semi-formalized logic for proving properties of
protocols, because we do not give formal proof rules for entailment between precon-
ditions or postconditions, PCL provides an approach for fully formal proofs of secu-
rity properties of protocols using any logic framework supporting the formal syntax and
symbolic semantics presented in this chapter.
Acknowledgements We thank Ante Derek, Nancy Durgin, and Dusko Pavlovic for con-
tributing towards the formulation of PCL, and Michael Backes, Changhua He, Jean-
Pierre Seifert, Mukund Sundararajan and Mathieu Turuani for collaborating on case stud-
ies that improved the logic. Computational PCL began as joint work with Ante Derek,
Vitaly Shmatikov, Mathieu Turuani, and Bogdan Warinschi.
References
[1] M. Abadi and A. Gordon. A calculus for cryptographic protocols: the spi calculus. Information and
Computation, 148(1):170, 1999. Expanded version available as SRC Research Report 149 (January
1998).
[2] Martn Abadi and Cdric Fournet. Mobile values, new names, and secure communication. In 28th ACM
Symposium on Principles of Programming Languages, pages 104115, 2001.
[3] M. Bellare and P. Rogaway. Entity authentication and key distribution. In Advances in Cryprtology -
Crypto 93 Proceedings, pages 232249. Springer-Verlag, 1994.
[4] M. Burrows, M. Abadi, and R. Needham. A logic of authentication. ACM Transactions on Computer
Systems, 8(1):1836, 1990.
[5] Anupam Datta, Ante Derek, John C. Mitchell, and Dusko Pavlovic. A derivation system for security
protocols and its logical formalization. In Proceedings of 16th IEEE Computer Security Foundations
Workshop, pages 109125. IEEE, 2003.
[6] Anupam Datta, Ante Derek, John C. Mitchell, and Dusko Pavlovic. Secure protocol composition (ex-
tended abstract). In Proceedings of ACM Workshop on Formal Methods in Security Engineering, pages
1123, 2003.
[7] Anupam Datta, Ante Derek, John C. Mitchell, and Dusko Pavlovic. Abstraction and renement in
protocol derivation. In Proceedings of 17th IEEE Computer Security Foundations Workshop, pages
3045. IEEE, 2004.
[8] AnupamDatta, Ante Derek, John C. Mitchell, and Dusko Pavlovic. Secure protocol composition. In Pro-
ceedings of 19th Annual Conference on Mathematical Foundations of Programming Semantics. ENTCS,
2004.
[9] Anupam Datta, Ante Derek, John C. Mitchell, and Dusko Pavlovic. A derivation system and composi-
tional logic for security protocols. Journal of Computer Security, 13(3):423482, 2005.
[10] Anupam Datta, Ante Derek, John C. Mitchell, and Arnab Roy. Protocol Composition Logic (PCL). In
Computation, Meaning end Logic: Articles dedicated to Gordon Plotkin, volume 172, pages 311358.
Electronic Notes in Theoretical Computer Science, 2007.
[11] Anupam Datta, Ante Derek, John C. Mitchell, Vitaly Shmatikov, and Mathieu Turuani. Probabilistic
polynomial-time semantics for a protocol security logic. In Proceedings of the 32nd International Col-
loquium on Automata, Languages and Programming (ICALP 05), Lecture Notes in Computer Science,
pages 1629. Springer-Verlag, 2005.
[12] Anupam Datta, Ante Derek, John C. Mitchell, and Bogdan Warinschi. Computationally sound compo-
sitional logic for key exchange protocols. In Proceedings of 19th IEEE Computer Security Foundations
Workshop, pages 321334. IEEE, 2006.
[13] W. Die, P. C. Van Oorschot, and M. J. Wiener. Authentication and authenticated key exchanges.
Designs, Codes and Cryptography, 2:107125, 1992.
[14] D. Dolev and A. Yao. On the security of public-key protocols. IEEE Transactions on Information
Theory, 2(29), 1983.
[15] N. A. Durgin, P. D. Lincoln, J. C. Mitchell, and A. Scedrov. Undecidability of bounded security proto-
cols. In Workshop on Formal Methods and Security Protocols, 1999.
[16] Nancy Durgin, Patrick Lincoln, John Mitchell, and Andre Scedrov. Multiset rewriting and the complex-
ity of bounded security protocols. J. Comput. Secur., 12(2):247311, 2004.
[17] Nancy Durgin, John C. Mitchell, and Dusko Pavlovic. A compositional logic for protocol correctness.
In Proceedings of 14th IEEE Computer Security Foundations Workshop, pages 241255. IEEE, 2001.
[18] Nancy Durgin, John C. Mitchell, and Dusko Pavlovic. A compositional logic for proving security prop-
erties of protocols. Journal of Computer Security, 11:677721, 2003.
[19] Joseph A. Goguen and Jos Meseguer. Order-sorted algebra i: Equational deduction for multiple inher-
itance, overloading, exceptions and partial operations. Theor. Comput. Sci., 105(2):217273, 1992.
[20] Li Gong, Roger Needham, and Raphael Yahalom. Reasoning About Belief in Cryptographic Proto-
cols. In Deborah Cooper and Teresa Lunt, editors, Proceedings 1990 IEEE Symposium on Research in
Security and Privacy, pages 234248. IEEE Computer Society, 1990.
[21] David Harel, Dexter Kozen, and Jerzy Tiuryn. Dynamic Logic. Foundations of Computing. MIT Press,
2000.
[22] Robert Harper, Furio Honsell, and Gordon D. Plotkin. A framework for dening logics. In LICS, pages
194204. IEEE Computer Society, 1987.
[23] Changhua He, Mukund Sundararajan, Anupam Datta, Ante Derek, and John C. Mitchell. A modular
correctness proof of IEEE 802.11i and TLS. In CCS 05: Proceedings of the 12th ACM conference on
Computer and communications security, pages 215, 2005.
[24] C. A. R. Hoare. An axiomatic basis for computer programming. Communications of the ACM,
12(10):576580, 1969.
[25] Patrick D. Lincoln, John C. Mitchell, Mark Mitchell, and Andre Scedrov. Probabilistic polynomial-time
equivalence and security protocols. In Formal Methods World Congress, vol. I, number 1708 in Lecture
Notes in Computer Science, pages 776793. Springer-Verlag, 1999.
[26] G. Lowe. Some new attacks upon security protocols. In Proceedings of 9th IEEE Computer Security
Foundations Workshop, pages 162169. IEEE, 1996.
[27] Z. Manna and A. Pnueli. Temporal Verication of Reactive Systems: Safety. Springer-Verlag, 1995.
[28] C. Meadows. The NRL protocol analyzer: An overview. Journal of Logic Programming, 26(2):113131,
1996.
[29] C. Meadows. Open issues in formal methods for cryptographic protocol analysis. In Proceedings of
DISCEX 2000, pages 237250. IEEE, 2000.
[30] J. C. Mitchell, V. Shmatikov, and U. Stern. Finite-state analysis of ssl 3.0. In Proceedings of the Seventh
USENIX Security Symposium, pages 201216, 1998.
[31] J.C. Mitchell, M. Mitchell, and U. Stern. Automated analysis of cryptographic protocols using Mur.
In Proc. IEEE Symp. Security and Privacy, pages 141151, 1997.
[32] R.M. Needham and M.D. Schroeder. Using encryption for authentication in large networks of comput-
ers. Communications of the ACM, 21(12):993999, 1978.
[33] L.C. Paulson. Mechanized proofs for a recursive authentication protocol. In Proceedings of 10th IEEE
Computer Security Foundations Workshop, pages 8495, 1997.
[34] L.C. Paulson. Proving properties of security protocols by induction. In Proceedings of 10th IEEE
Computer Security Foundations Workshop, pages 7083, 1997.
[35] Ajith Ramanathan, John C. Mitchell, Andre Scedrov, and Vanessa Teague. Probabilistic bisimulation
and equivalence for security analysis of network protocols. In Foundations of Software Science and
Computation Structures, 7th International Conference, FOSSACS 2004, Proceedings, volume 2987 of
Lecture Notes in Computer Science, pages 468483. Springer-Verlag, 2004.
[36] A. W. Roscoe. Modelling and verifying key-exchange protocols using CSP and FDR. In 8th IEEE
Computer Security Foundations Workshop, pages 98107. IEEE Computer Soc Press, 1995.
[37] Arnab Roy, Anupam Datta, Ante Derek, and John C. Mitchell. Inductive proofs of computational se-
crecy. In Joachim Biskup and Javier Lopez, editors, ESORICS, volume 4734 of Lecture Notes in Com-
puter Science, pages 219234. Springer, 2007.
[38] Arnab Roy, Anupam Datta, Ante Derek, John C. Mitchell, and Jean-Pierre Seifert. Secrecy analysis
in Protocol Composition Logic. In Proceedings of 11th Annual Asian Computing Science Conference,
2006.
[39] Arnab Roy, Anupam Datta, Ante Derek, John C. Mitchell, and Jean-Pierre Seifert. Secrecy analysis in
protocol composition logic. In Formal Logical Methods for System Security and Correctness, IOS Press,
2008. Volume based on presentations at Summer School 2007, Formal Logical Methods for System
Security and Correctness, Marktoberdorf, Germany, 2008.
[40] Arnab Roy, Anupam Datta, and John C. Mitchell. Formal proofs of cryptographic security of Die-
Hellman-based protocols. In Trustworthy Global Computing (TGC), pages 312329. Springer, 2007.
[41] S. Schneider. Security properties and CSP. In IEEE Symp. Security and Privacy, 1996.
[42] Steve Schneider. Verifying authentication protocols with csp. IEEE Transactions on Software Engineer-
ing, pages 74158, 1998.
[43] D. Song. Athena: a new ecient automatic checker for security protocol analysis. In Proceedings of
12th IEEE Computer Security Foundations Workshop, pages 192202. IEEE, 1999.
[44] P. Syverson and P.C. van Oorschot. On unifying some cryptographic protocol logics. In Proceedings of
7th IEEE Computer Security Foundations Workshop, pages 1429, 1994.
[45] T. Y. C. Woo and S. C. Lam. A semantic model for authentication protocols. In Proceedings IEEE
Symposium on Research in Security and Privacy, 1993.
Shapes: Surveying
Crypto Protocol Runs
1
Joshua D. GUTTMAN
Worcester Polytechnic Institute
Abstract. Given a cryptographic protocol, and some assumptions, can we present
everything that can happen, subject to these assumptions? The assumptions may
include: (i) some behavior assumed to have occurred, (ii) some keys assumed to
be uncompromised, and (iii) some values assumed to have been freshly chosen. An
object representing these types of information is called a skeleton.
The shapes for a skeleton are the minimal, essentially different executions that
are compatible with the assumptions in . The set of shapes for an is frequently
but not always nite. Given a nite set of shapes for , it is evident whether a
security goal such as authentication or condentiality holds for .
In this paper, we describe a search that nds the shapes, starting from a protocol
and a skeleton . The search is driven by the challenge-response patterns formal-
ized in the strand space authentication tests.
1. Initial Examples
We develop here a search technique for nding the minimal, essentially different exe-
cutions possible in a protocol, starting from some initial behavioral assumptions. This
search gives counterexamples to false authentication and condentiality assertions. Al-
ternatively, the search proves these properties, when they hold and the search terminates,
as it commonly though not universally does.
We start with intuitive analyses, using Blanchets Simple Example Protocol [2] (see
Fig. 1), and then proceed to formalize and justify them. Blanchets protocol SEP requires
an initiator to generate a fresh symmetric key , sign and encrypt it for a chosen
responder , and await reception of a message {}
.
2
Any responder will await a
message containing a signed and encrypted , at which point it will select a secret to
transmit encrypted with . A strand is a nite sequence of transmissions and receptions,
so the actions of the initiator or responder in a single local session form a strand. Strands
1
Partly supported by the National Science Foundation, grant CNS-0952287. Preliminary versions of some
of this material appeared in [7,6], written jointly with Shaddin Doghmi and Javier Thayer. That work
was funded partly by MITRE-Sponsored Research, and partly by the National Security Agency. Address:
guttman@{wpi.edu, mitre.org}.
2
Since we frequently refer to sets, we reserve {vs} for set formation. We write {}
for the encryption

of plaintext using key . If and its inverse decryption key are equal, i.e. =
1
, then {}
is a
symmetric encryption, and otherwise the encryption is asymmetric.
We model digital signature by asymmetric encryption. A private encryption key prepares the signed
message {}
; to verify the latter, one uses the public inverse

1
, recovering . A hash is an encryption
with a public key, for which no one has the matching decryption key.
IOS Press, 2011
doi:10.3233/978-1-60750-714-7-222
222
{{}
sk()
}
pk()
{}
{{}
sk()
}
pk()
{}
Figure 1. SEP: Blanchets Simple Example Protocol

are written either vertically or horizontally as sequences of nodes connected by double
arrows . When
1
follows
0
on a strand, although possibly not immediately, then
0

+
1
.
Informally, a strand is the activity of some principal. It is the activity of a principal
if it requires using a secret known only by , such as s (uncompromised) signing
key, or the (uncompromised) decryption key that matches s public encryption key.
However, in the formal model this principal is largely irrelevant, apart from its name,
which appears as a parameter in the template dening the role. The principal parameter
of the initiator role in Fig. 1 is and the principal parameter of the responder role is .
Our model also omits some information that is required in practice, such as the
intended recipient of a message, and an indication of which key to use to decrypt it. This
information is at the mercy of an adversary controlling the network. Thus, the remaining
ingredients of the protocol must still be able to prevent security failures, even if these
indications are misleading, so we can simplify the model by omitting them.
1.1. s Point of View
We start by exploring s point of view. We assume that has engaged in one or more
steps of a local session of SEP, and we ask what other behavior must occur in any possible
execution containing this behavior.
This is the point-of-view principle: knows that he engaged in these steps of his
local session. He would like to infer as much as possible about what other behavior must
have occurred, or could not have occurred.
The point of view principle is central to protocol analysis, which is largely the ac-
tivity of exploring what behaviors are possible, given some initially assumed behavior.
This initial assumed behavior is usually a run (or part of a run) of one principal. In that
case, the analysis tells us what behavior must have occurred in the distributed system,
from the point of view of that principal.
Secrecy of the session key . Suppose that an initiator has executed at least the rst
node of a session, transmitting a session key within a message {{}
sk()
}
pk()
. Is
guaranteed that an adversary can never obtain the value in a form protected by no
encryption? The answer is no, in at least two cases.
1. When the key generator chosing lacks randomness: An adversary may then
generate the candidate keys and (possibly) test which was sent.
Alternatively, the way was chosen may ensure that it is fresh and unguessable;
we use the term uniquely originating for such a .
originates for this transmission, and any other place it is sent or received
must then derive in an understandable way from this transmission or its later
J.D. Guttman / Shapes: Surveying Crypto Protocol Runs 223
{{}
sk()
}
pk()

non = {pk()
1
} unique = {}
Figure 2. Skeleton
0
: Disclosure of ?
transformed forms. An adversarys generate-and-test would be a separate point
of origination for the same value. Likewise, if a protocol participant were, by bad
luck, to generate the same for another run, that would be an additional point
of origination for . A reasonable cryptographic implementation of SEP should
ensure that these events are of negligible likelihood.
2. When s private decryption key pk()
1
is compromised: An adversary can
then extract the signed unit from {{}
sk()
}
pk()
, check the signature, and ex-
tract .
It is irrelevant whether does this ( is dishonest) or whether s secret
pk()
1
has fallen into the hands of a malicious party. In either case, s private
decryption key has been used in a way that is not stipulated in the protocol de-
nition. Thus, we say that a key is uncompromised if it is used only in accordance
with the protocol under analysis.
In our formalism, a key used contrary to the stipulations of the protocol must al-
ways originate. Thus, we call an uncompromised long-term key non-originating.
A strand of the protocol is called a regular strand. Thus, all local behaviors divide into
regular strands and adversary behaviors. We sometimes say that a principal is regular
if its private keys are used only in regular strands.
Is there any third way that an adversary could obtain the key ?
To answer this question, we carry out an experiment. We start with a diagram
(Fig. 2), representing a transmission of {{}
sk()
}
pk()
and the reception of , some-
how shorn of all cryptographic protection. We call a node like the right hand node of
Fig. 2 a listener node, since it listens, and hears the value , thereby witnessing that
has been disclosed. The diagram also incorporates the assumption that neither case 1
nor case 2 above applies, i.e. is uniquely originating and pk()
1
is non-originating,
which we express as unique = {} and non = {pk()
1
}. Can we embed Fig. 2 into a
more informative diagram representing a possible execution?
To answer this question, we appeal to a minimality principle. It states that in any
execution, if a set of transmission and reception nodes is non-empty, then has some
earliest member. Moreover, if is dened by the contents of the messages, then any
earliest node in is a transmission node. The message must have been sent before it
could have been received.
Since in
0
, there is a node in which appears without any sort of encryption, by
the minimality principle, there is a transmission node which is the earliest point at which
appears outside of the cryptographic protection of {{}
sk()
}
pk()
. If the adversary
could use pk()
1
, this could occur via an adversary decryption, but the assumption
pk()
1
non excludes this. If the adversary could be lucky enough to re-originate
the same , then this re-origination would be an earliest transmission unprotected by
{{}
sk()
}
pk()
. The assumption unique = {} excludes this. Thus, any earliest trans-
mission of outside the form {{}
sk()
}
pk()
lies on a regular strand of the protocol.
However, when we examine Fig. 1, we see that a symmetric key is received by a
participant only on the rst node of a responder strand. This key however is not retrans-
mitted; instead, is used to encrypt the payload , and the ciphertext {}
can never
lead to the disclosure of . A principal that already knows can use it to obtain , but
a principal that does not yet have information about cannot obtain from {}
. If an
adversary can recognize and has a hypothesis about the value of , then it can use the
message {}
to check the hypothesis. However, we will be concerned only with full

disclosure, not with a subtler notion of secrecy that resists hypothesis checking.
We have now exhausted all the possibilities.
0
is a dead end. No enrichment of
0
can be an execution that can possibly occur. We call it a dead skeleton.
This conclusion relies on a principle central to the search for shapes:
Principle 1.1 (The Nonce Test) Suppose that unique, and is found in some mes-
sage received in a skeleton at a node
1
. Moreover, suppose that, in the message of
1
, is found outside all of a number of encrypted forms {
1
}
1
, . . . , {
. Then in
any enrichment of such that is a possible execution, either:
1. One of the matching decryption keys
1
is disclosed before
1
occurs, so that
could be extracted by the adversary; or else
2. Some regular strand contains a node
1
in which is transmitted outside
{
1
}
1
, . . . , {
, but in all previous nodes

0

+
1
, was found (if at
all) only within these encryptions. Moreover,
1
occurs before
1
.
This says that if is extracted from the encrypted forms, then, in any possible execution,
either the adversary can do so (Case 1), which we witness by adding a listener node for
a decryption key
1
; or else some regular strand has done so (Case 2). We have just
applied Principle 1.1 in the case where = , = 1,
1
= pk(), and
1
= {}
sk()
.
In this application, Case 1 was excluded by the assumption pk()
1
non. The protocol
in Fig. 1 does not furnish any instance of the behavior described in Case 2. Hence the
dead end.
We use the list {
1
}
1
, . . . , {
because a protocol may re-use a nonce sev-

eral times. After a nonce has been transmitted inside the encryption {
1
}
1
and re-
ceived back inside the encryption {
2
}
2
, it may be retransmitted inside the encryption
{
3
}
3
. If it is ever received back in some new form {
4
}
4
, then that transformation
needs an explanation of one of the two forms mentioned in Principle 1.1. If it is ever
received back with no further encryption, then it can no longer be reused in this way.
s Authentication Guarantee. Suppose that an initiator has executed a local session
of its role in SEP. What forms are possible for the execution as a whole global behavior?
In exploring this question, we will make the same assumptions about non and unique.
Thus, we represent this graphically in the form shown in Fig. 3, where for brevity we
write
0
= {{}
sk()
}
pk()
. We again ask what explanations could exist for the various
nodes, i.e. what enrichment could elaborate into a skeleton that represents a possible
execution. The rst node requires no explanation, since transmits {{}
sk()
}
pk()
just as the protocol indicates.
By contrast, the second node, s reception of {}
, does require an explanation:

Where did {}
come from?
0
{}
non = {pk()
1
} unique = {}
Figure 3. Skeleton ;
0
is {{}
sk()
}
pk()
{}

1
or

{{}
sk()
}
pk()
2

{}

{}
non = {pk()
1
} unique = {}
Figure 4. Analysis of , Step 1;
0
is {{}
sk()
}
pk()
1. Possibly is disclosed to the adversary, who then prepared the message {}
.
We may test this candidate explanation by adding a listener node to witness dis-
closure of the encryption key .
2. Alternatively, we may add a strand of the protocol, including a node that transmits
{}
. As is evident from Fig. 1, this must be the second node of a responder

strand. However, what values are possible for the other parameters of the strand,
i.e. the names of the initiator and responder in this session? We will postpone the
question by choosing new, unconstrained values , .
This leads us to the two descendants of , shown as
1
,
2
in Fig. 4. We may now
immediately exclude
1
. It must be a dead end, because it is an enrichment of
0
in
Fig. 2. If any enrichment of
1
were a possible execution, then it would be the enrichment
of an enrichment of
0
, andsince the composition of enrichments is an enrichment
some enrichment of
0
would be a possible execution.
Turning to
2
, it has an unexplained node, the upper right node
receiving
{{}
sk()
}
pk()
. If it happens that = and = , then nothing further need be
done.
Otherwise, we may apply Principle 1.1. The value , having been previously
observed only in the form
0
, is now received on
in a different form, namely

{{}
sk()
}
pk()
. Since pk()
1
non, case 1 does not apply. We must thus have a
regular strand that receives only within the encrypted form
0
and retransmits it outside
of
0
. However, in analyzing
0
, we have already seen that the protocol contains no such
strand.
Thus, we are left with the single case of
2
in which = and = , which
is the desired execution
21
shown in Fig. 5. The index 21 is meant to indicate the path
along which it was encountered, as the sole child of
2
, which is itself the rightmost

{}

{}
non = {pk()
1
} unique = {}
Figure 5. Analysis of , Step 2: Its shape
21
child of .
21
is the sole shape for : Any execution compatible with must contain
at least the behavior shown in
21
.
We have made use of two additional principles in this analysis. One asserts that death
persists; the other concerns the origin of encrypted messages.
Principle 1.2 If a skeleton is dead, then so is any enrichment of .
We applied Principle 1.2 to discard
1
.
Principle 1.3 (The Encryption Test, 1) Suppose that {}
is found in some message

received in a skeleton at a node
1
. Then in any enrichment of such that is a
possible execution, either:
1. The encryption key is disclosed before
1
occurs, so that the adversary could
construct {}
from ; or else
2. A regular strand contains a node
1
in which {}
is transmitted, but no earlier

node
0

+
1
contains {}
. Moreover,
1
occurs before
1
.
We applied Principle 1.3 to construct skeletons
1
,
2
, using the instance = and
= . Case 1 furnished
1
and Case 2 yielded
2
. The node
1
is the later (reception)
node of , and
1
is the lower right transmission node in
2
.
We will strengthen Principle 1.3 and combine it in a single form with Principle 1.1,
resulting in the Authentication Test Principle, Theorem 5.5 of Section 5.
Secrecy of . Can be sure that the value remains a secret between and ? To test
this, we start with an expansion of skeleton in which there is also a listener node that
observes shorn of all cryptographic protection, as shown in the left portion of Fig. 6.
The question is only relevant if is assumed fresh and unguessable. is an enrichment of
. Every execution enriching must contain at least the structure we found in
21
, and it
must also contain the listener node for . Thus, it must be an enrichment of
21
. Now, at
this point we can apply Principle 1.1, instantiating = and node
1
being the listener
at the lower right. The index = 1, and the encrypted form containing is {}
. Since
is a symmetric session key,
1
= . Since no regular strand of SEP receives a value
encrypted by a symmetric key and retransmits that value in any other form, Case 2 of the
principle is vacuous. Thus, we add a listener node for , witnessing for its disclosure,
obtaining
211
in Fig. 7.
211
is dead as a consequence of Principle 1.2, since
211
certainly enriches the dead skeleton
0
in Fig. 2.
Thus, SEP fullls its goals, from the point of view of an initiator .
In the step from to
21
, we used an additional principle:
0
{}

{}

{}

non = {pk()
1
} unique = {, }
Figure 6. Skeletons and
21

{}

{}

non = {pk()
1
} unique = {, }
Figure 7. Dead skeleton
211

{{}
sk()
}
pk()

sk(), pk()
1
non
Figure 8. Skeleton : s Point of View, and its shape
1
Principle 1.4 Suppose that has the shapes
1
, . . . ,
. If enriches , then every

execution enriching is an enrichment of some
, where 1 .
Since had the single shape
21
, we applied Principle 1.4 with = 1 and
1
=
21
,
allowing us to jump right from to
21
. We could also have reconstructed its contents
using several applications of the other principles.
1.2. s Point of View
The story is quite different when we turn to the point of view of a responder .
s Authentication Guarantee. Suppose that a responder has received a mes-
sage of the form
0
= {{}
sk()
}
pk()
. Assuming now, in skeleton of Fig. 8, that
both s private signature key sk() and s private decryption key pk()
1
are non-
originating, what else must have happened in any enrichment of that is a possible
execution? We may try to apply Principle 1.3 again, where the encrypted unit {}
is
0
= {{}
sk()
}
pk()
. However, Case 1 then requires only that the public encryption
key pk() of is available to the adversary, from which we learn nothing.
{{}
sk()
}
pk()
{}
{{}
sk()
}
pk()
{}
Figure 9. SEPC: the Simple Example Protocol Corrected

{{}
sk()
}
pk()

{{}
sk()
}
pk()

{{}
sk()
}
pk()

sk(), pk()
1
non
Figure 10. Skeleton : s Point of View, and its shape
1
We may more protably apply Principle 1.3 by taking the encrypted unit {}
to
be {}
sk()
. Since the key sk() is non-originating, Case 1 is vacuous. Thus, every
possible execution must include an enrichment with a regular node producing {}
sk()
.
By Fig. 1, this must be the rst node of an initiator strand. We know that the parameter
representing the initiators name is , and the parameter representing the session key
has the value . However, we know nothing about the remaining parameter appearing
in an initiators rst node, i.e. the name of the intended responder. Since this value is
unconstrained, we ll it in with some new , thus obtaining the skeleton
1
.
Unfortunately, we cannot collect any more information about the parameter , un-
like our situation in skeleton
2
(Fig. 4).
1
contains all of the regular behavior needed
for an execution. It is the sole shape for .
Nothing says that s decryption key is uncompromised, so the adversary can de-
crypt the outer layer, using the public key pk() to re-encrypt {}
sk()
in the desired
form. Evidently, the session key may also be disclosed in this process. Thus, in SEP, a
responder does get a guarantee that initiated a session with key . However, since
may have chosen a compromised party as partner for that conversation, cannot
count on much, certainly not that , or any encrypted with , will remain condential.
1.3. Correcting SEP
Principles 1.1 and 1.3 are central to protocol design [9] as well as to protocol analy-
sis [7]. In SEP, our analysis of s guarantee applied Principle 1.3 to the critical term
{}
sk()
. Since this term involves only the two parameters , , evidently this cannot
force agreement on a particular responder .
To force to agree with on the responder, it sufces to add s name to this crit-
ical term. The resulting protocol SEPC takes the form given in Fig. 9. s authentication
result is shown in Fig. 10.
If we add to
1
a listener node for , and assume uniquely originating, the resulting
skeleton is an enrichment of the SEPC analogue to
0
. It again follows that cannot be
disclosed. When we extend s strand to include its second node, transmitting {}
, it
will also lead to the conclusion that is undisclosed.
Our correction of SEP is tighter or more minimal than Blanchets [2], where the
signed unit {}
sk()
is used. The occurrence of is unnecessary here. Prin-
ciple 1.3 helped identify exactly the parameters need to appear in the critical term to
achieve the protocol renement.
1.4. Goals of this Chapter
Blanchets Simple Example Protocol has illustrated the idea that, from a particular start-
ing point, one can nd all of the minimal, essentially different things that can happen,
compatible with that starting point. We call the minimal, essentially different executions
compatible with a starting point its shapes.
This chapter describes a search procedure that nds shapes systematically. Each
search step from the starting point adds information to , until the search has found be-
havior of the regular (uncompromised) participants, whichwhen combined with some
activity of the adversaryyields a full execution. Each search step increases information;
i.e. it is an enrichment in the sense we will formalize in the notion of homomorphism
(Def. 3.6).
There are three important ways to add information. We can add information by
adding listener nodes to witness for the assumption that a value is disclosed (Case 1 of
Principles 1.1 and 1.3). We can add information by adding new protocol message trans-
missions that help to explain the messages that have been received (Case 2 of Princi-
ples 1.1 and 1.3). And we can add information by identifying different parameters, as
we identied and with and respectively, to produce skeleton
21
. When there
are different possible ways to explain some one aspect of existing behavior, the search
branches. We implemented this search in a tool called CPSA, a Cryptographic Protocol
Shape Analyzer [17].
The purpose of this chapter is to present a theory underlying CPSA. The now very
informative software that implement this theoryspecied, from a different point of
view, in [18]will be the subject on another occasion. We prove three main results about
the search steps as a process of renement leading to shapes:
1. The search steps are sound (Thm. 6.7), so thatwhen we take a stepevery pos-
sible execution compatible with the assumptions before the step is still compati-
ble on at least one branch after the step.
2. The search steps are nitely branching (Thm. 6.8), so that each step produces
only nitely many new skeletons to explore.
3. The search steps are complete (Thm. 6.5), so that every shape is reached by some
nite sequence of search steps.
These results do not imply decidability for security goals, since the search may enumer-
ate an innite set of shapes. If one of these is a counterexample to a goal, then we cer-
tainly learn the goal is false. However, if a goal is in fact true, but has innitely many
shapes, then we cannot be sure it is true at any nite stage.
The shape search is related to Athena [19], which also searched for executions that
extend a given partial description. Athenas representation included adversary behav-
ior as well as regular strands. Athena used a more straightforward backward search,
in which the tool seeks all possible transmission pointswhether adversary actions or
regular strandsfor each component of a reception node that cannot yet be explained.
Athena later incorporated an early version of the authentication test method (Princi-
ples 1.1 and 1.3) to prune its search [15]. Cremerss Scyther [5,4] rened Athenas ideas,
combining them with the notion of characterization [8], which we describe below in
Section 3.3. Unlike our search, Scyther can provide a bounded-session analysis when
the unbounded-session analysis proves too costly, and this is an advantage. Our work
differs in its emphasis on the authentication test method, and in its systematic treatment
of enrichment via the skeletons-and-homomorphisms theory of Section 3.
1.5. Structure of this Chapter
Principles 1.1 and 1.3 have a different character from Principles 1.2 and 1.4. The former
determine the potential explanations for unexplained behavior, and they drive the form
of the search steps. By contrast, the latter are general observations about skeletons, about
enrichments or homomorphismsas we will call thembetween them, and about exe-
cutions. We will examine the latter in Section 3, after introducing the basic strand space
terminology in Section 2.
Section 4 introduces a second example, a modied form of the Trusted Computing
Groups protocol for constructing certicates for Attestation Identity Keys [1]. This sug-
gests a strengthened version of Principle 1.3, which is parallel with Principle 1.1 in form.
Section 5 states a combined version of Principles 1.1 and 1.3, showing that they charac-
terize when a skeleton is an execution (Thm. 5.5). Section 6 denes the search algorithm,
and concludes with the three main results.
2. Messages, Strands, Protocols
In our examples in Section 1, the strands send and receive messages that are built up using
tupling, written
0
1
, and encryption, written {}
. The basic values that contribute

to messages are keys such as or sk(), names , , etc., and payloads such as . We
provide more information about the messages in Sections 2.12.3. Sections 2.4 and 2.5
dene strands and protocols respectively.
2.1. Algebras of Messages
We regard the messages as forming an algebra M. M is closed under the two operations
of tupling and encryption. We allow tupling to take a tag, selected from some set TAG,
and any number 0 messages, to produce a message. The tags serve as a kind of
constant to conveniently distinguish among different forms of message, and they may
be implemented using distinctive bit-patterns inside messages. Encryption applies to two
messages, one representing the plaintext and the other representing the key.
Denition 2.1 Let X be an innite set of objects called indeterminates, and let B be an
algebra of objects called basic values, disjoint from the indeterminates. Let TAG be a
disjoint set of objects called tags.
An algebra M
X
[B] of messages is freely generated from X, B by two operations:
Tagged Tupling If tag TAG and
1
, . . . ,
M
X
[B], for 0, then the tagged
-tuple tag
1
. . .
is in M
X
[B].
Encryption If
1
,
2
M
X
[B], then their encryption {
1
}
2
M
X
[B].
We stipulate that there is a distinguished tag null TAG, and we write null
1
. . .
in the form
1
. . .
. That is, the tag null is invisible; the examples in Section 1 and
most of those later in this chapter use null .
We refer to M
X
[B] as an algebra, because we are interested in its homomorphisms.
We focus on its homomorphisms M
X
[B] M
X
[B] to itself (endomorphisms). We will
not fully specify B, but will give a sample algebra in Section 2.2, and in Section 2.3 we
will identify the crucial properties we will depend on for the later development. Each B
will be equipped with its own homomorphisms B B.
We often omit X or both X and B, and write M or M[B].
Denition 2.2 A homomorphism M M is a pair = (, ), where : B B is a
homomorphism on B and is a function : X M. It is dened for all M by the
conditions:
() = (), if B ({
0
}
1
) = {(
0
)}
(
1
)
() = (), if X (tag
1
. . .
) = tag (
1
) . . . (
)
Indeterminates are untyped blank slots, replaceable by any message. Tags remain
constant under homomorphisms. Messages are abstract syntax trees:
Denition 2.3 1. Let and be the partial functions where:
= {
1
}
2
implies () =
1
and () =
2
;
= tag
1
2
. . .
implies () =
1
and () =
2
. . .
;
B implies () and () are undened.
2. A path is a sequence in {, }
. We write cons(, ) for the sequence whose rst

member is and whose successive elements are those of . We write
1
2
for
the result of appending
2
to the end of
1
.
We regard as a partial function, where = Id and cons(, ) = . When
the rhs is dened, we have:
(a) () = ;
(b) cons(, )() = (()); and
(c) cons(, )() = (()).
3. traverses a key edge in if =
1
2
and
1
() is an encryption.
4.
0
is an ingredient of , written
0
, if
0
= () for some that does not
traverse a key edge in .
5.
0
appears in , written
0
, if
0
= () for some .
6. traverses a member of in if =
1
2
, where
1
() and
2
= .
As an example, consider the message = {{}
sk()
}
pk()
; for
0
= , , we have =
0
(). Since
0
does not traverse a key edge,
{{}
sk()
}
pk()
.
1
= , we have pk() =
1
(). However, since
1
traverses a key edge, we have
established only the weaker pk() {{}
sk()
}
pk()
.
2
= , , we have sk() =
2
(). Since
1
again traverses a key edge, we have only
sk() {{}
sk()
}
pk()
.
In {}
, only the path leads to . Hence, {}
but {}
. Since leads
to , {}
.
2.2. A Sample Algebra of Basic Values
The algebra of basic values may take many forms, and its details affect the remainder of
our development only in a limited way. In this section, we give a sample B, for the sake
of concreteness, which sufces for the example of Section 1. The example of Section 4
requires some additional machinery in B, but no new ideas. Lemma 2.7 characterizes the
essential requirements: if any B yields an M[B] satisfying Lemma 2.7, then the remainder
of the chapter will hold for that M[B].
Let be the natural numbers. We use the following constructors, i.e. injective func-
tions with disjoint range:
nm, txt, skey with domain . Their ranges are called names, texts, and symmetric keys,
respectively.
sk, pk with domain names, yielding values called signature keys and public keys respec-
tively.
invk with domain signature keys public keys, yielding values called verication keys
and private decryption keys resp.
We dene the inverse function
1
so that
sk(nm())
1
=invk(sk(nm())) invk(sk(nm()))
1
=sk(nm())
pk(nm())
1
=invk(pk(nm())) invk(pk(nm()))
1
=pk(nm()),
while for all other values
1
= .
Each homomorphism : B B is determined by a function mapping names to
names, texts to texts, and symmetric keys to symmetric keys. Moreover, each such
extends to a unique homomorphism.
Indeterminates, as we mentioned, are akin to untyped variables, since homomor-
phisms can send them to any value in M
X
[B]. By contrast, basic values are akin to sorted
variables. Homomorphisms map them to values of the same sort.
PARAMS is the union of the indeterminates X and the set of all basic values in B
of the forms nm(), txt(), and skey(). The parameters of a message Mwritten
params()are all of its subexpressions PARAMS.
Lemma 2.4 1. Each message has nitely many parameters params(); and
2. Letting , : M
X
[B] M
X
[B], if (i) params() X B, and (ii) for all
params(), () = (), then () = ().
2.3. Properties of Homomorphisms
Denition 2.5 Consider homomorphisms , , between subalgebras of M
X
[B].
1. A parameter PARAMS is a source parameter of iff () = .
2. is nitely generated iff it has nitely many source parameters.
3. Messages , M have a common instance iff () = () for some , in
which case unies , .
4. A homomorphism is an isomorphism, or a renaming, iff there exists a such
that and are the identity Id.
By the symmetry of the denition, in this case is a renaming also.
5. , differ by a renaming iff for some renaming , = .
6. If there exists a such that = , then we say that is at least as specic as
, and write
.
In clause 4, may be dened only on a subalgebra such as the range of , and likewise in
clause 5 may be dened only on the range of . A preorder means a reexive, transitive
relation.
Lemma 2.6 1. If = Id, then is a renaming.
2. Differing by a renaming is an equivalence relation.
Proof: 1. Suppose is dened on M
X
[B
]. First, is injective: if () = (
), then
since = (()) = ((
)) =
, =
. Moreover, letting X
= (X
) and B
be generated from (PARAMS(B
)), we have surjective onto M

X
[B
]. Thus, is an
isomorphism : M
X
[B
] M
X
[B
], and has an inverse : M

X
[B
] M
X
[B
].
2. Differing by a renaming is reexive because Id is a renaming, and it is transitive
because the composition of two renamings is a renaming.
To see that it is symmetric, suppose that = . Since is a renaming, there
is a such that = = Id. Applying to each side of the assumed equation,
( ) = . However, ( ) = ( ) = Id = . So is a renaming
such that = .
We sometimes call , isomorphic when they differ by a renaming.
Lemma 2.7 1.
is a preorder on homomorphisms.
2.
implies that and differ by a renaming. Hence,
is a partial
order on the equivalence classes.
3. When = =
, then () =
() for all rng(). Thus, the

choice of in Def. 2.5, Clause 6 is unique, on rng().
4. For any nitely generated , the set {:
} contains only nitely many

non-isomorphic members.
Proof: 1. Using Id and composition.
2. If
, then there exist , such that = and = . Hence,

letting
be the restriction of to ran(), we may apply Lemma 2.6, clause 1.

3. If = (
0
), then () = ((
0
)) = (
0
) =
((
0
)) =
().
4. Dene ascore(, ), for PARAMS, to be { PARAMS: () = } 1.
Dene xscore(, ), for X, to be number of encryptions and concatenations in ()
plus the number of multiple occurrences of basic values and indeterminates in ().
Dene xyscore(, , ) to be 0 if = , and otherwise the number of occurrences of
basic values and indeterminates shared between () and (). The score of is the
sum:
PARAMS
ascore(, ) +
X
xscore(, ) +
,X
xyscore(, , ).
Then score is non-negative, and well dened when is nitely generated. Moreover,
when
, and is nitely generated, score() score(). If score() = score(),

then , differ by a renaming. Hence, . . .
. . .

0
can have only
nitely many non-isomorphic members. Indeed, when score() = + 1, there are only
nitely many non-isomorphic
such that score() = .

A homomorphism unies messages , if () = (), and is a most general
unier for , if in addition, whenever
unies , , then
.
Lemma 2.8 1. Assume , M have a common instance. There exists a nitely
generated which is a most general unier of and .
2. Let = () and = (). Then , have a most specic common general-
ization for . That is, there is a nitely generated such that:
(a) For some
1
, = (
1
)(),
(b) For some
1
, = (
1
)(), and
(c) if
satises Clauses 2a2b, then
.
Lemmas 2.4, 2.62.8 summarize our central assumptions on the algebra. We believe
that for any algebra of basic values B, where every basic value can be assigned a nite
set of parameters, such that the resulting M
X
[B] satises these lemmas, will satisfy the
remaining results in this chapter.
Adjusted versions of our method appear still usable when the m.g.u. property fails,
but instead a nite set of uniers cover the common instances of any two messages, and
where a nite set of homomorphisms replace the most specic common generalization
of Clause 2. Sometimes the adversary has useful additional operations on basic values,
and some additional authentication test patterns must be dened on the basic values. By
contrast, in algebras with exclusive-or (e.g.), which may be applied to tuples or encryp-
tions rather than just basic values, and is subject to equational laws, other entirely new
ideas are required.
2.4. Strands and Origination
A single local session of a protocol at a single principal is a strand, containing a linearly
ordered sequence of transmissions and receptions that we call nodes. A transmission of
message is a directed term +, and a reception of message is a directed term .
The
node on strand is , using 1-based indexing. If , are successive

nodes on the same strand, holds, meaning that = and = + 1. The
transitive closure of is
+
, and its reexive transitive closure is
. The message
sent or received on the node is msg().
Origination. A message
0
originates at a node
1
if (1)
1
is a transmission node; (2)
0
msg(
1
); and (3) whenever
0

+
1
,
0
msg(
0
). Thus,
0
originates when
it was transmitted without having been either received or transmitted (as an ingredient)
previously on the same strand. Cf. Def. 2.3 for .
Values assumed to originate only on one node in an executionuniquely originating
valuesformalize the idea of freshly chosen, unguessable values. Values assumed to
originate nowhere may be used to encrypt or decrypt, but are never sent as message
ingredients. They are called non-originating values. For a non-originating value ,
for any transmitted message . However, {
0
}
possibly, which is why we

distinguish from in Def. 2.3.
As an example, when applying Principle 1.3 to Fig. 2, we stated that is not retrans-
mitted by any strand that has received it. This was meant in the sense of . We never
have msg() if for some reception node ,
+
and msg(), and is
a transmission node. However, we may have msg(), which is harmless because it
does not contribute to disclosure of .
We say that is the origin of
0
in a set of nodes if (1) , (2)
0
originates at
, and (3)
0
originates at no other node in . It is uniquely originating in if for some
, is the origin of
0
in .
We say that
0
is non-originating in if there is no such that
0
msg().
Evidently, if there is any such that
0
msg(), then any full execution extending
will have to provide an origin for
0
.
Principals and Other Parameters. We extend the notion of parameters from mes-
sages to nodes and strands cumulatively. Suppose that is a strand of length , and ;
then params() = params( ) where
params( ) =
0<
params(msg( )).
The parameters to a node are the potentially varying arguments which can affect the
messages sent or received up to and including that node. By Lemma 2.4, a strand has
only nitely many parameters, and any two homomorphisms agreeing on params() have
the same action on messages sent and received along .
In the model we use in this paper, there is no relevant entity acting as a principal.
There are only names, and these names serve as parameters to some strands. Names are
also associated with keys via the functions pk(), sk(). Thus, although informally we
view several strands as being ongoing activities of a single principal at a particular time,
in the model, there are only strands that share a particular name parameter and use the
keys associated with that parameter. When a protocol may manipulate some long-term
state belonging to the principals executing it, then we work in a richer model [11].
2.5. Protocols
Aprotocol is a nite set of strands, called the roles of , together with some constraints
on unique and non-origination. We assume that every protocol contains the listener
role Lsn[], which consists of a single reception node

. Instances of this listener role
have already appeared in Figs. 2, 4, 67.
The constraints on origination for roles, which we will illustrate in an example in
Section 4, may be used to ensure that a particular role always contributes a uniquely
originating value to an execution, as for instance a session key server may be trusted
always to choose a fresh and unguessable session key. They may also be used to ensure
that a particular role always involves a non-originating key. For instance, a protocol may
ensure that the certicate authority role always uses a non-originating signing key. In
modeling SEP, role origination constraints were not needed; we assumed only that par-
ticular values in a skeleton were non-originating or uniquely originating. There was no
need to assume that every time we added a strand, some parameters to it would satisfy
origination constraints.
The Indeterminate Acquisition Principle. Since indeterminates represent syntacti-
cally unconstrained messages received from protocol peers, or passed down as parame-
ters a higher-level protocol, we require an indeterminate to be received as an ingredient
before appearing in any other way:
If
1
is a node on , with an indeterminate msg(
1
),
then
0
,
0

1
, where
0
is a reception node and msg(
0
).
This Indeterminate Acquisition Principle is related to the requirement in constraint-
solving approachesoriginating with [13]that variables in constraint sequences al-
ways appear rst on the right-hand side of a constraint. The right hand sides represent
message receptions, where the adversary must generate some instance of the constraint,
and may select a value for the variable that makes this possible.
As an example protocol, the two strands shown in Fig. 1 are the roles of SEP. Our
analysis of SEP did not rely on any origination constraints. Finally, if were an inde-
terminate, then the responder role violates the Indeterminate Acquisition Principle. We
instead interpret as a basic value.
3. Skeletons and Homomorphisms
A skeleton consists of (possibly partially executed) regular strands, i.e. a nite set of
nodes, nodes(), with two additional kinds of information:
1. A partial ordering
on nodes();
2. Finite sets unique
, non
of basic values assumed uniquely originating and re-

spectively non-originating in .
More formally:
Denition 3.1 A four-tuple = (nodes, , non, unique) is a preskeleton if:
1. nodes is a nite set of regular nodes; moreover, for all
1
nodes, if
0

+
1
then
0
nodes;
2. is a partial ordering on nodes such that
0

+
1
implies
0

1
;
3. non and unique are nite sets of basic values, and
(a) non . nodes . msg();
(b) non . nodes . either msg() or
1
msg(); and
(c) unique . nodes s.t. msg().
A preskeleton is a skeleton if in addition:
4. for all unique, if originates at
0
nodes, then
(a) originates at no other node
1
nodes; and
(b) if msg(
1
) where
1
nodes, then
0

1
.
The parameters of form the union: params() =
nodes()
params().
All of the skeletons in Figs. 210 are skeletons, except when we cheated on Clause 4b.
Namely: In Fig. 2, the left hand node should precede the right hand node. In Fig. 6, the
second skeleton
21
should have the node transmitting {}
precede the listener node

for . In Fig. 7, the node transmitting
0
should also precede the listener for .
If violates Clause 3a, no enrichment of can satisfy it. By contrast, some
preskeletons may violate Clause 4a or Clause 4b but enrich to a skeleton. Two nodes,
at both of which some unique originates, may map to a single node originating it,
thereby satisfying Clause 4a. A strengthening of the ordering may satisfy Clause 4b,
while remaining acyclic. This works for the non-skeletons in Figs. 2, 6, and 7. We for-
malize these operations in Section 3.4.
3.1. Realized Skeletons
A skeleton is realized if its strands can really happen, without any other regular behav-
ior. The regular behavior present in a realized skeleton is combined with some adversary
behavior to explain how each message received by a regular node could have been gen-
erated by that time. The adversary behavior must not violate the skeletons assumptions
about non-origination and unique origination.
Penetrator Webs. We represent the actions of the adversary by means of strands of
certain special forms. These originate basic values or indeterminates; compose and trans-
mit a tuple, having received its components; separate and transmit the components of a
tuple, having received the tuple; encrypt and transmit a ciphertext, having received an
encryption key and a plaintext; and decrypt and transmit a plaintext, having received the
matching decryption key and a ciphertext:
Denition 3.2 An adversary strand has any of the following forms:
M
: + where is a basic value M
: + where is an indeterminate
C: +tag . . .
S: tag . . . + +
E: +{}
D:
1
{}
+
Because an adversary uses a key only by means of E and D strands, it can use a key only
if it receives that key value. Since every value that is received must have been originated,
it follows that an adversary can never use a non-originating value. This justies our use
of non-originating to model uncompromised.
The adversary can link together a number of strands, forming an adversary web
that accomplishes some compound task.
Denition 3.3 (Adversary web, derivable) Let =
, (
) be a nite
acyclic graph, where (i)
0

1
only if
0
,
1
are successive nodes on an adversary
strand; and (ii) only if is a transmission node, is a reception node, and
msg() = msg(). is an adversary web with support
spt
and result if
spt
and
are sets of messages and moreover:
1. If
2

is a reception node, then either msg(

2
)
spt
or there is a unique
1
such that
1

2
.
2. If
2

and
1

2
then
1

2
.
3. For each , either
spt
or for some positive
, msg() = .
If is a set of basic values, then term
1
is derivable from
spt
avoiding if there is a
web with support

spt
and
1

, where no basic value in originates on a

penetrator strand in .
This suggests that is a possible execution if, for each reception node , there exists an
adversary web deriving msg() using messages transmitted earlier in , and avoiding
basic values constrained by non
and unique
. However, if unique
, but it does not

originate on any node in , then it is in fact unconstrained: It can originate just once, but
on an adversary
node, after which the adversary can use it as much as necessary. The
constrained values in unique
are those that originate on a regular node of .

Denition 3.4 (Realized) The avoidance set avoid() for is the set
non
(unique
{: originates at some nodes
}).
The support support(, ) of nodes
in is {msg():
and is a trans-
mission node}.
A reception node nodes
is realized in if msg() is derivable from

support(, ) avoiding avoid(). is realized if it is a skeleton and every reception
node nodes
is realized in .
We have been saying informally that represents a possible execution, and we now
stipulate that this means that is realized. The adversary webs explain how the adversary
can generate values that will satisfy each reception node in .
Realized skeletons from Section 1 include
21
and
1
. In the case of
21
, the adver-
sary web needed to explain its two reception nodes are each the empty web, since each
reception node has a message that has already been transmitted on an earlier node. How-
ever,
1
requires an adversary web that decrypts {{}
sk()
}
pk()
using the decryption
key pk()
1
, and then re-encrypts with the public key pk(), neither of which is to be
avoided in
11
. Skeleton
1
is again realized, using the empty adversary web. By an old
result [20, Lemma 2.9]:
Lemma 3.5 If every node nodes
is realized in the preskeleton , then Defn. 3.1,

Clause 4b is satised in .
It is easy to check whether there is an adversary web that realizes from =
{:
and is a transmission node}. When all of the keys are basic values, we
can bring the web to a normal form in the Prawitz-like sense [16] that constructive adver-
sary strands never precede destructive ones [14,3,12]. When the keys may include com-
pound messages, there is a weaker normal form: Every path within the web either tra-
verses a key being used for encryption or decryption on an adversary strand, or else tra-
verses destructive strands before any constructive strands. In such a web, every message
is a member of the nite set:
{ : msg() . msg()}.
3.2. Homomorphisms
Our intuitive notion of enrichment will be formalized by homomorphisms among skele-
tons or preskeletons. A preskeleton homomorphism has two components. One is a ho-
momorphism on the underlying algebra M. It says how to transform the messages
sent and received on nodes of the source preskeleton to messages sent and received
on the target preskeleton. The other component is a map from nodes of the source
preskeleton to nodes of the target preskeleton. The most important condition is that
msg(()) = (msg()); i.e. the message sent or received on the target node should be
applied to the message sent or received on the source node. The target may contain
additional nodes not of the form ().
Denition 3.6 Suppose , are preskeletons, is a homomorphism on M, and
: nodes
nodes
. = [, ] is a homomorphism if
1. preserves strand structure:
(a) If then there is an
s.t. for all , ( ) =
;
(b) and () agree in direction, either transmission + or reception ;
2. For all , msg(()) = (msg());
3. Skeleton information preserved:
(a)
implies ()
();
(b) (non
) non
;
(c) (unique
) unique
;
4. Origination preserved for uniquely originating values: If unique
and
originates at nodes
, then () originates at ().

We write : when is a homomorphism from to . When ,
agree on
params(), then [, ] = [,
]; i.e., [, ] is the equivalence class of pairs under this

relation. The source of is , and the target of is .
We sometimes write
and
to refer to a and such that = [, ].

is an inclusion map if
is the identity function. In this case,
is also the
identity, i.e. = [
, Id]. is a subskeleton of if there is an inclusion : .

We regard the nitely generated homomorphism
0
which is the identity for all
params() as the canonical representative of [, ]. Thus, henceforth, we will assume
that the message homomorphism in [, ] is nitely generated.
The condition on origination in Clause 4 avoids the degeneracy in which a point
of origination is destroyed for some basic value unique
. We stipulate that such

degenerate maps are not homomorphisms.
Lemma 3.7 If is a preskeleton, then the identity Id
: . If : and
: , then : . Skeletons form a category under homomorphisms.
Section 1 incorporates many examples of homomorphisms, starting with an absence
of homomorphisms. The deadness of Fig. 2 asserts that there are no homomorphisms
from
0
whose target skeleton is realized. Figs. 34 illustrate a pair of homomorphisms

1
and
2
. In each of these homomorphisms, is included into a larger
{{}
sk()
}
pk()

{{}
sk()
}
pk()

{{}
sk()
}
pk()
Figure 11. A non-injective homomorphism

1

2
skeleton: the message homomorphism is the identity and the node map is the identity
in each case. The homomorphism
2

21
is a bit more interesting, since its message
homomorphism maps the names , to and , to . Its node map is a bijection.
By composition, we also have a homomorphism
21
.
The homomorphism
21
is an embedding, with a second embedding
21

211
, and similar maps
1
and
1
. We have not yet illustrated any case in
which is non-injective. Fig. 11 is an articial but simple example. A message homo-
morphism mapping , to the same value permits the two transmission nodes of
1
to
be identied in the target
2
. In this case, , are mapped to , and to , but in fact
the choice of target values is arbitrary. A renaming could change them to any other pair
of distinct values, producing an isomorphic result.
In Fig. 11, there are also two homomorphisms
1
,
2
in the opposite, right-to-left
direction. One of them, say
1
, renames to and maps the single node of
2
to the
left-hand node of
1
. The other homomorphism
2
renames to and also renames
to ; it maps the single node of
2
to the right-hand node of
1
. These homomorphisms
are, however, not essentially different.
1
has a non-trivial automorphism , i.e. an iso-
morphism to itself. This is the map that interchanges the two nodes, while mapping to
and to . In fact,
2
=
1
, i.e.
1
and
2
differ by an isomorphism.
3.3. Characterizing Executions
An execution means a realized skeleton. We regard each skeleton as describing a set
of executions. This is the set of realized homomorphic images of .
A dead skeleton describes the empty set of executions. A realized skeleton describes
a set of executions that includes itself. A skeleton that is neither dead nor realized de-
scribes a non-empty set that does not include itself.
Denition 3.8 is a dead skeleton if for every homomorphism : , is not
realized.
Lemma 3.9 If is dead and : , then is dead.
Proof: If : , then : , so is not realized.
This lemma formalizes Principle 1.2.
Any non-dead skeleton describes an innite set of executions. Since is non-
dead, it has at least one homomorphism : with realized. Moreover, we can
always take the disjoint union 2 =
of the realized skeleton with a renaming
of itself. If the renaming is chosen to use new values that do not to overlap with the
original ones, the disjoint union 2 =
will again be a realized skeleton. Clearly,

we can again rename 2 to (2)
, taking a union to obtain 4 = 2 (2)
. We can
repeat this process ad innitum.
Since the set of realized skeletons contains so many members, we would like to focus
on compact but informative ways to characterize this set. Given a skeleton , consider a
set of homomorphisms such that:
1. If , then : where is realized; and
2. If : where is realized, then = for some and some
homomorphism .
CPSAs goal is, given a starting point , to compute a such a set for .
However, a key choice was to decide which set of this kind to select. For instance,
one would prefer an algorithm that produces nite sets rather than innite ones when
possible. However, there is another consideration. Fig. 11 illustrates that we may have a
situation where
1

2

1
; so should we then prefer the larger skeleton
1
or the
smaller skeleton
2
?
We have opted for the smaller skeleton
2
. Why? Non-injective homomorphisms
that map different nodes to the same result, such as the one in Fig. 11, are always in-
formative. They tell us that two distinct strands in the source could have been the same,
since they are the same in the target. However, injective homomorphisms may not be
interesting. For instance, recall the realized skeletons , 2, 4, . . . we mentioned im-
mediately after Lemma 3.9. The homomorphisms from each member in this sequence
to later members do not tell us anything new. We opt to pack more information into the
choice of , and less into the onward homomorphisms that extend members of to
yield all other realized results. Hence, we use injective homomorphisms to relate shapes
to their instances:
Denition 3.10 1. = [, ] : is node-injective iff is an injective function
: nodes() nodes().
2.
n
iff for some node-injective , = .
3. A set of homomorphisms is a (node-injective) characterization for iff
(a) If , then : where is realized; and
(b) If : where is realized, then
n
for some .
4.
n

iff for every , there exists a
such that
n
.
5. min() = { : .
n
implies
n
}.
CPSAs goal is, given an , to compute a minimum characterization for . We will write

iff every is isomorphic to some
and vice versa. Then:

Lemma 3.11 1. If : is node-injective, then is an isomorphism from
to itself.
2. If
n

n
, then there is an isomorphism such that = . Hence,
n
is a partial order (to within isomorphism).
3. The relation
n
is well founded (to within isomorphism).
4. A set
of homomorphisms is nite if (i)
implies
n
, and (ii) no
two
1
,
2

differ by an isomorphism.
5. {: : is realized} is a characterization for .
6. min() is a non-empty characterization for if is.
7. If ,
are characterizations for , min() min(
).
Proof: 1. If = [, ] : is injective, then by the niteness of nodes(), is a
bijection. Since nodes() nodes() is nite, does not introduce new pairs into the
ordering. That is, () () implies .
So we must show next that the message algebra homomorphism is invertible.
However, by Lagranges theorem, there is a such that the
th
iterate
of is the
identity. If = 1, then is the identity. If = + 1, then the
th
iterate
of inverts
.
2. If
n

n
, then we have =
1
and =
2
, where
1
,
2
are
node-injective. Hence
2

1
is a node-injective homomorphism from the target of
to itself. By Clause 1,
2

1
has an inverse , i.e. (
2

1
) is the identity. Thus,
by associativity of composition,
2
is the desired inverse to
1
.
3. Let . . .
+1
n
. . .
0
be an innite descending chain of homomorphisms
in the
n
ordering, as in the following diagram, where each
is node-injective:
+1
z
z
z
z
z
z
z
z
_
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
U
. . .

+1

+1
. . .

0
We want to ensure that all but nitely many of the
are isomorphisms. By
Lemma 2.7, Clause 4, all but nitely many of the
differ from each other by renam-

ings. Hence all but nitely many of the
are isomorphisms. For convenience, assume

for some
0
, that all
with >
0
are the identity. Thus, all of the
for >
0
are inclusion maps. But a skeleton has only nitely many subskeletons.
4. Suppose that
satises (i). Let

1
,
2

n
, where : and
=
[
] :
.
Write (
1
,
2
) to mean: (a) ran(
1
) ran(
2
); (b)
1
(
1
)
2
(
2
); (c)
1
(non
1
)
2
(non
2
); and (d)
1
(unique
1
)
2
(unique
2
).
is a preorder, and when (
1
,
2
), there is an injective map from nodes(
1
)
to nodes(
2
) dened by () =
1
2
(
1
()). If also (
2
,
1
), is bijective.
Let (
1
) = {
2
: (
1
,
2
) (
2
,
1
)}. Since there are only nitely many
-equivalence classes (), it sufces to show that if any of them is innite, then it
contains isomorphic members.
Lets say that a skeleton is clean if each strand in results from a role by a
renaming, and all of these renamings have disjoint ranges.
For each member of (
1
), there is a clean skeleton and a message homomor-
phism such that such that = (). Moreover, by a cardinality argument, all of (
1
)
consists of images of a nite number of clean . Thus, if (
1
) is innite, there is a
single with innitely many (
1
) such that there exists a such that = ().
However, since for some : , each such
, by Lemma 2.7, Clause 4, so

that this set of message homomorphisms has isomorphic members
1
=
2
. Hence
[, ] is an isomorphism between skeletons
.
(Clause 3 also follows directly from Clause 4.)
5. Clause 3a of Def. 3.10 is immediate. Clause 3b holds because
n
.
6. Non-emptiness of min() follows from well-foundedness. Observe that if
min(), then there is some min() such that
n
. Since is a character-
ization, for any : with realized, there is a such that
n
. If
min(), then there is some min() with
n

n
, so
n
. Thus,
min() is a characterization.
7. If either or
is empty, then so is the other (i.e. is dead); in this case the

result is immediate. So assume both non-empty. Since min() is a characterization, for
every min(
) there is a min() such that

n
. Since min(
) is a
characterization, there is also a min(
) such that
n

n
. By the denition
of min,
n
. Hence , differ by an isomorphism. Symmetry of min(), min(
)
completes the proof.
This establishes that the CPSA goal, to compute the minimum characterization, is well-
dened to within isomorphism.
Denition 3.12 The shapes for a skeleton , written shapes(), are the members of the
nodewise minimum characterization for .
The shapes() form a well-dened set of homomorphisms (to within isomorphism),
since we may apply Lemma 3.11, Clauses 67 to the characterization containing all
homomorphisms from to realized skeletons. is dead iff shapes() = . We may
now justify Principle 1.4 directly from the denitions.
Lemma 3.13 Suppose : , and : where is realized. Then =
for some : with shapes(), and some node-injective : .
3.4. The Hull of a Preskeleton
If is a preskeleton but not a skeleton, then for some unique
, either
1. originates at two or more nodes (Def. 3.1, Cl. 4a); or else
2. originates at
0
and msg(
1
), although
0

1
(Def. 3.1, Cl. 4b).
In this subsection, we say how to x those situations. When they can be xed at all,
there is a single, canonical, most general way to do so.
A map is universal in some set of maps if and, for every
, there
is exactly one such that
is of the form
= .
Lemma 3.14 Suppose , are preskeletons, with : .
1. If
, then there is a
0
and a :
0
such that is universal among
all homomorphisms with source where
.
2. Suppose that
1
and
(
1
)
. Then there is a
0
and a :
0
such that is universal among all homomorphisms :
1
where
(
1
)
1
.
3. If
(
0
) =
(
1
) for
0
,
1
nodes(), then there is a
0
and a :
0
such that is universal among all homomorphisms fromwhich identify
0
and
1
.
Proof: 1. Dene nodes(
0
) by applying to each strand that contributes to , and let
be the bijection that maps each node nodes() to () . Let
0
= (
),
non
0
= (non
), and unique
0
= (unique
).
Then
0
is a preskeleton unless Def. 3.1, Clause 3a fails. However, if msg()
nodes(
0
) but (non
), then this property is preserved under composition. Thus,

since
, and satises Clause 3a, so does

0
.
Moreover, [, ] is a homomorphism unless Def. 3.6, Clause 4 fails. However, if
originates on , but () msg(( )) for < , then ()
msg(
( )),
contradicting the assumption that is a homomorphism.
2. Dene
0
to be the same as , except that the ordering is
1
. This ordering is
acyclic because its image under
is acyclic.
3.
0
=
0
and
1
=
1
, since if the two nodes lay at different indices,
no homomorphism could identify them. The messages msg(
0
1), . . . , msg(
0
)
are simultaneously uniable with msg(
1
1), . . . , msg(
1
) resp., since
equates
them. Let be their simultaneous m.g.u. Apply Clause 1 to this , obtaining
0
=
[
0
, ] :
0
.
By Clause 2, we may extend the ordering
0
so that
0
precedes (succeeds)
every node that
1
precedes (succeeds), and vice versa.
We now construct
1
by selecting the strand (
0
). Let
1
extend
0
by mapping
the nodes
1
to
0
, discarding the unnecessary nodes.
1
= [
1
, ] is the desired
homomorphism.
Lemma 3.14 is used in the next proof, and also repeatedly in Section 6.
Lemma 3.15 (Hull) If : and is a skeleton, then there is a
:
0
, such
that
is universal among homomorphisms from to skeletons.

Proof: If is a preskeleton but not a skeleton, then there is a counterexample either to
Def. 3.1, Clause 4a or else to Def. 3.1, Clause 4b. In the rst case, there are two nodes
0
,
1
at both of which the same unique
originates. By Def. 3.6, Clause 4,
()
originates at
(
0
) and at
(
1
). Since is a skeleton,
(
0
) =
(
1
). Thus,
we may apply Lemma 3.14, Clause 3.
In the second case, for some unique
, msg(
1
) but with the origin
0
of ,

1
. In this case, we apply Lemma 3.14, Clause 2.
If the result of a step is not a skeleton, we iterate; however, we must terminate: At
each step of the rst kind, we reduce the number of nodes. At each step of the second
kind, we reduce the number of incomparable nodes.
Denition 3.16 The hull of preskeleton , written hull(), is the universal map
given
in Lemma. 3.15, when it exists.
We sometimes use hull to refer to the skeleton
0
, target of hull():
0
.
3
4. Attestation Identity Protocol
In Section 1, we examined SEP to extract a number of search principles, one of which,
Principle 1.3, concerns receiving an encrypted unit. Unfortunately, however, Principle 1.3
3
The hull idea is due to Javier Thayer, as was the rst proof of Lemma 3.15.
ekc
TPM
ekc
ekc
PCA
{aic}
EK

{aic}
EK
aickeyrec
STORE
aickeyrec

ekc = {ekc MFEK}
sk(MF)
aic = {aic }
sk(PCA)
keyrec = {aikrec ,
1
}
SRK
Figure 12. Modied Anonymous Identity Protocol MAIP
is not strong enough as formulated. It does not cover all the transformations that proto-
cols apply to encrypted units, but only the most fundamental transformation, the act of
creating the encrypted unit in the rst place.
In this section, we will examine a second example to motivate a strengthening of
our Principle 1.3, namely the Trusted Computing Groups protocol for generating certi-
cates for Attestation Identity Keys (AIKs) [1]. These signature keys are intended to be
resident within a Trusted Platform Module (TPM), and never to be available outside it.
The certicate for an AIK verication key ensures that the private signature part
1
is resident in some TPM, without allowing the recipient to determine which one. They
provide, thus, anonymous assurance that signatures were prepared within some TPM.
AIP Roles. The privacy certicate authority that prepares certicates on AIKs will
prepare a certicate for any key presented in a well-formatted message. So how does
it ensure that the private part
1
is TPM-resident? It encrypts the certicate aic using
a public encryption key EK. That key is accompanied by a certicate from the TPMs
manufacturer saying that the matching decryption key EK
1
is itself a long-term TPM-
resident value. A TPM liberates the AIK certicate from this encryption only if it holds
the signature key
1
matching the key in the certicate. The (slightly modied)
protocol is shown in Fig. 12.
Non-Origination Assumptions. We associate two non-origination assumptions with
the PCAs transmission node in this protocol.
1. When the PCA accepts an endorsement key certicate {ekc MFEK}
sk(MF)
, it
must check that the signing key is known to be the signature key of a recognized
manufacturer. We model this by adding sk(MF) to the keys assumed to be non-
originating.
2. The point of the ekc is to vouch that the private part EK
1
is TPM-resident, and
therefore used only in accordance with the rules. Hence, we also add EK
1
to the
keys assumed to be non-originating.
aickeyrec
ekc
PCA
1

{aic}
EK
aickeyrec

non(
0
) = {sk(PCA)} non(
1
) = {sk(PCA), sk(MF), EK
1
}
Figure 13. PCA Analysis, step 1 (Point of view: Store)
If is the PCA role, we can express this assumption in the form
role_non( 2) = {sk(MF), EK
1
}.
A node of a role may also have some associated values that are guaranteed to be uniquely
originating, which we express with role_unique( ). For instance, the session key
transmitted by a key server should often be handled in this way.
AIP Transformations. In MAIP, there are two central transformations. The job of
constructing and emitting an aic is one transformation, which can be performed only
by the privacy certifying authority. However, it is equally essential to the working of the
protocol, that the PCA emits the aic only encrypted, and in such a way that the aic can
be decrypted and transmitted in usable form only by a genuine TPM.
Of these two transformations, the rst is certainly an instance of Principle 1.3. The
value {aic }
sk(PCA)
is emitted, without having been contained as an ingredient of
any previous node. Thus, if we assume that the signature key of PCA is uncompromised,
any execution containing an instance of the STORE role must also contain a matching
instance of the PCA role, as shown in Fig. 13.
4
However, the TPMs transformation to free the aic from its encryption is not an in-
stance of Principle 1.3. The digitally signed unit must be received before being retrans-
mitted. Thus, Principle 1.3, Clause 2 cannot apply. Moreover, Principle 1.1 does not ap-
ply. The AIK may be a freshly chosen value, but it has already been transmitted out-
side all encryptions at the time that the PCA receives it. So Principle 1.1 implies nothing.
What we need here is an analog to Principle 1.1, but applying to encryptions rather
than to fresh values. It needs one additional case, to cover the possibility that the adver-
sary could independently generate the encryption. Thus, it would take the form:
Principle 4.1 (The Encryption Test) Suppose that = {}
, is an encryption, and
is found in some message received in a skeleton at a node
1
. Moreover, sup-
pose that, in the message of
1
, is found outside all of a number of encrypted forms
{
1
}
1
, . . . , {
. Then in any enrichment of such that is a possible execution,

either:
4
Observe that in
1
we have added sk(MF), EK
1
to the keys assumed non-originating, in accord with the
origination constraint we associated with the PCA role.
ekc
PCA
{aic}
EK
aickeyrec

1

TPM

PCA
{aic}
EK

{aic}
EK
aickeyrec
aickeyrec

Figure 14. PCA Analysis, step 2 (Point of view: Store)
1. One of the matching decryption keys
1
is disclosed before
1
occurs, so that
could be extracted by the adversary; or else
2. The encryption key is disclosed before
1
occurs, so that the adversary could
construct = {}
from ; or else
3. Some regular strand contains a node
1
in which is transmitted outside the
forms {
1
}
1
, . . . , {
, but in all previous nodes

0

+
1
, was found
(if at all) only within the plaintexts
1
. . .
. Moreover,
1
occurs before
1
.
We apply this principle to the encryption = {aic }
sk(PCA)
, with the single en-
crypted form {aic}
EK
. If we assume that the signature key sk(PCA) is uncompromised,
as well as the TPM-resident value EK
1
, then the rst two disjuncts are inapplicable, and
we are left with the regular TPM strand that transforms the aic from the form{aic}
EK
to
aic.
Principle 1.3 is, however, a special case of Principle 4.1. If = 0 in the list of en-
crypted forms {
1
}
1
, . . . , {
so that this is the empty listthen the rst disjunct

is unsatisable. Moreover, in the last disjunct, no earlier occurrences of are permitted.
Hence, the old principle is nothing but the = 0 case.
Indeed, now Principles 1.1 and 4.1 are in essentially the same form. The only dif-
ferences are that (1) the critical ingredient is a uniquely originating basic value in
Principle 1.1 and an encryption = {}
in Principle 4.1, and (2) the possibility that

becomes compromised is relevant only in Principle 4.1. This suggests that we combine
them, which we shall do after a few denitions, in the form of Def. 5.3 and Thm. 5.5.
5. The Authentication Tests
We regard Principles 1.1 and 4.1 as specifying how certain tests can be solved. In
each one, the critical value or is found only inside a number of encryptions =
{{
1
}
1
, . . . , {
}, and is subsequently received at node

1
outside of these forms
. The test is to explain how it is extracted from . We call the escape set, since the
critical value does escape from it; indeed, it has done so before being received at
1
.
The solutions are of two kinds: Either a key is compromised, so the adversary can
create an occurrence of outside , or else a regular strand has a transmission node
1
which transmits or outside , although earlier nodes on the same strand contained the
critical value only within (if at all). There are only nitely many roles in , and the
instances of their nodes yield all the candidates for regular solution nodes
1
. Later, in
Section 6, we will also regard message homomorphisms as yielding solutions of a third
kind, since they can make the test disappear. That is, the image of no longer escapes
from the image of . We formalize being contained within as follows:
Denition 5.1 Let be a set of encryptions. A message
0
is found only within in
1
,
written
0

1
, iff for every path such that (
1
) =
0
, either (1) traverses a key
edge or else (2) traverses a member of before its end.
Message
0
is found outside in
1
, written
0

1
, iff not (
0

1
).
Equivalently,
0

1
iff for some path , (1) (
1
) =
0
, (2) traverses no key edge,
and (3) traverses no before its end. Thus,
0

1
iff
0

1
.
For instance, let
0
= {{}
sk()
}
pk()
, and let
0
= {
0
} and
1
= {{}
sk()
}.
The sole path , to in
0
traverses rst
0
and then {}
sk()
, so

0
and
0
.
We used
0
in Section 1.1, taking s point of view in SEP. We used
1
in Section 1.2,
taking s point of view. Moreover, for every ,
{}
, because the only path to

traverses a key edge. However, {}
sk()

0
.
Looking at examples from MAIP next, and letting
2
= {{aic}
EK
}, we have
aic
aic and aic
{aic}
EK
but aic
2
{aic}
EK
.
5.1. Cuts and Tests
Denition 5.2 Let be a basic value or an encryption, and be a set of encryptions.
Cut(, , ), the cut for , in , is dened to be:
Cut(, , ) = { nodes(): .
msg()}.
Thus, in Fig. 2, again letting {{{}
sk()
}
pk()
} =
0
,
Cut(,
0
,
0
) = {

},
i.e. the listener node at the right. In Fig. 3, the cut consists of the lower node:
Cut({}
, , ) = {
{}
}.
In Fig. 4, for both skeletons
1
and
2
, we were interested in the test Cut(,
0
,
).
In Figs. 67, it is Cut(,
3
,
), with
3
= {{}
}. The cuts driving the MAIP

analysis, shown in Figs. 1314, are (again with
2
= {{aic}
EK
}) Cut(aic, ,
0
) and
Cut(aic,
2
,
0
).
Denition 5.3 A node
1
= Cut(, , ), is solved in , iff
1. for some transmission node
1
,
1

1
; or else
2. there is a listener node
1
= Lsn[] with
1

1
, and either
(a) = {
0
}
, or else
(b) for some {
0
}
1
, =
1
1
is the matching decryption key.
We also say that
1
, is solved in the cut if
1
. is solved iff for all
1
,
1
is solved in .
1
, is a test if
1
is unsolved in . A solution for
1
is a transmission
or listener node
1
satisfying clause 1 or 2.
In skeleton
0
(Fig. 2) there is no way to add a solution to Cut(,
0
,
0
), which showed
that
0
is dead. In any homomorphic image of
0
, the image of Cut(,
0
,
0
) remains
unsolved. In Fig. 4, the solution to Cut(,
0
,
1
) is an instance of Clause 2a, while the
solution to Cut(,
0
,
2
) is an instance of Clause 1. The solutions to the MAIP cuts
Cut(aic, ,
1
) and Cut(aic,
2
,
2
) are both instances of Clause 1 (Figs. 1314).
Solved cuts are derivable using adversary webs (Def. 3.3):
Lemma 5.4 ([6, Prop. 4]) Let
1
be a reception node in , and suppose that for every
cut = Cut(, , ),
1
implies
1
is solved in . Then there exists an adversary
web deriving msg(
1
) from support(
1
, ) avoiding avoid().
Proof: Let = support(
1
, ). The proof is by structural induction on the pair
, msg(
1
), i.e. induction on the well-founded relation that holds between
1
,
1
and
2
,
2
when
1

2
and, for every
1
, there is a

2
such that
.
The induction hypothesis is that for every
1
,
1
below , msg(
1
) in this ordering,
1
is derivable from
1
using a web that avoids avoid().
Case msg(
1
) = : If the basic value avoid(), then the one-node web that origi-
nates sufces. If , then the empty web sufces.
Since msg(
1
) = , by the denition of skeleton, non
. Thus, assume
unique
and originates before

1
in , and the subset
= { : } is
non-empty. If some concatenation
0
, then apply the induction hypothesis to

(
{
0
0
}) {
0
} {
0
}. This asserts the existence of a penetrator web
deriving
. Obtain the desired web by prepending a separation S-strand above any occurrences of
0
and
0
in
.
Otherwise,
consists entirely of encryptions, and Cut(,
, ) is well-dened,
and by the assumption solved. By the denition of
, no transmission node
1

1
can have
msg(
1
). Thus, there is a decryption key
1
such that Lsn[
1
]
1
and some {}
. Apply the induction hypothesis to (
{}
){}. This yields

a web
deriving . Obtain the desired web by prepending a decryption D-strand above

any occurrences of in
.
Case msg(
1
) =
0
1
: Apply the induction hypothesis to ,
0
and ,
1
, obtaining
a pair of webs
0
,
1
deriving the two pieces. Obtain the desired web by appending a
separation C-strand at the bottom to derive
0
1
.
Case msg(
1
) = {
0
}
: If {
0
}
, then the empty web sufces. If contains any

concatenations, we reduce them as before.
Thus, assume consists only of encryptions. Letting
= { : {
0
}

}, Cut({
0
}
, , ) is well-dened, and since {

0
}
, it has no solution by a
transmission node. Hence, either Lsn[]
1
or else Lsn[
1
1
]
1
where some
{
1
}
.
In the rst case, apply the induction hypothesis to
,
0
, obtaining a web . Obtain
the desired web by appending an encryption E-strand using to obtain {
0
}
. In the
second case, apply the induction hypothesis to
{
1
}
1
{
1
} and {
0
}
, and
prepend a decryption D-strand above any uses of
1
.
Theorem 5.5 (Authentication Test Principle, [6, Prop. 5]) 1. If every cut in is
solved, then is realized.
2. If is realized, then has an extension
, obtained by adding only listener

nodes, in which every cut is solved.
Proof: 1. From Lemma 5.4.
2. Since is realized, for each reception node nodes(), there is an adversary
web
deriving msg() from preceding transmission nodes. Build
by addingfor
each message used as a key on an encryption or decryption strand in
a listener
node for , where
and (for all )
implies
. By construction,
all of these listeners are derivable, since the adversary has in fact derived them in
.
In
, let
1
Cut(, ,
) be minimal in the cut, and let be the bundle

combining the regular nodes of
with the adversary nodes of the webs
. Since

msg(
1
), there are
-minimal nodes
1
such that
msg(
1
), and
1

1
is a transmission node. If
1
=
1
,
1
is solved in the cut. Otherwise, since
1
is min-
imal in the cut,
1
is an adversary node. Since is a set of encryptions,
1
lies on an
encryption or decryption strand. By the construction of
, there is a listener below

1
for the encryption or decryption key used on this adversary strand.
When = Cut(, , ) and = [
] : , we say that () =
Cut(
(),
(), ). solves the test

1
, if
(
1
) is solved in (). destroys
the test
1
, if () if
(
1
) (). If destroys a test, then it solves it.
If :
and solves test

1
, , then by Def. 5.3, every solving
1
, is
of at least one of three kinds, namely a solution:
by destruction if
(
1
) ();
by transmission if there exists
1

(
1
) such that
1
is a transmission node
that is minimal in (); or
by listener if there exists
1
= Lsn[] such that (a)
1

(
1
), and (b) either
() = {}
or else {}
().
6. Cohorts of Solutions
A solution cover is a set covering all essentially different ways to solve or destroy a test
(modulo
n
). A cohort is a one where distinct members are
n
-incomparable:
Denition 6.1 Let = Cut(, , ); let
1
be an unsolved minimal node in ; and let
be a set of homomorphisms :
, where each
is a skeleton. is a solution
cover for
1
and = Cut(, , ) iff
1. For each ,
(
1
) is solved in (); and
2. If : , where
(
1
) is solved in (), then for some ,
n
.
is a cohort for
1
and = Cut(, , ) iff it is a solution cover such that
3. If
1
,
2
and
1

n

2
, then
2
=
1
.
If no solves
1
, , then is a cohort for
1
, (and conversely).
In Clause 2 we require that
n
, rather than merely that = with
a possibly non-node-injective . This requires some solution covers to contain more
members. Consider, for instance,
21
, which differs from
21
in Fig. 5 by omitting the
ordering relations between the top two nodes and the bottom two nodes. That is,
21
contains an initiator strand and a responder strand, but with the minimal partial order.
Thus, for the lower left node
1
, the test
1
, = Cut({}
, ,
21
) is unsolved.
A solution cover for
1
, consists of three homomorphisms: (i) a solution by lis-
tener that adds a listener strand Lsn[]; (ii) a solution by transmission that adds another
responder strand with transmission node
1

1
; and (iii) a solution by transmission
that does not add any nodes, but adds a pair to the ordering relation, namely, restoring the
precedence relation between the existing responder strand transmission and the reception
node
1
. Although (iii) is not a node-injective extension of (ii), it does factor through (ii).
Thus, without node-injectivity in Clause 2, the two homomorphisms (i,ii) would sufce.
Let [] choose a canonical representative from each isomorphism class of homomor-
phisms; i.e. (i) if
n

n
, then [] = [], and (ii) []
n

n
[]. We write
() to compose [] with min (Def. 3.10); i.e. dene () = {[] : min()}.
Lemma 6.2 Let = Cut(, , ); let
1
be an unsolved minimal node in .
1. {: solves
1
, } is a solution cover.
2. If and is a solution cover for
1
, then so is , where
= ( {:
n
}) {}.
3. If is a solution cover for
1
, then () is a cohort for
1
, .
Proof: 1. Immediate from Def. 6.1.
2. Clause 1 holds because . Clause 2 holds because if is any solution,
then
n
for some ; but if , then
n

n
.
3. () is a solution cover by the preceding clause, since () =
. It
is a cohort since it contains only canonical,
n
-minimal values.
Denition 6.3 When = Cut(, , ) and
1
is an unsolved minimal node in , then
dene cohort(
1
, ) = {: solves
1
, }.
Lemma 6.4 If cohort(
1
, ) and is a solution:
by destruction, then
is surjective,
= (
), non
(non
), and
unique
(unique
).
Moreover,
is
-minimal among such that ()

()
(msg(
1
)).
by transmission, then there is exactly one transmission node
1

(
1
) that is
minimal in (). Moreover:
0
d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d
1
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
e
. . .
1
p
p
p
p
p
p
Figure 15. Cohort members
and nodewise-injective
1. nodes(
) = ran(
) {
0
:
0

1
};
2.
is the least ordering that extends
), satises Def. 3.1, Cl. 4b, and

in which
1

(
1
);
3. non
(non
) and unique
(unique
);
5
4. Letting
1
= ( ), is
-minimal among such that, for all < ,

()
()
(msg( )) and also
()
()
msg(( )).
by listener, then nodes(
) = ran(
) {Lsn[]} for some and

0
such that either
= {
0
}
or else {
0
}
1 .
is the least ordering that extends
),
satises Def. 3.1, Cl. 4b, and in which
1

(
1
). Moreover,
= Id,
non
= non
, and unique
= unique
.
Proof: In each case, if the stated condition is not true, then we can reduce in the
n
ordering by making it true.
The comment about
21
after Def. 6.1 points out that there are two possibilities covered
in the by transmission clause here:
1
may be a newly added node, or it may be a node
already in , for which the ordering relation
1

1
has been newly added. This may
also apply in the by listener clause.
6.1. Completeness of the Search
Solving tests meets a progress or completeness condition. Namelymodulo omission of
listener strandsby solving tests we can reach all of the shapes. We allow an initial step
in which some strands of are identied; cf. Fig. 15.
Theorem 6.5 (Search Completeness) Suppose : , and every cut in is solved.
Let = {: . =
is surjective
is injective}.
= , and there is a universal
0
:
0
.
Let
0
be the node-injective
0
with =
0

0
.
There exists 0, and there exist (a) tests
0<
, (b) node-injective solu-
tions
:
1

0<
, and (c) node-injective

0<
, such that:
1. for each with 0 < ,
cohort(
) and
=
1
; and
2. every cut in
is solved.
5
When
1
= ( ), and has origination assumptions (see p. 25), we in fact have
non
(non
) (role_non( )) and unique
(unique
) (role_non( )).
Proof: Let = [
] : ( `
(nodes())) be with its target restricted to

the image of . Then and the embedding `(
(nodes())) are respectively

node-surjective and node-injective. Thus, = .
For each pair
1
,
2
of nodes of such that
(
1
) =
(
2
), apply Lemma 3.14,
Clause 3; so there is a universal
0
.
0
is injective, since we have already identied all
the pairs that
does.
Now suppose that
has been dened. If all cuts in
are solved, we are done.

Otherwise, let (
) with
and
= Cut(
) be unsolved. Since
) is solved,
+1

n

for some
+1
cohort(
). Any such
+1
must
be injective, since
is. Dene
+1
to be the node-injective homomorphism such that
=
+1

+1
, which exists by
+1

n

.
This process must terminate with a
in which all tests are solved, because, for

each , (
. . .
1
0
)
n
, and there are only nitely many non-isomorphic values
n
by Lemma 3.11, Clause 4.
6.2. Cohorts and Characterizations
CPSA incrementally computes a (node-injective) characterization for some starting
point . A cohort is a single information-increasing step in this process.
Although, as Thm. 5.5 suggests, CPSA adds listener nodes to solve tests, as reception
nodes they do not increase the information available to the adversary. In a shape :
, for each listener node nodes(), there is a listener node nodes() such that
=
(). Otherwise would not be minimal; could be omitted.

CPSA adds listener nodes for keys to indicate possible solutions in which is
disclosed. It may later add other regular strands showing how became disclosed. Thus,
CPSAs intermediate steps use listener nodes that it will discard when reporting a shape.
We dene fringe to trim out these listener nodes that will eventually be discarded.
Denition 6.6 When : , dene trim() = [
] :
where
= { nodes(): nodes() . =
() is not a listener node}
= , (
` ), non
, unique
.
Dene trim() = {trim(): }. A set of homomorphisms is a fringe for iff
every factors through trim().
Dene Targets() = {: ( : ) }.
This theorem follows from the denitions via Lemma 3.11:
Theorem 6.7 Let be a characterization for . The singleton {Id
} is a fringe for .
Let be a fringe for .
1. If : in where
1
, is unsolved, then
is also a fringe for , where
= ( {}) { : cohort(
1
, )}.
2. If every Targets() is realized, then min() min(trim()).
In Cl. 1, when cohort(
1
, ) is empty, is dead, and we discard : .
6.3. The CPSA Algorithm
Thm. 6.7 provides motivation for CPSAs algorithm. CPSA uses breadth-rst search start-
ing with an initial skeleton . CPSA maintains the fringe as a union of two sets, .
contains the as-yet unexplored part. contains the current estimate of the set of shapes.
contains those homomorphisms : such that is realized, and no <
n

with realized target has yet been seen. Initially, = {Id
}, and = .
CPSA halts if is empty, returning .
Otherwise, it selects one : from . If is realized, it compares trim()
to the current members of . If for some , <
n
trim(), is discarded, and
otherwise we add trim() to . If trim() <
n
for some , we discard them.
If is not realized, CPSA nds an unsolved test
1
, = Cut(, , ). CPSA com-
putes cohort(
1
, ), and then replaces by { : cohort(
1
, )}.
How does CPSA compute cohort(
1
, )? For solutions by destruction and by lis-
tener, it follows the prescriptions given in Lemma 6.4. In nding the solutions by trans-
mission, there are two stages. In the rst, CPSA considers every and each trans-
mission node . For each path within msg( ), if traverses no key edge, CPSA
attempts to unify with (msg( )). If this unication succeeds with some
0
, CPSA
attempts to extend
0
to satisfy the condition of Lemma 6.4, Cl. 4. If is nite, then
since there are at most nitely many encryptions along the path to any occurrence in an
earlier node
0
, there can be only nitely many successful outcomes. CPSA collects all
successful results, as , , vary.
This rst step could leave out solutions by transmission in which the critical value
is inserted into msg( ) as an ingredient in a larger message . Suppose, for some path
, (msg( )) is an indeterminate . Choose
0
with
0
() = for any where .
Consider
1
=
0
( ). Suppose that in msg(
1
), traverses neither a key edge nor
any , but whenever
0

+
1
, every path
0
in msg(
0
) that reaches traverses
either a key edge or a member of . Then
1
provides a solution to , even though the
choice of
0
() = was not motivated syntactically by unication in msg( ).
However, by the Indeterminate Acquisition Principle (Section 2.5, p. 16), there is
at least one reception node where < and msg( ). Thus, there is at
least one path
0
such that
0
does not traverse a key edge, and
0
(msg( )) = , or
equivalently
0
(msg(
0
( ))) = . Along every such path in msg(
0
( )), we must
unify some encryption with a member of . Since there are only a nite number of ways
to succeed, only nitely many can be successful substitutions for .
6
Theorem 6.8 Let be nite, and let be a cohort for
1
, = Cut(, , ). There are
only nitely many .
Proof: By the niteness of , there are only nitely many solutions by listener. More-
over, consider a solution by destruction . Since
()
()
(msg(
1
)), for
each path to in msg(
1
), there is some encryption that traverses, such that
unies with some member of . By the niteness of and of msg(

1
), and the
m.g.u. property, there are only nitely many most general ways to do so.
If is a solution by transmission, then it meets the conditions in the discussion
above, in each case belonging to a nite set of possibilities.
6
Key ideas in the cohort computation are due to John Ramsdell and Paul Rowe.
The CPSA algorithm is thus nitely branching; by Thm. 6.7 it never discards any possi-
bilities, and by Thm. 6.5 it reaches each shape after nitely many steps.
Conclusion. We have presented here a theory explaining CPSA, the Cryptographic
Protocol Shape Analyzer. We will write more specically about the design and imple-
mentation of CPSA elsewhere.
We believe that the Authentication Test Principle is central to cryptographic proto-
cols. Indeed, already in our rst paper about the tests, we pointed out that they provide
very strong heuristics to guide cryptographic protocol design [12]. We have also illus-
trated a systematic protocol design process, which led to a protocol achieving goals akin
to the Secure Electronic Transaction protocol, organized by reference to the tests [9].
Moreover, we have recently used the tests to justify a criterion for when combining a pro-
tocol with new behaviors preserves all security goals met by the original protocol [10].
We hope to develop the theory we have just described to provide a systematic set of pro-
tocol transformations that preserve security goals. This appears likely to provide rigorous
techniques to replace the heuristics that protocol designers currently use.
Acknowledgments. I am enormously grateful to F. Javier Thayer, who through a
decade and more has been an integral collaborator. Shaddin Dughmi (a.k.a. Doghmi) and
John D. Ramsdell contributed so much to the theory and to making it work. Dughmi
wrote the rst version of CPSA. Ramsdell is author of the current version.
Jonathan Herzog contributed to the original strand space ideas. Paul Rowe suggested
key ideas and puzzles. Moses Liskov and Leonard Monk helped clarify this chapter.
References
[1] Boris Balacheff, Liqun Chen, Siani Pearson, David Plaquin, and Graeme Proudler. Trusted Computing
Platforms: TCPA Technology in Context. Prentice Hall PTR, Upper Saddle River, NJ, 2003.
[2] Bruno Blanchet. Vrication automatique de protocoles cryptographiques: modle formel et modle
calculatoire. Automatic verication of security protocols: formal model and computational model. M-
moire dhabilitation diriger des recherches, Universit Paris-Dauphine, November 2008.
[3] Edmund Clarke, Somesh Jha, and Will Marrero. Using state space exploration and a natural deduction
style message derivation engine to verify security protocols. In Proceedings, IFIP Working Conference
on Programming Concepts and Methods (PROCOMET), 1998.
[4] Cas J.F. Cremers. Unbounded verication, falsication, and characterization of security protocols by
pattern renement. In ACM Conference on Computer and Communications Security (CCS), pages 119
128, New York, NY, USA, 2008. ACM.
[5] C.J.F. Cremers. Scyther - Semantics and Verication of Security Protocols. Ph.D. dissertation, Eind-
hoven University of Technology, 2006.
[6] Shaddin F. Doghmi, Joshua D. Guttman, and F. Javier Thayer. Completeness of the authentication tests.
In J. Biskup and J. Lopez, editors, European Symposium on Research in Computer Security (ESORICS),
number 4734 in LNCS, pages 106121. Springer-Verlag, September 2007.
[7] Shaddin F. Doghmi, Joshua D. Guttman, and F. Javier Thayer. Searching for shapes in cryptographic
protocols. In Tools and Algorithms for Construction and Analysis of Systems (TACAS), number 4424 in
LNCS, pages 523538, 2007.
[8] Shaddin F. Doghmi, Joshua D. Guttman, and F. Javier Thayer. Skeletons, homomorphisms, and shapes:
Characterizing protocol executions. In M. Mislove, editor, Proceedings, Mathematical Foundations of
Program Semantics, April 2007.
[9] Joshua D. Guttman. Authentication tests and disjoint encryption: a design method for security protocols.
Journal of Computer Security, 12(3/4):409433, 2004.
[10] Joshua D. Guttman. Cryptographic protocol composition via the authentication tests. In Luca de Al-
faro, editor, Foundations of Software Science and Computation Structures (FOSSACS), number 5504 in
LNCS, pages 303317. Springer, 2009.
[11] Joshua D. Guttman. Fair exchange in strand spaces. In M. Boreale and S. Kremer, editors, SecCo: 7th In-
ternational Workshop on Security Issues in Concurrency, EPTCS. Electronic Proceedings in Theoretical
Computer Science, Sep 2009.
[12] Joshua D. Guttman and F. Javier Thayer. Authentication tests and the structure of bundles. Theoretical
Computer Science, 283(2):333380, June 2002. Conference version appeared in IEEE Symposium on
Security and Privacy, May 2000.
[13] Jonathan K. Millen and Vitaly Shmatikov. Constraint solving for bounded-process cryptographic pro-
tocol analysis. In 8th ACM Conference on Computer and Communications Security (CCS 01), pages
166175. ACM, 2001.
[14] Lawrence C. Paulson. Proving properties of security protocols by induction. In 10th IEEE Computer
Security Foundations Workshop, pages 7083. IEEE Computer Society Press, 1997.
[15] Adrian Perrig and Dawn Xiaodong Song. Looking for diamonds in the desert: Extending automatic
protocol generation to three-party authentication and key agreement protocols. In Proceedings of the
13th IEEE Computer Security Foundations Workshop. IEEE Computer Society Press, July 2000.
[16] Dag Prawitz. Natural Deduction: A Proof-Theoretic Study. Almqvist and Wiksel, Stockholm, 1965.
[17] John D. Ramsdell and Joshua D. Guttman. CPSA: A cryptographic protocol shapes analyzer. In Hack-
age. The MITRE Corporation, 2009. http://hackage.haskell.org/package/cpsa; see
esp. doc subdirectory.
[18] John D. Ramsdell, Joshua D. Guttman, and Paul D. Rowe. The CPSA Specication: A Reduction System
for Searching for Shapes in Cryptographic Protocols. The MITRE Corporation, 2009. In http:
//hackage.haskell.org/package/cpsa source distribution, doc directory.
[19] Dawn Xiaodong Song. Athena: a new efcient automated checker for security protocol analysis. In
Proceedings of the 12th IEEE Computer Security Foundations Workshop. IEEE Computer Society Press,
June 1999.
[20] F. Javier Thayer, Jonathan C. Herzog, and Joshua D. Guttman. Strand spaces: Proving security protocols
correct. Journal of Computer Security, 7(2/3):191230, 1999.
Security Analysis using Rank Functions
in CSP
Steve SCHNEIDER
University of Surrey
Abstract. Communicating Sequential Processes (CSP) is an abstract language for
describing processes and reasoning about their interactions within concurrent sys-
tems. It is appropriate for investigating the overall behaviour that emerges. It has a
mature theory, and powerful tool support [For03] and can be considered as an off-
the-shelf framework which can be customised for particular domains through addi-
tional domain-specic constructions and theory. This chapter introduces the appli-
cation of CSP to the analysis of security protocols. For the purposes of this chapter,
we will introduce only those parts of CSP that we use in protocol analysis. Fuller
descriptions of the language and theory can be found in [Hoa85,Ros97,Sch99].
1. Review of CSP
In CSP, processes are described in terms of the patterns of events that they can perform.
Events are occurrences in the lifetime of a process, including communications with other
processes, as well as other actions that they might be performing. In our context, events
will typically have several components, such as trans.A.B.m representing communica-
tion of a message m over channel trans.A.B. Messages will themselves have some spe-
cic structures (to include encryption and signing), and are drawn from a dened set of
messages.
Processes are described using a language comprised of a number of process con-
structors:
Prex If e is an event, and P is a process, then e P is the process which initially is
prepared only to perform event e, after which it behaves as P.
Output For a channel c and value v, the process c!v P outputs v along channel c, and
subsequently behaves as P. Semantically it is equivalent to c.v P, with the !
symbol used to indicate output.
Input If P(x) is a family of processes indexed by x, then c?x P(x) is a process which
initially reads a value x on channel c, and subsequently behaves as P(x). We also
make frequent use of pattern matching. We can input messages of a particular
form or with some particular values, by giving the general pattern. Only inputs
that match the pattern are accepted, and the variables in the pattern are bound
according to the value received. For example, to accept triples in which the second
value is 3, we could use the input c?(x, 3, y) P(x, y). As another example, to
accept messages encrypted only with a particular key K we could use the input
c?{m}
s
K
P(m).
IOS Press, 2011
doi:10.3233/978-1-60750-714-7-258
258
Termination The process STOP indicates termination (or deadlock): this process can
perform no further events.
Choice If P(i) is a nite or innite family of processes indexed by i I, then the process
i
P(i) offers the choice of all of the P(i) processes, and can behave as any of
them. The choice is made on occurrence of the rst event.
Interleaving The process
i
P(i) is the interleaving of all of the P(i) processes. All of
the P(i) processes run independently and concurrently, and can be scheduled in
any order. There is also a binary form P Q.
Parallel The parallel combination P[ A] Q of two processes runs P and Q concurrently,
but they must synchronise on all events in the set A. A special case is the parallel
combination P Q, which requires synchronisation on all events. This synchro-
nisation mechanism is the way in which processes interact with each other. For
example, the processes in (c!v P) (c?x Q(x)) share the channel c, so
the parallel combination will communicate the value v along c, and subsequently
behave as P Q(v). If A is a singleton set {a} then the set brackets may be elided.
Thus the combination P[ a ] STOP behaves as P blocked on the event a.
Recursion Processes can be dened recursively, using (parameterised) process names:
the denition N(p) = P(p) denes process N(p) with parameter p to behave as
P(p). The name N also appears in the body of P, corresponding to a recursive call.
The language also includes internal choice, abstraction, timeout, event renaming, and
interrupts, but these are not needed here so will not be considered further.
The semantic foundation we will use is the traces model for CSP. A trace is a (-
nite) sequence of events. Traces are written as sequences of events listed between angled
brackets: e
1
, . . . , e
n
.
The traces model associates every CSP process with a set of traces, consisting of
all the traces that might possibly be observed in some execution of that process. For
example,
traces(in?x out!x STOP) = {}
{in.v v M}
{in.v, out.v v M}
where M is the type of channel in.
The theory of CSP gives ways of reasoning directly about the set of traces of any
system described in CSP.
Specications are concerned with allowable system behaviours. A trace specica-
tion will describe which traces are allowable, and a CSP system can then be checked
against the specication by considering all its traces and demonstrating that they are all
acceptable. We write P sat S to indicate that every trace of traces(P) meets the predicate
S. For example, consider the predicate a precedes b dened on traces as follows:
a precedes b = (last(tr) = b a in tr)
where last(tr) is the last event in trace tr (undened if tr = ), and a in tr means that a
appears somewhere in the trace tr. Then
(a b STOP) sat a precedes b
S. Schneider / Security Analysis Using Rank Functions in CSP 259
2. Protocol modelling and verication
We will apply this framework to security protocol analysis. This involves developing a
CSP model of a system which expresses the protocol, and specifying the security prop-
erty to be considered. In order to judge the CSP model against the specication we make
use of the rank function theorem which is at the heart of the approach. We use the
Corrected handshake protocol of Chapter Introduction Figure 1 as a running example,
and begin with the standard notation:
A B :
{
[A.B.k]
sk(A)
}
a
pk(B)
[k fresh]
B A : {s}
s
k
This protocol description is written in terms of the messages to be exchanged between the
protocol participants, and describes how each protocol participant is expected to behave.
In order to model this protocol in CSP, we need to dene the set of possible mes-
sages that can be communicated. For this protocol we must consider that messages can
be constructed using concatenation, shared key encryption, public key encryption, and
signing. Participant identiers, shared keys, and plain text are available as message com-
ponents. We dene the space of messages as follows, and consider all messages in the
CSP model to come from this set:
M
1
, M
2
::= messages
I ( USER) agent identities
S ( PLAIN) plaintext
K ( KEY) shared keys
M
1
.M
2
concatenation of messages
{M}
s
K
symmetric encryption of message M by key K
{M}
a
pk(I)
asymmetric encryption of message M by agent Is public key
[M]
sk(I)
signing of message M with agent Is signature key
We assume sets USER of user identiers; PLAIN of plaintext messages (from which the
payload in message 2 is drawn), and KEY of shared keys. This approach treats messages
that are constructed differently as different, thus building into the model that any par-
ticular message can be constructed in only one way, an assumption known as perfect
encryption [PQ00].
We are now in a position to model the protocol participants. The protocol initiator,
denoted A, chooses a fresh key k and a protocol partner j, assembles the rst message
by signing and then encrypting with js public key, and transmits it to j. A then awaits a
message encrypted with the key k. As run of the protocol may be described in CSP as
follows:
INIT
A
(k) =
j
trans.A!j!
{
[A.j.k]
sk(A)
}
a
pk(j)
rec.A.j?{s}
s
k
STOP
We use channel trans for outputs from a protocol participant, and channel rec for inputs.
trans.A.j.m is a transmission of message m from A, intended for j. As we shall see in the
PAIRING
S m
1
S m
2
S m
1
m
2
UNPAIRING
S m
1
m
2
S m
1
S m
2
MEMBER
S m
[m S]
SUBSET
S
m
S m
[S
S]
TRANSITIVE CLOSURE
s
.S s
m
S m
ENCRYPTION 1
S m S k
S {m}
s
k
DECRYPTION 1
S {m}
s
k
S k
S m
ENCRYPTION 2
S m
S {m}
a
pk(i)
DECRYPTION 2
S {m}
a
pk(i)
S m
[i = A, B]
SIGNING
S m
S [m]
sk(i)
[i = A, B]
MESSAGE EXTRACTION
S [m]
sk
S m
Figure 1. Attacker inference rules
model, we allow for the fact that it might not reach j. Observe the initial choice of j, and
the use of pattern matching in the received message: the key of the input message must
be k, though any message s can be accepted as the contents.
The protocol responder, denoted B, receives an initial message signed by i and en-
crypted with his public key pk(B). That message contains a key k, which B then uses to
encrypt a response s.
RESP
B
(s) = rec.B?i?
{
[i.B.k]
sk(i)
}
a
pk(B)
trans.B!i!{s}
s
k
STOP
We must also model the hostile environment within which A and B communicate.
We use the Dolev-Yao model [DY83], in which the attacker has complete control of the
network. Messages are transmitted to the attacker for forwarding to the intended recip-
ient; and messages received come from the attacker. The attacker can also divert, in-
vent, replay, destroy, and alter messages. We also assume that the attacker can participate
in protocol runs as a legitimate user, so some of the user identities in USER are under
the control of the attacker (i.e. the attacker can decrypt messages encrypted under their
public keys, and can sign with their signature keys).
Conversely, the attacker may not decrypt messages without possession of the de-
cryption key; nor sign messages without knowledge of the signature key. The messages
that the attacker is able to generate, and thus use in an attack, are limited by the attackers
knowledge. Figure 2 gives the rules that govern how the attacker can generate new mes-
sages: is dened as the smallest relation closed under all of these rules. Thus S m
means that the attacker can construct message m from the set of messages S. Note that
rules DECRYPTION 2 and SIGNING encapsulate the assumption that the attacker controls
any users other than A and B.
The CSP model of the attacker will be a process ENEMY parameterised by the set
S of messages that the attacker knows. This will be a combination of those messages
known initially, together with those sent out by protocol participants. ENEMY(S) can
receive any message m from any user i sent to any other user j, in which case the set S
is augmented with m. ENEMY(S) can also supply any message m that can be generated
from S, to any user i, as if it came from user j.
ENEMY(S) = trans?i?j?m ENEMY(S {m})
iUSER
jUSER
mSm
rec!i!j!m ENEMY(S)
This denes the threat model in terms of attacker capabilities. Correctness in the context
of this attacker indicates that there are no attacks froman attacker with these capabilities.
The attacker behaviour includes the possibility of passing messages on correctly, as well
as the standard manouevres used in attacks: blocking, redirecting, spoong, combining,
dissecting, and replaying messages. However, the key point in this model is that the
attacker is unable to attack the cryptographic mechanisms.
The denition of the attacker in the model will need to identify the initial knowledge:
a set IK of messages that the attacker is considered to have available initially. This will
include all user names, some plaintext, and some session keys. However, any fresh keys
or text used by honest agents in protocol runs will not be in IK, to model our expectation
that the attacker should not be able to guess them. The attacker can learn them only
through protocol runs.
We then dene ENEMY to be ENEMY(IK).
A model of a single run of the protocol with A as initiator and B as responder, with
specic key k
AB
and secret s
AB
will be:
SYS = (INIT
A
(k
AB
) RESP
B
(s
AB
)) [ trans, rec ] ENEMY
A and B do not synchronise on any events directly: all of their communications are via
ENEMY. On the other hand trans and rec are in the alphabets of both sides of the parallel
operator, so all occurrences of trans and rec involve one of the protocol participants, and
also ENEMY. Thus ENEMY is involved in all communications within the system.
SYS describes a model involving just a single pair of protocol participants A and B
on a single run of the protocol. In order to explain the essence of the approach we will
consider this model through the majority of this chapter. However, this can be generalised
to the case of arbitrarily many concurrent runs, discussed in Section 6.
2.1. Specication
Having developed the model of the protocol, we nowconsider the properties that we wish
to demonstrate. We will consider authentication of each party by the other, and secrecy.
Authentication is concerned with establishing the identity of the other party. If A
runs the protocol with B, then the intention is that by the end of the protocol run A can
be condent that the protocol was indeed run with B. From Bs point of view, B wishes
to be condent that a protocol run apparently with A was indeed with A.
A B
{
[A.B.k]
sk(A)
}
a
pk(B)
respgo.B.A.s.k
{s}
s
k
initdone.A.B.s.k
Figure 2. Introducing specication events for A authenticating B
This can be captured within the traces of SYS, stating that any trace which includes
a protocol run of A with B should also contain a corresponding protocol run of B with A.
However, we nd it cleaner to introduce particular specication events into the protocol
to state explicitly that a protocol participant has reached a particular stage, and what
information they have used in that protocol run. By instrumenting the protocol with such
events we can give specications directly on those events rather than implicitly in terms
of the sequence of events that have gone previously.
Thus for A to authenticate B we add an event initdone.A.B.s.k which A uses to signal
completion of a protocol run with B, with key k, where s is the plaintext that has been
received in message 2. We also add an event respgo.B.A.s.k into Bs run to indicate that
B is running the protocol with A, with plaintext s, and with key k received in message 1.
For authentication, respgo needs to appear causally prior to initdone in the protocol run.
The placement of these additional events is illustrated in Figure 2.
The precise authentication property can be varied by varying the specication
events selected. Agreement purely on the key is captured by the pair initdone.A.B.k and
respgo.B.A.k; agreement only on the protocol participants would be captured by using
the pair initdone.A.B and respgo.B.A. This would provide A with assurance that the other
participant is B, but no assurance that they agree on the key k or text s. A hierarchy of
authentication properties is discussed in [Low97].
To consider the authentication property, the descriptions of INIT
A
and RESP
B
are
adjusted to incorporate these specication events:
INIT
A
(k
AB
) = trans.A!B!
{
[A.B.k
AB
]
sk(A)
}
a
pk(B)
rec.A.B?{s}
s
k
AB
initdone.A.B.s.k
AB
STOP
RESP
B
(s
AB
) = rec.B?j?
{
[j.B.k]
sk(j)
}
a
pk(B)
respgo.B.j.s
AB
.k
trans.B!j!{s
AB
}
s
k
STOP
The authentication property from As point of view is that whenever the signal
even initdone.A.B.s.k occurs with specic s and k, then respgo.B.A.s.k should previously
have occurred, with the same s and k. This will indicate that B is running the protocol,
with A, and that they agree on the content of the protocol run. This requirement as a
trace specication is that any trace of SYS which contains initdone.A.B.s.k also contains
respgo.B.A.s.k. The attacker cannot perform initdone or respgo events since they have
been introduced purely for the purposes of specicationthey are modelling points in
the protocol rather than communications that the attacker can engage in.
Aviolation of the property will be a trace of SYS in which A performs initdone.A.B.s.k
without B having previously performed the corresponding respgo.B.A.s.k. In that case
A will have been brought to a point where the protocol run apparently with B has com-
pleted, but B has not been involved in the same protocol run. This will be either because
there is a mistake in the protocol, or because an attack is possible.
We x (arbitrary) key k
AB
and text s
AB
, and consider authentication with respect to
these. The form of specication SYS is required to satisfy is then:
respgo.B.A.k
AB
.s
AB
precedes initdone.A.B.k
AB
.s
AB
which states that any trace in which the initdone event appears must have the correspond-
ing respgo appear earlier in the trace.
2.2. A general theorem for proving authentication
The following theorem gives conditions for establishing that an event a precedes another
event b in a network SYS consisting of a number of users USER
i
in parallel with ENEMY.
It makes use of a rank function which associates messages and signals with integers. If
every component within the system can only introduce messages of positive rank when
a is blocked, and if b has non-positive rank, then it follows that b cannot occur when a is
blocked. Thus in the unblocked system any occurrence of b must follow an occurrence
of a.
In the theorem, conditions 1 and 2 establish that ENEMY cannot introduce messages
of non-positive rank; condition 3 states that b has non-positive rank; and condition 4
states that if each user i only receives messages of positive rank, then it can communicate
messages and signals only of positive rank.
Rank Function Theorem
If : MESSAGE SIGNAL is such that:
1. m IK.(m) > 0
2. S MESSAGE.((S) > 0 S m) (m) > 0
3. (b) 0
4. i.(USER
i
[ a ] Stop) sat (tr rec) > 0 (tr) > 0
then (
i
USER
i
) [ trans, rec ] ENEMY sat a precedes b.
In condition 4, the notation tr rec denotes the projection of trace tr onto the channel
rec: in other words, the subsequence of rec events occurring within tr. This requirement
on USER
i
blocked on a is that if only positive rank messages are received, then no non-
positive rank message should be produced. The proof of the theoremis given in [Sch98b].
We have abused notation and extended to apply not only to messages and signals,
but also to events, traces, and sets:
(c.m) = (m)
(S) = min{(s) s S}
(tr) = min{(s) s in tr}
For any particular protocol specication the challenge is to identify a suitable that
meets the conditions. Identication of such a establishes correctness of the protocol
with respect to that specication.
2.3. Application of the theorem
We require in this particular case that:
1. every message in IK has positive rank;
2. if every message in a set S has positive rank, and S m, then m has positive rank;
3. initdone.A.B.k
AB
.s
AB
does not have positive rank;
4. INIT
A
(k
AB
) maintains positive rank: if it has only received messages of positive
rank then it only outputs messages of positive rank. Note that
INIT(k
AB
) [ respgo.B.A.s
AB
.k
AB
] STOP = INIT
A
(k
AB
);
5. RESP
B
(s
AB
) [ respgo.B.A.s
AB
.k
AB
] STOP maintains positive rank: if it has only
received messages of positive rank then it only outputs messages of positive rank.
Observe we are considering RESP
B
with the respgo event blocked.
If we can nd a rank function that meets all these conditions, then we will have estab-
lished that SYS satises respgo.B.A.k
AB
.s
AB
precedes initdone.A.B.k
AB
.s
AB
, and hence
that the protocol provides the authentication guarantee required.
Figure 3 gives a rank function that meets all of the required properties.
1. We assume that k
AB
IK since it is fresh for user A. Thus all the messages in IK
will have positive rank.
2. This condition is established inductively over the inference rules. In particular,
we can check for each rule in turn that if it is true for the premisses, then it is also
true for the conclusion.
3. initdone.A.B.k
AB
.s
AB
does not have positive rank, by denition of .
4. INIT
A
(k
AB
) maintains positive rank. It outputs a single protocol message, which
has positive rank; and it can only perform the nal initdone.A.B.s
AB
.k
AB
event if
it has previously received a message of rank 0: a message encrypted with k
AB
.
Thus if it only receives messages of positive rank it will only perform events of
positive rank.
5. It is useful rst to expand the restricted RESP
B
:
RESP
B
(s
AB
) [ respgo.B.A.s
AB
.k
AB
] STOP
= rec.B?j?
{
[j.B.k]
sk(j)
}
a
pk(B)
if (j = A k = k
AB
)
then STOP
else respgo.B.j.s
AB
.k
trans.B!j!{s
AB
}
s
k
STOP
The only time B can send a message of rank 0 is when the received key k is in fact
k
AB
. In this case we must have j = A to reach that point in the restricted protocol.
(i) = 1
(s) = 1
(k) =
{
0 if k = k
AB
1 otherwise
(m
1
.m
2
) = min{(m
1
).(m
2
)}
({m}
s
k
) =
{
0 if k = k
AB
(m) otherwise
({m}
a
pk(i)
) =
{
1 if i = B m = [A.B.k
]
sk(A)
(m) otherwise
([m]
sk(i)
) =
{
0 if m = i.B.k
AB
(m) otherwise
(sig) =
{
0 if sig = initdone.A.B.s
AB
.k
AB
1 otherwise
Figure 3. A rank function for authentication
But then the rank of the received message is 0: (
{
[j.B.k]
sk(j)
}
a
pk(B)
) = 0. Hence
transmission of a message of rank 0 follows receipt of a message of rank 0. Thus
RESP
B
(s
AB
) [ respgo.B.A.s
AB
.k
AB
] STOP maintains positive rank.
We can conclude that As run of the protocol authenticates B.
2.4. Protocol simplication
If the participants are removed from message 1 of the protocol, then we obtain the sim-
plied (awed) version:
A B :
{
[k]
sk(A)
}
a
pk(B)
B A : {s}
s
k
We will consider how this simplication affects the correctness proof.
The natural change to make to the rank function is to change the message in the
denition of to follow the change in the protocol, resulting in the following alternative
clauses (the other clauses are unaffected):
({m}
a
pk(i)
) =
{
1 if i = B m = [k
]
sk(A)
(m) otherwise
([m]
sk(i)
) =
{
0 if m = k
AB
(m) otherwise
The models for analysis also change to reect the simpler rst message:
INIT
A
(k
AB
)
= trans.A!B!
{
[k
AB
]
sk(A)
}
a
pk(B)
rec.A.B?{s}
s
k
AB
initdone.A.B.s.k
AB
STOP
RESP
B
(s
AB
) [ respgo.B.A.s
AB
.k
AB
] STOP
= rec.B?j?
{
[k]
sk(j)
}
a
pk(B)
if (j = A k = k
AB
)
then STOP
else respgo.B.j.s
AB
.k
trans.B!j!{s
AB
}
s
k
STOP
We nd that the revised rank function with the revised CSP models still meets all
the rank function properties. Thus the simplied (awed!) protocol still establishes the
authentication property that A authenticates B, and they agree on the session key k
AB
and
the secret message s
AB
. Although awed in other ways, it still provides this authentication
property.
3. Responder authenticating initiator
The previous section veried that the initiator authenticates the responder. We are also
concerned with authentication in the other direction. The same approach is taken: a pair
of events to specify authentication are introduced into the model of the protocol; a suit-
able model of a protocol run is dened in CSP, this time from the responders point of
view; a rank function is identied which meets the properties of the rank function theo-
rem, establishing the authentication property.
The authenticating events in this instance are respdone and initgo. The event
respdone occurs after the message received from A. The event initgo should be causally
prior to that message, so must occur before As rst communication. At that point A
has the key k but not s, so the event will be initgo.A.B.k. This should be followed by
respgo.B.A.k. This is pictured in Figure 4.
In the CSP model to analyse for this property, we are concerned with Bs use of the
rst protocol message in authenticating the initiator. We therefore x the user A that B is
responding to, and the key k
AB
that B receives in that message.
Since this authentication property is relative to B, we model A as being able to initiate
with any party j, and with any key k. The rank function theorem requires restriction
on initgo.A.B.k
AB
. We therefore obtain the following processes for the initiator and the
responder, which should maintain positive for any proposed rank function :
INIT
A
[ initgo.A.B.k
AB
] STOP =
j,k
if j = B k = k
AB
then STOP
else initgo.A.j.k trans.A!j!
{
[A.j.k]
sk(A)
}
a
pk(j)
rec.A.j?{s}
s
k
STOP
initgo.A.B.k
A B
{
[A.B.k]
sk(A)
}
a
pk(B)
respdone.B.A.k
{s}
s
k
Figure 4. Introducing specication events for B authenticating A
RESP
B
(s
AB
, k
AB
) =
rec.B.A?
{
[A.B.k
AB
]
sk(A)
}
a
pk(B)
respdone.B.A.k
AB
trans.B!A!{s
AB
}
s
k
AB
STOP
The following rank function meets all the conditions of the rank function theorem:
(i) = 1
(s) = 1
(k) = 1
(m
1
.m
2
) = min{(m
1
).(m
2
)}
({m}
s
k
) = (m)
({m}
a
pk(i)
) = (m)
([m]
sk(i)
) =
{
0 if i = A m = A.B.k
AB
(m) otherwise
(sig) =
{
0 if sig = respdone.B.A.k
AB
1 otherwise
This rank function captures the requirement that the enemy cannot generate or obtain
the message [A.B.k
AB
]
sk(A)
, even if it knows k
AB
(note that (k
AB
) = 1, allowing for the
enemy to be able to generate it). This fact is sufcient to guarantee to B that A must have
initiated the protocol run with B, with key k
AB
, establishing authentication.
3.1. Protocol simplication
As previously, if the participants are removed from message 1 of the protocol, then we
obtain the simplied version:
A B :
{
[k]
sk(A)
}
a
pk(B)
B A : {s}
s
k
The revised CSP protocol descriptions are:
INIT
A
[ initgo.A.B.k
AB
] STOP =
j,k
if j = B k = k
AB
then STOP
else initgo.A.j.k trans.A!j!
{
[k]
sk(A)
}
a
pk(j)
rec.A.j?{s}
s
k
STOP
RESP
B
(s
AB
, k
AB
) =
rec.B.A?
{
[k
AB
]
sk(A)
}
a
pk(B)
respdone.B.A.k
AB
trans.B!A!{s
AB
}
s
k
AB
STOP
The natural change to the rank function is in the clause for signed messages, which
becomes:
({m}
a
sk(i)
) =
{
0 if i = A m = k
AB
(m) otherwise
However, we nownd that INIT
A
[ initgo.A.B.k
AB
] STOP no longer meets condition
4 of the rank function theorem, since if k = k
AB
and j = B then it can communicate
trans.A.j.
{
[k
AB
]
sk(A)
}
a
pk(j)
and thus transmit a communication of rank 0 without having
rst received one.
Two responses to this observation are possible: either seek another rank function
which does work; or explore if the reason the rank function fails is because there is an
attack. In this case there is the man in the middle attack seen earlier in Chapter Intro-
duction Figure 1: B accepts the rst message as evidence that A has initiated the proto-
col with B, but in fact A might have initiated it with a different party. We write the attack
as follows:
: A E :
{
[k
AB
]
sk(A)
}
a
pk(E)
: E(A) B :
{
[k
AB
]
sk(A)
}
a
pk(B)
: B E(A) : {s
0
}
s
k
AB
where E(A) represents E masquerading as A.
The predicate initgo.A.B.k
AB
precedes respdone.B.A.k
AB
is not met by the trace cor-
responding to this attack. The conrmation signal respdone.B.A.k
AB
is in fact preceded
by initgo.A.E.k
AB
. Hence the authentication property is not satised by the simplied
protocol.
4. Secrecy
There are also secrecy requirements on this protocol.
SECRECY INIT The secrecy requirement for the initiator is that if s is accepted as
secret after the protocol run, then s should not be known to the intruder (provided
the responder is honest).
SECRECY RESP Similarly, the secrecy requirement for the responder is that if s is
sent in the protocol run, then it should not be known to the intruder (provided the
initiator is honest).
The assumption of honesty in the other party is natural, since the secret is being shared
with themif the other party is dishonest then there can be no guarantees about secrecy.
For reasons of space we will carry out the analysis for SECRECY RESP. The anal-
ysis for SECRECY INIT is very similar.
4.1. Modeling for secrecy analysis
The intruders acquisition of message s can be modelled by its capability to perform
trans.E.E.s or some other communication demonstrating possession of s. To establish
that such communications cannot occur it is sufcient to provide a rank function such
that s has rank 0. Secrecy is concerned with the impossibility of a particular commu-
nication, rather than establishing a precedence relationship between two events. Use-
fully, this can be expressed in the form required by the rank function theorem. The rank
function theorem can be applied by introducing an impossible event imp which no par-
ticipant performs: the statement imp precedes trans.E.E.s is equivalent to requiring
that trans.E.E.s can never occur (since imp can never occur). Expressing it in the form
imp precedes trans.E.E.s allows direct application of the rank function theorem. Ob-
serve that in this case no additional specication events need to be introduced, and since
imp is not in the alphabet of any process, restricting the systems behaviour on imp makes
no difference to the behaviour of any of the participants.
4.1.1. SECRECY RESP
The model for analysis of secrecy with respect to the responder B xes on A as the
initiator. RESP
B
therefore describes a run with A. The initiator A is modelled as following
the protocol faithfully (since B assumes A is honest), though possibly with a different
participant. Thus A chooses an arbitrary party j with whom to run the protocol.
INIT
A
(k
0
) =
j
trans.A!j!
{
[A.j.k
0
]
sk(A)
}
a
pk(j)
rec.A.j?{s}
s
k
0
STOP
RESP
B
(s
0
) =
rec.B.A?
{
[A.B.k]
sk(A)
}
a
pk(B)
trans.B!A!{s
0
}
s
k
STOP
The secret sent by B is s
0
, so any suitable rank function will necessarily assign s
0
a
rank of 0. Observe that here we must assume that s
0
IK, though interestingly this
assumption was not necessary for the authentication properties.
The following rank function meets all the conditions of the rank function theorem:
(i) = 1
(s) =
{
0 if s = s
0
1 otherwise
(k) =
{
0 if k = k
0
1 otherwise
(m
1
.m
2
) = min{(m
1
).(m
2
)}
({m}
s
k
) =
{
1 if k = k
0
s = s
0
(m) otherwise
({m}
a
pk(i)
) =
{
1 if i = B m = [A.B.k
0
]
sk(A)
(m) otherwise
([m]
sk(i)
) =
{
0 if i = A m = A.B.k
(m) otherwise
The clause for ([m]
sk(i)
) captures the fact that the enemy cannot obtain any message
of the form[A.B.k]
sk(A)
. This is the key to howthe protocol provides the secrecy property:
that B can be assured that any such signed message must indeed have been generated by
A, and hence that the key k is not known to the attacker.
4.2. The simplied version
For the simplied version of the protocol, the natural change to make to the rank function
is to simplify the messages in the denition of , resulting in the following alternative
clauses (the other clauses are unaffected):
({m}
a
pk(i)
) =
{
1 if i = B m = [k
0
]
sk(A)
(m) otherwise
([m]
sk(i)
) =
{
0 if i = A m = k( KEY)
(m) otherwise
However, we now nd that condition 4 for a rank function no longer holds: INIT
A
can
immediately transmit a message of rank 0: the message
{
[k
0
]
sk(A)
}
a
pk(E)
. In this case this
leads us to the following attack:
: A E :
{
[k
0
]
sk(A)
}
a
pk(E)
: E(A) B :
{
[k
0
]
sk(A)
}
a
pk(B)
: B E(A) : {s
0
}
s
k
0
The responder relies on the contents of the rst message (i.e. the session key) being se-
cret. However, in the simplied case it might have gone to another party before reaching
the responder, hence the protocol is awed with respect to responder secrecy. In the orig-
inal version, the inclusion of the identiers A and B are sufcient for B to know that A
encrypted the rst message with Bs public key, ensuring secrecy of the session key and
hence the payload.
5. Multiple runs
In general, several concurrent overlapping runs of the protocol might take place, and pro-
tocol participants might be involved in more than one protocol run, possibly in different
roles.
The general behaviour of such a protocol participant can be described within CSP,
as an interleaving of initiator and responder runs, each with an arbitrary protocol partner.
A general initiator run and a general responder run are rst dened, and then a user is
constructed from collections of these. Fresh messages required for the runs are modelled
by requiring that each run uses a different such message, and different agents all use
different messages.
A general initiator run for user C with a fresh key k chooses a partner j and runs the
protocol:
INIT
C
(k) =
j
trans.C.j.
{
[C.j.k]
sk(C)
}
a
pk(j)
rec.C.j?{s}
s
k
initdone.C.j.s.k STOP
A general responder run for user C with a fresh secret s is ready to engage in the
protocol: it awaits contact from an initiator i and then follows the protocol with i:
RESP
C
(s) =
rec.C?i?
{
[i.C.k]
sk(i)
}
a
pk(C
respgo.C.i.s.k trans.C!i!{s}
s
k
STOP
A general participant C can then engage in arbitrarily many protocol runs concur-
rently as sender and receiver. This is captured as the interleaving of initiator and respon-
der runs:
USER
C
= (
kKEY
C
INIT
C
(k)) (
sMSG
C
RESP(s))
Observe that in this description each initiator run has a different key k, and each respon-
der run has a different message s. Each agent C has its own set of fresh keys KEY
C
and
messages MSG
C
, and in the model these will be pairwise disjoint so any fresh key or mes-
sage is associated with at most one agent, modelling the expectation that the probability
of key or message overlap is negligible.
As an example of how the general case can be established, we will consider the
property respgo.B.A.s
AB
.k
AB
precedes initdone.A.B.s
AB
.k
AB
: that A authenticates B. In
fact we can use the same rank function, given in Figure 3 as we used in the case of a
single protocol run. The composition rules of Figure 5 allow the proof obligations on
USER
C
to be reduced to individual runs. These rules follow from the trace semantics of
general choice and general interleaving [Ros97,Sch99].
Checking that USER
C
[ respgo.B.A.s
AB
.k
AB
] STOP sat maintains then reduces
(by rule INTERLEAVING of Figure 5) to checking the following:
that each INIT
C
(k) [ respgo.B.A.s
AB
.k
AB
] STOP sat maintains ;
that each RESP
C
(s) [ respgo.B.A.s
AB
.k
AB
] STOP sat maintains .
INTERLEAVING
i.(P
i
sat maintains )
i
P
i
sat maintains
CHOICE
i.(P
i
sat maintains )
i
P
i
sat maintains
Figure 5. Composition rules for maintains
These each reduce to consideration of the possible cases. We will work through INIT
C
(k)
as an example.
INIT
C
(k) sat maintains as long as the initiating message has positive rank. Thus
by rule CHOICE we must show that
{
[C.j.k]
sk(C)
}
a
pk(j)
has positive rank, for any C, j,
and k KEY
C
.
Case 1: If j = B and C = A and k = k
AB
then (
{
[C.j.k]
sk(C)
}
a
pk(j)
) = 1 from
the denition of .
Case 2: Otherwise (
{
[C.j.k]
sk(C)
}
a
pk(j)
) = ([C.j.k]
sk(C)
)
Subcase 2.1: If j = B and k = k
AB
, then C = A. This follows from the fact
that k
AB
KEY
C
for some unique C, but for the particular key k
AB
we know that
k
AB
KEY
A
. Hence j = B, k = k
AB
, and C = A. But this is case 1, so Subcase 2.1
is impossible.
Subcase 2.2: j = B or k = k
AB
. Then ([C.j.k]
sk(C)
) = (C.j.k). If k = k
AB
then
C = A, and we also have from the model that k
AB
is the key used in a session
A initiates with B, thus we have j = B, contradicting the condition for the case.
Otherwise k = k
AB
, so (k) = 1. Then (C.j.k) = 1, so (
{
[C.j.k]
sk(C)
}
a
pk(j)
) =
1 as required.
In all cases therefore we have that (
{
[C.j.k]
sk(C)
}
a
pk(j)
) = 1, establishing that
INIT
C
(k) sat maintains .
A similar consideration of the cases in the responder denition establishes that each
RESP
C
(s) [ respgo.B.A.k
AB
.s
AB
] STOP sat maintains .
Combining all these results yields that USER
C
[ respgo.B.A.k
AB
.s
AB
] STOP sat
maintains for all users C, establishing condition 4 of the rank function theorem.
In this way we can prove that the protocol does allow the initiator to authenticate
the responder in the fully general case allowing any number of concurrent protocol runs
between any participants.
6. Extensions
This chapter has introduced the approach of using rank functions to the analysis and
verication of security protocols. We have shown how protocols can be instrumented
with signals to allow various avours of authentication properties to be expressed (more
detailed discussion of the avours of authentication can be found in [Low97,Sch98b,
SBS09]), and also shown how secrecy can be specied. The rank function approach was
rst presented in [Sch97,Sch98b], and expounded at greater length in [RSG
+
00]. An
introduction to the approach also appeared in [SD04] as an application area of CSP. The
basic approach has been extended in a number of ways, both in terms of extending the
theory and in terms of developing tool support.
6.1. Timestamps
An approach to handling timestamps was presented in [ES00,Eva03]. Timestamps are an-
other common mechanism used within security protocols to provide assurances of fresh-
ness and prevent replay attacks. Their handling requires the modelling of the passage of
time, the protocol parties awareness of the correct time and ability to make decisions,
and the fact that some delays between message creation and message receipt must be al-
lowed for. An authentication protocol will aim to establish that if a timestamped message
is received at a particular time then it must have been generated within some previous
time window.
6.2. Other properties
A rank function approach was developed to handle non-repudiation protocols [Sch98a]
in which parties each seek evidence from the other that the protocol has taken place, to
prevent the other party fromrepudiating the transaction at a later date. In such cases, each
party in the protocol is untrusted by the other, and is effectively modelled as the enemy.
The aim is to collect sufcient evidence to convince a third party that the other protocol
party must have participatedessentially that the evidence produced can only follow
some activity by the other protocol party, in much the same way as an authentication
property.
The approach has also been extended to handle various forms of forward secrecy.
Forward secrecy can be taken to mean that the payload of the protocol is secret even if
some secret elements of the protocol, such as a session key, become known to the attacker
at a later stage. In this case, the classical rank function considers either that the enemy
will never obtain the message, or that the enemy might as well have it fromthe beginning.
However, this approach is not appropriate for temporary secrets such as session keys.
Instead, in [Del06,DS07] the notion of a rank function is generalised to a temporal rank
function so that ranks range across positive integers (together with innity), which may
be thought of as corresponding to the time at which a message might be available to the
enemy. This allows analysis of protocols which rely on the secrecy of some information
at a particular point in time. A generalised version of the rank function theorem is able
to establish long-term secrecy of messages in these cases.
In the context of group protocols, concern can also focus on whether secrets es-
tablished by honest members of a group can be exposed at some other stage if an
enemy joins the group. The rank function approach has been applied in this context
[GT07,Gaw08] for both forward secrecy (secret keys cannot be obtained from later runs)
and backward secrecy (secret keys cannot be obtained from earlier runs).
6.3. Algebraic properties of cryptographic primitives
Some cryptographic schemes have particular properties (for example, commutativity of
encryption) useful for constructing protocol schemes, but which might allow other pos-
sibilities of attack. The rank function approach extends to handle these cases, where the
properties can be captured as equations on messages, or as further message derivation
clauses (in the generates relation). In one example, an analysis of Gongs protocol built
around exclusive-or [Gon89] was presented in [Sch02]. Exclusive-or has several proper-
ties, such as commutativity, self-inverse of encryption keys, and cancellation properties.
The analysis modelled these as equations on the algebra of messages, and the additional
requirement on a rank function is that it must be well-dened in the context of the equa-
tions: if two (differently constructed) messages are equal, then they should have the same
rank. Since rank functions tend to be dened by induction over the BNF for constructing
messages, establishing well-denedness is an additional requirement. This approach was
also used in [DS07] for a class of group Dife-Hellman authenticated key-agreement
protocols: keys can be constructed using exponentiation in a number of different ways,
and it is important that all constructions of the same key have the same rank.
6.4. Tool support
Various forms of tool support have been developed for the rank function approach, in
some cases with underlying theory to underpin the approach. A theory of rank functions
on top of CSP was developed in the theorem-prover PVS [DS97]. This theory allowed
denitions of rank functions, CSP descriptions of protocol participants, and verication
of the conditions of the rank function theorem. Since much of the work in carrying out
such a proof is mechanical house-keeping the provision of tool support is natural. The
PVS theories for CSP and for rank functions were refactored and extended (to handle
time) in [Eva03,ES05]. PVS has also been used to implement inference systems based on
rank functions to check whether attacks are possible [GBT09]. In this approach, various
properties of a rank function are given, and the inference system is used to establish
whether an attack is possible from the protocol rules.
As an alternative to theorem-proving, an approach for automatically generating a
rank function for a given protocol was developed in [Hea00,HS00]. This approach con-
structs a minimal function whose positive messages include those of the enemys initial
knowledge, are closed under the message generation rules, and are closed under the pro-
tocol agents behaviour for outputting. If the resulting function also gives a rank of 0 to
the authenticating message, then it meets all the conditions of the rank function theorem,
and the protocol is veried. Conversely if the resulting function gives a positive rank,
then there can be no rank function that will meet all the conditions of the rank function
theorem.
Acknowledgements
I am grateful to Roberto Delicata for comments on this chapter.
References
[Del06] R. Delicata. Reasoning about Secrecy in the Rank Function framework. PhD thesis, University
of Surrey, 2006.
[DS97] B. Dutertre and S.A. Schneider. Embedding CSP in PVS: an application to authentication proto-
cols. In tpHOL, 1997.
[DS07] Rob Delicata and Steve Schneider. An algebraic approach to the verication of a class of dife-
hellman protocols. Int. J. Inf. Sec., 6(2-3):183196, 2007.
[DY83] D. Dolev and A.C. Yao. On the security of public key protocols. IEEE Transactions on Informa-
tion Theory, 29(2), 1983.
[ES00] N. Evans and S.A. Schneider. Analysing time dependent security properties in CSP using PVS.
In ESORICS, volume 1895 of LNCS, 2000.
[ES05] N. Evans and S.A. Schneider. Verifying security protocols with PVS: Widening the rank function
approach. Journal of Logic and Algebraic Programming, 2005.
[Eva03] N. Evans. Investigating Security Through proof. PhD thesis, Royal Holloway, University of
London, 2003.
[For03] Formal Systems (Europe) Ltd. FDR2 user manual, 2003.
[Gaw08] A. Gawanmeh. On the formal verication of group key security protocols. PhD thesis, Concordia
University, Canada, 2008.
[GBT09] A. Gawanmeh, A. Bouhoula, and S. Tahar. Rank functions based inference system for group key
management protocols verication. International Journal of Network Security, 8(2), 2009.
[Gon89] L. Gong. Using one-way functions for authentication. Computer Communications Review, 19(5),
1989.
[GT07] A. Gawanmeh and S. Tahar. Rank theorems for forward secrecy in group key management proto-
cols. In IEEE International Conference on Advanced Information Networking and Applications
Workshops (AINAW07), 2007.
[Hea00] J.A. Heather. Oh! Is it really you?Using rank functions to verify authentication protocols.
PhD thesis, Royal Holloway, University of London, 2000.
[Hoa85] C.A.R. Hoare. Communicating Sequential Processes. Prentice-Hall, 1985.
[HS00] James Heather and Steve Schneider. Towards automatic verication of authentication protocols
on an unbounded network. In CSFW, pages 132143, 2000.
[Low97] Gavin Lowe. A hierarchy of authentication specications. In CSFW, 1997.
[PQ00] O. Pereira and J-J. Quisquater. On the perfect encryption assumption. In WITS 00: Workshop on
Issues in the Theory of Security, 2000.
[Ros97] A.W. Roscoe. The Theory and Practice of Concurrency. Prentice-Hall, 1997.
[RSG
+
00] P.Y.A. Ryan, S.A. Schneider, M.H. Goldsmith, G. Lowe, and A.W. Roscoe. Modelling and Anal-
ysis of Security Protocols. Addison-Wesley, 2000.
[SBS09] S. Shaikh, V. Bush, and S. Schneider. Specifying authentication using signal events in CSP.
Computers & Security, 28(5), 2009.
[Sch97] Steve Schneider. Verifying authentication protocols with CSP. In CSFW, pages 317, 1997.
[Sch98a] S.A. Schneider. Formal analysis of a non-repudiation protocol. In 11th IEEE Computer Security
Foundations Workshop, 1998.
[Sch98b] Steve Schneider. Verifying authentication protocols in CSP. IEEE Trans. Software Eng.,
24(9):741758, 1998.
[Sch99] S.A. Schneider. Concurrent and Real-time Systems: the CSP Approach. Addison-Wesley, 1999.
[Sch02] S.A. Schneider. Verifying security protocol implementations. In FMOODS02: Formal Methods
for Open Object-based Distributed Systems, 2002.
[SD04] S. Schneider and R. Delicata. Verifying security protocols: An application of CSP. In Communi-
cating Sequential Processes: the First 25 Years, pages 243263, 2004.
Computational Soundness
- The Case of Dife-Hellman Keys -
Emmanuel BRESSON
a
Yassine LAKHNECH
b
Laurent MAZAR
c
and
Bogdan WARINSCHI
d
a
DCSSI Crypto Lab, Paris, France
b
VERIMAG Grenoble, Grenoble, France
c
LexiFI, Paris, France
d
University of Bristol, United Kingdom
Abstract. Symbolic models for security are built around axioms that reect appeal-
ing intuition regarding the security of basic primitives. The resulting adversaries
however often seem unrealistically strong in some of their abilities and not suf-
ciently powerful in others. An interesting research direction pioneered by Abadi
and Rogaway is to show that despite these apparent limitations symbolic models
can be used to obtain results that are meaningful with respect to the more detailed
and realistic models used in computational cryptography. This line of research is
now known as computational soundness. This chapter describes in detail a compu-
tational soundness result that extends the original work of Abadi and Rogaway. We
show that it is possible to reason about computational indistinguishability of distri-
butions obtained by using symmetric encryption and exponentiation in nite groups
with entirely symbolic methods. The result relies on standard notions of security
for the encryption scheme and on a powerful generalization of the Dife-Hellman
assumption.
1. Introduction
1.1. Background
Symbolic vs. Computational Models. A common criticism of symbolic approaches for
security is that they rely on models that are too abstract to offer clear security guarantees.
In such models the adversary appears to be severely restricted. The axioms that char-
acterize security of primitives allow the adversary only a limited number of operations,
and it is usually unclear how to enforce these axioms in actual implementations. Further-
more, the representation of messages as symbols does not permit reasoning about partial
information, a real concern in many applications.
This criticism is even more relevant given alternative models that offer clearly
stronger guarantees. Under these computational models, security analysis of protocols
considers a much lower level of abstraction. Typically, parties are viewed as algorithms
(written in some Turing-complete language) and the messages with which they operate
and communicate are actual bitstrings. The adversaries are required to operate efciently
(i.e. run in time polynomial in some security parameter), but are otherwise allowed to
IOS Press, 2011
doi:10.3233/978-1-60750-714-7-277
277
perform arbitrary computations. Furthermore, unlike in the case of symbolic methods
where security of primitives is axiomatized, in computational approaches security is de-
ned. This enables rigorous proofs that implementations actually meet their required
security levels starting from widely accepted assumptions.
The technique most commonly used in such proofs is known as "reduction". The idea
is to show that the security of a cryptographic construct can be reduced to solving some
problem(s) that is believed to be hard. Specically, one argues that any adversary that
is successful against the cryptographic construct can be used to solve some underlying
hard problem. Typical hard problems include factoring, taking discrete logarithms, the
computational Dife-Hellman problem, etc [24].
The low level of abstraction and the powerful and realistic adversarial model imply
strong security guarantees schemes with computational security proofs. Unfortunately,
reduction techniques do not scale well. While they enjoyed considerable success for
primitives and small protocols, more complex cryptographic constructs are notoriously
difcult to analyze rigorously. Nowadays it is quite common that proofs are either high
level sketches that are missing important details, or they are detailed but in this case they
are virtually impossible to check. For symbolic methods, the situation is in some sense
reversed. As discussed above, the high level of abstraction, the axiomatic way of assum-
ing security of primitives, and the rather limited adversary imply that the symbolic secu-
rity proofs do not have clear implications for actual implementations. However, proofs
can be, and usually are, quite rigorous. More importantly, symbolic analysis may benet
from machine support or may even be completely automated, as explained in previous
chapters.
1.2. Symbolic techniques and computational analysis
Motivated in part by the unsettling gap between the two co-existing approaches, and in
part by the realization that computational proofs could benet from the rigourousness
specic to symbolic methods, a signicant research effort attempts to investigate the
links between symbolic and computational methods for security analysis. The goal is to
tame the complexity specic to computational models via symbolic techniques. Existing
research falls along two main directions.
Symbolic reasoning with computational semantics. One research direction aims to di-
rectly apply the methods and techniques specic to symbolic approaches to computa-
tional models. For example, the work of Datta et al. [2] investigates Protocol Security
Logic that is a variant of the PCL logic of Chapter Protocol Composition Logic. The
crucial difference is that the semantics domain of the logic is a standard computational
model, so logical statements are statements about such models. The work of Courant et
al [25] is along similar lines: they show how to use a Hoare-like logic to reason directly
about the computational security of various encryption schemes.
A related but different approach aims to formalize directly computational proofs.
Examples include the work of Blanchet and Pointcheval [15] who develop a framework
based on the game playing technique of Shoup [35] and Bellare and Rogaway [7], and
that of Barthe et al. [5] who used Coq to develop a formal theory of the mathematics
needed for cryptographic proofs, and apply it to several important cryptographic primi-
tives.
E. Bresson et al. / Computational Soundness: The Case of Dife-Hellman Keys 278
Computational soundness. The second research direction is to determine if and under
what conditions proofs carried out in symbolic models imply security under computa-
tional models. This direction became to be known as computational soundness. The rst
such result was due to Abadi and Rogaway [1] who prove a computational soundness
result for security against passive adversaries. Techniques for dealing with the active
case were later proposed by Backes, Ptzmann, and Waidner [3] and by Micciancio and
Warinschi [28]. Numerous other results have built upon these works by considering vari-
ations in the underlying execution model, the set of cryptographic primitives, and the
range of security properties treated (see [20] for a comprehensive survey of the more
recent work.)
At a high level, each of these results relies on the idea that the symbolic abstraction
does not lose too much information regarding the actual (computational) execution. An
alternative interpretation is that these results show that certain adversarial events that are
impossible to achieve in abstract models are highly improbable to achieve in computa-
tional ones.
In turn, this relation between symbolic and computational executions entails compu-
tational soundness theorems: a protocol that is secure symbolically, is also secure com-
putationally. Since the same security property may be expressed in very different ways
in the two settings, this second step does not immediately follow from the previous kind
of results. However, when possible to establish, computational soundness theorems may
prove truly valuable as they essentially say that computational security can be proved
working entirely in symbolic models. In this chapter we give in detail a typical compu-
tational soundness result.
1.3. An extension of the Abadi-Rogaway logic with Dife-Hellman keys
We describe an extension of the the work by Abadi and Rogaway [1]. There are several
reasons that motivate our choice. Abadi and Rogaways seminal result illustrates quite
well the potential of the computational soundness approach. The simpler setting of a pas-
sive adversary enables relatively simple proofs, and the particular extension that we an-
alyze raises some problems typical to computational soundness theorems. Furthermore,
the result itself is applicable to realistic protocols.
In brief, the setting considered by Abadi and Rogaway [1] concerns protocols where
parties exchange messages built from a set of basic messages (constants and keys) us-
ing concatenation and symmetric encryption. These messages are interpreted as either
symbolic terms or as computational distributions on bit-strings. The soundness result of
the paper is that symbolic terms that are equivalent (via an appropriate equivalence re-
lation) have associated distributions that are computationally indistinguishable. This re-
sult implies that one can reason symbolically about indistinguishability of computational
distributions.
The extension that we present considers an extended class of protocols where sym-
metric encryptions keys may also be derived via (general) Dife-Hellman exchanges. In
this setting parties share some cryptographic group and the set of protocol messages is
extended with group elements. Furthermore, symmetric encryption keys can be derived
from group elements using some key-derivation function. We show how to obtain the
analogue of the Abadi-Rogaway result for this extended setting.
A generalization of the Dife-Hellman assumption. The usefulness of computational
soundness results depends on the size of the class of protocols that they treat. Trivial
soundness theorems can be easily established. For example, one can simply limit the
symbolic analysis to the empty class of protocols or, equally unsatisfactory, one can
declare all protocols symbolically insecure. The difculties lie in proving soundness for
(non-trivial) symbolic analysis of large class of protocols.
One typical problem that often arises is that the intuition that guides the axiomatic
security for primitives is not always warranted by the computational security denitions.
More specically, some uses of primitives may be considered secure when analyzed
symbolically, but the same uses lead to complete breakdowns in computational models. It
is therefore crucial that the design of the symbolic model requires to classify all possible
uses of the primitives into secure and insecure.
Instantiated in the particular context of the extension that we present in this chap-
ter the problem is as follows. We consider group elements obtained by exponentiating a
group generator to various polynomials. These elements can then be used as symmetric
encryption keys. To create a symbolic model that is sound with respect to the computa-
tional model, it is crucial to understand which of the keys derived from group elements
can be recovered and which keys are secret. Simple uses are easy to deal with. For ex-
ample, a Dife-Hellman key of the form g
2
is secure even if g
1
and g
2
are known,
however the key g
1
+
2
can be easily computed. More generally however, for any ar-
bitrary polynomial , one has to determine precisely determine which keys of the form
g
(
1
,
2
,...,
)
can be recovered and which cannot.
In the rst part of the chapter we present a generalization of the DDH assumption
that accomplishes precisely this task. This result is entirely in the realm of computational
cryptography and is absolutely necessary for developing the soundness result that we
present in detail in the remainder of the chapter.
2. Notation and cryptographic preliminaries
In this section we introduce some notation and recall some of the main cryptographic
notions necessary for our results.
We write [] for the set {1, 2, . . . , }. We write for the size of set . If is a ran-
domized algorithm we write
$
() for the process of sampling from the distribution
of s output on input . We write
for an algorithm that may query oracle in

its computation. Access to more than one oracle is indicated in the straightforward way.
2.1. Computational indistinguishability
Computational indistinguishability of distributions is a standard notion of equivalence
between probability distributions on bitstrings. Informally, two probability distributions
are indistinguishable if no efcient algorithm can determine from which of the two dis-
tributions a given bitstring has been sampled. The formal denition that we give below
(as well as the denitions for other primitives and concepts that we utilize in this chapter)
is in the style of concrete security. Recall that this style departs from that of asymptotic
security (where security is guaranteed as a security parameter tends to innity). Instead,
concrete bounds on the running time of the adversary are translated into concrete bounds
on the probability that the adversary is able to accomplish a specic task. One benet
is that one can x a security parameter and thus avoid working with families of primi-
tives. For example, in this setting one can compare probability distributions, as opposed
to distribution ensembles (families of probability distributions indexed by the security
parameter) as in the asymptotic setting.
Denition 1 (Computational indistinguishability) Let and be two probability
distributions. We say that and are (, )-indistinguishable and we write
,
,
if, for any probabilistic distinguisher that runs in time at most , its advantage in
distinguishing between the two distributions is smaller than :
Adv
ind
,
() =
Pr[
$
: () = 1] Pr[ : () = 1]
<
The probability is over the choice of and and the random coins of .
2.2. Secure symmetric encryption schemes
A symmetric encryption scheme is given by three algorithms:
: Parameters Coins Keys
: Keys Plaintexts Coins Ciphertexts
: Keys Ciphertexts Plaintexts {}
The key generation algorithm is probabilistic. It takes as input a security parameter
and outputs a key . We write
$
() for the process of generating key on input
security parameter . If the security parameter is xed, or understood from the context,
we may simply omit it and write
$
for the same process. Notice that here as well
as for all other randomized algorithms we do not explicitly show the dependence on the
random coins used by the key generation algorithm. The encryption algorithm is also
randomized. It takes as input a key and a message Plaintexts and returns a ci-
phertext . We write
$
(, ) for the process of generating ciphertext , an encryp-
tion of plaintext under key . The decryption algorithm is typically deterministic. It
takes as input a key and a ciphertext and returns the underlying plaintext or if the
decryption process does not succeed. We write (, ) for the process of obtain-
ing as a decryption of using key . It is mandated that for any that can be the
output of the key generation algorithm and for any message Plaintexts it holds that
(, (, )) = .
The security of encryption scheme comes in many avors. We follow the denitional
approach of Bellare et al. [8] and of Abadi and Rogaway [1]. The idea is to dene security
of an encryption scheme via the requirement that an adversary is not able to tell apart
encryptions of messages that he chooses, from encryptions of some xed string. One
way to model this intuition is to consider adversaries that interact with an oracle to which
it can submit arbitrary bitstrings. This oracle is keyed by some key of the symmetric
encryption scheme and can behave in one of two possible ways. The rst possibility is
that it returns encryptions under of the bitstrings that the adversary submits as queries.
We write (, ) for this oracle to which we refer to as the "real" oracle. The second
possible behavior is that the oracle ignores its query and simply returns an encryption
of 0 under . We write (, 0) for this oracle, and refer to it as the "fake" oracle. The
task of the adversary is to gure out with which of the two possible oracles it interacts.
Without loss of generality we may assume that the output of the adversary is binary: 1
for the guess that it interacts with the real oracle and 0 for the guess that it interacts with
the fake oracle. A scheme is secure if the adversary cannot tell apart the two oracles, or
in other words, that the adversary outputs 1 when it interacts with the rst oracle about
as often as when it interacts with the second oracle. Since in his attempt to distinguish
between the two oracles the adversary gets to choose which plaintexts it wants to see
encrypted, the resulting security notion is called indistinguishability against plaintext
attack. Our presentation of the notion departs from the standard notion in that it requires
that an adversary cannot tell apart encryptions of messages, even if these messages are of
different length. We write IND-CPA
for this notion to distinguish it from the standard

IND-CPA notion
1
.
Denition 2 (IND-CPA
security) Let = (, , ) be a symmetric encryption

scheme and some xed security parameter. We dene the advantage of an adversary
by
Adv
ind-cpa
() =
=
Pr
[
$
:
(,)
= 1
]
Pr
[
$
:
(,0)
= 1
]
.
We say that an encryption scheme (, , ) is (, )-IND-CPA
-secure if for any ad-

versary running in time it holds that: Adv
ind-cpa
() < .
2.3. The Decisional Dife-Hellman assumption
Fix a cyclic group of order and let be a generator of . Informally, the Decisional
Dife-Hellman assumption states that it is difcult to distinguish a triple (
1
,
2
,
)
from (
1
,
2
,
2
) when
1
,
2
, are chosen uniformly at random.
Denition 3 (The Decisional Dife-Hellman assumption) Let be a group of order
and a generator of . For an algorithm dene its advantage against the Decisional
Dife-Hellman problem in by
Adv
ind-ddh
() =
Pr
[
1
,
2
$
: (
1
,
2
,
2
) = 1
]
Pr
[
1
,
2
,
$
: (
1
,
2
,
) = 1
]
The probabilities are taken over the choices of

1
,
2
and as well as the random coins
of . We say that the (, )-DDH assumption holds in , or alternatively that the DDH
problem is (, ) hard in if for all probabilistic adversaries that run in time it holds
that Adv
ind-ddh
() < .
1
To obtain the standard IND-CPA security notion one replaces in the following denition the oracle (, 0)
with the oracle (, 0
) that when queried with message returns the encryption of the all 0 string of length
.
3. A generalization of the Decisional Dife-Hellman assumption
In this section we present a generalization of the standard Decisional Dife-Hellman
assumption and explain its relation with the original problem.
3.1. Motivation
We start with a motivating discussion and some intuition. Consider some cyclic group
of order , a generator of , and a tuple
1
= (
1
,
2
,
3
,
3
), where the
exponents are chosen uniformly at random. Can an adversary tell the tuple above from
the tuple
2
= (
1
,
2
,
3
,
), i.e. the tuple where the last element is replaced with a

group element chosen uniformly at random? It turns out that telling the two tuples apart
is as hard as solving the DDH problem. This can be seen as follows. Consider the tuple
3
= (
1
,
2
,
3
,
3
), with randomly chosen
1
,
2
,
3
, . Notice that
3
is in fact
selected from the same distribution as
2
(the exponent in the last element of the tuple is
chosen at random from
in both cases and the rest of the components are the same).
Finally, observe that an adversary that distinguishes between
1
and
3
can be easily
converted into an adversary that solves the DDH problem in . Indeed, on input a triple
(, , ) adversary selects
3
$
and passes to as input the tuple (, ,
3
,
3
).
If the input of is a true DDH tuple then the input of follows the distribution of
1
. If
the input of is a fake DDH tuple, then the input to follows the distribution of
3
.
Consider now the tuples (
1
,
2
,
1
+
2
) and (
1
,
2
,
). Clearly, in this case

an adversary can immediately tell the two cases apart by simply checking if the product
of the rst two components of the tuple equals the third component. More generally, the
adversary can tell if the exponent in the third component of the tuple is a linear com-
binations of the exponents of the rst two components by raising these two appropriate
powers and then multiplying them.
The two examples show that while for an adversary it is trivial to identify linear
relations between the exponents observing any other sort of relation seems to be difcult.
In this section we conrm this intuition in the form of a powerful generalization
of the DDH assumption. Informally, we allow the adversary to see
(
1
,
2
,...,
)
for
polynomials
in a set , for randomly chosen

1
,
2
, . . . ,
. The task of the adver-

sary is then to distinguish
(
1
,
2
,...,
)
for polynomials
in some set from
for
randomly chosen
. It turns out that as long as the polynomials in are linearly inde-

pendent and are not in the linear span of then this task is tightly related to solving the
DDH problem in the underlying group.
In the remainder of the section we formalize the generalization of the DDH problem
and explain how it relates to the DDH assumption in the underlying group. The formal
proof of the result is outside the scope of this chapter (see [13] for details), but we recall
sufciently many details to clarify the relation between the above problem and the DDH
problem.
Fix a set of variables {
1
,
2
, . . . ,
} and let
[
1
,
2
, . . . ,
] be the
ring of multivariate polynomials with coefcients in
. For a polynomial
[
1
,
2
, . . . ,
] we write () for the set of variables that occur in and ()

for the set of monomials (recall that a monomial is just a product of variables to posi-
tive integer powers) that occur in . The notation extends to sets of polynomials in the
obvious way. For example, for set = {
1
3
+
1
4
,
2
+
1
4
} we have that
() = {
1
,
2
,
3
,
4
} and () = {
2
,
1
3
,
1
4
}. XXX For a mono-
mial we write () for the order of (i.e., the sum of the powers of its variables).
We say is power-free if any
() occurs in only raised to power 1. For

example polynomials
1
+
2
3
and
1
3
are power-free but
1
+
2
2
is not.
We write PF(
[
1
,
2
, . . . ,
]) for the set of power-free polynomials with variables

{
1
, . . . ,
} and coefcients in
. The results that we present only hold for such

polynomials, so in the remainder of the chapter, otherwise specied, the polynomials
that we consider are power-free. For a set of polynomials = {
1
,
2
, . . . ,
} we write
Span() for the set of polynomials spanned by , that is
Span() = {
=1
, = 1, 2, . . . , }
3.2. The (P,Q)-DDH assumption
In what follows we x sets = {
1
,
2
, . . . ,
} and = {
1
,
2
, . . . ,
} of
power-free polynomials in
[
1
,
2
, . . . ,
]. Let = {
1
,
2
, . . . ,
} be a
set of variables that do not occur in and : (() ()) = . To
these sets we associate three oracles that share an internal state which is a mapping
: {
1
,
2
, . . . ,
. We write P(), Q() and R() for these oracles. The

behavior of the oracles is as follows.
Oracle P accepts as input any polynomial and returns the value
((
1
),(
2
),...,(
))
.
Oracles Q and R accept as input any polynomial
and return, respectively,

the values
((
1
),(
2
),...,(
))
and
(
)
.
An adversary is given access to either the pair of oracles P, Q, or to the pair of oracles
P, R, and his goal is to determine which is the case. We call the problem associated to
polynomial sets and , the (, )-DDH problem, and the pair (, ) a challenge. For
example, if = {
1
,
2
} and = {
1
2
} then the (, ) DDH assumption is
precisely the DDH assumption. With other choices for and one can easily get other
variations of the DDH problem encountered throughout the literature. These include the
group Dife-Hellman assumptions [12], the parallel Dife-Hellman assumption [11], the
General Dife-Hellman Exponent (GDHE) [10], the Square Exponent [26,19,36], the
Inverse Exponent [33] and many others.
The assumption is given in the next denition.
Denition 4 (The (, )-Decisional Dife-Hellman assumption) Let be a cyclic
group of order and a generator of . Let , PF(
[
1
,
2
, . . . ,
]) be nite
sets of power-free polynomials. We dene the advantage of an algorithm against the
(, )-DDH problem by
Adv
(,)-ddh
() =
Pr
[
P(),Q()
= 1
]
Pr
[
P(),R()
= 1
]
where the probabilities are taken over the coins of and over the map selected uni-
formly at random from the maps from {
1
,
2
, . . . ,
. We say that the

(, )-(, )-DDH assumption holds in or, alternatively, that the (, )-DDH as-
sumption is (, )-hard in , if for any probabilistic adversary that runs in time , its
advantage is at most .
For convenience of notation, we sometimes write Real
,
and Fake
,
for the pairs of
oracles (P, Q) and (P, R), respectively. If there is no ambiguity, we further simplify the
notation to just Real and Fake.
The next lemma captures a class of pairs (, ) for which the the (, )-DDH
problem is easy to solve in any group.
Lemma 1 (Trivial challenges) The (, )-DDH problem is trivial to solve if at least
one of the following conditions holds
1. Span() Span() = {0}
2. The polynomial in are linearly dependant
If a challenge is not trivial we call it non-trivial. Next we aim to show that solving a non-
trivial challenge is related to solving the Decisional Dife-Hellman problem. We present
a reduction that constructs an adversary against the latter problem from any adversary
against the (, )-DDH for any non-trivial challenge (, ). To specify how the success
of the two adversaries are related we need to dene several quantities. The following
denitions from [13] are somewhat technical and can be safely skipped.
Dene the graph
(,)
whose vertexes are the elements of ( ), the mono-
mials that occur in the polynomials of and . There is an edge between two vertexes
1
and
2
if there exists such that
1
,
2
(). Let
+
() be the set
of monomials reachable in this graph from (). The order of within , denoted
by
+
(), is dened by
() =
()
(
() 1
)
The set nm(, ) of non-maximal elements of
+
() is the set of monomials
() such that there exists a strict super-monomial

2
of that is in () but
not in
+
(). These two quantities are involved in the following relation between
the DDH and (, )-DDH problems. The following theorem says that an adversary that
solves the (, )-DDH problem can be used to solve the DDH problem (with some loss
of efciency that is quantied in the theorem).
Theorem 1 (Relating (, )-DDH to DDH) Let be a cyclic group. Let (, ) be a
non-trivial challenge over variables
1
to
. If the DDH problem is (, )-hard in ,

then (, )-DDH is (
)-hard in , for
= 2
(
() +
(
2
nm(,)
1
)
.
(
+
+
()
)
)
and 2
= .
The concrete bounds in the above theorem show that in some cases the loss of security
can be exponential (when and are such that the set nm(, ) is very large). Never-
theless, in most cases (e.g. when contains only monomials) the loss is very small. In
the remainder of the paper we will not be concerned with the precise bounds.
2
This means that all the variables of appear in
and is different from
.
4. A Symbolic Logic for Dife-Hellman Exponentials and Encryption
In this section we develop the soundness result of this paper. Recall that the goal is to
show that reasoning about protocol messages using abstract, symbolic representations
has meaningful implications with respect to computational models for such messages.
4.1. Syntax
We consider protocols where messages are constructed from a set of basic atoms: group
elements, symmetric keys, and random nonces. More complex messages are obtained
from basic messages using concatenation and encryption.
Formally, we x nite but arbitrarily large sets of nonce symbols Nonce =
{
1
,
2
, . . .}, keys for a symmetric encryption scheme SKeys = {
1
,
2
, . . .}, and
exponents Exponents = {
1
,
2
, . . .}. We write Poly for the set of power-free poly-
nomials over variables in Exponents with coefcients in
. Notice that is an ar-

bitrary but xed natural number, and is a parameter of the symbolic language that we
dene here. Messages are terms in the set Msg dened by the grammar:
Basic ::= SKeys g
Poly
Nonce
Keys ::= SKeys (g
Poly
)
Msg ::= Basic (Msg, Msg) {Msg}
s
Keys
In the above denition g and are symbols different form all other symbols. They repre-
sent a generator for some group and a key derivation function, respectively. The second
dening rule for Keys indicates that we consider encryption keys that are either gener-
ated by the key generation algorithm of an encryption scheme, or are derived from group
elements using the key derivation function.
When an element of Keys occurs in an expression of the form {}
s
is said to
be in a key position. All other occurrences are said to be in non-key or message position.
In the remainder of the paper we assume that the pairing operation (_, _) is asso-
ciative so, for example, we simply write (g
1
, g
2
, g
3
) instead of (g
1
, (g
2
, g
3
)).
Furthermore, we may also omit the parenthesis. We refer to elements of Msg as terms,
expressions, or messages interchangeably.
4.2. Symbolic analysis
In this section we capture symbolically the information that an adversary can obtain
from messages. The conceptual ideas extend those of Abadi and Rogaway [1] and are
as follows. First we x the powers granted to the adversary. For example, the adversary
should be able to decrypt ciphertexts for which it can obtain the decryption key. Next,
to each term in Msg we attach a pattern. This is an (extended) expression that contains
only the information an adversary can observe, given the powers that we grant him. The
details follow.
THE SYMBOLIC ADVERSARY. The messages that an adversary can compute froma given
set of terms are captured via a deduction relation (Msg) Msg. For Msg

(
1
,
2
)

1
(
1
,
2
)

2

1
,
2
(
1
,
2
)
g
1
g
, g
g
+
{}
s
(g
)
, g

{}
s
,

Figure 1. Rules for dening the deduction power of the adversary. Symbols and range over Poly,
ranges over
and ranges over SKeys.

and Msg, we write to mean that the adversary can compute given . The
deduction relation is the smallest relation dened by the rules in Figure 1.
The rst four rules are straightforward. The rules on the second row indicate that the
adversary knows the group generator, that it can multiply group elements that it knows,
and that it can raise group elements to arbitrary (constant) powers. The rst rule of the
third row allows the adversary to decrypt a ciphertext under a key derived from a group
element, provided that the adversary can compute that group element. The last rule allows
the adversary to decrypt ciphertexts provided that the adversary can also derive the key
used for encryption.
Example 1 For example we have that:
g
1
, g
2
, {}
s
(g
1
+
2
)
but g
1
, g
2
, {}
s
(g
2
)

The rst deduction holds because from g
1
and g
2
the adversary can compute g
1
+
2
,
and hence the encryption key. In the second example the adversary cannot obtain since
although it knows g
1
and g
2
, the deduction rules do not allow it to compute g
2
which is required for decryption.
PATTERNS FOR EXPRESSIONS. The information that an adversary obtains from a sym-
bolic term can be captured by a pattern [1,27]. Intuitively, the pattern of expression
Msg is obtained by replacing all its unrecoverable sub-expressions (those sub-
expressions that occur encrypted under keys that the adversary cannot derive from ) by
the symbol (undecryptable). For an expression Msg its pattern is dened by the
inductive rules in Figure 2.
Example 2 For example, the pattern of the expression
g
1
, g
2
, {
1
}
s
(g
2)
, {
2
}
s
1
, {
3
}
s
(g
1
+
2)
, {
4
}
s
3
is
pattern(
) =
if
Basic
pattern
(
(
1
,
2
)
)
=
(
pattern(
1
), pattern(
2
)
)
pattern
(
{
}
s
)
= {pattern(
)}
s
if
pattern
(
{
}
s
)
= {}
s
if
pattern
(
{
}
s
(g
)
)
= {pattern(
)}
s
(g
)
if g
pattern
(
{
}
s
(g
)
)
= {}
s
(g
)
if g
Figure 2. Rules for dening the pattern of expression . In the above ranges over Poly and ranges over
SKeys.
g
1
, g
2
, {}
s
(g
2
)
, {}
s
1
, {
3
}
s
(g
1
+
2
)
, {
4
}
s
3
EXPRESSION EQUIVALENCE. We aim to dene an equivalence relation on the set of
expressions such that if two expressions convey the same amount of information to an
adversary then the expressions should be deemed equivalent. A natural candidate relation
(given the intuition that governs our denition of patterns) is therefore dened as follows:
1

2
if and only if pattern(
1
) = pattern(
2
).
This notion of equivalence is however too strict. For example expressions
1
and
2
(which both represent symmetric keys) should be considered equivalent, yet their pat-
terns are different. A similar situation also holds for nonces. The solution is to relax the
notion of equality and consider equivalent those expressions that have equal patterns,
modulo a (bijective) renaming of key and nonce symbols. The two expressions above
would have equal patterns modulo the renaming that sends
1
to
2
.
A more subtle issue concerns the use of exponentials. Consider expressions
1
=
(g
1
, g
2
, g
2
) and
2
= (g
1
, g
2
, g
3
). Intuitively, if the DDH assumption is
true then the two expressions should be equivalent. Unfortunately their patterns are
clearly different. The reason is that our notion of patterns does not capture the rela-
tions that an adversary may observe between the various group elements that occur in
an expression. The x that we adopt is to consider equality of patterns modulo injec-
tive renamings of polynomials that dene group elements, as long as these renamings
do not change the set of observable relations between group elements. We therefore
want to identify expressions
1
and
2
above, but at the same time, expressions
1
and
3
= (g
1
, g
2
, g
1
+
2
) should remain distinguishable. Indeed, there exists a linear
dependency in
3
that does not exist in
1
. To determine which renamings are appro-
priate we rely on the results concerning the DDH assumption that we have developed
in Section 3. Recall that the intuition that governs those results says that an adversary
can only observe linear dependencies between the various exponents. Motivated by this
intuition, we introduce the concept of linear dependence preserving injective renaming
for a set Poly of polynomials. Such a renaming is an injective map from to
Poly which preserves the linear dependencies already existing in , and that does not
introduce new ones.
Denition 5 (Linear dependence preserving renamings) Let Poly be an arbi-
trary set of polynomials and : Poly be an injective map. Then is said to be
linear dependence preserving (ldp) if:
(
1
,
2
, . . . ,
)(
1
, ...,
=1
=1
) =
For an expression Msg we write poly() for the set of polynomials that occurs in
. Given a mapping : poly() Poly we write (or ()) for the expression
in which for all poly() we replace each occurrence of g
with g
()
.
Example 3 If = (g
1
, g
2
, g
2
) and : poly() Poly the map dened by
(
1
) =
1
, (
2
) =
2
and (
1
2
) =
3
is ldp and = (g
1
, g
2
, g
3
). In
contrast,
with
(
1
) =
1
,
(
2
) =
2
and
(
1
2
) =
1
+
2
is not ldp
since:
1
+
2
+ ( 1)
1
2
=
(
1
) +
(
2
) + ( 1)
(
1
2
) = 0
The following notion of expression equivalence accounts for bijective renamings of keys
and nonces, as well as for the relations that an adversary may observe between the various
group elements that occur in an expression via ldp renamings.
Denition 6 Expressions
1
and
2
are equivalent, and we write
1

=
2
, if there
exists injective renamings
1
: SKeys SKeys,
2
: Nonce Nonce, and
injective ldp-renaming
3
: poly(
2
) Poly such that:
pattern(
1
) = pattern(
2
3
)
ACYCLIC EXPRESSIONS. An important concept for computational soundness in general
and for the results in this chapter in particular is the notion of acyclic expressions [1].
Informally, these are expressions where encryption cycles (situations where a key
1
encrypts key
2
, which in turn encrypts
3
, and so on, but one of the keys
is equal
to
1
) do not occur. Due to technical reasons, soundness cannot be guaranteed in such
situations by standard assumptions on the encryption scheme.
For an expression we dene the relation
on the set SKeys Poly (re-

stricted to the symmetric keys and polynomials that actually occur in ). For any
, SKeys Poly we set
if or
occurs in in a message position

encrypted with (if SKeys) or with () (if Poly). This relation is used in
dening formally acyclic expressions.
Denition 7 (Acyclic expression) An expression is acyclic if the two following con-
ditions are satised:
1. If is a polynomial such that (g
) occurs as an encryption key in , then is

not a linear combination of the polynomials that occur in (and are different
from ).
2. The relation
induced by is acyclic.
Algorithm pat(E)
0; uKeys(); ;

while = do
select an element maximal in with respect to
+1

[{ }
s
{}
s
]
{}
+ 1
output
Figure 3. Iterative algorithm for computing the pattern of an acyclic expression .

The rst condition is intended to avoid encryptions in which the plaintext and the en-
cryption key are linearly dependent, as for example in
{
1
, g
1
+
2
}
s
(g
2 )
. It can be
easily shown that the occurrence of such a ciphertext can reveal the encryption key with-
out contradicting the security of the encryption scheme. This condition can be further re-
laxed by requiring that is not a linear combination of polynomials that occur encrypted
under g
. We work with the more restrictive but simpler condition of Denition 7 only
for simplicity.
For acyclic expressions we give in Figure 3 an algorithmic procedure for com-
puting their associated pattern. The algorithm uses the set uKeys() = {
Keys, }, the set of keys that cannot be recovered from . Notice that ranges
over both standard keys and keys derived from group elements. Informally, the algo-
rithm works as follows. It selects an arbitrary unrecoverable key that does not occur en-
crypted in and replaces all encryptions under that key with encryptions of . We write
[{ }
s
{}
s
] for the expression obtained from by replacing each occurrence of

an encryption {}
s
with {}
s
. The algorithm repeats until there is no unrecoverable

key in that occurs in a message position. This nal expression is the pattern of the
original expression. The algorithm is formalized in Figure 3.
4.3. Computational Interpretation
Next we show how expressions can be interpreted, computationally, as distributions on
bitstrings.
TERMS AS DISTRIBUTIONS. Computationally, each element of Msg (and more gener-
ally, any pattern) is interpreted as a distribution. For example, elements of SKeys rep-
resent (the distributions of) cryptographic keys obtained by running the key generation
algorithm of some (xed) encryption scheme. A term like g
represents the distribution

of
when exponent is chosen at random, and (g
2
) represents the distribution of
keys obtained by applying a key derivation function to the group element
2
for ran-
dom
1
and
2
. A slightly more complex example is the expression: (g
, g
, {}
s
(g
)
)
that represents the distribution of a conversation between two parties that rst exchange
a Dife-Hellman key, and then use this key to encrypt a symmetric key.
We now specify precisely how to associate to each symbolic expression in Msg a
distribution. For this, we x an encryption scheme = (, , ), a group =
of order , and a key-derivation function kd : {0, 1}
. Here, and throughout the

Algorithm Init()
For each key SKeys set ()
$
()
For each nonce Nonce set ()
$
{0, 1}
For each Exponents set ()

$
{1, 2, . . . , }
Set () = 0
Output
Algorithm Gen(, )
If SKeys Nonce {} then ()
If = (
1
,
2
) then
1
$
Gen(
1
, );
2
$
Gen(
2
, );
1
,
2
If = g
(
1
,
2
,...,
)
then
((
1
),(
2
),...,(
))
If = {
1
}
s
then
$
Gen(
1
, );
$
((), )
If = {
1
}
s
(g
)
then
$
Gen(
1
, ); Gen(g
, )
$
(kd(), )
Return
Figure 4. Algorithms for associating a distribution to an expression (or a pattern) .
remainder of the section is a xed security parameter. About the key derivation function
we assume that when applied to a random group element it returns a symmetric key,
distributed identically with the output of the key generation function .
The algorithm in Figure 4 associates to each expression in Msg (and in fact, more
generally, to each pattern) a distribution. The association is as follows. First, the random-
ized algorithm Init is executed to obtain a map that associates to each key, nonce, and
random exponent that occur in a bitstring. The symbol is mapped to some xed
string, here 0. Then, algorithm Gen(, ) uses to (recursively) compute a bit-string as-
sociated to each subterm of , inductively. For example, expression (
1
,
2
) is mapped
to
1
,
2
, where , : {0, 1}
{0, 1}
is some injective, invertible mapping which

we x, but leave unspecied, and
1
and
2
are sampled according to
1
and
2
, respec-
tively. Similarly, expression {
1
}
s
is mapped to encryption of
1
under (), where
1
is sampled according to
1
and () is the key associated to by . The interpretation
of keys derived from group elements are obtained from the computational interpretation
of those elements by using the key derivation function kd.
We write [[]]
,
for the distribution of obtained using the two algorithms, that is:
$
Init();
$
Gen(, ). Since and are clear from the context, we may simply
write [[]] for the same distribution.
4.4. Soundness of symbolic analysis
In this section we show that symbolic analysis can be meaningfully used to reason about
the distributions associated to expressions. Specically, we establish two results. The
rst result states that the distribution associated to an expression and the distribution
associated to its pattern are indistinguishable. Informally, this means that patterns are a
sound abstraction of the information obtained by an adversary: no information is lost
even if parts of the expression are essentially erased. Building on this result, we show
that equivalent expressions (expressions that have the same pattern modulo appropriate
renamings) also have indistinguishable distributions. Computational indistinguishability
of distributions can therefore be established by reasoning entirely symbolically.
Before stating our soundness theorem we comment on the requirements that we put
on the primitives used in the implementation. As described in Section 2 and similarly to
the original paper of Abadi and Rogaway [1], we implement encryption using a scheme
that is IND-CPA
. We emphasize that we use the additional requirement only for sim-

plicity a similar result can be obtained for IND-CPA security, by rening the pattern
denition [29,27].
The implementation that we consider uses a group where the DDH problem is hard.
In particular, this implies that for any acyclic expression if (g
) is an unrecoverable
encryption key that occurs in , then the (
)-(poly() {}, {})-DDH assumption

also holds in , for some parameters
that depend on the structure of poly() and on

. Indeed, if is acyclic then is not a linear combination of the other polynomials that
occur in . The results of this section require a group where each (poly() {}, {})-
DDH problem is difcult. To avoid enumerating over all polynomials in , and to obtain
a result independent of the structure of the polynomials we simply demand that the group
used in the implementation ensures the required level of difculty.
Denition 8 Group is said to be (, )-appropriate for acyclic expression if the
(poly() {}, {})-DDH problem is (, )-hard in , for all for which (g
) is an
unrecoverable encryption key in .
Finally, we also require that the key derivation function kd is such that () and kd(
)
output equal distributions when is selected at random.
We can now state and prove a rst result that establishes a link between the symbolic
and the computational models for expressions. Informally, it says that from the point of
view of a computational adversary, no signicant amount of information is lost if one
replaces an acyclic expression with its pattern.
Theorem 2 Let be an acyclic expression. Let be an (
)-IND-CPA
secure
encryption scheme and be an (
)-appropriate group for . Then,

[[]]
,

[[pattern()]]
where
and
are parameters dependent on that we determine in the proof.

Proof:
The proof makes use of the iterative way of computing patterns for acyclic expressions
(Figure 3). Let
0
,
1
, . . . ,
be the sequence of expressions computed during the ex-

ecution of the algorithm. The expressions are such that
0
= and
= pattern().
First, notice that it is sufcient to show that distributions
= [[
]] and
+1
= [[
+1
]]
are close for any to conclude that [[
0
]] and [[
]] are also close. The following lemma

formalizes this intuition.
Lemma 2 Let
0
,
1
, . . . ,
be distributions such that for any {0, 1, . . . , 1}

it holds that

+1
. Then
0

,

holds, where = max
and
= min
.
To see this, consider an adversary that runs in time . Then, we have that:
Pr
[
: () = 1
]
Pr
[
0
: () = 1
]
=1
Pr
[
: () = 1
]
Pr
[
1
: () = 1
]
max
where the rst inequality follows by triangle inequality and the last one from the assump-
tion on the distributions.
Let
0
,
1
, . . . ,
be the sequence of expressions computed by the algorithm. Re-

call that
+1
=
[{ }
s
{}
s
] for some Keys. We show that this trans-

formation does not signicantly change the distribution associated to
, provided that
the primitives used in the implementation are secure. The desired relation between the
distributions associated to =
0
and pattern() =
then follow from the argument

outlined above.
To argue that distributions of [[]] and [[[{ }
s
{}
s
]]] are close we differen-

tiate between the case when is in SKeys and when is in (g
Poly
). We give two
lemmas. The rst lemma directly treats the rst case. The second lemma is a stepping
stone for proving the second case. We rst state these lemmas and explain how to use
them to obtain our result. Their proofs are in Appendix A and Appendix B, respectively.
Lemma 3 Let be an acyclic expression, and SKeys a key that only occurs in
in key positions. Then, if is an (
)-IND-CPA
secure encryption scheme, then:

[[]]
,
[[[{ }
s
{}
s
]]]
for =
and =
for some constant
.
The next lemma states that if in an expression one replaces an encryption key
(g
) with a random encryption key

0
the distribution of the expression does not
change signicantly. In the statement of the lemma, and throughout the paper, we write
[{ }
s
(g
)
{ }
s
] for the expression that results by replacing each occurrence of

encryption key (g
) by .
Lemma 4 Let be an acyclic expression, (g
0
) an encryption key that only occurs in
in key positions. Let
0
SKeys be a key that does not occur in . If (poly()
{
0
}, {
0
})-DDH is (
)-difcult in then:
[[]]
,
[[[{ }
s
(g
0)
{ }
s
0
]]]
for =
and =
, for some constant
.
We now explain how to use the previous two lemmas to conclude that the distance
between distributions
and
+1
is small. If
+1
=
[{ }
s
{}
s
] and
SKeys it follows by Lemma 3 that:
[[
]]
,

,(
)
[[
+1
]]
,
(1)
The case when
+1
=
[{ }
s
(g
)
{}
s
(g
)
] is slightly more complex, as it
is not directly covered by the above lemmas. Nevertheless, we can use the transfor-
mations in the lemmas to "emulate" the transformation above. Specically, to simu-
late the result of the transformation { }
s
(g
)
{}
s
(g
)
on an expression one can
apply, sequentially, the following three transformations: { }
s
(g
)
{ }
s
0
where
0
SKeys is a key that does not occur in the expression, then the transformation
{ }
s
0
{}
s
0
, followed by the transformation { }
s
0
{ }
s
(g
)
. Essentially,
the rst transformation replaces all occurrences of encryption key (g
) with a fresh
encryption key
0
. The next transformation replaces all terms encrypted with
0
by
. Finally, the key
0
is transformed back into (g
). This can be seen as follows.

Let
0
,
1
[{ }
s
(g
0)
{ }
s
0
],
2
=
1
[{ }
s
0
{}
s
0
], and
=
2
[{ }
s
0
{ }
s
(g
0)
]. Notice that
3
=
+1
. Since each of the three transfor-
mations above is covered by one of the two lemmas above we obtain a relation between
the distributions [[
]] and [[
+1
]].
Since
0
only occurs in
1
as an encryption key, by Lemma 3, we have that

[[
1
]]
,(
)
[[
2
]]
By Lemma 4, we have that:
[[
0
]]
,(
)
[[
1
]]
and also
[[
3
]]
,(
)
[[
2
]]
The last result follows since
2
=
3
[{ }
s
0
{ }
s
(g
0)
]. >From the above equations,
by Lemma 2 we get that
[[
]] = [[
0
]]
,
[[
3
]] = [[
+1
]]
where =
+ 2
and = min((
), (
)).
We have argued that for any {0, 1, . . . , 1}, [[
]]
,

[[
+1
]]
,
with
or
+ 2
, and
min(
), then by another
application of Lemma 2 we obtain:
[[]]
,
= [[
0
]]
,

[[
]]
,
= [[pattern()]]
,
for
+ 2
) and
= min(
), as desired.
The next theorem establishes the main result of this chapter: symbolically equivalent
expressions have associated computationally indistinguishable distributions. The result
holds for acyclic expressions as long as encryption is IND-CPA
and a more stringent

requirement holds on the group . Namely, we require that if
1
,
2
, . . . ,
is a base
of poly() then the ({}, {
1
,
2
, . . . ,
})-DDH problem is hard in . We overload the

meaning of "appropriateness", and in what follows we will assume that in addition to the
requirements of Denition 8, the above problem is also (, )-hard in .
Theorem 3 (Symbolic equivalence implies computational indistinguishability) Let
be a group that is (
)-appropriate for acyclic expressions

1
and
2
and an
(
)-IND-CPA
secure encryption scheme. Then
1

=
2
= [[
1
]]
,

,
[[
2
]]
,
for some and (that we determine in the proof).
The proof builds on Theorem 2. Since, by denition, the two expressions are equiv-
alent if their patterns are related via bijective renamings of keys and nonces, and ldp-
renamings of polynomials, it is sufcient to show that such renamings do not signi-
cantly change the distribution associated to a pattern. Before we give the proof we intro-
duce two useful lemmas. The rst lemma simplies dealing with arbitrary polynomials
in the exponents.
The lemma says that if
1
,
2
, . . .
is a basis of poly(), then the ldp renaming

which for each [] maps
to some fresh variable
(that does not occur in ) does

not change the distribution associated to .
Lemma 5 Let be an acyclic expression, {
1
,
2
, . . . ,
} a base of poly(), let
1
,
2
, . . . ,
be exponent variables that do not occur in . Let be the ldp-renaming

with (
) =
. Let be an arbitrary symmetric encryption scheme and a group that

is (
)-appropriate for . Then

[[]]
,

[[]]
,
Proof:
We show that an algorithm that distinguishes between the distributions of and that
of breaks the assumptions that is appropriate for . More specically, we show
that a successful distinguisher can be used to construct an adversary against the the
({}, {
1
,
2
, . . . ,
})-DDH problem. The construction is given in Figure 5.
The adversary is against the ({}, {

1
,
2
, . . . ,
})-DDH problem and therefore has ac-

cess to two oracles
1
and
2
the rst oracle is trivial for this particular problem. The
adversary constructs a bitstring much in the same way bitstrings are associated to
expressions by algorithm Gen: it generates bitstring interpretation for all of the symbols
that occur in using the Init procedure. However from the resulting assignment it only
uses the interpretation for keys and nonces. The interpretation for group elements uses
the oracles: for each group element g
, if =
for some = 1, 2, . . . , (that is, if

belongs to the base of poly()), then its interpretation is obtained by querying to
2
.
The interpretation of g
for any other polynomial is obtained by using the coefcients

of the representation of in base {
1
,
2
, . . . ,
} in the straightforward way.

Consider now the two possibilities for the oracle
2
. When this is the "real" ora-
cle, the interpretations of group elements are precisely as in the Gen algorithm so is
distributed according to [[]]. When
2
is the "fake" oracle the interpretation of g
is a
random group element obtained by
where
is a randomly chosen exponent. In this

case the sample computed by is from [[]]
,
.
We therefore have that (to simplify notation in the following equation we write
for the empty set and for {
1
,
2
, . . . ,
}):
Adversary
1
,
2
()
$
Init()
For {1, 2, . . . , } do
set (g
)
$
2
()
$
mGen
1
,
2
(, )
Return ()
Algorithm mGen
1
,
2
(, )
If = (
1
,
2
) then
1
$
mGen(
1
, );
2
$
mGen(
2
, );
1
,
2
If = g
(
1
,
2
,...,
)
then
let
1
,
2
, . . . ,
such that =
=1
=1
(g
);
If = {
1
}
then
$
mGen(
1
, );
$
((), );
If = {
1
}
(g
)
then
let
1
,
2
, . . . ,
such that =
=1
=1
(g
);
$
mGen(
1
, ); (kd(), )
Return
Figure 5. Adversary is against the ({}, {
1
,
2
, . . . ,
})-DDHassumption. It uses procedure mGen which

makes use of the oracle of .
Adv
(,)-DDH
= Pr
[
Real
(,)
=1
]
Pr
[
Fake
(,)
= 1
]
= Pr
[
$
[[]] : () = 1
]
Pr
[
$
[[]] : () = 1
]
As before, since the running time of ,
is
, where
is the time that

takes to construct the sample it passes to , if the ({}, {
1
,
2
, . . . ,
})-DDHis (
)-
difcult, then it must be the case that [[]]
,

[[]], as desired.
The next lemma is the core of the proof of Theorem 3. It states that injective renam-
ings of nonces and keys, as well as injective ldp renamings do not signicantly change
the distribution of an expression.
Lemma 6 Let be an acyclic expression. Let
1
be a permutation on Keys,
2
be a
permutation on Nonces and
3
be a ldp-renaming of polynomials in poly(). If is
appropriate for , then
[[]]
,

,
[[
1
3
]]
where = 2
and =
, for some constant
.
Proof:
First, notice that it is trivial that any injective renaming of keys and nonces leaves
the distribution of an expression unchanged. The reason is that the algorithm that as-
sociates distributions to bitstrings does not depend on the particular symbols used in
the expression. It is therefore sufcient to show that for any acyclic expression if
3
: poly() Poly is an arbitrary ldp-renaming then and
3
have distributions
that are indistinguishable:
[[]]
,

,
[[
3
]]
Let
1
,
2
, . . . ,
be a base of poly(). Since

3
is ldp, then
3
(
1
),
3
(
2
), . . . ,
3
(
)
is a base for poly(
3
). Consider the ldp-renaming : poly() Poly that for each
[] maps
to
. Then,
1
3
; : poly(
3
) Poly is also an ldp-renaming that
maps
3
(
) to
. (Here we write
1
;
2
for the renaming obtained by rst applying
1
followed by
2
.) The expression and the substitution satisfy the conditions of
Lemma 5, so it holds that:
[[]]
,

[[]]
,
(2)
Similarly, expression
3
and ldp-renaming
1
3
; satisfy the conditions of the same
lemma so we get that
[[
3
]]
,

[[
1
3
;
3
; ]]
,
= [[]]
,
(3)
By the two equations above and Lemma 2 we conclude that
[[]]
,

2
[[
3
]].
Theorem 3 can be concluded from the previous results as follows.
Proof:
If
1

=
2
then there exists injective renamings
1
: SKeys SKeys,
2
:
Nonce Nonce, and ldp-renaming
3
: poly(
2
) Poly such that pattern(
1
) =
pattern(
2
3
). Therefore we have the following sequence of equivalences:
[[
2
]]
1
,
1
[[pattern(
2
)]]
2
,
2
[[pattern(
2
3
)]] = [[pattern(
1
)]]
3
,
3
[[
1
]].
where the rst and last equivalences follow from Theorem 2, the second equivalence fol-
lows by Lemma 6, and the third equality from the assumptions that
1
and
2
are sym-
bolically equivalent. Notice that all of the parameters involved depend on the underlying
group and also on the particular expressions
1
and
2
.
4.5. An example
To appreciate the power that the above soundness theorem provides, consider the expres-
sion:
() =
(
g
1
, g
2
, g
3
, g
2
, g
3
, g
3
, {}
s
(g
3)
, {}
s
)
where is some arbitrary expression. Expression represents the transcript of the exe-
cutions of the following (toy) protocol: three parties with secret keys
1
,
2
and
3
rst
agree on a common secret key (g
3
) (by broadcasting the rst 6 messages in the
expression). Then, one of the parties generates a new key which it broadcasts to the
other parties encrypted under (g
3
). Finally, one of the parties, sends some secret
expression encrypted under . To argue about the security of the secret expression
(against a passive adversary) it is sufcient to show that the distributions associated to
the expressions () and (0) are indistinguishable.
Although conceptually simple, a full cryptographic proof would require several re-
ductions (to DDH and security of encryption), and most likely would involve at least
one hybrid argument (for proving the security of encrypting under (
3
)). The
tedious details of such a proof can be entirely avoided by using the soundness theorem:
it is straightforward to verify that ()

= (0), and in general, this procedure could
potentially be automated. Since () is acyclic, the desired result follows immediately
by Theorem 3.
References
[1] M. Abadi and P. Rogaway. Reconciling two views of cryptography (the computational soundness of
formal encryption). In IFIP TCS 2000, pp. 322.
[2] A. Datta, A. Derek, J.C.Mitchell, V.Shmatikov, M. Turuani. Probabilistic polynomial-time semantics
for a Protocol Security Logic. In ICALP 2005 , pp. 1629.
[3] M. Backes, B. Ptzmann, and M. Waidner. A composable cryptographic library with nested operations.
In CCS 2003, pp. 220230.
[4] F. Bao, R. Deng, and H. Zhu. Variations of Dife-Hellman problem. In ICICS 2003, pp. 301312.
[5] G. Barthe, B. Gregoire, R. Janvier, and S. Zanella Bquelin. A framework for language-based cryptog-
raphy proofs. In 2nd Informal ACM SIGPLAN Workshop on Mechanizing Metatheory, 2007.
[6] M. Bellare, A. Boldyreva, and S. Micali. Public-key encryption in a multi-user setting: security, proofs,
and improvements. In EUROCRYPT 2000, pp. 259274.
[7] M. Bellare and P. Rogaway. The game-playing technique and the security of triple encryption. in
CRYPTO 2006, pp. 409426.
[8] M. Bellare, A. Desai, E. Jokipii, and Ph. Rogaway. A concrete security treatment of symmetric encryp-
tion: Analysis of the DES modes of operation. In FOCS 1997, pages 394403.
[9] M. Blum and S. Micali. How to generate cryptographically strong sequences of pseudo-random bits.
SIAM J. of Computing, 13:850864, 1984.
[10] D. Boneh, X. Boyen, and E.-J. Goh. Hierarchical identity based encryption with constant size ciphertext.
In EUROCRYPT 2005, pp. 440456.
[11] E. Bresson, O. Chevassut, and D. Pointcheval. Group Dife-Hellman key exchange secure against
dictionary attacks. In ASIACRYPT 2002, pp. 497514.
[12] E. Bresson, O. Chevassut, and D. Pointcheval. The group Dife-Hellman problems. In SAC 2002, pp.
325338.
[13] E. Bresson, Y. Lakhnech, L. Mazar, and B. Warinschi. A generalization of DDH with applications to
protocol analysis and computational soundness. In Crypto 2007, pp. 482499.
[14] M. Burmester and Y. Desmedt. A secure and efcient conference key distribution system (extended
abstract). In EUROCRYPT 1994, pp. 275286.
[15] B. Blanchet and D. Pointcheval. Automated security proofs with sequences of games. In CRYPTO 2006,
pp. 537554.
[16] R. Canetti. Universally composable security: A new paradigm for cryptographic protocols. In FOCS
2001, pages 136145.
[17] R. Canetti. Towards realizing random oracles: Hash functions that hide all partial information. In
CRYPTO 1997, pp. 455469.
[18] Y. Chevalier, R. Ksters, M. Rusinowitch, and M. Turuani. Deciding the Security of Protocols with
Dife-Hellman Exponentiation and Products in Exponents. In FSTTCS 2003, pp. 124135.
[19] D. Coppersmith and I. Shparlinski. On polynomial approximation of the discrete logarithm and the
Dife-Hellman mapping. J. of Cryptology, 13(2):339360, 2000.
[20] V. Cortier, S. Kremer and B. Warinschi. A Survey of Symbolic Methods in Computational Analysis of
Cryptographic Systems. J. of Automated Reasoning.
[21] R. Cramer and V. Shoup. A practical public key cryptosystem provably secure against adaptive chosen
ciphertext attack. In CRYPTO 1998, pp. 1325.
[22] D. Dolev and A. Yao. On the security of public key protocols. IEEE IT, 29(12):198208, 1983.
[23] T. ElGamal. A public key cryptosystem and a signature scheme based on discrete logarithm. IEEE IT,
31(4):469472, 1985.
[24] O. Goldreich. Foundations of Cryptography Basic Tools. Cambridge University Press, 2004.
[25] J. Couran, M. Dabugnard, C. Ene, P. Lafourcade, and Y. Lakhnech. Towards Automated Proofs for
Asymmetric Encryption in the Random Oracle Model. In ACM CCS 2008, pp. 371-380, 2008.
[26] U. Maurer and S. Wolf. Dife-Hellman oracles. In CRYPTO 1996, pp. 268282.
[27] D. Micciancio and S. Panjwani. Adaptive security of symbolic encryption. In TCC 2005, pp. 245263.
[28] D. Micciancio and B. Warinschi. Soundness of formal encryption in the presence of active adversaries.
In TCC04, pp. 133151.
[29] D. Micciancio and B. Warinschi. Completeness theorems for the Abadi-Rogaway logic of encrypted
expressions. J. of Computer Security, 12(1):99129, 2004. Preliminary version in WITS 2002.
[30] J. Millen and V. Shmatikov. Symbolic protocol analysis with products and Dife-Hellman exponentia-
tion. In CSFW 2003, pp. 4761.
[31] M. Naor and O. Reingold. Number-theoretic constructions of efcient pseudo-random functions. In
FOCS 1997, pp. 458467.
[32] M. Rusinowitch and M. Turuani. Protocol insecurity with a nite number of sessions and composed
keys is NP-complete. J. of Theoretical Computer Science, 1-3(299):451475, 2003.
[33] A.-R. Sadeghi and M. Steiner. Assumptions related to discrete logarithms: Why subtleties make a real
difference. In EUROCRYPT 2001, pp. 244261.
[34] V. Shoup. Lower bounds for discrete logarithms and related problems. In EUROCRYPT 1997, pp.
256266.
[35] V. Shoup. Sequences of games: a tool for taming complexity of security proofs. Cryptology ePrint
Archive 2004/332.
[36] I. Shparlinski. Security of most signicant bits of
2
. IPL, 83(2):109113, 2002.
[37] M. Steiner, G. Tsudik, and M. Waidner. Dife-Hellman key distribution extended to group communica-
tion. In ACM CCS 1996, pp. 3137.
A. Proof of Lemma 3
Recall that here we show that if is an expression in which
0
SKeys does not
occur encrypted in (it only occurs as an encryption key), and if is an (
)-
IND-CPA
secure encryption scheme then replacing terms encrypted under

0
with
does not change the distribution of the expression signicantly. Formally, we show that:
[[]]
,

,
[[[{ }
s
0
{}
s
0
]]]
,
for some =
and =
for some
constant
that we determine during the proof. The intuition is that a distinguisher

that observes the change in the distribution must observe the change of plaintext under a
key he dose not know, and hence breaks encryption.
Given a distinguisher for distributions [[]] and [[[{ }
s
0
{}
s
0
]]] we construct
an adversary against . The construction is in Figure 6. The idea of the construction is
to generate a bitstring such that if the oracle to which has access is the real oracle (i.e.
it returns true encryptions of the message that is queried) then is sampled according to
[[]], and if the oracle of is the fake oracle (which returns encryptions of 0) then the
is sampled according to [[[{ }
s
0
{ }
s
0
]]]. To accomplish this task, executes
the Init() algorithm (given earlier in Figure 4) to obtain bitstring interpretation for
all symbols that occur in . Then, uses to produce bitstring interpretations for all
of the terms that occur in much in the same way as the algorithm Gen of Figure 4.
The only difference is that encryptions under
0
are obtained via the oracle to which
has access (line 5 of the modied generation algorithm mGen.) The sample that is
Algorithm mGen
(,
0
, )
If = (
1
,
2
) then
1
$
Gen(
1
, );
2
$
Gen(
2
, );
1
,
2
If = g
(
1
,
2
,...,
)
then
((
1
),(
2
),...,(
))
If = {
1
}
s
and =
0
then
$
Gen(
1
, );
$
((), );
If = {
1
}
s
and =
0
then
$
Gen(
1
, );
$
();
If = {
1
}
s
(g
)
then
$
Gen(
1
, ); Gen(g
); (kd(), )
Return e
Adversary
(,
0
)
$
Init()
$
mGen
(,
0
, )
output ()
Figure 6. Adversary is against encryption. It uses procedure mGen which makes use of the oracle of .
generated satises the desired property. If the oracle to which has access is a real oracle
(), symbolic encryptions under

0
are interpreted as encryptions under . In other
words the result of mGen(,
0
, ) is the same as the result of Gen(,
) where
is
except that the key assigned to
0
is set to be , the key of the encryption oracle. In
the case when the oracle of is a fake oracle, the oracle that returns
(0) each time

it is queried, then all encryptions under
0
are interpreted as encryptions under of 0.
This means that produced by mGen is sampled from [{ }
s
0
{}
s
0
]. Notice that
in both cases it is crucial that
0
occurs in only in key positions and not as messages.
Otherwise , who has access to (the interpretation of
0
) only indirectly through its
oracle, would not be able to produce a consistent interpretation for . We therefore have
that:
Adv
ind-cpa
() =
=
Pr
[
()
= 1
]
Pr
[
(0)
= 1
]
Pr
[
$
[[]] : () = 1
]
Pr
[
$
[[[{ }
s
0
{}
s
0
] : () = 1]]
]
The right hand-side of the last inequality is exactly the advantage of in distinguishing
distributions [[]] and [{ }
s
0
{}
s
0
]. If
is the running time of then the

running time of is
, where
is some constant time that spends

in preparing the sample . If is (
)-IND-CPA
then we immediately obtain that

[[]]
,
[[[{ }
s
0
{}
s
0
]]], where =
and =
.
B. Proof of Lemma 4
Recall that here we show that if is an acyclic expression in which (g
0
) only occurs
as an encryption key then one can replace each occurrence of (g
0
) in with a new
key
0
without signicantly changing the distribution of the expression. More precisely,
we show how to turn a distinguisher between distributions [[]] and [[[{ }
s
(g
0
)

{ }
s
0
]]] into an attacker for the (poly() {}, {})-DDH assumption. To simplify
notation (and in line with the notation of Section 3) in the remainder of this section we
write for the set poly() {
0
} and for the set {
0
}.
The adversary that we construct is in Figure 7.
Algorithm mGen
1
,
2
(,
0
, )
If = (
1
,
2
) then
1
$
mGen
1
,
2
(
1
, );
2
$
mGen
1
,
2
(
2
, );
1
,
2
If = g
(
1
,
2
,...,
)
then
$
1
()
If = {
1
}
then
$
mGen
1
,
2
(
1
, );
$
((), );
If = {
1
}
(g
)
and =
0
then
$
1
();
$
mGen(
1
, ); (, )
If = {
1
}
(g
)
and =
0
then
$
2
();
$
mGen(
1
, ); (kd(), )
Return
Adversary
1
,
2
(,
0
)
$
Init()
$
mGen
1
,
2
(,
0
, )
output ()
Figure 7. Adversary is against the (poly() {
0
}, {
0
})-DDH assumption. It uses procedure mGen
which makes use of the oracle of .
Recall that has access to two oracles. The rst oracle accepts as queries polyno-
mials , and returns
(
1
,
2
,...,
)
. The second oracle accepts a single query,
0
and behaves in one of two ways: in the rst case it returns
0
(
1
,
2
,...,
)
in the second
case it returns
1
. The task of the adversary is to determine in which of the two possible
situations it is.
Starting from , adversary constructs a sample . First it executes the Init() al-
gorithm to obtain an interpretation for all of the symbols that occur in and then recur-
sively constructs . The construction of is similar to the way the generation algorithm
Gen works, except that the interpretation of group elements that occur in is obtained
from the oracles of . For all polynomials in with =
0
, the generation procedure
obtains the interpretation of g
from oracle
1
(which returns the true value of g
under
the interpretation for variables that it maintains internally). The interpretation of g
0
is
obtained from its second oracle. We distinguish two cases. When interacts with the
"real" oracle it obtains back the interpretation of
0
. Therefore, in this case, is dis-
tributed according to [[]]. In the fake game the value returned is
for a random expo-

nent . Since we assumed that the distribution of and that of kd(g
) are identical,
then symbolic encryptions under (g
0
) are interpreted as encryptions under a random
key. It follows that in this case is distributed according to [[[{ }
s
(g
)
{ }
s
0
]]] for
some
0
that does not occur in . We therefore have that:
Adv
(,)-ddh
() =
=
Pr
[
Real
(,)
= 1
]
Pr
[
Fake
(,)
= 1
]
Pr
[
$
[[]] : () = 1
]
Pr
[
$
[[[{ }
s
(g
)
{ }
s
0
]]] : () = 1
]

Notice that the last term is the advantage that has in distinguishing between distribu-
tions [[]] and [[[{ }
s
(g
)
{ }
s
0
]]]. If the running time of is
then the running

time of is
. Here
is the time that uses to compute the sample . If

is (
)-appropriate for , then it follows that [[]]

,
[[[{ }
s
(g
)
{ }
s
0
]]] for
=
and =

Author Index
Blanchet, B. 86
Bresson, E. 277
Comon-Lundh, H. 35
Cortier, V. v, 1
Datta, A. 182
Delaune, S. 35
Focardi, R. 143
Guttman, J.D. 222
Kremer, S. v, 1
Lakhnech, Y. 277
Lowe, G. 62
Maffei, M. 143
Mazar, L. 277
Millen, J.K. 35
Mitchell, J.C. 182
Roy, A. 182
Rusinowitch, M. 13
Ryan, M.D. 112
Schneider, S. 258
Smyth, B. 112
Stiller, S.H. 182
Turuani, M. 13
Warinschi, B. 277
IOS Press, 2011
303

Formal Models PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Formal Models PDF

Uploaded by

Copyright:

Available Formats

FORMAL MODELS AND TECHNIQUES FOR

ANALYZING SECURITY PROTOCOLS

. This property is often referred

) and symmetric key (

) encryptions. The set of basic messages is nite and denoted

A signature, usually denoted by []

with a private key

. For conciseness we denote by

the set of messages

}. Given two sets of messages and

Table 1. Intruder Rules

(, ) replaces a set of messages , by the

if there exists one rule (from

for the reexive and transitive closure of . We denote the applica-

() for all messages }, and

in the same way. We call derivation a se-

or if there exists a derivation

, ... assuming that is only known by the

As for messages, a signature usually denoted as []

with a private key

. Let () be the set of variables that occur in a term

are terms. Given a

in a correct execution order. For the readability of examples, we allow

, and for all

is present. One can remark that principals are not al-

Figure 1. Handshake Protocol

and is a basic message.

. Then we say that is forged from and we denote it by

in an (active) attack. Hence we can formulate the denition of an

1, . . . , such that for all = 1, . . . , , we have

Figure 3. Otway-Rees Protocol

to send a secret mes-

, to be the number of distinct subterms of , i.e the number of elements in

. We note that a standard

, but this differ-

Figure 4. DAG Representation of the First Message of Otway-Rees Protocol

(). A related notion of

and then we take the smallest prex of

() a derivation of minimal length among the deriva-

() is a subterm of or . Lemma 1 means

be (one of) the rst occuring

has necessarily be obtained by a decomposition

subtermof such that

, this means that is a subterm of , and thus

be (one of) the last occuring term

) . Similarly, by minimality of and since

) would be useless and would not

is a subterm of , and thus thanks to Lemma 1,

is a subterm of ; And nally, composition using

means that there exists

subterm of , and thus by hypothesis both and

then for all 1 ,

. By denition of , for any term

there exists with

subterm of such that either

() . Therefore, thanks to Lemmas 1 and 2 above, (and thus

(, ), which proves the proposition.

times. The FORALL

times. The work done in this innermost loop is

we generate the clauses: , and , ;

1, . . . , (where is the cardinality of

now replace , for readability, unlike previous sections.