Formal Models and Techniques for Analyzing Security Protocols

FORMAL MODELS AND TECHNIQUES FOR ANALYZING SECURITY PROTOCOLS Cryptology and Information Security Series The Cryptolo...

Author: Veronique Cortier | Steve Kremer

12 downloads 866 Views 2MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

FORMAL MODELS AND TECHNIQUES FOR ANALYZING SECURITY PROTOCOLS

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 Supérieure, France Gregory Neven, IBM Research, Switzerland Phong Nguyen, CNRS / École Normale Supérieure, 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. Vol. 3. Vol. 2. Vol. 1.

Y. Li and J. Zhou (Eds.), Radio Frequency Identification System Security – RFIDsec’10 Asia Workshop Proceedings C. Czosseck and K. Geers (Eds.), The Virtual Battlefield: Perspectives on Cyber Warfare M. Joye and G. Neven (Eds.), Identity-Based Cryptography J. Lopez and J. Zhou (Eds.), Wireless Sensor Network Security

ISSN 1871-6431 (print) ISSN 1879-8101 (online)

Formal Models and Techniques for Analyzing Security Protocols

Edited by

Véronique 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: [email protected] Distributor in the USA and Canada IOS Press, Inc. 4502 Rachael Manor Drive Fairfax, VA 22032 USA fax: +1 703 323 3668 e-mail: [email protected]

LEGAL NOTICE The publisher is not responsible for the use which might be made of the following information. PRINTED IN THE NETHERLANDS

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

Preface Security protocols are small distributed programs which aim to achieve security properties such as confidentiality, authentication, anonymity, etc. Nowadays, security protocols are omnipresent in our daily lives: home-banking, electronic commerce, mobile phones, etc. However, because these protocols are generally implemented on potentially insecure networks (e.g. the Internet) they are extremely difficult to devise. Using Roger Needham’s words “Security protocols are three line programs that people still manage to get wrong”. Based on the seminal work of Dolev and Yao, symbolic methods 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 unbounded 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 complexity questions and models with solid theoretical foundations have been developed together with proof techniques. Automated tools have also been designed and successfully 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 protocols. We are extremely grateful to all the authors for their hard work and effort in preparing these chapters. January 2011 Véronique Cortier and Steve Kremer

This page intentionally left blank

vii

Contents Preface Véronique Cortier and Steve Kremer

v

Introduction Véronique Cortier and Steve Kremer

1

Verifying a Bounded Number of Sessions and Its Complexity Michael Rusinowitch and Mathieu Turuani Constraint Solving Techniques and Enriching the Model with Equational Theories Hubert Comon-Lundh, Stéphanie Delaune and Jonathan K. Millen

13

35

Analysing Security Protocols Using CSP Gavin Lowe

62

Using Horn Clauses for Analyzing Security Protocols Bruno Blanchet

86

Applied pi Calculus Mark D. Ryan and Ben Smyth

112

Types for Security Protocols Riccardo Focardi and Matteo Maffei

143

Protocol Composition Logic Anupam Datta, John C. Mitchell, Arnab Roy and Stephan Hyeonjun Stiller

182

Shapes: Surveying Crypto Protocol Runs Joshua D. Guttman

222

Security Analysis Using Rank Functions in CSP Steve Schneider

258

Computational Soundness – The Case of Diffie-Hellman Keys Emmanuel Bresson, Yassine Lakhnech, Laurent Mazaré and Bogdan Warinschi

277

Author Index

303

This page intentionally left blank

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. doi:10.3233/978-1-60750-714-7-1

1

Introduction Véronique 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 predecessor, the Secure Sockets Layer (SSL). These protocols are typically used for guaranteeing a secure connection to a web site in particular for secure payment over the Internet. 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 government offered the possibility to vote via the Internet. The development of such protocols 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 protocols makes the use of formal veriﬁcation 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 adversary 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 perform cryptanalysis or to decrypt a ciphertext without knowing the decryption key. Finding 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 identiﬁed using formal methods, demonstrating their usefulness. At the end of the ’90s more foundational questions were investigated: the general undecidability results for automated veriﬁcation of security protocols have been reﬁned and decidable classes of protocols and restrictions yielding decidability were identiﬁed 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

2

V. Cortier and S. Kremer / Introduction

assumption. A lot of efforts were performed to relax this assumption by introducing algebraic 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 understanding of the underlying difﬁculties of security protocol veriﬁcation but also enabled the development of efﬁcient tools such as among others the AVISPA platform [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 conﬁdentiality. For instance the ProVerif tool allows to check the resistance against dictionary attacks [Bla04], as well as indistinguishability properties [BAF05]. Moreover, complex properties of contract signing [KR02,CKS01,KK05] and electronic voting protocols [DKR09,KT09,BHM08a] have been formalized. The theory as well as the tools for formal analysis have now reached a state of maturity where they can be used on practical protocols. However, there is not one technique or tool which combines all beneﬁts. There exist today many formalisms and approaches which have each their own beneﬁts. 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 inﬂuential developments in this ﬁeld.

1. Some examples of security protocols Security protocols aim at different goals such as key distribution, message integrity, authentication, 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|}sk . Similarly, we write {|m|}apk 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 examples 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, illustrated 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. Participant A generates a fresh session key k, signs it with his secret key sk(A) and encrypts it using B’s public key pk(B). When B receives this message he decrypts it using his secret key, veriﬁes 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.

3

V. Cortier and S. Kremer / Introduction

[k]sk( A) a

A

B

pk(B)

{|s|}sk (a) (Flawed) handshake protocol

A

[k]sk( A) a

[k]sk( A) a

C

pk(C)

B

pk(B)

{|s|}sk (b) Man in the middle attack

A

[A, B, k]sk( A) a

B

pk(B)

{|s|}sk (c) Corrected handshake protocol Figure 1. Handshake protocol

However, this protocol is vulnerable to a man in the middle attack described in Figure 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 participants 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 methods [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 B’s public key). Similarly, freshness of the nonce N B should convince B that the third message originates from A.

4

V. Cortier and S. Kremer / Introduction

A

B

{|N A , A|}apk(B) {|N A , N B |}apk( A) {|N B |}apk(B) (a) NSPK protocol

A

{|N A , A|}apk(C)

C

{|N A , C|}apk(B)

{|N A , N B |}apk( A)

{|N A , N B |}apk( A)

{|N B |}apk(C)

{|N B |}apk(B)

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|}apk( A) , ﬁxes the protocol. 2. Formal models One of the main advantages of formal methods is to provide a clear, well-deﬁned mathematical 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-

5

V. Cortier and S. Kremer / Introduction

x

y

{|x|}sy

{|x|}sy

y

x

y

x, y

x

x, y

x, y

x

y

Figure 3. Dolev-Yao deduction system.

tion symbols are of arity 2 and model symmetric encryption and concatenation respectively. 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 reﬂect 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|}sk,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|}sy , y) = x. These two ways of modeling encryption are similar but not equivalent. For example, Millen [Mil03] has shown that some attacks can be detected only when destructors are explicitly represented. One of the advantages of using equational theories is to reﬂect in a natural way the properties of the underlying primitives. Indeed destructors correspond to functions that are actually available to an attacker. Many complex cryptographic primitives such as blind signatures, re-encryption [DKR09], Exclusive Or, Difﬁe-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 uniﬁed model would enable better comparisons between each result but such a uniﬁed model does not exist currently. The reason for having several popular symbolic models probably 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 reﬂect protocol behaviors. One the other hand, models have to remain relatively simple in order to allow the design of (automatic) decision procedures.

6

V. Cortier and S. Kremer / Introduction

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 veriﬁcation. 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 reﬂect 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 capabilities 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 Dexter’s 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 unbounded 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 Blanchet’s 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 underlying 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 implementation 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 CryptoSPA [FM99], the spi-calculus [AG97] or the applied pi calculus [AF01]) provide com-

V. Cortier and S. Kremer / Introduction

7

munication primitives for sending and receiving messages, restriction, parallel composition and replication of processes. This yields an accurate (symbolic) modelling of protocols, 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 deﬁnition 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 deﬁnition 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 Mitchell’s 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 application. The two most classical security properties are secrecy and authentication. Most of the veriﬁcation 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 speciﬁed using a reachablity-based property: a protocol is said to preserve the conﬁdentiality 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 picalculus [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 speciﬁed 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 authentication, e.g. by Schneider [Sch97] and by Lowe [Low97]. Equivalence-based properties While secrecy and authentication goals are usually speciﬁed as reachability properties, more complex properties such as privacy-like properties usually require the use of equivalence-based deﬁnitions. Strong secrecy, described above, is a ﬁrst example of an equivalence-based deﬁnition. Equivalence-based properties 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 deﬁnitions of anonymity have been proposed [Aba02,SH02,Low02]. In particular, the deﬁnition proposed by Shmatikov

8

V. Cortier and S. Kremer / Introduction

and Hughes relies on observational equivalence. Other examples of security properties stated as equivalence-based properties are privacy in e-voting protocols, receiptfreeness or coercion-resistance [DKR09]. Equivalence-based properties can also be used for analysing security properties speciﬁed 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 veriﬁcation 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 veriﬁcation. It has also given birth to an automated tool [ABB+ 02,ABB+ 05]. While many early models considered free term algebras it is now widely recognized that this is not sufﬁcient 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 theories” 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 speciﬁed using a process algebra. 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 applied 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 veriﬁcation 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 developed the strand spaces model. This model allows to directly reason on the graphical representation of protocol executions. The model and some of its associated veriﬁcation

V. Cortier and S. Kremer / Introduction

9

techniques are presented in the chapter “Shapes: surveying crypto protocols runs”. Another possibility for analysing protocols is to compute on over-approximation of the attacker behavior, still showing the security of the protocol. This is the intuitive goal of the rank functions deﬁned by Schneider and presented in the chapter “Security analysis using rank functions in CSP”. Formal models differ signiﬁcantly from computational ones. In modern cryptography, security deﬁnitions are based on complexity theory. Messages are modeled by bitstrings and encryption functions are algorithms on bit-strings. The issue is then to detect whether an adversary (a Turing machine) is able to learn a conﬁdential information in reasonable (polynomial) time with non negligible probability. This notion of security seems to better reﬂect the class of attacks that can be mounted in practice. However, security proof are error-prone and difﬁcult to automate. Computational and symbolic models have been developed separately since the 80s. They seem a priori very distinct and difﬁcult 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 cryptographic indistinguishability of sequences of messages can be abstracted by the symbolic equivalence of the corresponding sequences of terms. This result has then been followed by many extensions. To conclude this book, the chapter “Computational soundness: the case of Difﬁe-Helman keys” illustrates this new line of research by presenting a soundness result between symbolic and cryptographic equivalences for Difﬁe-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. Bödersheim, M. Rusinowitch, 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 Veriﬁcation (CAV 2002), volume 2404 of LNCS, pages 349–353. Springer, July 2002. [ABB+ 05] A. Armando, D. Basin, Y. Boichut, Y. Chevalier, L. Compagna, J. Cuellar, P. Hankes Drielsma, P.-C. Héam, O. Kouchnarenko, J. Mantovani, S. Mödersheim, 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 Conference on Computer Aided Veriﬁcation, CAV’2005, volume 3576 of Lecture Notes in Computer Science, pages 281–285, 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 1–10, 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 (POPL’01), pages 104–115, 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 (CCS’97), pages 36–47. ACM Press, 1997. [AG98] M. Abadi and A. Gordon. A bisimulation method for cryptographic protocols. Nordic Journal of Computing, 5(4):267–303, 1998. [AL00] R. Amadio and D. Lugiez. On the reachability problem in cryptographic protocols. In Proc. of the 12th International Conference on Concurrency Theory (CONCUR’00), volume 1877 of LNCS, pages 380–394, 2000.

10 [ALV02]

V. Cortier and S. Kremer / Introduction

R. Amadio, D. Lugiez, and V. Vanackère. On the symbolic reduction of processes with cryptographic functions. Theoretical Computer Science, 290(1):695–740, 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 3–22, August 2000. [BAF05] Bruno Blanchet, Martín Abadi, and Cédric Fournet. Automated veriﬁcation of selected equivalences for security protocols. In 20th IEEE Symposium on Logic in Computer Science (LICS 2005), pages 331–340. IEEE Computer Society, June 2005. [BAF08] Bruno Blanchet, Martín Abadi, and Cédric Fournet. Automated veriﬁcation of selected equivalences for security protocols. Journal of Logic and Algebraic Programming, 75(1):3–51, 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 233–271. 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 Foundations Workshop (CSFW’15), pages 175–190. 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 157–166, 1999. [BHM08a] Michael Backes, Catalin Hritcu, and Matteo Maffei. Automated veriﬁcation 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 Proceedings of 2008 ACM Conference on Computer and Communication Security (CCS’08, 2008. [Bla01] B. Blanchet. An efﬁcient cryptographic protocol veriﬁer based on prolog rules. In Proc. of the 14th Computer Security Foundations Workshop (CSFW’01). IEEE Computer Society Press, June 2001. [Bla04] Bruno Blanchet. Automatic proof of strong secrecy for security protocols. In IEEE Symposium on Security and Privacy (SP’04), pages 86–100, Oakland, California, May 2004. [Bla05] Bruno Blanchet. An automatic security protocol veriﬁer based on resolution theorem proving (invited tutorial). In 20th International Conference on Automated Deduction (CADE-20), Tallinn, Estonia, July 2005. [Bla08] Bruno Blanchet. Vériﬁcation automatique de protocoles cryptographiques : modèle formel et modèle calculatoire. Automatic veriﬁcation of security protocols: formal model and computational model. Mémoire d’habilitation à diriger des recherches, Université Paris-Dauphine, November 2008. En français 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 (ICALP’01). 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 (ICALP’99), 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 (CSFW’99), pages 55–69. IEEE Computer Society Press, 1999. [CDL06] V. Cortier, S. Delaune, and P. Lafourcade. A Survey of Algebraic Properties Used in Cryptographic 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 176–185. ACM Press, November 2001. [CL04] H. Comon-Lundh. Résolution de contraintes et recherche d’attaques 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 (RTA’2003), volume 2706 of LNCS, pages 148–164. Springer-Verlag, 2003. [CLC08] Hubert Comon-Lundh and Véronique Cortier. Computational soundness of observational equiv-

V. Cortier and S. Kremer / Introduction

11

alence. In Proceedings of the 15th ACM Conference on Computer and Communications Security (CCS’08), Alexandria, Virginia, USA, October 2008. ACM Press. [Cre08] Cas Cremers. The Scyther Tool: Veriﬁcation, falsiﬁcation, and analysis of security protocols. In Computer Aided Veriﬁcation, 20th International Conference, CAV 2008, Princeton, USA, Proc., volume 5123/2008 of Lecture Notes in Computer Science, pages 414–418. 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 177–186. Plenum Press, 1983. [DKR09] Stéphanie Delaune, Steve Kremer, and Mark D. Ryan. Verifying privacy-type properties of electronic voting protocols. Journal of Computer Security, 17(4):435–487, July 2009. [DLM82] R. Demillo, N. Lynch, and M. Merritt. Cryptographic protocols. In Proc. of the 14th 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):247–311, 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 350–357. IEEE Computer Society Press, 1981. [FM99] Riccardo Focardi and Fabio Martinelli. A uniform approach for the deﬁnition of security properties. In Proc. of World Congress on Formal Methods (FM’99), volume 1708 of Lecture Notes in Computer Science, pages 794–813. Springer, 1999. [Gou08] Jean Goubault-Larrecq. Towards producing formally checkable security proofs, automatically. In Proceedings of the 21st IEEE Computer Security Foundations Symposium (CSF’08), pages 224–238, 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 (CSFW’00), pages 24–34. 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(3–4):409–433, 2004. [Gut09] Joshua D. Guttman. Cryptographic protocol composition via the authentication tests. In Foundations of Software Science and Computation Structures (FOSSACS’09), Lecture Notes in Computer Science, March 2009. [KK05] D. Kähler and R. Küsters. 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 233–247. 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 (CSFW’02), pages 206–220. IEEE Computer Society Press, June 2002. [KR05] Steve Kremer and Mark. Ryan. Analysis of an electronic voting protocol in the applied picalculus. In Mooly Sagiv, editor, Programming Languages and Systems –Proceedings of the 14th European Symposium on Programming (ESOP’05), volume 3444 of Lecture Notes in Computer Science, pages 186–200, Edinburgh, U.K., April 2005. Springer. [KT09] R. Küsters 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 251–266. IEEE Computer Society, 2009. [Low96a] G. Lowe. Breaking and ﬁxing the Needham-Schroeder public-key protocol using FDR. In T. Margaria and B. Steffen, editors, Tools and Algorithms for the Construction and Analysis of Systems (TACAS’96), volume 1055 of LNCS, pages 147–166. Springer-Verlag, march 1996. [Low96b] G. Lowe. Some new attacks upon security protocols. In Proc. of the 9th Computer Seurity Foundation Workshop (CSFW’96), pages 162–169. IEEE Computer Society Press, 1996. [Low97] G. Lowe. A hierarchy of authentication speciﬁcation. In Proc. of the 10th Computer Security Foundations Workshop (CSFW’97). 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.

12 [Mea96]

[Mer83] [Mil84] [Mil03] [MS01]

[MS03] [Pau98] [RT01]

[Sch96] [Sch97] [SH02] [THG99] [VSS05]

[Wei99]

V. Cortier and S. Kremer / Introduction

Catherine Meadows. Language generation and veriﬁcation in the nrl protocol analyzer. In Proceedings of the 9th Computer Security Foundations Workshop (CSFW’96). IEEE Computer Society Press, 1996. Michael J. Merritt. Cryptographic Protocols. PhD thesis, Georgia Institute of Technology, February 1983. Jonathan K. Millen. The interrogator: A tool for cryptographic protocol security. In IEEE Symposium on Security and Privacy, pages 134–141, 1984. J. Millen. On the freedom of decryption. Information Processing Letters, 2003. J. Millen and V. Shmatikov. Constraint solving for bounded-process cryptographic protocol analysis. In Proc. of the 8th ACM Conference on Computer and Communications Security (CCS’01), 2001. J. Millen and V. Shmatikov. Symbolic protocol analysis with products and difﬁe-hellman exponentiation. In Proc. of the 16th IEE Computer Seurity Foundation Workshop (CSFW’03), 2003. L. Paulson. The inductive approach to verifying cryptographic protocols. Journal of Computer Security, 6(1):85–128, 1998. M. Rusinowitch and M. Turuani. Protocol insecurity with ﬁnite number of sessions is NPcomplete. In Proc. of the 14th Computer Security Foundations Workshop (CSFW’01), pages 174–190. IEEE Computer Society Press, 2001. S. A. Schneider. Security properties and CSP. In Proc. of the Symposium on Security and Privacy, pages 174–187. IEEE Computer Society Press, 1996. S. Schneider. Verifying authentication protocols with CSP. In Proc. of the 10th Computer Security Foundations Workshop (CSFW’97). IEEE Computer Society Press, 1997. V. Shmatikov and D.J.D Hughes. Deﬁning Anonymity and Privacy (extended abstract). In Proc. of the Workshop on Issues in the Theory of Security (WITS ’02), 2002. J. Thayer, J. Herzog, and J. Guttman. Strand spaces: proving security protocols correct. IEEE Journal of Computer Security, 7:191–230, 1999. 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 337–352. Springer-Verlag, 2005. 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, CADE’99, volume 1632 of LNCS, pages 378–382, 1999.

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. doi:10.3233/978-1-60750-714-7-13

13

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 nonatomic 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 veriﬁcation problem is undecidable [13] even in the restricted 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 practical veriﬁcation 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 simpliﬁed. The main result of this chapter states that for a ﬁxed number of interleaved protocol 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 properties of cryptographic primitives can be covered by the approach ([5,6]). The result we

14

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

present here can also be derived through a constraint solving approach and the careful design of simpliﬁcation rules to be applied to intruder constraints ([8]). Although this result is of a theoretical ﬂavor, it gives information of practical relevance 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 intruder 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 principal are speciﬁed 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 modiﬁcations. 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 represented 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

Decomposition rules 𝐿𝑑 (⟨𝑎, 𝑏⟩) :

𝐿𝑑 ({∣𝑎∣}a𝐾 ) : 𝐿𝑑 ({∣𝑎∣}s𝑏 ) :

⟨𝑎, 𝑏⟩ → 𝑎, 𝑏, ⟨𝑎, 𝑏⟩ {∣𝑎∣}a𝐾 , 𝐾 −1 → {∣𝑎∣}a𝐾 , 𝐾 −1 , 𝑎

15

Composition rules 𝐿𝑐 (⟨𝑎, 𝑏⟩) : 𝐿𝑐 ({∣𝑎∣}a𝐾 ) :

{∣𝑎∣}s𝑏 , 𝑏 → {∣𝑎∣}s𝑏 , 𝑏, 𝑎 𝐿𝑐 ({∣𝑎∣}s𝑏 ) : Table 1. Intruder Rules

𝑎, 𝑏 → 𝑎, 𝑏, ⟨𝑎, 𝑏⟩ 𝑎, 𝐾 → 𝑎, 𝐾, {∣𝑎∣}a𝐾 𝑎, 𝑏 → 𝑎, 𝑏, {∣𝑎∣}s𝑏

2.2. Intruder In the Dolev Yao model [10] the intruder has the ability to eavesdrop, divert and memorize 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 modiﬁes them and forwards them to the receiver under the identity of the ofﬁcial sender. In other words all communications are mediated by a hostile environment represented 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 messages. 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 remaining 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 deﬁned 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 reﬂexive and transitive closure of →. We denote the application 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 sequence 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 inﬁnitely many data only known to him with simple encryptions. For instance he can construct an inﬁnite sequence of terms only s { s }s known to him, like e.g. {∣𝑁 ∣}𝑁 , {∣𝑁 ∣}𝑁 𝑁 , ... 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:

16

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity a

s

𝑡𝑒𝑟𝑚 ::= 𝑉 𝑎𝑟 ∣ 𝐴𝑡𝑜𝑚𝑠 ∣ ⟨𝑡𝑒𝑟𝑚, 𝑡𝑒𝑟𝑚⟩ ∣ {∣𝑡𝑒𝑟𝑚∣}𝐾𝑒𝑦𝑠 ∣ {∣𝑡𝑒𝑟𝑚∣}𝑡𝑒𝑟𝑚 As for messages, a signature usually denoted as [𝑀 ]𝑘′ with a private key 𝑘 ′ ∈ 𝐾𝑒𝑦𝑠 a is here represented as {∣𝑀 ∣}𝑘′ . 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 𝜎 deﬁned 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, 𝐸𝜎 = {𝑡𝜎 ∣ 𝑡 ∈ 𝐸}. A principal (except the initiator) reply after receiving a message matching a speciﬁed 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 speciﬁcation. 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 speciﬁed 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 speciﬁcation 𝑃 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 𝜋 deﬁnes 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 corresponding message 𝑆𝜄 𝜎 when 𝑅𝜄 𝜎 is present. One can remark that principals are not allowed to generate any new data such as nonces. But this is not a problem when the number of sessions is ﬁnite: in this setting from the operational point it is equivalent to assume that the new data generated by a principal during a protocol execution is part of his initial knowledge.

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

A

17

B }a { a {∣𝑘∣}𝐾 −1

𝐾𝐵

𝐴

s

{∣𝑠∣}𝑘

Figure 1. Handshake Protocol

Example: Handshake protocol We recall this simple protocol (from Chapter “Introduction” ) and its presentation by −1 a message sequence chart. 𝑘 is a symmetric key, 𝐾𝐵 a public key, 𝐾𝐴 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 { a ((A,1), 𝐼𝑛𝑖𝑡 ⇒ {∣𝑘∣}𝐾 −1 ) 𝐴 𝐾𝐵 }a { a s ⇒ {∣𝑠∣}𝑥 ) ((B,1), {∣𝑥∣}𝐾 −1 𝐴

𝐾𝐵

2.4. Attacks: Passive and active cases Considering a protocol speciﬁcation 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. Deﬁnition 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(𝐸).

18

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

The existence of a passive attack can be reduced to a deduction problem: Deﬁnition 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 now the 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 uniﬁes 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 (deﬁned 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 modify 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 deﬁnition of an attack using the predicate forge: Deﬁnition 3 (active attack) Given a protocol 𝑃 = {𝑅𝜄′ ⇒ 𝑆𝜄′ ∣ 𝜄 ∈ ℐ}, a secret message 𝑆𝑒𝑐𝑟𝑒𝑡 and assuming the intruder has initial knowledge 𝑆0 , an active attack (or an attack in short) is described by a ground substitution 𝜎 and a correct execution order 𝜋 : ℐ ′ −→ 1, . . . , 𝑘 such that for all 𝑖 = 1, . . . , 𝑘, we have 𝑅𝑖 𝜎 ∈ forge(𝑆0 , 𝑆1 𝜎, .., 𝑆𝑖−1 𝜎) and 𝑆𝑒𝑐𝑟𝑒𝑡 ∈ forge(𝑆0 , 𝑆1 𝜎, .., 𝑆𝑘 𝜎) where 𝑅𝑖 = 𝑅𝜋′ −1 (𝑖) and 𝑆𝑖 = 𝑆𝜋′ −1 (𝑖) . The deﬁnition 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 impersonate 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 from two handshake protocol sessions running in parallel. This system can be considered as a single session for a protocol admitting 4 steps speciﬁed below: }a { a ((A,1), 𝐼𝑛𝑖𝑡 ⇒ {∣𝑘𝐴,𝐶 ∣}𝐾 −1 ) 𝐴 𝐾𝐶 }a { a s ⇒ {∣𝑠𝐴,𝐶 ∣}𝑥 ) ((C,1), {∣𝑥∣}𝐾𝐴−1 𝐾𝐶 }a { a ) ((A,1’), 𝐼𝑛𝑖𝑡 ⇒ {∣𝑘𝐴,𝐵 ∣}𝐾 −1 𝐴 𝐾𝐵 } { ′ a a s ⇒ {∣𝑠𝐴,𝐵 ∣}𝑥′ ) ((B,1’), {∣𝑥 ∣}𝐾 −1 𝐴

𝐾𝐵

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

A

C

19

B

}a { a {∣𝑘𝐴,𝐶 ∣}𝐾 −1 𝐴

𝐾𝐶

}a { a {∣𝑘𝐴,𝐶 ∣}𝐾 −1 𝐴

𝐾𝐵

s

{∣𝑠𝐴,𝐵 ∣}𝑘𝐴,𝐶

Figure 2. Attack on Simple Protocol −1 We assume that the initial intruder knowledge is 𝑆0 = {𝐾𝐵 , 𝐾𝐴, 𝐾𝐶 , 𝐾𝐶 , 𝐼𝑛𝑖𝑡}. 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 𝜎 ∈ forge(𝑆0 )   ⎨ 𝜋 (1) 𝑅𝜋−1 (2) 𝜎 ∈ forge(𝑆0 , 𝑆𝜋−1 (1) 𝜎) 𝑅 −1 𝜎 ∈ forge(𝑆0 , 𝑆𝜋−1 (1) 𝜎, 𝑆𝜋 −1 (2) 𝜎)   ⎩ 𝜋 (3) 𝑠𝐴,𝐵 ∈ forge(𝑆0 , 𝑆𝜋−1 (1) 𝜎, 𝑆𝜋 −1 (2) 𝜎, 𝑆𝜋−1 (3) 𝜎) This can be veriﬁed easily. For instance, the last relation is valid since −1 ∈ 𝑆0 𝐾𝐴 , 𝐾 𝐶

}a { 𝑆𝜋−1 (1) 𝜎 = {∣𝑘𝐴,𝐶 ∣}a𝐾 −1 𝐴

𝐾𝐶

𝑆𝜋−1 (3) 𝜎 = {∣𝑠𝐴,𝐵 ∣}a𝑘𝐴,𝐶

}a { a s −1 𝐾𝐴 , 𝐾𝐶 , {∣𝑘𝐴,𝐶 ∣}𝐾 −1 , {∣𝑠𝐴,𝐵 ∣}𝑘𝐴,𝐶 𝐴 𝐾 𝐶 }a { a s a −1 → 𝐾 𝐴 , 𝐾𝐶 , {∣𝑘𝐴,𝐶 ∣}𝐾 −1 , {∣𝑠𝐴,𝐵 ∣}𝑘𝐴,𝐶 , {∣𝑘𝐴,𝐶 ∣}𝐾 −1 𝐴 𝐴 𝐾 𝐶 }a { a s a −1 → 𝐾𝐴 , 𝐾𝐶 , {∣𝑘𝐴,𝐶 ∣}𝐾 −1 , {∣𝑠𝐴,𝐵 ∣}𝑘𝐴,𝐶 , {∣𝑘𝐴,𝐶 ∣}𝐾 −1 , 𝑘𝐴,𝐶 𝐴 𝐴 𝐶 }𝐾 { a a s a −1 → 𝐾𝐴 , 𝐾𝐶 , {∣𝑘𝐴,𝐶 ∣}𝐾 −1 , {∣𝑠𝐴,𝐵 ∣}𝑘𝐴,𝐶 , {∣𝑘𝐴,𝐶 ∣}𝐾 −1 , 𝑘𝐴,𝐶 , 𝑠𝐴,𝐵 𝐴

𝐾𝐶

𝐴

and

20

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

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 symmetric key 𝐾𝑎𝑏 to be used by 𝐴 and 𝐵 for further safe communications. We have extended the protocol with an extra step where 𝐴 uses the key 𝐾𝐴𝐵 to send a secret message to 𝐵. In the attack, 𝐴 will be fooled into believing that the term ⟨𝑀, 𝐴, 𝐵⟩ (shorthand for ⟨⟨𝑀, 𝐴⟩, 𝐵⟩) is in fact the new key. The sequence of messages deﬁning OtwayRees is depicted in Figure 3. Let us write now this protocol speciﬁcation with our notation, with 𝑚𝐴𝐵 as a short-hand for ⟨𝑥7 , 𝑥𝐴 , 𝑥𝐵 ⟩. ((𝐴, 1), ((𝐵, 1), ((𝑆, 1), ((𝐵, 2), ((𝐴, 2), ((𝐵, 3),

𝐼𝑛𝑖𝑡 ⟨𝑥2 , 𝑥3 , 𝐵⟩, 𝑥4 s s 𝑚𝐴𝐵 , {∣𝑥8 , 𝑚𝐴𝐵 ∣}𝐾𝐴𝑆 , {∣𝑥9 , 𝑚𝐴𝐵 ∣}𝐾𝐵𝑆 s s 𝑚𝐴𝐵 , {∣𝑥8 , 𝑚𝐴𝐵 ∣}𝐾𝐴𝑆 , {∣𝑥9 , 𝑚𝐴𝐵 ∣}𝐾𝐵𝑆 s 𝑥2 , 𝑥5 , {∣𝑁𝐵 , 𝑥6 ∣}𝐾𝐵𝑆 s 𝑀, {∣𝑁𝐴 , 𝑥1 ∣}𝐾𝐴𝑆 s {∣𝑆𝑒𝑐𝑟𝑒𝑡∣}𝑥6

s

⇒ ⟨𝑀, 𝐴, 𝐵⟩, {∣𝑁𝐴 , ⟨𝑀, 𝐴, 𝐵⟩∣}𝐾𝐴𝑆 s ⇒ 𝑥2 , 𝑥3 , 𝐵, 𝑥4 , {∣𝑁𝐵 , 𝑥2 , 𝑥3 , 𝐵∣}𝐾𝐵𝑆 s s ⇒ 𝑥7 , {∣𝑥8 , 𝐾𝑎𝑏 ∣}𝐾𝐴𝑆 , {∣𝑥9 , 𝐾𝑎𝑏 ∣}𝐾𝐵𝑆 s s ⇒ 𝑥7 , {∣𝑥8 , 𝐾𝑎𝑏 ∣}𝐾𝐴𝑆 , {∣𝑥9 , 𝐾𝑎𝑏 ∣}𝐾𝐵𝑆 ⇒ 𝑥2 , 𝑥5 s ⇒ {∣𝑆𝑒𝑐𝑟𝑒𝑡∣}𝑥1 ⇒ 𝑒𝑛𝑑

) ) ) ) ) ) )

A protocol execution can be obtained by taking the protocol steps in the given order and by applying the following substitution:

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

𝑥1 = 𝐾𝑎𝑏 𝑥2 = 𝑀 𝑥3 = 𝐴 s 𝑥4 = {∣⟨𝑁𝐴 , ⟨𝑀, 𝐴, 𝐵⟩⟩∣}𝐾𝐴𝑆

s

𝑥5 = {∣𝑥8 , 𝐾𝑎𝑏 ∣}𝐾𝐴𝑆 𝑥7 = 𝑀 𝑥8 = 𝑁𝐴

𝑥6 = 𝐾𝑎𝑏 𝑥9 = 𝑁𝐵

21

𝑥𝐴 = 𝐴 𝑥𝐵 = 𝐵

An attack can be performed on this protocol with initial intruder knowledge 𝑆0 = {𝐶ℎ𝑎𝑟𝑙𝑖𝑒, 𝐼𝑛𝑖𝑡}, using: Substitution 𝜎 = [𝑥1 ← ⟨𝑀, 𝐴, 𝐵⟩]

Protocol steps 𝜋(𝐴, 1) = 1, 𝜋(𝐴, 2) = 2

since we have: ⎧ ⎨ 𝑅𝜋 −1 (1) 𝜎 ∈ forge(𝑆0 ) 𝑅 −1 𝜎 ∈ forge(𝑆0 , 𝑆𝜋−1 (1) 𝜎) ⎩ 𝜋 (2) 𝑆𝑒𝑐𝑟𝑒𝑡 ∈ forge(𝑆0 , 𝑆𝜋−1 (1) 𝜎, 𝑆𝜋−1 (2) 𝜎) 3. Passive case In this section we show how to decide efﬁciently 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 𝑣𝑠 = ⟨𝑣𝑒 , 𝑏⟩} 𝑢𝑝 s a ℰ2 = {𝑣𝑠 −→ 𝑣𝑒 ∣ ∃𝑏, 𝑣𝑠 = {∣𝑏∣}𝑣𝑒 or 𝑣𝑠 = {∣𝑏∣}𝑣𝑒 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 deﬁne 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 difference 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 4. Now, why do we deﬁne the DAG size for terms ? First, because it is a way to represent 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. Consequently, 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 deﬁnition :

22

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

𝐾𝑎𝑠 s

{∣_∣}_ ⟨_, _⟩

𝐵 ⟨_, _⟩

⟨_, _⟩

𝐴 ⟨_, _⟩

𝑁𝑎

𝑀

Figure 4. DAG Representation of the First Message of Otway-Rees Protocol

Deﬁnition 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 deﬁnitions 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. Deﬁnition 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 preﬁx of 𝐷 containing 𝑡. We will consider particular derivations minimal in length : Deﬁnition 6 We denote 𝐷𝑒𝑟𝑖𝑣𝑡 (𝐸) a derivation of minimal length among the derivations 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 𝐸

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

23

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 / 𝐸) Moreover, by minimality all 𝐿𝑑 (𝑣) ∈ 𝐷1 , 𝑣 is a subterm of 𝐸. (Note: 𝑝 > 1 since 𝑡′ ∈ of 𝐷 we have 𝐿𝑐 (𝑡′ ) ∕∈ 𝐷. Therefore, 𝑡′ has necessarily be obtained by a decomposition rule in 𝐷1 , i.e. there exists a term 𝑢 with 𝑡′ subterm of 𝑢 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 a allowed as pointed above; Decomposition of {∣𝑢∣}𝑡′−1 is not allowed because 𝑡′ is not an s atom (since it is composed), and thus not in 𝐾𝑒𝑦𝑠; Decomposition of {∣𝑢∣}𝑡′ 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 𝐸1 .. →𝐿𝑛 𝐸𝑛 then for all 1 ≤ 𝑖 ≤ 𝑛, 𝐸𝑖 ⊆ 𝑆𝑢𝑏(𝐸𝑖 ) ⊆ 𝑆𝑢𝑏(𝑡, 𝐸). Proof: Let 𝐷𝑒𝑟𝑖𝑣𝑡 (𝐸) = 𝐸 →𝐿1 ... →𝐿𝑛 𝐸𝑛 . By deﬁnition 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 Algorithm 1, and assumes a representation of 𝑆𝑢𝑏(𝐸, 𝑡) as a DAG: anyway the DAG can be computed in polynomial time from inputs given in standard tree representations.

24

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26:

INPUTS: 𝐸, 𝑡 represented by a DAG for 𝑆𝑢𝑏(𝐸, 𝑡) 𝐾1 ← 𝐸 𝐾0 ← 𝑆𝑢𝑏(𝐸, 𝑡) ∖ 𝐸 repeat 𝐶←∅ for all 𝑒 ∈ 𝑆𝑢𝑏(𝐸, 𝑡) do s a if 𝑒 ∈ 𝐾0 , and 𝑙, 𝑟 ∈ 𝐾1 , with 𝑒 = {∣𝑙∣}𝑟 or 𝑒 = {∣𝑙∣}𝑟 or 𝑒 = ⟨𝑙, 𝑟⟩ then 𝐾0 ← 𝐾0 ∖ {𝑒} 𝐾1 ← 𝐾1 ∪ {𝑒} 𝐶 ← 𝐶 ∪ {𝑒} end if s a if 𝑒 ∈ 𝐾1 , 𝑙 ∈ 𝐾0 , 𝑟 ∈ 𝐾1 , with 𝑒 = {∣𝑙∣}𝑟 or 𝑒 = {∣𝑙∣}𝑟 then 𝐾0 ← 𝐾0 ∖ {𝑙} 𝐾1 ← 𝐾1 ∪ {𝑙} 𝐶 ← 𝐶 ∪ {𝑙} end if if 𝑒 ∈ 𝐾1 with 𝑒 = ⟨𝑙, 𝑟⟩ then 𝐾1 ← 𝐾1 ∪ {𝑙, 𝑟} end if end for until 𝐶 = ∅ or 𝑡 ∈ 𝐾1 if 𝑡 ∈ 𝐾1 then True else False 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 efﬁcient 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:

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity s

25

a

∙ for 𝑠 = {∣𝑒∣}𝑏 or 𝑠 = {∣𝑒∣}𝑏 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 satisﬁable iff 𝑡 cannot be derived by intruder rules from 𝐸. There exists a linear algorithm by Dowling and Gallier [11] to test the satisﬁability 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 Deﬁnition 4) can always be constructed from subterms that are already occurring in the problem speciﬁcation. 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 deﬁne 𝑅𝑖 = 𝑅𝜋′ −1 (𝑖) and 𝑆𝑖 = 𝑆𝜋′ −1 (𝑖) for 𝑖 = 1, . . . , 𝑘. Note that 𝑅′ , 𝑆 ′ now replace 𝑅, 𝑆 for readability, unlike previous sections. We also deﬁne: 𝒮𝒫 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 speciﬁcation. 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 protocol’s 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 application 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 deﬁnition of 𝐷𝑒𝑟𝑖𝑣𝛾 (𝐸), since it already contains

26

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

a composition of 𝛾. Hence 𝐷′ build 𝑡 from 𝐸, satisﬁes 𝐿𝑑 (𝛾) ∈ / 𝐷 ′ , 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 deﬁnition 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 deﬁnition 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 derivation. We note that 𝑠 ∈ / 𝐴𝑡𝑜𝑚𝑠 (by deﬁnition 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 deﬁned 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 𝐸0 →𝐿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 𝛿.

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity a

27

s

∗ If 𝐿𝑖 = 𝐿𝑑 (𝑡) with 𝑡 = ⟨𝛼, 𝛽⟩ or 𝑡 = {∣𝛼∣}𝛽 or 𝑡 = {∣𝛼∣}𝛽 , then 𝑠 ∕= 𝑡 by construction 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, (𝜎′ , 𝜋) deﬁnes an attack. However, this violates the minimality of (𝜎, 𝜋) as a normal attack (see Deﬁnition 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 procedure 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 presented 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 speciﬁcation {(𝜄, 𝑅𝜄′ ⇒ 𝑆𝜄′ ) ∣ 𝜄 ∈ ℐ}. 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 Algorithm 2. We discuss its correctness and complexity below, ﬁrst for a single session then for the several ones.

28

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

1: 2: 3: 4: 5: 6: 7:

INPUTS: Protocol speciﬁcation 𝑃 , set of terms 𝑆0 , and term 𝑆𝑒𝑐𝑟𝑒𝑡. Guess a correct execution order 𝜋 : ℐ ′ −→ {1, .., 𝑘} with 𝑘 = ∣ℐ ′ ∣ Guess a ground substitution 𝜎 such that ∣𝑉 𝜎∣𝐷𝐴𝐺 ≤ ∣𝑃 ∣𝐷𝐴𝐺 Let 𝑅𝑖 = 𝑅𝜋′ −1 (𝑖) and 𝑆𝑖 = 𝑆𝜋′ −1 (𝑖) for 𝑖 ∈ {1..𝑘} Let 𝑅𝑘+1 be 𝑆𝑒𝑐𝑟𝑒𝑡. For each 𝑖 ∈ {1..𝑘 + 1}, check that 𝑅𝑖 𝜎 ∈ forge({𝑆𝑗 𝜎 ∣ 𝑗 < 𝑖} ∪ {𝑆0 }) using Algorithm 1 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 deﬁnes 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, deﬁning a correct execution order and a ground substitution which are possible guesses for the algorithm since the passive attack decision algorithm is complete. On the other hand if the procedure answers YES, the veriﬁcation 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 speciﬁcation 𝑃 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 deﬁnition. Also variables from different sessions should be different. This is because we consider that

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

29

in this model messages are not memorized from one session to another (except maybe by the intruder). Therefore we shall deﬁne 𝑚 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 deﬁnition the union 𝑖 of the steps in all copies 𝑖=1 𝑊∪ ∪ 𝑚 𝑃𝑖 , for 𝑖 = 1..𝑚. The partial order on 𝑚 𝑊 is deﬁned as 𝑖 𝑖=1 𝑖=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 speciﬁcation 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 speciﬁcation. variables are 𝑥1 , .., 𝑥𝑛 = − ⋀ The 𝜀propositional 𝜀𝑖,2 𝜀𝑖,3 𝑖,1 → − and an instance of 3-SAT is 𝑓 ( 𝑥 ) = 𝑖∈𝐼 (𝑥𝑖,1 ∨𝑥𝑖,2 ∨𝑥𝑖,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. ⊥).

30

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

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 term ⊥ for representing the boolean value False. The encryption by 𝐾 will encode s negation, and thus, the boolean value True}is represented by ⊤ = {∣⊥∣}𝐾 . This coding { s s of 3-SAT do not requires e.g. that {∣⊥∣}𝐾 𝐾 reduce to ⊥, so multiple encryption with 𝐾 over ⊥ do not represent any speciﬁc boolean value. The symmetric key 𝑃 exists for storing data under process. Then we deﬁne : ∙ 𝑔(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. s → → → Principal A: (𝐴, 1), 𝑥1 , .., 𝑥𝑛 ⇒ {∣⟨𝑓1 (− 𝑥 ), ⟨𝑓2 (− 𝑥 ), ⟨.., ⟨𝑓𝑛 (− 𝑥 ), 𝑒𝑛𝑑⟩⟩⟩⟩∣}𝑃

Principal B: (𝐵, 𝑖),

} { ⟨⟨{∣⊥∣}s , ⟨𝑥, 𝑦⟩⟩, 𝑧⟩ s ⇒ {∣𝑧∣}s 𝐾 𝑃 𝑃

for 𝑖 ∈ 𝐼.

Principal C: (𝐶, 𝑖),

} { ⟨⟨𝑥, ⟨{∣⊥∣}s , 𝑦⟩⟩, 𝑧⟩ s ⇒ {∣𝑧∣}s 𝐾 𝑃 𝑃

for 𝑖 ∈ 𝐼.

Principal D: (𝐷, 𝑖),

} { ⟨⟨𝑥, ⟨𝑦, {∣⊥∣}s ⟩⟩, 𝑧⟩ s ⇒ {∣𝑧∣}s 𝐾 𝑃 𝑃

for 𝑖 ∈ 𝐼.

s

Principal E: (𝐸, 1), {∣𝑒𝑛𝑑∣}𝑃 ⇒ 𝑆𝑒𝑐𝑟𝑒𝑡 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, s there is an attack iff the message sent by principal A can be reduced to {∣𝑒𝑛𝑑∣}𝑃 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 problem of ﬁ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 obtain 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 sequential protocol is already an NP-hard problem. Therefore the non-determinism of the intruder is sufﬁcient for the insecurity problem to be NP-hard.

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

31

⋀𝑚 → Let 𝑓 (− 𝑥 ) = 𝑖=1 𝐷𝑗 be an instance of 3-SAT following the same deﬁnition 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: { s }s { s }s → 𝑥 1. {∣𝑃 ∣} , {∣𝑃 ∣} , and 𝑃 . The intruder will assign boolean values to − ⊥

𝐾

s

⊤

𝐾 s

{∣𝑃 ∣}⊤ . by using {∣𝑃 ∣}⊥ or{ { s }s s }s → 2. {∣𝐾∣}⊥ 𝑉𝑗 and {∣𝐾∣}⊤ 𝑉𝑗 , for 𝑗 = 1..𝑛. These are faked values for − 𝑥 allowing 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 s s intruder does not know 𝐾, these values can only be {∣𝑃 ∣}⊥ or {∣𝑃 ∣}⊤ . For each conjunct indices 𝑖 , 1 ≤ 𝑖 ≤ 𝑚, and for each 𝑗 , 1 ≤ 𝑗 ≤ 𝑛, such that 𝑥𝑗 is a variable in the conjunct 𝐷𝑖 , let us deﬁne 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 ors der to decrypt at least one message {∣𝑆𝑒𝑐𝑟𝑒𝑡𝑖 ∣}𝑦 for each 𝑖. However the intruder has { s }s only two possible actions: either he sends to 𝐴 the message {∣𝐾∣}⊤ 𝑉𝑗 or the mes{ s }s s but then he will receive back {∣𝑆𝑒𝑐𝑟𝑒𝑡𝑖 ∣} which is useless (this step sage {∣𝐾∣} ⊥

𝐾

𝑉𝑗

can } } for the intruder), or he has assigned to 𝑉𝑗 the correct value { as blank { be sconsidered {∣𝑃 ∣} 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: }s { .. . (𝐴, (𝑚 + 1, 0)) : 𝑃 ⇒ ..{∣𝐵𝑖𝑔𝑆𝑒𝑐𝑟𝑒𝑡∣}s 𝑆𝑒𝑐𝑟𝑒𝑡1

𝑆𝑒𝑐𝑟𝑒𝑡𝑚

Therefore, the intruder knows 𝐵𝑖𝑔𝑆𝑒𝑐𝑟𝑒𝑡 if and only if each conjunct 𝐷𝑗 is evaluated to ⊤, and this protocol has an attack on 𝐵𝑖𝑔𝑆𝑒𝑐𝑟𝑒𝑡 if and only if the 3-SAT instance 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).

32

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

Decomposition rules Composition rules ˛ ˛¯s ˘˛ ˘˛ s ˛¯s ˛ 𝐿𝑠 (𝑡) : 𝑡 → 𝑎, 𝑡 with 𝑡 = {∣𝑎∣}𝑏 𝑏 𝐿𝑟 (𝑡) : 𝑎 → 𝑎, 𝑡 with 𝑡 = ˛{∣𝑎∣}s𝑏 ˛ 𝑏 ˛ ˛¯a ¯ ˘˛ ˘˛ a 𝐿𝑠 (𝑡) : 𝑡 → 𝑎, 𝑡 with 𝑡 = ˛{∣𝑎∣}a𝐾 ˛ 𝐾 −1 𝐿𝑟 (𝑡) : 𝑎 → 𝑎, 𝑡 with 𝑡 = ˛{∣𝑎∣}a𝐾 ˛ 𝐾 −1 Table 2. 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 NPcomplete 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 supposed 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 2 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 a ((𝐴, 0), 𝑖𝑛𝑖𝑡 ⇒ {∣𝑆𝑒𝑐𝑟𝑒𝑡∣}𝑃 ((𝐴, 1), {∣𝑥∣}a𝐾 −1 ⇒ 𝑥) { }a ((𝐴, 2), {∣𝑦∣}a𝑃 𝐾 ⇒ 𝑦) since and and

Attack }a { 𝜎(𝑥) = {∣𝑆𝑒𝑐𝑟𝑒𝑡∣}a𝑃 𝐾 𝜎(𝑦) = 𝑆𝑒𝑐𝑟𝑒𝑡

}a }a {{ {∣𝑆𝑒𝑐𝑟𝑒𝑡∣}a𝑃 →𝐿𝑟 {∣𝑆𝑒𝑐𝑟𝑒𝑡∣}a𝑃 , {∣𝑆𝑒𝑐𝑟𝑒𝑡∣}a𝑃 𝐾 𝐾 −1 { a }a (𝐴, 1) produces {∣𝑆𝑒𝑐𝑟𝑒𝑡∣}𝑃 𝐾 (𝐴, 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 encryption 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 𝐿𝑑 , allowing 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 properties like authentication, integrity, some kinds of fairness, etc.. can also be expressed using an appropriate execution order and a polynomial number of forge constraints. Thus, they can also be detected in NP time.

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

No bounds [13] Inﬁnite number of sessions, and bounded messages [12]

Without Nonces

With Nonces

Undecidable

Undecidable

DEXPTIME-complete

Finite number of sessions, and unbounded messages Table 3. Known results

NP-complete

33

Undecidable NP-complete

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 inequalities, especially inequalities between data obtained from the intruder, all the constraints are satisﬁed 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 3. 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 380–394. Springer-Verlag, 2000. [2] A. Armando, D. Basin, Y. Boichut, Y. Chevalier, L. Compagna, J. Cuellar, P. Hankes Drielsma, P.-C. Héam, O. Kouchnarenko, J. Mantovani, S. Mödersheim, 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 Conference on Computer Aided Veriﬁcation, CAV’2005, volume 3576 of Lecture Notes in Computer Science, pages 281–285, 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: CSFW’99, pages 55–69. IEEE Computer Society Press, 1999. [4] Y. Chevalier. Résolution de problèmes d’accessibilité pour la compilation et la validation de protocoles cryptographiques. Phd thesis, Université Henri Poincaré, Nancy, deecember 2003. [5] Y. Chevalier, R. Küsters, M. Rusinowitch, and M. Turuani. An NP Decision Procedure for Protocol Insecurity with XOR. In Proceedings of the Logic In Computer Science Conference, LICS’03, pages 261–270, 2003. http://www.avispa-project.org. [6] Y. Chevalier, R. Küsters, M. Rusinowitch, M. Turuani, and L. Vigneron. Deciding the Security of Protocols with Difﬁe-Hellman Exponentiation and Products in Exponents. In Proceedings of FSTTCS’2003, 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 87–106. 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.

34 [9] [10] [11] [12] [13] [14] [15]

[16]

[17] [18] [19] [20]

[21] [22]

M. Rusinowitch and M. Turuani / Verifying a Bounded Number of Sessions and Its Complexity

R. Corin and S. Etalle. An Improved Constraint-Based System for the Veriﬁcation of Security Protocols. In Proceedings of SAS 2002, LNCS 2477, pages 326–341. Springer-Verlag, 2002. D. Dolev and A. Yao. On the Security of Public-Key Protocols. IEEE Transactions on Information Theory, 2(29), 1983. W. F. Dowling and J. H. Gallier. Continuation semantics for ﬂowgraph equations. Theor. Comput. Sci., 44:307–331, 1986. 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. S. Even and O. Goldreich. On the security of multi-party ping-pong protocols. Foundations of Computer Science, Annual IEEE Symposium on, 0:34–39, 1983. A. Huima. Efﬁcient inﬁnite-state analysis of security protocols. In Proceedings of the FLOC’99 Workshop on Formal Methods and Security Protocols (FMSP’99), 1999. 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 131–160. SpringerVerlag, 2000. Z. Liang and R. M. Verma. Correcting and Improving the NP Proof for Cryptographic Protocol Insecurity. In Information Systems Security, 5th International Conference, ICISS 2009, Kolkata, India, December 14-18, 2009, Proceedings, volume 5905 of Lecture Notes in Computer Science, pages 101–116. Springer, 2009. F. Martinelli and T. C. N. R. Analysis of security protocols as open systems. Theoretical Computer Science, 290:1057–1106, 2003. J. K. Millen and G. Denker. Capsl and mucapsl. Journal of Telecommunications and Information Technology, 4:16–27, 2002. J. K. Millen and V. Shmatikov. Constraint solving for bounded-process cryptographic protocol analysis. In ACM Conference on Computer and Communications Security, pages 166–175, 2001. 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. M. Turuani. Sécurité des Protocoles Cryptographiques: Décidabilité et Complexité. Phd thesis, Université Henri Poincaré, Nancy, december 2003. M. Turuani. The CL-Atse Protocol Analyser. In Term Rewriting and Applications - Proc. of RTA, volume 4098 of Lecture Notes in Computer Science, pages 277–286, Seattle, WA, USA, 2006.

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. doi:10.3233/978-1-60750-714-7-35

35

Constraint solving techniques and enriching the model with equational theories Hubert COMON-LUNDH a and Stéphanie 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 inﬁnite set of possible executions of a ﬁnite protocol, in presence of an arbitrary active attacker. Solving a derivability constraint consists in computing a simpliﬁed representation of such executions, which is amenable to the veriﬁcation of any (trace) security property. Our goal is to explain this method on a non-trivial combination of primitives. In this chapter we explain how to model the protocol executions using derivability constraints, and how such constraints are interpreted, depending on the cryptographic primitives and the assumed attacker capabilities. Such capabilities are represented as a deduction system that has some speciﬁc 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 attacker, 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 speciﬁes a set of roles, each of which is a template for a ﬁnite sequence of actions 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, depending 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 inﬁnitely many) possible instances 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 satisﬁability of the derivability constraints, together with the negation of the security goal. For instance, if the security goal is the conﬁdentiality of some data 𝑠, then the protocol is secure if the derivability contraints, together with the derivability of 𝑠, is unsatisﬁable. Hence, de-

36

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

ciding the satisﬁability of a derivability constraint (together with some other formula) yields, as a particular case, an alternative to the decision algorithm described in the previous 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 satisﬁability 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 pairing/unpairing. In principle, the same method can be applied to numerous other cryptographic primitives, adapting however the underlying set of simpliﬁcation rules. The procedure that we describe in this chapter is actually a generalization of the known procedures for such primitives [19,11]: we provide with a constraint simpliﬁcation 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 authentication 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 transformation rules that are applied to constraints until they are solved. The difﬁcult 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 brieﬂy. 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 intruder’s proof that is “optimal”, until the constraint is solved. Outline. In Section 2, we review the various ways of describing the intruder’s capabilities. 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 exposition 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

37

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 veriﬁcation 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 deﬁnitions. A typed version can be encoded using tags and possibly additional function symbols and rules. We assume 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 assumed 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𝑥2

𝑥2

𝑥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.

38

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

𝑥

𝑦

⟨𝑥, 𝑦⟩ 𝑥

𝑦

{∣𝑥∣}a𝑦 𝑥

𝑦 [𝑥]𝑦

(P)

(AE)

(S)

⟨𝑥, 𝑦⟩ 𝑥 {∣𝑥∣}apk(𝑦)

dk(𝑦) 𝑥

[𝑥]sk(𝑦)

⟨𝑥, 𝑦⟩

(U1 )

vk(𝑦) 𝑥

𝑦 (AD) (V)

𝑥 pk(𝑥) 𝑥 vk(𝑥)

(U2 ) (PK) (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 destructors. In particular, in a free algebra, decryption {∣𝑥∣}−s 𝑦 and projection 𝜋𝑖 (⟨𝑥, 𝑦⟩) operations 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 satisfactorily 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 deﬁned 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 deﬁne the derivability relation, denoted 𝑇 ⊢ 𝑢, that represents the intruder capability to derive a message 𝑢 from a set of available messages 𝑇 . Deﬁnition 1 (derivability relation) The derivability relation ⊢ is deﬁned 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 𝑇 ⊢ 𝑡; 𝑢1 . . . 𝑢𝑛 ∙ 𝑇 ⊢ 𝑠 if there is a deduction rule and a substitution 𝜎 such 𝑢 that 𝑠 = 𝑢𝜎 and 𝑇 ⊢ 𝑢𝑖 𝜎 for every 𝑖 ∈ {1, . . . , 𝑛}. Example 3 Let 𝑇 = {{∣𝑎∣}apk(𝑏) , vk(𝑏), [dk(𝑏)]sk(𝑏) }. Using the rules given in Example 1, we may model the deduction of 𝑎 from the set of terms 𝑇 as follows:

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

[dk(𝑏)]sk(𝑏) {∣𝑎∣}apk(𝑏)

39

vk(𝑏)

dk(𝑏) 𝑎

In many cases, equations like {∣{∣𝑥∣}s𝑦 ∣}−s 𝑦 = 𝑥 can be oriented to form term rewriting s −s rules, in this case {∣{∣𝑥∣}𝑦 ∣}𝑦 → 𝑥. 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 considered 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 inﬁnite (yet recursive) set of deduction rules, relying on an extended rewriting system. From now on, 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 equations): 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𝑏

𝑏 ⊕ {∣𝑐∣}s𝑏

𝑎⊕𝑏 𝑎

(XOR)

(SD)

(XOR)

40

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

Deduction rules: 𝑥1

⋅⋅⋅

𝑥𝑛

(𝑥1 ⊕ ⋅ ⋅ ⋅ ⊕ 𝑥𝑛 )↓ 𝑥1

𝑥2

⟨𝑥1 , 𝑥2 ⟩ 𝑥1

𝑥2

{∣𝑥1 ∣}s𝑥2 Rewrite rules:

(XOR) for any 𝑛 ∈ ℕ

(P)

(SE)

⟨𝑥1 , 𝑥2 ⟩ 𝑥1 {∣𝑥1 ∣}s𝑥2

𝑥2

𝑥1

𝑥⊕𝑥⊕𝑦 → 𝑦

⟨𝑥1 , 𝑥2 ⟩

(U1 )

𝑥2

(U2 )

(SD)

𝑥⊕𝑥 → 0

𝑥⊕0 → 𝑥

Equations: 𝑥1 ⊕ ⋅ ⋅ ⋅ ⊕ 𝑥𝑛 = 𝑥𝜏 (1) ⊕ ⋅ ⋅ ⋅ ⊕ 𝑥𝜏 (𝑛) for any 𝑛 ∈ ℕ and any permutation 𝜏 . Figure 1. Deduction rules, rewriting rules, and equations for encryption, pairing, and exclusive-or.

⎧ 𝑎 ⊕ {∣𝑐∣}s𝑏 𝑏 ⊕ {∣𝑐∣}s𝑏    (XOR)  ⎨ {∣𝑎∣}s 𝑎⊕𝑏 𝑎⊕𝑏 𝜋2 = (SD)   𝑎   ⎩ 𝑏

𝑎 ⊕ {∣𝑐∣}s𝑏

𝑏 ⊕ {∣𝑐∣}s𝑏

𝑎⊕𝑏

(XOR)

(XOR)

Now, it is easy to see that 𝑇 ⊢ 𝑐. 2.3. Proofs The intruder’s deductions are represented as tree proofs, as in the previous example. We formalize these notions here. Deﬁnition 2 (proof) A proof 𝜋 with respect to a set of deduction rules ℐ (and a convergent 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 𝑠 1 , . . . , 𝑠𝑛 ∈ ℐ and a substitution 𝜎 such that 𝑠𝑖 𝜎 = 𝑡𝑖 for every is a deduction rule 𝑠 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𝑏 {∣𝑐∣}s𝑏

𝑎

(XOR).

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

41

The instances of the deduction rules (U1 ), (U2 ), 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 subterm 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𝑐

𝑐

𝑎⊕𝑏

{∣𝑎∣}s𝑏 ⊕ 𝑏

(SD)

𝑏⊕𝑐

𝑐

{∣𝑎∣}s𝑏

(XOR)

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 deﬁne 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 useless 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 inference rules, there are also similar simpliﬁcation and gathering rules [24]. There is however 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 deﬁnition 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. Deﬁnition 3 (local proof) A local proof 𝜋 of 𝑇 ⊢ 𝑢 is a proof in which

42

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

𝑢1 ⋅ ⋅ ⋅ 𝑢𝑖 𝑢 𝑢𝑖+1 ⋅ ⋅ ⋅ 𝑢𝑗 𝑢 𝑢𝑗+1 ⋅ ⋅ ⋅ 𝑢𝑛 𝑣 ⇒ 𝑣 1 ⋅ ⋅ ⋅ 𝑣𝑚 𝑣

𝑢1 ⋅ ⋅ ⋅ 𝑢𝑖

(XOR)

(XOR) 𝑢1 ⋅ ⋅ ⋅ 𝑢𝑖 𝑢𝑖+1 ⋅ ⋅ ⋅ 𝑢𝑗 𝑢𝑗+1 ⋅ ⋅ ⋅ 𝑢𝑛 𝑣

𝑢𝑖+1 ⋅ ⋅ ⋅ 𝑢𝑛

𝑢 ⇒

(XOR) 𝑢1 ⋅ ⋅ ⋅ 𝑢𝑖 𝑣1 ⋅ ⋅ ⋅ 𝑣𝑚 𝑢𝑖+1 ⋅ ⋅ ⋅ 𝑢𝑛 𝑢

𝜋𝑖

𝜋

𝜋𝑖+1

𝑢1 ⋅ ⋅ ⋅ 𝑢𝑖

𝑢

𝑢𝑖+1 ⋅ ⋅ ⋅ 𝑢𝑛

𝜋1

𝜋𝑛

𝑢 𝜋

𝜋1

𝑢

𝑢1

⟨𝑢, 𝑢1 ⟩ 𝑢

(P)

⇒

(U1 )

𝜋1

𝜋

𝜋

𝑢1

𝑢

𝑢

⟨𝑢1 , 𝑢⟩ 𝑢

𝜋

𝜋1

𝑢

𝑢1

{∣𝑢∣}s𝑢1

(SE) 𝑢

𝜋1′ 𝑢1

(P) (U2 )

⇒ (SD)

(XOR)

𝜋

⇒

(XOR)

(XOR)

𝑢

⇒

𝜋 𝑢

𝜋 𝑢

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 decomposition or not.

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

43

1. If last(𝜋) is not a decomposition, either hyp(last(𝜋)) are subterms of its conclusion (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) 𝜋= 𝑢 / St(𝑢) for some 𝑖. with conc(𝜋𝑖 ) ∈ 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 assumption 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 normalisation 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 (U1 ) (or (U2 )), i.e. {𝜋 1 (Ui ) 𝜋= 𝑢 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 encryption symbol, last(𝜋1 ) must be either an instance of (SE) or a decomposi-

44

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

tion. The ﬁrst case is ruled out since 𝜋 is a normal proof, hence last(𝜋1 ) is a decomposition. 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, because 𝜋 is a normal proof. Therefore, if last(𝜋𝑗 ) is not a decomposition, then top(𝑢𝑗 ) ∕= ⊕. It must then be a subterm of some 𝑢𝑘 , 𝑘 ∕= 𝑗 (actually a strict subterm since 𝜋 is a normal proof). Thus, the maximal terms in {𝑢1 , . . . , 𝑢𝑛 } with respect to the subterm relation, are terms 𝑢𝑗 , such that last(𝜋𝑗 ) is a decomposition. 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 deciding 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: deﬁnitions and examples 3.1. Introduction with an example Consider the ﬂawed handshake protocol example described in Figure 3, temporarily returning 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 inﬁnite number of possible message instances. Hence the veriﬁcation 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

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

𝐴

∘ o

{∣[𝑘]sk(𝐴) ∣}apk(𝐵)

{∣𝑠∣}s𝑘

45

/ 𝐵

∘

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(𝑎) ∣}apk(𝑐) ). get({∣𝑥∣}s𝑘 ). 𝐵(𝑏, 𝑎) : 𝜈𝑠. get({∣[𝑧]sk(𝑎) ∣}apk(𝑏) ). 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 speciﬁed 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 possibly 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 network can be intercepted and modiﬁed 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 deﬁne a precise operational semantics of such a process algebra (see the chapter “Applied Pi Calculus”). It is not always sufﬁcient to consider a small system consisting of only one thread per role, for security analysis. Conditions under which such small systems are sufﬁcient 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 private: 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:

46

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

𝑇init = {pk(𝑎), pk(𝑏), pk(𝑐), vk(𝑎), vk(𝑏), vk(𝑐), dk(𝑐), sk(𝑐), 𝑎, 𝑏, 𝑐}. The next step is to construct the parallel composition of the two sessions. The parallel 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 intruder’s 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(𝑎) ∣}apk(𝑐) ), get({∣[𝑧]sk(𝑎) ∣}apk(𝑏) ), send({∣𝑠∣}s𝑧 ), get({∣𝑥∣}s𝑘 ) Is it solvable? There are two get actions, hence two derivation constraints: 𝒞=

⎧ ⎨ ⎩

?

𝑇init , {∣[𝑘]sk(𝑎) ∣}apk(𝑐) ⊢ {∣[𝑧]sk(𝑎) ∣}apk(𝑏) ?

𝑇init , {∣[𝑘]sk(𝑎) ∣}apk(𝑐) , {∣𝑠∣}s𝑧 ⊢ {∣𝑥∣}s𝑘

Note that the set of terms on the left of each derivation constraint is actually a union 𝑇init ∪ ..., but it simpliﬁes 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 satisﬁed by the substitution 𝜎 = {𝑧 → 𝑘, 𝑥 → 𝑠}. The fact that the second constraint is satisﬁed is obvious. Indeed, a normal proof of 𝑇init , {∣[𝑘]sk(𝑎) ∣}apk(𝑐) , {∣𝑠∣}s𝑘 ⊢ {∣𝑠∣}s𝑘 is actually reduced to a leaf. The fact that the ﬁrst constraint is satisﬁed takes some effort to see. A normal proof witnessing this fact is described below. {∣[𝑘]sk(𝑎) ∣}apk(𝑐)

sk(𝑐)

[𝑘]sk(𝑎)

pk(𝑏)

{∣[𝑘]sk(𝑎) ∣}apk(𝑏) 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 artiﬁcial 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 , ... ⊢ 𝑠.

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

47

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 satisﬁes 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 sufﬁcient. 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 generate a sufﬁcient 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 deﬁne the notion of a derivation constraint system, which is not speciﬁc to our set of primitives/deduction rules. Deﬁnition 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 satisﬁes 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.

48

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

Let us remark that the monotonicity and determinacy conditions imply two important properties: ∙ Origination: for every 𝑖 ∈ {1, . . . , 𝑛}, for every 𝑥 ∈ vars(𝑇𝑖 ), there must be a 𝑗 < 𝑖 such that 𝑥 ∈ vars(𝑢𝑗 ). In particular, we have that vars(𝑇1 ) = ∅. Indeed, / vars(𝑢) for any term 𝑢 that can be deduced from if 𝑥 ∈ / {𝑢1 , ⋅ ⋅ ⋅ , 𝑢𝑖−1 }, then 𝑥 ∈ {𝑢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 determinacy property, yielding a more general (yet less natural) deﬁnition 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 satisﬁes the origination and any instance of it also satisﬁes 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 simpliﬁcations. In order to keep the set of solutions, we may add existential quantiﬁers for these new variables, in front of a derivation constraint system. Actually, we may consider some additional formulas with only slight modiﬁcations 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 properties. The constraint solving algorithm is not modiﬁed, 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. Deﬁnition 5 (solution) Given a convergent set of rewrite rules (possibly modulo associativity 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 ⊢ ?

𝑢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 𝑢𝜎↓ = 𝑣𝜎↓.

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

49

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 𝜎 satisﬁes 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 particular, this implies that 𝑥1 , . . . , 𝑥𝑛 are distinct variables. Lemma 2 A solved constraint system has always at least one solution (actually, inﬁnitely 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 deﬁnes 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. membership) 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 introduction, we consider the derivation constraint system, together with the negation of these equalities. It is satisﬁable 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 sufﬁces to simplify the derivation constraints into solved forms (which may yield some replacements of the variables in the disequality part) and then check the satisﬁability of the disequality part.

50

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

?

?

?

?

?

?

?

?

?

R3 :

𝑇 ⊢ 𝑢 ⇝ ∃𝑥. 𝑇 ⊢ ⟨𝑥, 𝑢⟩

R1 :

𝑇 ⊢ ⟨𝑢1 , 𝑢2 ⟩ ⇝ 𝑇 ⊢ 𝑢1 ∧ 𝑇 ⊢ 𝑢2

R4 :

𝑇 ⊢ 𝑢 ⇝ ∃𝑥. 𝑇 ⊢ ⟨𝑢, 𝑥⟩

R2 :

𝑇 ⊢ {∣𝑢1 ∣}s𝑢2 ⇝ 𝑇 ⊢ 𝑢1 ∧ 𝑇 ⊢ 𝑢2

R5 :

𝑇 ⊢ 𝑢 ⇝ ∃𝑥. 𝑇 ⊢ {∣𝑢∣}s𝑥 ∧ 𝑇 ⊢ 𝑥

?

?

R6 :

?

?

?

?

?

𝑇 ⊢ 𝑥 ∧ 𝑇 ′ ⊢ 𝑥 ⇝ 𝑇 ⊢ 𝑥 if 𝑇 ⊆ 𝑇 ′ R7 :

?

?

𝑇 ⊢ 𝑢 ⇝ 𝑡 = 𝑢 if 𝑡 ∈ 𝑇

Figure 4. Naive constraint reduction rules

This idea can be applied to other security properties than agreement or conﬁdentiality, 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 efﬁcient 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 guessing 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(𝑡, 𝑢)

51

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

We do not include it in Figure 4 since this rule is a deterministic simpliﬁcation rule: it may be applied to any constraint without considering any alternative simpliﬁcation. By convention, 𝜎 =⊥ is a failure if the two terms are not uniﬁable. 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 R3 , R4 and R5 ) can be repeatedly applied any number of times. That is why we do not aim at reproducing any possible intruder’s 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 R3 , R4 and, R5 ; 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 simpliﬁcation rules for a theory of exclusive-or, pairing and symmetric encryption. The simpliﬁcation rules exactly reﬂect the intruder capabilities. They must be applied “don’t 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 :

𝑇 ⊢𝑡 ⇝ 𝑡=𝑢

C:

𝑇 ⊢ 𝑓 (𝑡1 , . . . , 𝑡𝑛 ) ⇝ 𝑇 ⊢ 𝑡1 ∧ . . . ∧ 𝑇 ⊢ 𝑡𝑛

C⊕ :

𝑇 ⊢𝑢⊕𝑣 ⇝ 𝑇 ⊢𝑢 ∧ 𝑇 ⊢𝑣

D𝜋 1 :

𝑇 ⊢ 𝑡 ⇝ 𝑇 ⊢ ⟨𝑢, 𝑣⟩ ∧ 𝑡 = 𝑢

D 𝜋2 :

? ?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

Ddec : 𝑇 ⊢ 𝑡 ⇝ 𝑇 ⊢

if 𝑓 ∕= ⊕ if ⟨𝑢, 𝑣⟩ ∈ St(𝑇 )

𝑇 ⊢ 𝑡 ⇝ 𝑇 ⊢ ⟨𝑢, 𝑣⟩ ∧ 𝑡 = 𝑣 {∣𝑢∣}s𝑣

if 𝑢 ∈ 𝑇

if ⟨𝑢, 𝑣⟩ ∈ St(𝑇 )

?

?

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 simpliﬁed and the resulting substitutions are applied to the rest of the constraint: U:

𝒞 ∧ℰ →

⋁

𝒞𝜎↓ ∧ 𝜎

𝜎 ∈ mgu(ℰ)

Here, mgu(ℰ) denotes a complete set of most general uniﬁers of ℰ modulo E⊕ . Such a set is ﬁnite and has even more properties, as we will see in the Lemma 8. Contrary to the

52

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

case of encryption and pairing only, the set of minimal uniﬁers, though ﬁnite, may not be reduced to a singleton. ?

Example 11 The equation ⟨𝑥, 𝑥⟩ ⊕ ⟨𝑦, 𝑦⟩ = ⟨𝑎, 𝑎⟩ ⊕ ⟨𝑏, 𝑏⟩ has two most general uniﬁers 𝜎1 = {𝑥 → 𝑎, 𝑦 → 𝑏} and 𝜎2 = {𝑥 → 𝑏, 𝑦 → 𝑎}. In addition, we simplify the constraints with the rules ?

?

?

?

?

S1 : 𝑇 ⊢ 𝑢 ∧ 𝑇 ′ ⊢ 𝑢 → 𝑇 ⊢ 𝑢

if 𝑇 ⊆ 𝑇 ′ ?

S2 : 𝑇 ⊢ 𝑥 ∧ 𝑇1 ⊢ 𝑢1 ⋅ ⋅ ⋅ ∧ 𝑇𝑛 ⊢ 𝑢𝑛

?

?

?

→ 𝑇 ⊢ 𝑥 ∧ 𝑇1 , 𝑥 ⊢ 𝑢1 ⋅ ⋅ ⋅ ∧ 𝑇𝑛 , 𝑥 ⊢ 𝑢𝑛 if 𝑇1 , . . . , 𝑇𝑛 are all left hand sides such that 𝑇 ⊊ 𝑇𝑖 , and 𝑥 ∈ / 𝑇𝑖 . We also use two simpliﬁcations of right members of constraints of the form 𝑥 ⊕ 𝑡:

?

?

?

?

XR1 : 𝑇 ′ ⊢ 𝑥 ∧ 𝑇 ⊢ 𝑥 ⊕ 𝑡 → 𝑇 ′ ⊢ 𝑥 ∧ 𝑇 ⊢ 𝑡 ?

?

if 𝑇 ′ ⊆ 𝑇

?

XR2 : 𝑇 ⊢ 𝑥 ⊕ 𝑡 → ∃𝑦. 𝑇 ⊢ 𝑦 ∧ 𝑥 = 𝑦 ⊕ 𝑡 if 𝑥 ∈ / vars(𝑇 ) ∪ vars(𝑡) and XR1 cannot be applied By convention, newly quantiﬁed variables should not occur previously in the constraint. 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 ⊢ 𝑐

→S2

⎧ ⎨ ⎩

?

𝑇1 ⊢ 𝑥 ?

𝑇2 , 𝑥 ⊢ 𝑐

⇝Ddec

⎧    ⎨

?

𝑇1 ⊢ 𝑥 ?

s

𝑇2 , 𝑥 ⊢ {∣𝑐∣}𝑏    ? ⎩ 𝑇2 , 𝑥 ⊢ 𝑏

⇝D⊕

⎧       ⎨

?

𝑇1 ⊢ 𝑥 ?

𝑇2 , 𝑥 ⊢ 𝑎 ⊕ {∣𝑐∣}s𝑏

?   𝑇2 , 𝑥 ⊢ 𝑎     ? ⎩ 𝑇2 , 𝑥 ⊢ 𝑏

53

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

⇝Ax

⎧ ⎨ ⎩

⎧    ⎨

?

𝑇1 ⊢ 𝑥 ?

𝑇2 , 𝑥 ⊢ 𝑎 ⇝D⊕    ? ⎩ 𝑇2 , 𝑥 ⊢ 𝑏

?

𝑇1 ⊢ 𝑥 ?

𝑇2 , 𝑥 ⊢ 𝑎

⇝Ddec

⎧    ⎨

⎧       ⎨

?

𝑇1 ⊢ 𝑥 ?

𝑇2 , 𝑥 ⊢ 𝑎

?   𝑇2 , 𝑥 ⊢ 𝑎 ⊕ {∣𝑐∣}s𝑏     ? ⎩ 𝑇2 , 𝑥 ⊢ 𝑏 ⊕ {∣𝑐∣}s𝑏 ?

𝑇1 ⊢ 𝑥 ?

{∣𝑎∣}s𝑥

𝑇2 , 𝑥 ⊢    ? ⎩ 𝑇2 , 𝑥 ⊢ 𝑥

→S1

⇝Ax

⎧ ⎨ ⎩

⎧    ⎨

?

𝑇1 ⊢ 𝑥 ?

𝑇2 , 𝑥 ⊢ 𝑎    ? ⎩ 𝑇2 , 𝑥 ⊢ 𝑏 ⊕ {∣𝑐∣}s𝑏

⇝Ax

?

𝑇1 ⊢ 𝑥 ?

𝑇2 , 𝑥 ⊢ {∣𝑎∣}s𝑥

?

⇝Ax 𝑇1 ⊢ 𝑥

The rules can actually be reﬁned, 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 difﬁcult to show that the simpliﬁcation rules S1 , S2 , XR1 , XR2 , U preserve the set of solutions, hence we may eagerly (and deterministically) apply these rules: Lemma 3 (soundness and completeness of simpliﬁcation rules) The simpliﬁcation rules U, S1 , S2 , XR1 , XR2 are sound and complete: they preserve the set of solutions. Then the rules of the Figure 5 are applied to simpliﬁed 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 Corollary 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 inﬁnite sequence of transformations. 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 displayed in the Figure 4. We imposed however additional restrictions, typically that, for decompositions, we may only consider the subterms of 𝑇 . This reﬂects 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 decomposition, then step(𝜋) ∈ St(𝑇 𝜎↓). This does not necessarily mean that hyp(last(𝜋)) are instances of terms in St(𝑇 ), because St(𝑇 𝜎↓) ∕⊆ St(𝑇 )𝜎↓. The main difﬁculty 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.

54

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

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 sufﬁcient 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

𝜋1

of 𝜋, for every 𝑖, either conc(𝜋𝑖 ) ∈ St(𝑇 )𝜎↓ or conc(𝜋𝑖 ) ∈ fact(𝑣).

⋅⋅⋅ 𝑣

𝜋𝑛

(XOR)

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 𝑇 𝜎 ⊢ ⟨𝑎, 𝑏⟩ ⊕ 𝑒.

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

𝜋0 =

⎧  ⎨  ⎩

{∣𝑥 ⊕ 𝑑∣}s𝑘 𝜎↓ (𝑥 ⊕ 𝑑)𝜎↓

𝑓

𝑘 𝑐⊕𝑒

55

𝑔

⟨𝑓, 𝑔⟩

⟨𝑎, 𝑏⟩ ⊕ 𝑒

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 inﬁnite 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 uniﬁcation 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 uniﬁers 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

56

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

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 nondecreasing. 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, S1 , S2 , XR1 , XR2 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 simpliﬁcation rules, for which the statement is not straightforward. ∙ When applying U, either the equation is trivial (in which case 𝒱(𝒞) remains constant), or the equation is unsatisﬁable (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 XR2 , 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.

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

57

∙ 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 , Ddec , 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 simpliﬁcation by U, XR1 , XR2 that takes place at this step (except trivial equations simpliﬁcations), 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 sufﬁces then to cut looping branches in order to get a terminating and complete procedure: according to Lemma 9, from any inﬁnite transformation sequence we may extract an inﬁnite 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 S1 . 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 inﬁnite 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 simpliﬁcation sequence is ﬁnite and yields a solved form. The termination proof does not give much information about complexity. Furthermore, the strategy is quite rough and can be reﬁned: there is still some work to do, if we wish to get the shortest simpliﬁcation sequence. For instance we would need to avoid repeating several times the same simpliﬁcations (as explained in [16]). With such an additional work, the simpliﬁcation of constraints might yield a NP decision procedure for the satisﬁability 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

58

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

decision procedure (for the existence of an attack) in [36]. For the same set of cryptographic primitives as the one we have shown in this chapter, but without exclusiveor, 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 uniﬁcation is already undecidable. The ﬁrst fragment considers some properties of modular exponentiation that are sufﬁcient 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 satisﬁable, 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 satisﬁability. 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 properties of cryptographic primitives [5,7,40]. There are also ways of getting rid of some equational axioms, and then using the veriﬁers that are designed for free term algebras [17,27,28]. Only some [33,4,40] are (currently) really relying on constraint solving techniques. 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

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

59

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 cryptographic primitives, such as bilinear pairings, used in elliptic curve cryptography, and zero-knowledge proofs. Another persistent demand is to handle more kinds of security goals, such as anonymity, fair exchange, group key management, and properties expressed 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, because the process is indistinguishable from an ideal process in which all relevant informations have been shufﬂed or hidden. The constraint solving approach is relevant for deciding equivalences of processes. It requires however signiﬁcant 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 challenge 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] [2]

[3] [4]

[5]

[6] [7] [8]

[9] [10]

M. Abadi and C. Fournet. Mobile values, new names, and secure communication. In Proceedings of the 28th ACM Symposium on Principles of Programming Languages (POPL’01), pages 104–115, 2001. 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, Artiﬁcial Intelligence, and Reasoning (LPAR’08), volume 5330 of LNAI, pages 128–142. Springer, 2008. F. Baader and K. Schulz. Uniﬁcation in the union of disjoint equational theories: Combining decision procedures. Journal of Symbolic Computation, 21:211–243, 1996. D. Basin, S. Mödersheim, 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 (CCS’03), pages 335–344. ACM, 2003. D. Basin, S. Mödersheim, and L. Viganò. Algebraic intruder deductions. In Proceedings of the 12th International Conference on Logic for Programming, Artiﬁcial Intelligence, and Reasoning (LPAR’05), volume 3835 of LNAI, pages 549–564. Springer-Verlag, 2005. V. Bernat and H. Comon-Lundh. Normal proofs in intruder theories. In Revised Selected Papers of the 11th Asian Computing Science Conference (ASIAN’06), volume 4435 of LNCS. Springer, 2008. B. Blanchet, M. Abadi, and C. Fournet. Automated veriﬁcation of selected equivalences for security protocols. Journal of Logic and Algebraic Programming, 75(1):3–51, 2008. 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 Techniques and Applications (RTA’09), volume 5595 of LNCS, pages 133–147. Springer, 2009. S. Bursuc, S. Delaune, and H. Comon-Lundh. Deducibility constraints. In Proceedings of the 13th Asian Computing Science Conference (ASIAN’09), LNCS. Springer, 2009. Y. Chevalier, R. Küsters, M. Rusinowitch, and M. Turuani. Deciding the security of protocols with Difﬁe-Hellman exponentiation and products in exponents. In Proceedings of the 23rd Conference on

60

[11] [12]

[13]

[14]

[15] [16] [17]

[18]

[19]

[20]

[21] [22]

[23]

[24] [25]

[26]

[27]

[28]

[29] [30]

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

Foundations of Software Technology and Theoretical Computer Science (FST&TCS’03), volume 2914 of LNCS, 2003. Y. Chevalier, R. Küsters, M. Rusinowitch, and M. Turuani. An NP decision procedure for protocol insecurity with XOR. Theoretical Computer Science, 338(1-3):247–274, 2005. Y. Chevalier, R. Küsters, M. Rusinowitch, and M. Turuani. Complexity results for security protocols with Difﬁe-Hellman exponentiation and commuting public key encryption. ACM Trans. Comput. Log., 9(4), 2008. Y. Chevalier and M. Rusinowitch. Combining Intruder Theories. In Proceedings of the 32nd International Colloquium on Automata, Languages and Programming, ICALP’05, volume 3580 of LNCS, pages 639–651. Springer, 2005. Y. Chevalier and M. Rusinowitch. Hierarchical combination of intruder theories. In Proceedings of the 17th International Conference on Rewriting Techniques and Application (RTA’06), volume 4098 of LNCS, pages 108–122, 2006. Y. Chevalier and M. Rusinowitch. Hierarchical combination of intruder theories. Information and Computation, 206(2-4):352–377, 2008. 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. H. Comon-Lundh and S. Delaune. The ﬁnite variant property: How to get rid of some algebraic properties. In Proceedings of the 16th International Conference on Rewriting Techniques and Applications (RTA’05), volume 3467 of LNCS, 2005. H. Comon-Lundh, S. Delaune, and J. Millen. Constraint solving techniques and enriching the model with equational theories. Research Report LSV-10-18, Laboratoire Spéciﬁcation et Vériﬁcation, ENS Cachan, France, Nov. 2010. 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. R. Corin and S. Etalle. An improved constraint-based system for the veriﬁcation of security protocols. In Proceedings of the 9th Static Analysis Symposium (SAS’02), volume 2477 of LNCS, pages 326–341, 2002. V. Cortier, S. Delaune, and P. Lafourcade. A survey of algebraic properties used in cryptographic protocols. Journal of Computer Security, 14(1):1–43, 2006. V. Cortier, M. Rusinowitch, and E. Zalinescu. A resolution 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 (PPDP’05), pages 12–22. ACM press, 2005. 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, (ICALP’06), Part II, volume 4052 of LNCS, pages 132–143, 2006. S. Delaune, P. Lafourcade, D. Lugiez, and R. Treinen. Symbolic protocol analysis for monoidal equational theories. Information and Computation, 206(2-4):312–351, 2008. D. Dolev and A. Yao. On the security of public key protocols. In Proceedings of the 22nd Symposium on Foundations of Computer Science, pages 350–357, Nashville (USA, Tennessee, 1981. IEEE Comp. Soc. Press. D. Kähler and R. Küsters. Constraint solving for contract-signing protocols. In Proceedings of the 16th International Conference on Concurrency Theory (CONCUR’05), volume 3653 of LNCS, pages 233–247. Springer, 2005. R. Küsters 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 (CCS’08), pages 129–138. ACM, 2008. R. Küsters and T. Truderung. Using ProVerif to Analyze Protocols with Difﬁe-Hellman Exponentiation. In Proceedings of the 22nd IEEE Computer Security Foundations Symposium (CSF 2009), pages 157– 171. IEEE Computer Society, 2009. G. Lowe. Towards a completeness result for model checking of security protocols. Journal of Computer Security, 7(2-3):89–146, 1999. C. Lynch and C. Meadows. On the relative soundness of the free algebra model for public key encryp-

H. Comon-Lundh et al. / Constraint Solving Techniques and Enriching the Model

[31] [32] [33] [34] [35] [36] [37] [38]

[39] [40]

61

tion. ENTCS, 125(1):43–54, 2005. C. Meadows and P. Narendran. A uniﬁcation algorithm for the group Difﬁe-Hellman protocol. In Proceedings of the Workshop on Issues in the Theory of Security (WITS’02), 2002. J. Millen. On the freedom of decryption. Information Processing Letters, 86(6):329–333, 2003. 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. J. Millen and V. Shmatikov. Symbolic protocol analysis with an abelian group operator or DifﬁeHellman exponentiation. Journal of Computer Security, 2005. R. Ramanujam and S. P. Suresh. Decidability of context-explicit security protocols. Journal of Computer Security, 13(1):135–165, 2005. 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. S. Schneider. Security properties and CSP. In IEEE Symposium on Security and Privacy, pages 174– 187, 1996. V. Shmatikov. Decidable analysis of cryptographic protocols with products and modular exponentiation. In Proceedings of the 13th European Symposium on Programming (ESOP’04), volume 2986 of LNCS, 2004. F. J. Thayer, J. C. Herzog, and J. D. Guttman. Strand spaces: Proving security protocols correct. Journal of Computer Security, 7(1), 1999. M. Turuani. The CL-Atse protocol analyser. In Proceedings of the 17th International Conference on Term Rewriting and Applications (RTA’06), volume 4098 of LNCS, pages 277–286. Springer, 2006.

62

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. doi:10.3233/978-1-60750-714-7-62

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 book’s running example: Message 1 . a → b : {∣[k ]SK (a) ∣}aPK (b) s Message 2 . b → a : {∣s∣}k The initiator a creates a fresh session key k , signs it with her secret key SK (a), encrypts it with the responder b’s 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 recipients; encrypt and decrypt messages using keys he knows, so as to learn new messages; 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 speciﬁcations, 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

G. Lowe / Analysing Security Protocols Using CSP

63

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 reﬂected 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 brieﬂy discuss some extensions of the technique.

2. A brief overview of CSP Communicating Sequential Processes (CSP) [Hoa85,Ros97] is a process algebra for describing 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 fragment 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 □ P (i) represents an indexed i:I 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 ∥ Q runs P and Q in parallel, synchronising on events from A, 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 ]Pi : each process Pi synchronises on events from i:I 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 reﬁned by Q , written P ⊑T Q , if all the traces of Q are traces of P : P ⊑T Q ⇔ traces(P ) ⊇ traces(Q ).

64

G. Lowe / Analysing Security Protocols Using CSP

Typically, Q will be a model of a system and P will be a speciﬁcation process that can perform those traces that meet some requirement; the reﬁnement will hold if P can perform only traces that meet the requirement. The tool FDR [Ros94,For97] can be used to test such reﬁnements automatically, for ﬁnite state processes.

3. Modelling the protocol In this section we describe the basic technique of CSP model checking of security protocols. 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 ory

all b .M ice .Bo l dA Alice n e . s d sen

rec e rec ive.M eiv e.A allor y lic e.B .Bob ob

Initiator(Alice,Ka)

Responder(Bob,Sb) Figure 1. The system

In the next subsection we give some basic deﬁnitions 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 deﬁnitions using “blackboard CSP”; it is straightforward to translate this into machine-readable CSP, for use with FDR. 3.1. The basics We begin by deﬁning a datatype Encryption representing the space of all possible messages. 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 deﬁned below. For example, a typical instance of message 1 of the form {∣[k ]SK (a) ∣}aPK (b) would be represented by the element Encrypt .(PK .b, Encrypt .(SK .a, k )) of Encryption.

G. Lowe / Analysing Security Protocols Using CSP

65

For convenience, we deﬁne 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 deﬁne a function to return the inverse key of a given key: inverse(Ka) = Ka, inverse(PK .a) = SK .a,

inverse(Km) = Km, 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 deﬁne 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 deﬁne 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. commands 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 processes. 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 message from the environment, telling it with whom to run the protocol. It then sends an appropriate message 1, and receives back an appropriate message 2 containing an arbitrary value for s.

66

G. Lowe / Analysing Security Protocols Using CSP

Initiator (a, k ) = env .a.(Env0 , b) → □ b:Agent

send .a.b.(Msg1 , Encrypt .(PK (b), Encrypt .(SK (a), k ))) → receive.b.a.(Msg2 , Encrypt .(k , s)) → STOP . □ s:Secret

The deﬁnition 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 receiving 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. System0 = 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, therefore, 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 deﬁne a deduction system to capture the intruder’s capabilities: we write X ⊢ f if, given set of facts X , he is able to create the fact f . The relation ⊢ is deﬁned by the following four rules: {f , k } ⊢ Encrypt .(k , f ), {Encrypt .(k , f ), inverse(k )} ⊢ f , {f1 , . . . , fn } ⊢ Sq.⟨f1 , . . . , fn ⟩, {Sq.⟨f1 , . . . , fn ⟩} ⊢ fi ,

for k ∈ AllKeys, for k ∈ AllKeys, 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

G. Lowe / Analysing Security Protocols Using CSP

67

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 deﬁnition for the intruder that can hear messages sent across the network, deduce new facts from what he knows (as deﬁned by the ⊢ relation), and then send facts he knows to other agents (possibly using identities other than his own). We deﬁne MsgBody to be the bodies of messages (i.e., without the label), and declare 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 deﬁne the intruder is as follows; the parameter S represents the intruder’s current knowledge. Intruder0 (S ) = hear ?f : MsgBody → Intruder0 (S ∪ {f }) □ say?f : S ∩ MsgBody → Intruder0 (S ) □ leak ?f : S ∩ Secret → Intruder0 (S ) □ infer .(f , X ) → Intruder0 (S ∪ {f }). □ f :Fact, X ⊆S , X ⊢f , f ∈S /

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 intruder’s initial knowledge; we assume that the intruder knows all the agent’s 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 deﬁnition of the intruder ensures1 ∀ tr ′⌢⟨say.f ⟩ ∈ traces(Intruder0 (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 inefﬁcient in practice, because of the way FDR works. FDR produces explicit state machines for se1 “⌢”

denotes concatenation of traces.

68

G. Lowe / Analysing Security Protocols Using CSP

quential processes, such as Intruder0 (IIK ) above. If there are N facts that the intruder might learn, then the Intruder0 process has 2 N states. It is typical for N to be of the order 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 ) □ infer .(f , X ) → Knows(f ), □ X ⊆Fact, X ⊢f

Knows(f ) = f ∈ MsgBody & hear .f → Knows(f ) □ f ∈ MsgBody & say.f → Knows(f ) □ f ∈ Secret & leak .f → Knows(f ) □ infer .(f ′ , X ) → Knows(f ). □′ ′ f :Fact, X ⊆Fact, f ∈X , X ⊢f

If the intruder doesn’t 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 know f . 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 ). Intruder0 = ∥

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 deﬁnition, but FDR can construct it much more quickly. We can make the deﬁnition more efﬁcient, 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

G. Lowe / Analysing Security Protocols Using CSP

69

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 doesn’t matter what order they are made in: we should force FDR to 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. Intruder1 = chase(Intruder0 ∖ {∣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 = Intruder1 [[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 reﬂect the fact that the intruder has complete control over the network: System = System0

∥

{∣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

70

G. Lowe / Analysing Security Protocols Using CSP

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 perform leak .s indicating 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 reﬁnement SecretSpec ⊑T SecretSystem. When we perform this check, FDR ﬁnds that the reﬁnement 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 IAlice represents the intruder faking a message, pretending to be Alice, or intercepting a message intended for Alice):

G. Lowe / Analysing Security Protocols Using CSP

Message 0 . → Alice Message 1 . Alice → Mallory Message 1 . IAlice → Bob Message 2 . Bob → IAlice The intruder knows Sb.

: : : :

71

Mallory {∣[Ka]SK (Alice) ∣}aPK (Mallory) {∣[Ka]SK (Alice) ∣}aPK (Bob) {∣Sb∣}sKa

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 running the protocol as initiator, apparently with b, using session key k ; ∙ The event Complete.ResponderRole.b.a.k indicates that b thinks he has completed 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 perform the Running event when she sends message 1, and we arrange for responder b to perform the Complete event when he sends message 2; we hide all other events. AuthSystem0 = 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∣}.

72

G. Lowe / Analysing Security Protocols Using CSP

(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 speciﬁcation process, which allows only such traces AuthSpec = Running.InitiatorRole?a.b.k → Chaos({Complete.ResponderRole.b.a.k }). Note that this speciﬁcation 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 reﬁnement AuthSpec ⊑T AuthSystem. (The above reﬁnement test is appropriate since AuthSystem performs at most a single Running event; for a system that could perform n such events, we would replace the left hand side of the reﬁnement test by an interleaving of n copies of AuthSpec.) FDR ﬁnds that this reﬁnement 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 reﬁnement check AlivenessSpec ⊑T SystemAliveness, where

G. Lowe / Analysing Security Protocols Using CSP

73

AlivenessSpec = Running.InitiatorRole.Alice?c?k → Chaos({Complete.ResponderRole.b.Alice.k ∣ b ∈ Agent }), SystemAliveness = AuthSystem0 ∖ (Σ − 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 identiﬁed 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 recipient’s identity within this signed message. We also include the sender’s identity, although this is not actually necessary: Message 1 . a → b : {∣[a, b, k ]SK (a) ∣}aPK (b) s Message 2 . b → a : {∣s∣}k It is straightforward to adapt the CSP model to reﬂect this change in the protocol: it simply requires a change to the deﬁnitions 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 he’s 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 necessarily imply that there is no attack upon some other system running the protocol (although 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

74

G. Lowe / Analysing Security Protocols Using CSP

System0 = (Responder (Bob, Sb) ∣∣∣ Others)

∥

{∣send,receive∣}

Intruder ,

where Others models all the other honest instances. Of course, there are inﬁnitely 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 inﬁnite number of models, parameterised 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 attacks, deduce that there are no attacks upon an arbitrary system of the form of System0 , 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 sufﬁxes 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:

G. Lowe / Analysing Security Protocols Using CSP

{} ⊢ Encrypt .(PK (Mallory), Encrypt .(SK (a), Sq.⟨a, Mallory, k ⟩)), for a ∈ Honest, k ∈ SessionKeyKnown.

75

(2)

We now consider item 2 above, corresponding to the responder b sending a message 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 secrets 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 SystemInt = 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, SystemInt 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 SystemInt 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 SystemInt where there is no corresponding attack on System. However, we have designed SystemInt 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.

76

G. Lowe / Analysing Security Protocols Using CSP

Note that we have, in fact, produced an inﬁnite family of systems, one for each choice of the types Agent , SessionKey and Secret (and their subtypes); we sometimes write SystemInt (Agent , SessionKey, Secret ) to make this dependence explicit. Note in particular that the intruder is also parameterised by these types, both in the deﬁnition of the set of deductions, and in the deﬁnition of his initial knowledge IIK as deﬁned 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 SystemInt (Agent , SessionKey, Secret ) to the analysis of a single system SystemInt (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 perform any computations that constrain what T may be. The processes we have deﬁned 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 from an 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 SystemInt (Agent , SessionKey, Secret ). In order to reduce the inﬁnite family of systems of the form of SystemInt , we will deﬁne a function 𝜙 : Fact → Fact , and (informally speaking) consider a system that uses fact 𝜙(f ) whenever SystemInt uses f . Given a particular choice of Agent , SessionKey and Secret , we deﬁne 𝜙 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 † = SystemInt (𝜙Ag (Agent ), 𝜙SK (SessionKey), 𝜙Sec (Secret )) = SystemInt (Agent † , SessionKey † , Secret † ).

G. Lowe / Analysing Security Protocols Using CSP

77

We give the deﬁnitions of 𝜙Ag , etc., below (in fact, we’ll use different deﬁnitions depending on the property we’re 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 SystemInt 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(SystemInt (Agent , SessionKey, Secret ))}.

(5)

If we can do that, and prove some property of the traces of System † (by performing a reﬁnement check using FDR) we will be able to deduce a corresponding property about the traces of SystemInt . Equation (5) does hold, but this requires some justiﬁcation; 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 satisﬁes PosConjEqT precisely when the failure of each equality check in P results in the process STOP . For example, the following process satisﬁes PosConjEqT: P (T ) = in?x : T → in?y : T → if x = y then a → STOP else STOP . The CSP processes we have deﬁned to model the honest protocol participants satisfy PosConjEqT. However, this won’t 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 deﬁned to model the intruder also satisﬁes equation (6). In [RB99], it is shown that this will be the case provided the underlying deduction relation ⊢ 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 ⊕ t1 , k ⊕ t2 } ⊢ k ,

for k ∈ Key, t1 , t2 ∈ Text, t1 ∕= t2 .

If 𝜙(t1 ) = 𝜙(t2 ), for some t1 ∕= t2 , then the deduction system is not positive.

78

G. Lowe / Analysing Security Protocols Using CSP

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 † satisﬁes equation (5). 5.3. Testing for secrecy and authentication We now describe how to adapt the reﬁnement test for secrecy from Section 4.1. Recall that we are only considering secrecy from the point of view of the principal responder. We deﬁne the reduction functions 𝜙Ag , etc., as follows, to reduce each of the subtypes to singleton values: 𝜙Ag (Bob) = Bob, 𝜙Ag (Mallory) = Mallory, 𝜙Ag (a) = Alice, for a ∈ Honest − {Bob}, 𝜙Sec (Sb) = Sb, 𝜙Sec (s) = Sm, 𝜙Sec (s) = Sa, 𝜙SK (k ) = Km, 𝜙SK (k ) = Ka,

for s ∈ SecretKnown ∪ SecretIntruder, for s ∈ SecretUnknown, for k ∈ SessionKeyKnown ∪ SessionKeyIntruder , for k ∈ SessionKeyUnknown.

This deﬁnition 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 intruder’s 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 (1–4)) 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 satisﬁed, 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∣}).

G. Lowe / Analysing Security Protocols Using CSP

79

We consider a speciﬁcation analogous to SecretSpec, but restricted to just the principal responder and the principal responder’s 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 SystemInt . The success of the above reﬁnement 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 deﬁnition of 𝜙Ag etc., SystemInt (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 SystemInt (Agent , SessionKey, Secret ), for all choices of the types. Thus we have veriﬁed 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 deﬁne 𝜙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 principal 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 ⟩)), {}).

80

G. Lowe / Analysing Security Protocols Using CSP

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 speciﬁcation 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 SystemInt . The success of the above reﬁnement 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 SystemInt (Agent , SessionKey, Secret ). Suppose, for a contradiction, that SystemInt (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, 𝜙SK (K ) = Kb, 𝜙SK (k ) = Km, 𝜙SK (k ) = Ka,

for c ∕= A, Bob, for k ∈ SessionKeyKnown ∪ SessionKeyIntruder − {K }, for k ∈ SessionKeyUnknown − {K }.

3 In the interests of efﬁciency, we should hide and chase all infer events other than Msg1Inf (a, k ) events when we construct the intruder process.

G. Lowe / Analysing Security Protocols Using CSP

81

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 contradicts equation (7). Thus we have obtained a contradiction to equation (8). Hence SystemInt (Agent , SessionKey, Secret ) satisﬁes the authentication property, for all choices of the types. Thus we have veriﬁed 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. However, 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 description written by the user. In this section we brieﬂy 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 deﬁnes the speciﬁcations 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 deﬁnes which keys are inverses of one another. The #Processes section deﬁnes 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 deﬁnes the initial knowledge of the agents; Casper uses this information to check that the protocol is feasible, in that each agent has all the information necessary to run the protocol. The #Protocol description section deﬁnes 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 deﬁnes the security properties to be tested. The two Secret speciﬁcations correspond to the two secrecy properties considered in Section 4.1: that a believes that s is a secret that only b should know, and vice versa. The two Agreement speciﬁcations correspond to the ﬁrst two authentication properties considered 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 speciﬁcation corresponds to the property considered at the end of Section 4.2: that if b completes a run of the protocol, apparently with a, then a has previously been running the protocol. The #Actual variables section deﬁnes the atomic values to be used in the protocol model; this is used in the deﬁnition of the Encryption datatype in the model. This section also deﬁnes which keys are inverses of one another. The #Functions section tells Casper to produce symbolic deﬁnitions for the functions PK and SK; alternatively,

82

G. Lowe / Analysing Security Protocols Using CSP

#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 0. -> a 1. a -> b 2. b -> a

description : b : { {k}{SK(a)} }{PK(b)} : {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 deﬁnitions. The #System section deﬁnes 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-

G. Lowe / Analysing Security Protocols Using CSP

83

#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, generate types containing just enough values, and give the intruder just enough initial knowledge, in order for the security of this small system to imply the security of arbitrary systems, using an argument as in Section 5.3. The user has to declare only the intruder’s identity, and to specify what initial knowledge from non-data-independent types the intruder 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 techniques 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.

84

G. Lowe / Analysing Security Protocols Using CSP

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 Difﬁe-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 poorlychosen 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 technique 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 internalising 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 presented 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 GibsonRobinson, Steve Kremer, Tomasz Mazur, Toby Murray and Bernard Sufrin.

References [BR02] [Bro01] [DY83] [For97] [Hoa85] [Hui01]

P. J. Broadfoot and A. W. Roscoe. Capturing parallel attacks within the data independence framework. In Proceedings of the 15th IEEE Computer Security Foundations Workshop, 2002. Philippa Broadfoot. Data independence in the model checking of security protocols. DPhil thesis, Oxford University, 2001. D. Dolev and A.C. Yao. On the security of public-key protocols. Communications of the ACM, 29(8):198–208, August 1983. Formal Systems (Europe) Ltd. Failures-Divergence Reﬁnement—FDR 2 User Manual, 1997. Available via URL http://www.formal.demon.co.uk/FDR2.html. C. A. R. Hoare. Communicating Sequential Processes. Prentice Hall, 1985. Mei Lin Hui. A CSP Appraoch to the Analysis of Security Protocols. PhD thesis, University of Leicester, 2001.

G. Lowe / Analysing Security Protocols Using CSP

[Kle08] [Laz99] [LBDH]

[Low96]

[Low97a] [Low97b] [Low98] [Low04] [Low09]

[LR97] [MCF87] [Mea96] [RB99] [RG97]

[Ros94] [Ros95] [Ros97] [Ros98] [RSG+ 00]

85

Eldar Kleiner. A Web Services Security Study using Casper and FDR. DPhil thesis, Oxford University, 2008. Ranko Lazi´c. A Semantic Study of Data Independence with Applications to Model Checking. DPhil thesis, Oxford University, 1999. Gavin Lowe, Philippa Broadfoot, Christopher Dilloway, and Mei Lin Hui. Casper: A Compiler for the Analysis of Security Protocols, User Manual and Tutorial. Oxford University Computing Laboratory. Available via http://www.comlab.ox.ac.uk/people/gavin. lowe/Security/Casper/index.html. 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 147–166. Springer Verlag, 1996. Also in Software—Concepts and Tools, 17:93–102, 1996. Gavin Lowe. Casper: A compiler for the analysis of security protocols. In Proceedings of 10th IEEE Computer Security Foundations Workshop, pages 18–30, 1997. Gavin Lowe. A hierarchy of authentication speciﬁcations. In Proceedings of 10th IEEE Computer Security Foundations Workshop, 1997. Gavin Lowe. Casper: A compiler for the analysis of security protocols. Journal of Computer Security, 6:53–84, 1998. Gavin Lowe. Analysing protocols subject to guessing attacks. Journal of Computer Security, 12(1):83–98, 2004. Gavin Lowe. Casper: A compiler for the analysis of security protocols, 1996–2009. World Wide Web home page at URL http://www.comlab.ox.ac.uk/people/gavin. lowe/Security/Casper/index.html. Gavin Lowe and Bill Roscoe. Using CSP to detect errors in the TMN protocol. IEEE Transactions on Software Engineering, 23(10):659–669, 1997. J. K. Millen, S. C. Clark, and S. B. Freedman. The interrogator: Protocol security analysis. IEEE Transactions on software Engineering, 13(2), 1987. Catherine Meadows. The NRL Protocol Analyzer: An overview. Journal of Logic Programming, 26(2):113–131, 1996. A. W. Roscoe and P. J. Broadfoot. Proving security protocols with model checkers by data independence techniques. Journal of Computer Security, 7(2, 3):147–190, 1999. A. W. Roscoe and M. H. Goldsmith. The perfect “spy” for model-checking cryptoprotocols. In Proceedings of the DIMACS Workshop on Design and Formal Veriﬁcation of Security Protocols, 1997. Available via URL http://dimacs.rutgers.edu/Workshops/Security/ program2/program.html. A. W. Roscoe. Model-checking CSP. In A Classical Mind, Essays in Honour of C. A. R. Hoare. Prentice-Hall, 1994. A. W. Roscoe. Modelling and verifying key-exchange protocols using CSP and FDR. In 8th IEEE Computer Security Foundations Workshop, 1995. A. W. Roscoe. The Theory and Practice of Concurrency. Prentice Hall, 1997. A. W. Roscoe. Proving security protocols with model checkers by data independence techniques. In 11th Computer Security Foundations Workshop, pages 84–95, 1998. Peter Ryan, Steve Schneider, Michael Goldsmith, Gavin Lowe, and Bill Roscoe. Modelling and Analysis of Security Protocols. Pearson Education, 2000.

86

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. doi:10.3233/978-1-60750-714-7-86

Using Horn Clauses for Analyzing Security Protocols Bruno BLANCHET 1 CNRS, École Normale Supérieure, 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 foundation of the protocol veriﬁer ProVerif. It is fully automatic, efﬁcient, and can handle an unbounded number of sessions and an unbounded message space. It supports various cryptographic primitives deﬁned 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 veriﬁcation, security protocols, Horn clauses, secrecy.

Introduction Security protocols can be veriﬁed 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 decidability results could be obtained (see Chapters “ Verifying a bounded number of sessions 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 relying 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 knowledge. 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 auto1 Corresponding Author: Bruno Blanchet, École Normale Supérieure, DI, 45 rue d’Ulm, 75005 Paris, France; E-mail: [email protected].

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

87

matic protocol veriﬁer ProVerif that we developed. In this method, messages are represented 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 efﬁcient resolution algorithm determines 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 veriﬁer does not ﬁnd a ﬂaw in the protocol, then there is no ﬂaw. The veriﬁer therefore provides real security guarantees. In contrast, it may give a false attack against the protocol. 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 incomplete, this method provides a good balance in practice: it terminates in the vast majority of cases and is very efﬁcient and precise. It can handle a wide variety of cryptographic primitives deﬁned by rewrite rules or by equations, including shared-key and public-key cryptography (encryption and signatures), hash functions, and the Difﬁe-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 veriﬁcation method based on an abstract representation of the attacker knowledge by tree automata. This method was extended by Goubault-Larrecq [62]. Genet and Klay [59] combine tree automata with rewriting. This method has lead to the implementation of the TA4SP veriﬁer (TreeAutomata-based Automatic Approximations for the Analysis of Security Protocols) [39]. The main drawback of this approach is that, in contrast to Horn clauses, tree automata cannot represent relational information on messages: when a variable appears several times in a message, one forgets that it has the same value at all its occurrences, 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 deﬁned for secrecy for shared-key protocols, then extended to message authenticity and public-key protocols [37], with a polynomial complexity. ∙ Most protocol veriﬁers compute the knowledge of the attacker. In contrast, Hermès [41] computes the form of messages, for instance encryption under certain keys, that guarantee the preservation of secrecy. The paper handles shared-key

88

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

𝑀, 𝑁 ::= 𝑥 𝑎[𝑀1 , . . . , 𝑀𝑛 ] 𝑓 (𝑀1 , . . . , 𝑀𝑛)

terms variable name 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-interpretationbased 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 veriﬁcation 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 resolution 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 symbols, and 𝑝 over predicate symbols. The terms 𝑀 represent messages that are exchanged between participants of the protocol. A variable can represent any term. Names represent 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 preceding messages are different. As noticed by Martín 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

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

89

enough to handle many protocols, and can be enriched by adding other parameters to the name. In particular, by adding as parameter a session identiﬁer 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 identiﬁers here for simplicity. 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”: }a { Message 1. 𝐴 → 𝐵 : [𝑘]sk 𝐴 pk 𝐵 s Message 2. 𝐵 → 𝐴 : {∣𝑠∣}𝑘 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 from the 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 messages. For instance, pencrypt and pk are constructors. Destructors manipulate terms. A destructor 𝑔 is deﬁned 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 destructor, deﬁned by pdecrypt(pencrypt(𝑚, pk(sk )), sk ) → 𝑚. This rewrite rule models that, by decrypting a ciphertext with the corresponding secret key, one obtains the cleartext. Other functions are deﬁned similarly: ∙ For signatures, we use a constructor sign and write sign(𝑚, sk ) for the message 𝑚 signed under the secret key sk . A destructor getmess deﬁned 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 destructor sdecrypt, deﬁned by sdecrypt(sencrypt(𝑚, 𝑘), 𝑘) → 𝑚. ∙ A one-way hash function is represented by a constructor ℎ (and no destructor).

90

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

∙ Tuples of arity 𝑛 are represented by a constructor (_, . . . , _) and 𝑛 destructors 𝑖th𝑛 deﬁned by 𝑖th𝑛 ((𝑥1 , . . . , 𝑥𝑛 )) → 𝑥𝑖 , 𝑖 ∈ {1, . . . , 𝑛}. Tuples can be used to represent various data structures in protocols. Rewrite rules offer a ﬂexible method for deﬁning 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 message 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.

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

91

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 starting 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 𝐵 expects 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 sufﬁcient 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 deﬁned 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. Moreover, 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.

92

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

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 𝐴 [ ])), The protocol: First message: Second message:

attacker(pk(sk 𝐵 [ ]))

attacker(pk(𝑥)) ⇒ attacker(pencrypt(sign(𝑘[pk(𝑥)], sk 𝐴 [ ]), pk(𝑥))) 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 listen 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 channels 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, destructors, 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 message, 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.

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

93

1.5. Approximations The reader can notice that our representation of protocols is approximate. Speciﬁcally, 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 Véronique Cortier) First step: Second step: Third step:

s

s

𝐴 sends {∣⟨𝑁1 , 𝑀 ⟩∣}𝑘 , {∣⟨𝑁2 , 𝑀 ⟩∣}𝑘 s If 𝐴 receives {∣⟨𝑥, 𝑀 ⟩∣}𝑘 , he replies with 𝑥 If 𝐴 receives 𝑁1 , 𝑁2 , he replies with s

where 𝑁1 , 𝑁2 , and 𝑀 are nonces. In an exact model, 𝐴 never sends s, since {∣⟨𝑁1 , 𝑀 ⟩∣}s𝑘 s or {∣⟨𝑁2 , 𝑀 ⟩∣}𝑘 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 𝑀 s (that is, the corresponding clause can be applied twice), so that both {∣⟨𝑁1 , 𝑀 ⟩∣}𝑘 and s {∣⟨𝑁2 , 𝑀 ⟩∣}𝑘 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 approximation 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 veriﬁer, which will be able to handle larger and more complex protocols. Another advantage is that the veriﬁer 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 veriﬁer: 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

94

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

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 computes 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 signature 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 decrypt 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 session 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. ﬁx the protocol by adding the { In contrast, if}we a public key of 𝐵 in the ﬁrst message [⟨pk 𝐵 , 𝑘⟩]sk 𝐴 pk , attacker(s) is not derivable 𝐵 from the clauses, so the ﬁxed protocol preserves the secrecy of s. Next, we formally deﬁne 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 hypotheses 𝐹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 important. (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. Deﬁnition 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 deﬁned as follows, as illustrated in Figure 3. Deﬁnition 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 deﬁned 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.

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

95

root 𝐹 𝑅′

𝜂′

subroot

𝐹0 ...

𝑅

𝐹1 ...

𝜂 ... ...

... 𝐹𝑛 ...

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 𝐹 from ℛ if 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 problem solved 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 encryptions. 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 resolution 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 veriﬁer 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 deﬁne resolution: when the conclusion of a clause 𝑅 uniﬁes 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 deﬁned as follows:

96

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

Deﬁnition 3 Let 𝑅 and 𝑅′ be two clauses, 𝑅 = 𝐻 ⇒ 𝐶, and 𝑅′ = 𝐻 ′ ⇒ 𝐶 ′ . Assume that there exists 𝐹0 ∈ 𝐻 ′ such that 𝐶 and 𝐹0 are uniﬁable and 𝜎 is the most general uniﬁer of 𝐶 and 𝐹0 . In this case, we deﬁne 𝑅 ∘𝐹0 𝑅′ = 𝜎(𝐻 ∪ (𝐻 ′ ∖ {𝐹0 })) ⇒ 𝜎𝐶 ′ . The clause 𝑅 ∘𝐹0 𝑅′ 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 𝑅 ∘𝐹0 𝑅′ is attacker(pk(𝑥)) ∧ attacker(𝑥) ⇒ attacker(sign(𝑘[pk(𝑥)], sk 𝐴 [ ])) with the substitution 𝜎 = {sk → 𝑥, 𝑚 → sign(𝑘[pk(𝑥)], sk 𝐴 [ ])}. We guide the resolution by a selection function: Deﬁnition 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 uniﬁed in the resolution are selected. We will therefore choose the selection function to reduce the number of possible uniﬁcations between selected 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 uniﬁed will all facts of the form attacker(𝑀 ). Therefore, we should avoid selecting them. So a basic selection function is a function sel 0 that satisﬁes the constraint { sel 0 (𝐻 ⇒ 𝐶) =

∅ {𝐹0 }

if ∀𝐹 ∈ 𝐻, ∃𝑥 variable, 𝐹 = attacker(𝑥) 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):

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

97

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 𝑅 ∘𝐹0 𝑅′ is deﬁned, ℛ ← elim({𝑅 ∘𝐹0 𝑅′ } ∪ ℛ). 3. Return {𝑅 ∈ ℛ ∣ sel (𝑅) = ∅}. Second phase: backward depth-ﬁrst search ⎧ ∅ if ∃𝑅′ ∈ ℛ, 𝑅′ ⊒ 𝑅    ⎨{𝑅} otherwise, if sel (𝑅) = ∅ deriv(𝑅, ℛ, ℛ1 ) = ∪ ′ ′  {deriv(𝑅 ∘ 𝑅, {𝑅} ∪ ℛ, ℛ ) ∣ 𝑅 ∈ ℛ1 , 𝐹0 1   ⎩ ′ 𝐹0 ∈ sel (𝑅) such that 𝑅 ∘𝐹0 𝑅 is deﬁned } 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 derivation 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 𝑅 ∘𝐹0 𝑅′ . This replacement decreases the number of clauses in the derivation, so it terminates, 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 negation of the goal 𝐹 is added to the clauses, under the form of a clause without conclusion: 𝐹 ⇒. 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

98

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

an element 𝐹0 of the hypothesis of 𝑅. So 𝑅 is replaced with 𝑅′ ∘𝐹0 𝑅 (third case of the deﬁnition 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 deﬁnition of deriv. The transformation of 𝑅 described above is repeated until one of the following two conditions is satisﬁed: ∙ 𝑅 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 deﬁnition of deriv); ∙ sel (𝑅) is empty: we have obtained a suitable clause 𝑅 and we return it (second case of the deﬁnition of deriv). Intuitively, the correctness of derivable expresses that if 𝐹 ′ , instance of 𝐹 , is derivable, 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 derivation 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 satisﬁes (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 derivable from saturate(ℛ0 ). If the selection function satisﬁes (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 deﬁnition of derivable, 𝐶 is an instance of 𝐹 , so 𝐶 = 𝐹 , and sel (𝐻 ⇒ 𝐶) = ∅, so all elements of 𝐻 are of the form attacker(𝑥𝑖 ) for some variable

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

𝐶1′ 𝑅′

99

𝐶1′ 𝜂′ 𝐻1′

𝑅′′

𝜂 ′′

𝐻1 ∪ (𝐻1′ ∖ {𝜎𝐹0 })

𝜎𝐹0 𝑅

𝜂

𝐻1

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 hypothesis of 𝑅′ . Then there exists a son 𝜂 of 𝜂′ , labeled 𝑅, such that the edge 𝜂 ′ → 𝜂 is labeled by an instance of 𝐹0 , 𝑅 ∘𝐹0 𝑅′ is deﬁned, and one obtains a derivation of the same fact by replacing the nodes 𝜂 and 𝜂 ′ with a node 𝜂 ′′ labeled 𝑅′′ = 𝑅 ∘𝐹0 𝑅′ . 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′ ⇒ 𝐶1′ ), so there exists a substitution 𝜎 such that 𝜎𝐻 ′ ⊆ 𝐻1′ and 𝜎𝐶 ′ = 𝐶1′ . Since 𝐹0 ∈ 𝐻 ′ , 𝜎𝐹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 uniﬁable, so 𝑅 ∘𝐹0 𝑅′ is deﬁned. Let 𝜎 ′ be the most general uniﬁer of 𝐶 and 𝐹0 , and 𝜎 ′′ such that 𝜎 = 𝜎′′ 𝜎′ . We have 𝑅 ∘𝐹0 𝑅′ = 𝜎′ (𝐻 ∪ (𝐻 ′ ∖ {𝐹0 })) ⇒ 𝜎 ′ 𝐶 ′ . Moreover, 𝜎 ′′ 𝜎′ (𝐻 ∪ (𝐻 ′ ∖ {𝐹0 })) ⊆ 𝐻1 ∪ (𝐻1′ ∖ {𝜎𝐹0 }) and 𝜎 ′′ 𝜎 ′ 𝐶 ′ = 𝜎𝐶 ′ = 𝐶1′ . Hence 𝑅′′ = 𝑅 ∘𝐹0 𝑅′ ⊒ (𝐻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 𝜂 ′′ . ⊔ ⊓

100

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

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, ℛ satisﬁes 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 𝑅 ∘𝐹0 𝑅′ is deﬁned. In this case, 𝑅 ∘𝐹0 𝑅′ 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 instruction, 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({𝑅 ∘𝐹0 𝑅′ } ∪ ℛ). Hence, 𝑅 ∘𝐹0 𝑅′ 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 . / ℛ1 , sel (𝑅′ ) ∕= ∅. Take 𝐹0 ∈ sel (𝑅′ ). By Let 𝑅′ be the clause labeling 𝜂 ′ . Since 𝑅′ ∈ ′ Lemma 3, there exists a son of 𝜂 of 𝜂 labeled by 𝑅, such that 𝑅 ∘𝐹0 𝑅′ is deﬁned, and we can replace 𝜂 and 𝜂 ′ with a node 𝜂 ′′ labeled by 𝑅 ∘𝐹0 𝑅′ . Since all sons of 𝜂 ′ are labeled by elements of ℛ1 , 𝑅 ∈ ℛ1 . Hence sel (𝑅) = ∅. So, by Lemma 5, Property 2, 𝑅 ∘𝐹0 𝑅′ 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 𝜂 ′′ .

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

101

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 𝑅 ∘𝐹0 𝑅′ , 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 𝐷′ satisﬁes 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 deﬁnition 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 satisﬁes 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 𝑅 ∘𝐹0 𝑅′ is deﬁned and we can replace 𝜂 and 𝜂′ with a node 𝜂′′ labeled by 𝑅0 = 𝑅 ∘𝐹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 deﬁnition 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 deﬁnition 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 deﬁnition of deriv), so 𝑅′ ∈ derivable(𝐹, ℛ1 ). The other clauses of this derivation are in ℛ1 . By deﬁnition 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 𝑅 ∘𝐹0 𝑅′ , then it is also derivable by applying 𝑅 and 𝑅′ .) ⊔ ⊓

102

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

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 speciﬁc to protocols. Elimination of duplicate hypotheses If a clause contains several times the same hypotheses, 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 satisﬁed for some value of 𝑥. Decomposition of data constructors A data constructor is a constructor 𝑓 of arity 𝑛 that comes with associated destructors 𝑔𝑖 for 𝑖 ∈ {1, . . . , 𝑛} deﬁned 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 conclusion 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 tautologies 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 veriﬁer. (When this fact is of the form attacker(𝑀 ), 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 veriﬁer 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 optimizations. For a full proof, we refer the reader to [30, Appendix C].

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

103

2.4. Termination In general, the resolution algorithm may not terminate. (The derivability problem is undecidable.) 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 cryptographic primitives only public-key encryption and signatures with atomic keys, sharedkey 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: }a { Message 1. 𝐴 → 𝐵 : ⟨𝑐1 , [⟨𝑐0 , 𝑘⟩]sk 𝐴 ⟩ pk 𝐵 s Message 2. 𝐵 → 𝐴 : {∣⟨𝑐2 , 𝑠⟩∣}𝑘 Adding tags preserves the expected behavior of the protocol, that is, the attack-free executions 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 received messages and prevent confusions between messages. More formally, tagging prevents 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, efﬁcient 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 splitting terminates on protocols that blindly copy at most one term in each message. In contrast, 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 abstractions. 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 deﬁned cryptographic primitives by associating rewrite rules to destructors. Another way of deﬁning primitives is by equational theories, as in the applied

104

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

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 DifﬁeHellman key agreements. The Difﬁe-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 veriﬁcation approach can be extended to handle some equational theories. For example, the Difﬁe-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 generator of ℤ∗𝑝 . The equation exp(exp(g, 𝑥), 𝑦) = (g𝑥 )𝑦 mod 𝑝 = (g𝑦 )𝑥 mod 𝑝 = exp(exp(g, 𝑦), 𝑥) is satisﬁed. In ProVerif, following the ideas used in the applied pi calculus [6], we do not consider the underlying number theory; we work abstractly with the equation (4). The Difﬁe-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 𝐵 computes 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 deﬁnition 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, 𝑎), 𝑏) reduces to its two forms modulo the equational theory. The rewrite rules in the deﬁnition 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 equations 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 uniﬁcation, so it remains efﬁcient. However, it also has limitations; for example, it cannot handle associative functions, such as XOR, because it would generate an inﬁnite number of rewrite rules for the destructors. Recently, other treatments of equations that can handle XOR and Difﬁe-Hellman key agreements with more detailed algebraic relations (including equations of the multiplicative group modulo 𝑝) within the Horn clause approach have been proposed by Küsters and Truderung: they handle XOR provided one of its two arguments is a constant in the clauses that model the protocol [71] and Difﬁe-Hellman key agreements provided the exponents are constants in the clauses that model the protocol [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

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

105

of sessions, and to [76,45,65,78] for other treatments of Difﬁe-Hellman key agreements, using uniﬁcation 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 previously. These clauses can be generated automatically from a speciﬁcation 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 speciﬁcations, 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 form “if 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 distinguish two processes (i.e. protocols). Process equivalences can be used for formalizing various security properties, in particular by expressing that the attacker cannot distinguish a process from its speciﬁcation. ProVerif can prove particular 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 constants, 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 property 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 derivation [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 veriﬁer 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 NeedhamSchroeder 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 nontermination cases were some ﬂawed versions of the Woo-Lam shared-key protocol. The other protocols were veriﬁed in less than one second each on a Pentium M 1.8 GHz [30].

106

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

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 protocols 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 veriﬁcation of a certiﬁed 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 protocol 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 veriﬁcation tool TulaFale: 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 protocols in F# (a functional language of the Microsoft .NET environment): a subset of F# large enough for expressing security protocols is translated into the input 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 veriﬁed using correspondences, while secrecy of keys corresponds to strong secrecy. ∙ ProVerif was also used for verifying a certiﬁed email web service [74], a certiﬁed 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 analyzing 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.

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

107

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 certiﬁcation 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 veriﬁcation problem is 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 efﬁcient in practice. Acknowledgments This work owes much to discussions with Martín Abadi. I am very grateful to him for what he taught me. We thank Mark Ryan and Ben Smyth for comments on a draft of this chapter. This work was partly done at Bell Labs Research, Lucent Technologies, Palo Alto and at Max-Planck-Institut für Informatik, Saarbrücken. This chapter borrows material from [27,31,32].

References [1] [2]

[3] [4] [5] [6]

[7]

[8] [9] [10]

[11] [12] [13]

[14]

M. Abadi. Security protocols and their properties. In Foundations of Secure Computation, NATO Science Series, pages 39–60. IOS Press, 2000. 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 25–41. Springer, Apr. 2001. M. Abadi and B. Blanchet. Analyzing security protocols with secrecy types and logic programs. Journal of the ACM, 52(1):102–146, Jan. 2005. M. Abadi and B. Blanchet. Computer-assisted veriﬁcation of a protocol for certiﬁed email. Science of Computer Programming, 58(1–2):3–27, Oct. 2005. Special issue SAS’03. M. Abadi, B. Blanchet, and C. Fournet. Just Fast Keying in the pi calculus. ACM Transactions on Information and System Security (TISSEC), 10(3):1–59, July 2007. M. Abadi and C. Fournet. Mobile values, new names, and secure communication. In 28th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL’01), pages 104–115. ACM Press, Jan. 2001. M. Abadi, N. Glew, B. Horne, and B. Pinkas. Certiﬁed email with a light on-line trusted third party: Design and implementation. In 11th International World Wide Web Conference, pages 387–395. ACM Press, May 2002. M. Abadi and A. D. Gordon. A calculus for cryptographic protocols: The spi calculus. Information and Computation, 148(1):1–70, Jan. 1999. M. Abadi and R. Needham. Prudent engineering practice for cryptographic protocols. IEEE Transactions on Software Engineering, 22(1):6–15, Jan. 1996. 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):242–273, May 2004. X. Allamigeon and B. Blanchet. Reconstruction of attacks against cryptographic protocols. In 18th IEEE Computer Security Foundations Workshop (CSFW-18), pages 140–154. IEEE, June 2005. R. Anderson and R. Needham. Programming Satan’s computer. In Computer Science Today: Recent Trends and Developments, volume 1000 of LNCS, pages 426–440. Springer, 1995. M. Arapinis and M. Duﬂot. Bounding messages for free in security protocols. In 27th Conference on Foundations of Software Technology and Theoretical Computer Science (FSTTCS’07), volume 4855 of LNCS, pages 376–387. Springer, Dec. 2007. L. Bachmair and H. Ganzinger. Resolution theorem proving. In Handbook of Automated Reasoning, volume 1, chapter 2, pages 19–100. North Holland, 2001.

108 [15] [16]

[17]

[18]

[19]

[20] [21]

[22] [23]

[24]

[25]

[26]

[27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38]

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

M. Backes, A. Cortesi, and M. Maffei. Causality-based abstraction of multiplicity in security protocols. In 20th IEEE Computer Security Foundations Symposium (CSF’07), pages 355–369. IEEE, July 2007. M. Backes, C. Hritcu, and M. Maffei. Automated veriﬁcation of electronic voting protocols in the applied pi-calculus. In 21st IEEE Computer Security Foundations Symposium (CSF’08), pages 195–209. IEEE Computer Society, June 2008. 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 202–215. IEEE, May 2008. 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 72–84, May 1992. 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 244–250, Nov. 1993. K. Bhargavan, R. Corin, C. Fournet, and A. Gordon. Secure sessions for web services. In ACM Workshop on Secure Web Services (SWS’04), Oct. 2004. K. Bhargavan, R. Corin, C. Fournet, and E. Z˘alinescu. Cryptographically veriﬁed implementations for TLS. In Proceedings of the 15th ACM Conference on Computer and Communications Security (CCS’08), pages 459–468. ACM, Oct. 2008. K. Bhargavan, C. Fournet, and A. Gordon. Verifying policy-based security for web services. In ACM Conference on Computer and Communications Security (CCS’04), pages 268–277. ACM, Oct. 2004. K. Bhargavan, C. Fournet, and A. Gordon. Veriﬁed reference implementations of WS-Security protocols. In 3rd International Workshop on Web Services and Formal Methods (WS-FM 2006), volume 4184 of LNCS, pages 88–106. Springer, Sept. 2006. K. Bhargavan, C. Fournet, A. Gordon, and N. Swamy. Veriﬁed implementations of the information card federated identity-management protocol. In ACM Symposium on Information, Computer and Communications Security (ASIACCS’08), pages 123–135. ACM, Mar. 2008. K. Bhargavan, C. Fournet, A. Gordon, and S. Tse. Veriﬁed interoperable implementations of security protocols. In 19th IEEE Computer Security Foundations Workshop (CSFW’06), pages 139–152. IEEE Computer Society, July 2006. 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 197–222. Springer, Nov. 2003. Paper and tool available at http://securing.ws/. B. Blanchet. An efﬁcient cryptographic protocol veriﬁer based on Prolog rules. In 14th IEEE Computer Security Foundations Workshop (CSFW-14), pages 82–96. IEEE Computer Society, June 2001. B. Blanchet. Automatic proof of strong secrecy for security protocols. In IEEE Symposium on Security and Privacy, pages 86–100, May 2004. B. Blanchet. Security protocols: From linear to classical logic by abstract interpretation. Information Processing Letters, 95(5):473–479, Sept. 2005. B. Blanchet. Automatic veriﬁcation of correspondences for security protocols. Report arXiv:0802.3444v1, 2008. Available at http://arxiv.org/abs/0802.3444v1. B. Blanchet. Vériﬁcation automatique de protocoles cryptographiques : modèle formel et modèle calculatoire. Mémoire d’habilitation à diriger des recherches, Université Paris-Dauphine, Nov. 2008. B. Blanchet. Automatic veriﬁcation of correspondences for security protocols. Journal of Computer Security, 17(4):363–434, July 2009. B. Blanchet, M. Abadi, and C. Fournet. Automated veriﬁcation of selected equivalences for security protocols. Journal of Logic and Algebraic Programming, 75(1):3–51, Feb.–Mar. 2008. 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 417–431. IEEE, May 2008. B. Blanchet and A. Podelski. Veriﬁcation of cryptographic protocols: Tagging enforces termination. Theoretical Computer Science, 333(1-2):67–90, Mar. 2005. Special issue FoSSaCS’03. C. Bodei. Security Issues in Process Calculi. PhD thesis, Università di Pisa, Jan. 2000. C. Bodei, M. Buchholtz, P. Degano, F. Nielson, and H. R. Nielson. Static validation of security protocols. Journal of Computer Security, 13(3):347–390, 2005. C. Bodei, P. Degano, F. Nielson, and H. R. Nielson. Control ﬂow analysis for the 𝜋-calculus. In International Conference on Concurrency Theory (CONCUR’98), volume 1466 of LNCS, pages 84–98.

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

[39]

[40]

[41] [42] [43]

[44] [45]

[46] [47]

[48]

[49]

[50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60]

[61]

109

Springer, Sept. 1998. 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 467–480, Mar. 2006. D. Bolignano. Towards a mechanization of cryptographic protocol veriﬁcation. In 9th International Conference on Computer Aided Veriﬁcation (CAV’97), volume 1254 of LNCS, pages 131–142. Springer, 1997. L. Bozga, Y. Lakhnech, and M. Périn. Pattern-based abstraction for verifying secrecy in protocols. International Journal on Software Tools for Technology Transfer (STTT), 8(1):57–76, Feb. 2006. M. Burrows, M. Abadi, and R. Needham. A logic of authentication. Proceedings of the Royal Society of London A, 426:233–271, 1989. R. Canetti and J. Herzog. Universally composable symbolic analysis of mutual authentication and key exchange protocols. In Proceedings, Theory of Cryptography Conference (TCC’06), volume 3876 of LNCS, pages 380–403. Springer, Mar. 2006. L. Cardelli, G. Ghelli, and A. D. Gordon. Secrecy and group creation. In CONCUR 2000: Concurrency Theory, volume 1877 of LNCS, pages 365–379. Springer, Aug. 2000. Y. Chevalier, R. Küsters, M. Rusinowitch, and M. Turuani. Deciding the security of protocols with Difﬁe-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. Y. Chevalier, R. Küsters, M. Rusinowitch, and M. Turuani. An NP decision procedure for protocol insecurity with XOR. Theoretical Computer Science, 338(1–3):247–274, June 2005. H. Comon-Lundh and V. Cortier. New decidability results for fragments of ﬁrst-order logic and application to cryptographic protocols. In 14th Int. Conf. Rewriting Techniques and Applications (RTA’2003), volume 2706 of LNCS, pages 148–164. Springer, June 2003. H. Comon-Lundh and V. Cortier. Security properties: two agents are sufﬁcient. In Programming Languages and Systems: 12th European Symposium on Programming (ESOP’03), volume 2618 of LNCS, pages 99–113. Springer, Apr. 2003. 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 (LICS’03), pages 271–280. IEEE Computer Society, June 2003. P. Cousot and R. Cousot. Systematic design of program analysis frameworks. In 6th Annual ACM Symposium on Principles of Programming Languages, pages 269–282, 29-31 Jan. 1979. H. de Nivelle. Ordering Reﬁnements of Resolution. PhD thesis, Technische Universiteit Delft, Oct. 1995. G. Denker, J. Meseguer, and C. Talcott. Protocol speciﬁcation and analysis in Maude. In Workshop on Formal Methods and Security Protocols, 25 June 1998. D. E. Denning and G. M. Sacco. Timestamps in key distribution protocols. Commun. ACM, 24(8):533– 536, Aug. 1981. W. Difﬁe and M. Hellman. New directions in cryptography. IEEE Transactions on Information Theory, IT-22(6):644–654, Nov. 1976. D. Dolev and A. C. Yao. On the security of public key protocols. IEEE Transactions on Information Theory, IT-29(12):198–208, Mar. 1983. 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):247–311, 2004. 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):162–202, 2006. G. Filé and R. Vigo. Expressive power of deﬁnite clauses for verifying authenticity. In 22nd IEEE Computer Security Foundations Symposium (CSF’09), pages 251–265. IEEE, July 2009. T. Genet and F. Klay. Rewriting for cryptographic protocol veriﬁcation. In 17th International Conference on Automated Deduction (CADE-17), volume 1831 of LNCS, pages 271–290. Springer, June 2000. J. C. Godskesen. Formal veriﬁcation of the ARAN protocol using the applied pi-calculus. In 6th International IFIP WG 1.7 Workshop on Issues in the Theory of Security (WITS’06), pages 99–113, Mar. 2006. A. Gordon and A. Jeffrey. Authenticity by typing for security protocols. Journal of Computer Security, 11(4):451–521, 2003.

110 [62]

[63] [64]

[65]

[66] [67]

[68]

[69] [70]

[71]

[72] [73]

[74]

[75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85]

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

J. Goubault-Larrecq. A method for automatic cryptographic protocol veriﬁcation (extended abstract), invited paper. In Fifth International Workshop on Formal Methods for Parallel Programming: Theory and Applications (FMPPTA’2000), volume 1800 of LNCS, pages 977–984. Springer, May 2000. J. Goubault-Larrecq. Deciding ℋ1 by resolution. Information Processing Letters, 95(3):401–408, Aug. 2005. J. Goubault-Larrecq and F. Parrennes. Cryptographic protocol analysis on real C code. In Proceedings of the 6th International Conference on Veriﬁcation, Model Checking and Abstract Interpretation (VMCAI’05), volume 3385 of LNCS, pages 363–379. Springer, Jan. 2005. J. Goubault-Larrecq, M. Roger, and K. N. Verma. Abstraction and resolution modulo AC: How to verify Difﬁe-Hellman-like protocols automatically. Journal of Logic and Algebraic Programming, 64(2):219– 251, Aug. 2005. 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 255–268, July 2000. 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 (FAST’03), pages 29–42. Usenix, Apr. 2003. H. Khurana and H.-S. Hahm. Certiﬁed mailing lists. In Proceedings of the ACM Symposium on Communication, Information, Computer and Communication Security (ASIACCS’06), pages 46–58. ACM, Mar. 2006. H. Krawczyk. SKEME: A versatile secure key exchange mechanism for Internet. In Internet Society Symposium on Network and Distributed Systems Security, Feb. 1996. S. Kremer and M. D. Ryan. Analysis of an electronic voting protocol in the applied pi calculus. In Programming Languages and Systems: 14th European Symposium on Programming, ESOP 2005, volume 3444 of LNCS, pages 186–200. Springer, Apr. 2005. R. Küsters 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 (CCS’08), pages 129–138. ACM, Oct. 2008. R. Küsters and T. Truderung. Using ProVerif to analyze protocols with Difﬁe-Hellman exponentiation. In 22nd IEEE Computer Security Foundations Symposium (CSF’09), pages 157–171. IEEE, July 2009. G. Lowe. Breaking and ﬁxing the Needham-Schroeder public-key protocol using FDR. In Tools and Algorithms for the Construction and Analysis of Systems, volume 1055 of LNCS, pages 147–166. Springer, 1996. 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 (ICWS’05), pages 75–82. IEEE Computer Society, July 2005. C. Lynch. Oriented equational logic programming is complete. Journal of Symbolic Computation, 21(1):23–45, 1997. C. Meadows and P. Narendran. A uniﬁcation algorithm for the group Difﬁe-Hellman protocol. In Workshop on Issues in the Theory of Security (WITS’02), Jan. 2002. C. A. Meadows. The NRL protocol analyzer: An overview. Journal of Logic Programming, 26(2):113– 131, 1996. J. Millen and V. Shmatikov. Symbolic protocol analysis with an abelian group operator or DifﬁeHellman exponentiation. Journal of Computer Security, 13(3):515–564, 2005. J. K. Millen, S. C. Clark, and S. B. Freedman. The Interrogator: Protocol security analysis. IEEE Transactions on Software Engineering, SE-13(2):274–288, Feb. 1987. D. Monniaux. Abstracting cryptographic protocols with tree automata. Science of Computer Programming, 47(2–3):177–202, 2003. R. M. Needham and M. D. Schroeder. Using encryption for authentication in large networks of computers. Commun. ACM, 21(12):993–999, Dec. 1978. R. M. Needham and M. D. Schroeder. Authentication revisited. Operating Systems Review, 21(1):7, 1987. D. Otway and O. Rees. Efﬁcient and timely mutual authentication. Operating Systems Review, 21(1):8– 10, 1987. L. C. Paulson. The inductive approach to verifying cryptographic protocols. Journal of Computer Security, 6(1–2):85–128, 1998. R. Ramanujam and S. Suresh. Tagging makes secrecy decidable with unbounded nonces as well. In

B. Blanchet / Using Horn Clauses for Analyzing Security Protocols

111

FST TCS 2003: Foundations of Software Technology and Theoretical Computer Science, volume 2914 of LNCS, pages 363–374. Springer, Dec. 2003. [86] C. Weidenbach. Towards an automatic analysis of security protocols in ﬁrst-order logic. In 16th International Conference on Automated Deduction (CADE-16), volume 1632 of Lecture Notes in Artiﬁcial Intelligence, pages 314–328. Springer, July 1999. [87] T. Y. C. Woo and S. S. Lam. Authentication for distributed systems. Computer, 25(1):39–52, Jan. 1992. [88] T. Y. C. Woo and S. S. Lam. Authentication for distributed systems. In Internet Besieged: Countering Cyberspace Scofﬂaws, pages 319–355. ACM Press and Addison-Wesley, Oct. 1997.

112

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. doi:10.3233/978-1-60750-714-7-112

Applied pi calculus Mark D. RYAN and Ben SMYTH School of Computer Science, University of Birmingham, United Kingdom e-mail: [email protected], [email protected] 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 process 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 veriﬁcation, formal methods, reachability, 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 semantics 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 modelled 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: ∙ Certiﬁed email [4]; ∙ Privacy properties [38,34,12,40], and election-veriﬁability properties [39] in electronic voting; ∙ Authorisation protocols [27,43], and attestation protocols [46,13] in trusted computing; ∙ 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].

M.D. Ryan and B. Smyth / Applied pi Calculus

113

1.1. Handshake protocol We recall the na¨ıve 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 server’s 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 client’s public key pk(𝑠𝑘𝒞 ). When 𝒞 receives this message he decrypts it using his private key 𝑠𝑘𝒞 , veriﬁes 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 (𝒮) {∣[𝑘]𝑠𝑘𝒮 ∣}apk(𝑠𝑘𝒞 ) {∣𝑠∣}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 speciﬁcation 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 𝒞.

114

M.D. Ryan and B. Smyth / Applied pi Calculus

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 speciﬁcally 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 deﬁned by means of an equational theory. 2.1. Syntax and informal semantics The calculus assumes an inﬁnite set of names, an inﬁnite set of variables and a signature Σ consisting of a ﬁnite set of function symbols each with an associated arity. Function 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 function application 𝑔(𝑀1 , . . . , 𝑀𝑙 ) 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 ˜ . We write {𝑀 /𝑥} for the syntactic substitution (usuoccasionally abbreviated 𝑢 ˜ and 𝑀 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.

M.D. Ryan and B. Smyth / Applied pi Calculus

115

The grammar for processes is shown below: 𝑃, 𝑄, 𝑅 ::= 0 𝑃 ∣𝑄 !𝑃 𝜈 𝑛.𝑃 if 𝑀 = 𝑁 then 𝑃 else 𝑄 𝑢(𝑥).𝑃 𝑢⟨𝑀 ⟩.𝑃

processes (or plain processes) null process parallel composition replication name restriction 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 inﬁnite composition 𝑃 ∣ 𝑃 ∣ . . ., which is often used to capture an unbounded number of sessions. Name restriction 𝜈 𝑛.𝑃 binds 𝑛 inside 𝑃 , the introduction of restricted names (or private names) is useful to capture both fresh random numbers (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

116

M.D. Ryan and B. Smyth / Applied pi Calculus

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 active 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 substitution 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 substitutions are processes, whereas syntactic substitions are not. In addition, their semantic behaviours differ. Syntactic substitutions can be applied directly to processes; for example, the application of a syntactic substitution 𝜎 to the free variables of an extended process 𝐴 is written 𝐴𝜎. By contrast, active substitutions cannot be applied directly to processes (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 inﬁnite 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 deﬁned 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 conﬁrmed [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 deﬁne 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

M.D. Ryan and B. Smyth / Applied pi Calculus

117

𝑢(𝑥). 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 deﬁned 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 substitutions {𝑀 /𝑥}; 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 process 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(𝑥, 𝑧), 𝑦)⟩) ∣ (𝜈 𝑠.{𝑠/𝑥}) ∣ {ℎ(𝑥, 𝑠′ )/𝑧 }) deﬁned 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 identiﬁers 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 deﬁned with respect to the signature Σ𝐻 = {true, fst, snd, hash, pk, getmsg, pair, sdec, senc, adec, aenc, sign, checksign, mac} where 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 functions is captured by the smallest equational theory 𝐸𝐻 satisfying the following equations over variables 𝑥, 𝑦:

118

M.D. Ryan and B. Smyth / Applied pi Calculus

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 cryptography, digital signature schemes with message recovery, hash functions and message authentication codes. For example, in order to express that the application of the symmetric decryption function sdec to the term modelling a symmetric encryption senc(𝑘, 𝑚) should return the plaintext 𝑚 if the correct key 𝑘 is supplied, we use the equation sdec(𝑥, senc(𝑥, 𝑦)) = 𝑦. The absence of any equational theory associated with the hash function ensures preimage resistance, second-preimage resistance and collision resistance properties of cryptographic hash functions (in fact, far stronger properties are ensured); and similar properties for the function mac. Observe 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 using the equations deﬁned for fst, snd. The Handshake protocol can now be captured in our calculus as the process 𝑃 , deﬁned 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 𝒞, 𝒮 respectively. The public key parts pk(𝑠𝑘𝒞 ), pk(𝑠𝑘𝒮 ) are then output on the public communication 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 syntactic scope does not represent the knowledge of a protocol’s participants. For example, the server’s 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 interlocutor’s 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.

M.D. Ryan and B. Smyth / Applied pi Calculus

119

Figure 1. Properties of equality modulo the equational theory Given an equational theory 𝐸 the following properties are satisﬁed for all terms 𝐿, 𝑀, 𝑁 , functions 𝑓 of arity 𝑙, substitutions 𝜎 and names 𝑚, 𝑛: 1. 𝑀 = 𝑁 ∈ 𝐸 ⇒ 𝑀 =𝐸 𝑁 2. Equivalence relation: ∙ Reﬂexivity: 𝑀 =𝐸 𝑀 ∙ Symmetry: 𝑀 =𝐸 𝑁 ⇒ 𝑁 =𝐸 𝑀 ∙ Transitivity: 𝐿 =𝐸 𝑀 ∧ 𝑀 =𝐸 𝑁 ⇒ 𝐿 =𝐸 𝑁 3. Application of function symbols: 𝑀1 =𝐸 𝑁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 interlocutor’s public key 𝑥 𝑝𝑘. Meanwhile 𝒞 awaits the input of his interlocutor’s 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 𝑠 encrypted 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 conﬁrms 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 interlocutor’s secret; that is, 𝑄 is deﬁned by the process let 𝑧 𝑠 = snd(sdec(𝑘, 𝑧)) in 𝑄′ for some 𝑄′ . The purpose of the protocol is to establish a session key to transport the secret represented 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 deﬁned over the signature Σ (sometimes written 𝑀, 𝑁 ∈ 𝑇Σ ). This allows us to capture relationships between primitives deﬁned in Σ. We deﬁne 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:

120

M.D. Ryan and B. Smyth / Applied pi Calculus

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 deﬁne 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 PAR -A PAR -C R EPL

𝐴≡𝐴∣0 𝐴 ∣ (𝐵 ∣ 𝐶) ≡ (𝐴 ∣ 𝐵) ∣ 𝐶 𝐴∣𝐵≡𝐵 ∣𝐴 !𝑃 ≡ 𝑃 ∣ !𝑃

N EW-0 𝜈 𝑛.0 ≡ 0 N EW-C 𝜈 𝑢.𝜈 𝑤.𝐴 ≡ 𝜈 𝑤.𝜈 𝑢.𝐴 N EW-PAR 𝐴 ∣ 𝜈 𝑢.𝐵 ≡ 𝜈 𝑢.(𝐴 ∣ 𝐵) where 𝑢 ∕∈ fv(𝐴) ∪ fn(𝐴) A LIAS 𝜈 𝑥.{𝑀 /𝑥} ≡ 0 S UBST {𝑀 /𝑥} ∣ 𝐴 ≡ {𝑀 /𝑥} ∣ 𝐴{𝑀 /𝑥} R EWRITE {𝑀 /𝑥} ≡ {𝑁 /𝑥} where 𝑀 =𝐸 𝑁 The rules for parallel composition, replication and restriction are self-explanatory. A LIAS enables the introduction of an arbitrary active substitution with restricted scope. S UBST 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 substitutions 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 occurrences of 𝑥 in 𝐴 should be replaced by 𝑀 (in such a way that no names or variables in 𝑀 become bound). The ﬁnal rule, R EWRITE, allows terms that are equal modulo the equational theory to be swapped as desired.

M.D. Ryan and B. Smyth / Applied pi Calculus

121

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 ifstatements are evaluated and the then- or else-branch is taken, or because internal subprocesses communicate with each other. The execution of a process with respect to control ﬂow and communication is captured by internal reduction. Formally, internal reduction (− →) is the smallest relation on extended processes closed under structural equivalence and application of evaluation contexts such that: C OMM

𝑐⟨𝑥⟩.𝑃 ∣ 𝑐(𝑥).𝑄 − →𝑃 ∣𝑄

T HEN

if 𝑁 = 𝑁 then 𝑃 else 𝑄 − →𝑃

E LSE

if 𝐿 = 𝑀 then 𝑃 else 𝑄 − →𝑄 for ground terms 𝐿, 𝑀 where 𝐿 ∕=𝐸 𝑀

Communication (C OMM) is deﬁned on variables, making it look rather restricted. However, this entails no loss of generality because A LIAS and S UBST can be used to allow 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 C OMM, we derive 𝑃 ∣ 𝑄{𝑀 /𝑥} by application of an evaluation context. To see this step in more detail, consider 𝐶[ ] = 𝜈 𝑥.( ∣ {𝑀 /𝑥}) and observe 𝜈 𝑥.(𝑐⟨𝑥⟩.𝑃 ∣ 𝑐(𝑥).𝑄 ∣ {𝑀 /𝑥}) = 𝐶[𝑐⟨𝑥⟩.𝑃 ∣ 𝑐(𝑥).𝑄] − → 𝐶[𝑃 ∣ 𝑄] which is struc→ is closed under structural equivalence, we turally equivalent to 𝑃 ∣ 𝑄{𝑀 /𝑥}. Since − have 𝑐⟨𝑀 ⟩.𝑃 ∣ 𝑐(𝑥).𝑄 − → 𝑃 ∣ 𝑄{𝑀 /𝑥}. Conditionals (T HEN and E LSE) are dependent on the equational theory. Applications of T HEN may require the use of the structural equivalence rule R EWRITE to derive “𝑁 = 𝑁 ” from “𝑀 = 𝑁 ” where 𝑀 =𝐸 𝑁 . E LSE may require that active substitutions in the context be applied using A LIAS and S UBST 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 represented by a context. In order to prove that security properties hold for all adversaries, quantiﬁcation over all contexts is typically required, which can be difﬁcult in practice. The labelled operational semantics we now present aim to eliminate universal quantiﬁcation of the context. 𝛼 → 𝐵, where 𝛼 is a label The labelled semantics deﬁnes a ternary relation written, 𝐴 − 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

122

M.D. Ryan and B. Smyth / Applied pi Calculus

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

𝑐⟨𝑢⟩

𝑐⟨𝑢⟩.𝑃 −−−→ 𝑃

O UT-ATOM

𝑐⟨𝑢⟩

𝐴 −−−→ 𝐴′

O PEN -ATOM

𝜈 𝑢.𝐴 −−−−−→ 𝐴′ 𝛼

𝐴− → 𝐴′

S COPE

𝑢 does not occur in 𝛼 𝛼

𝜈 𝑢.𝐴 − → 𝜈 𝑢.𝐴′ 𝛼

PAR

𝑢 ∕= 𝑐

𝜈 𝑢.𝑐⟨𝑢⟩

𝐴− → 𝐴′

S TRUCT

bv(𝛼) ∩ fv(𝐵) = bn(𝛼) ∩ fn(𝐵) = ∅ 𝛼

𝐴∣𝐵− → 𝐴′ ∣ 𝐵 𝐴≡𝐵

𝛼

𝐵− → 𝐵′ 𝛼

𝐵 ′ ≡ 𝐴′

𝐴− → 𝐴′

The rule O PEN -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: O UT-ATOM 𝑐⟨𝑥⟩ 𝑐⟨𝑥⟩.𝑃 −−→ 𝑃 PAR 𝑐⟨𝑥⟩ 𝑐⟨𝑥⟩.𝑃 ∣ {𝑀 /𝑥} −−→ 𝑃 ∣ {𝑀 /𝑥} O PEN -ATOM 𝜈 𝑥.𝑐⟨𝑥⟩ 𝑐⟨𝑀 ⟩.𝑃 ≡ 𝜈 𝑥.(𝑐⟨𝑥⟩.𝑃 ∣ {𝑀 /𝑥}) −−−−−→ 𝑃 ∣ {𝑀 /𝑥} ≡ 𝑃 ∣ {𝑀 /𝑥} S TRUCT 𝜈 𝑥.𝑐⟨𝑥⟩ 𝑀 𝑐⟨𝑀 ⟩.𝑃 −−−−−→ 𝑃 ∣ { /𝑥} Note that the fact 𝑥 ∕∈ fv(𝑃 ) is needed for the ﬁrst of the two structural equivalences in the occurrence of S TRUCT. Example 4 (Labelled semantics) Consider the process 𝐴 ≜ 𝑐⟨𝑚⟩.𝑐⟨𝑚⟩. Show the re𝜈 𝑥.𝑐⟨𝑥⟩ 𝜈 𝑦.𝑐⟨𝑦⟩

𝜈 𝑥.𝑐⟨𝑥⟩ 𝑐⟨𝑥⟩

ductions 𝐴 −−−−−→−−−−−→ {𝑚/𝑥} ∣ {𝑚/𝑦 }. Also show the reductions 𝐴 −−−−−→−−→ {𝑚/𝑥}. (Hint. The last one involves an application of S UBST.) 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 environment’s use of names is controlled.

M.D. Ryan and B. Smyth / Applied pi Calculus

123

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 environment, 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 execution: 𝐴′′

𝜈 𝑦.𝑐⟨𝑦⟩

−−−−−→

𝑐(sdec(𝑘,𝑦))

𝜈 𝑠.(𝑐(𝑥).if 𝑥 = 𝑠 then 𝑐⟨𝑖 𝑔𝑜𝑡 𝑠⟩ ∣ {senc(𝑘, 𝑠)/𝑦 })

−−−−−−−→ 𝜈 𝑠.(if sdec(𝑘, 𝑦) = 𝑠 then 𝑐⟨𝑖 𝑔𝑜𝑡 𝑠⟩ ∣ {senc(𝑘, 𝑠)/𝑦 }) ≡ 𝜈 𝑠.(if sdec(𝑘, senc(𝑘, 𝑠)) = 𝑠 then 𝑐⟨𝑖 𝑔𝑜𝑡 𝑠⟩ ∣ {senc(𝑘, 𝑠)/𝑦 }) ≡ 𝜈 𝑠.(if 𝑠 = 𝑠 then 𝑐⟨𝑖 𝑔𝑜𝑡 𝑠⟩ ∣ {senc(𝑘, 𝑠)/𝑦}) − → 𝜈 𝑠.(𝑐⟨𝑖 𝑔𝑜𝑡 𝑠⟩ ∣ {senc(𝑘, 𝑠)/𝑦}) 𝜈 𝑧.𝑐⟨𝑧⟩

−−−−−→ 𝜈 𝑠.({senc(𝑘, 𝑠)/𝑦 } ∣ {𝑖 𝑔𝑜𝑡 𝑠/𝑧 }) ≡ 𝜈 𝑠.({senc(𝑘, 𝑠)/𝑦 }) ∣ {𝑖 𝑔𝑜𝑡 𝑠/𝑧 } The ﬁrst of the equivalences ≡ holds by the rule S UBST; the second one is by R EWRITE , 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 I N and S COPE, because I N asks us to perform the substitution

124

M.D. Ryan and B. Smyth / Applied pi Calculus

𝜈 𝑠.(if 𝑥 = 𝑠 then 𝑐⟨𝑖 𝑔𝑜𝑡 𝑠⟩{𝑠/𝑥}) which would insert the 𝑠 from the substitution into the scope of the 𝜈𝑠. As previously 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 deﬁnitions of secrecy and correspondence in the presence of an adversary who has full control of the network. The attacker can therefore eavesdrop, 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 protocol’s 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. Deﬁnition 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 “!”. Deﬁnition 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 reduction 𝑃 − →∗ 𝐶[𝑐⟨𝑀 ⟩.𝑅] holds with no alpha-renaming of the names in fn(𝑀 ). In Deﬁnition 2, the process 𝐶[𝑐⟨𝑀 ⟩.𝑅] is capable of outputting the term 𝑀 on the free channel 𝑐 in one further step. Note that the deﬁnition 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 𝑠.

M.D. Ryan and B. Smyth / Applied pi Calculus

125

Deﬁnition 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 deﬁnition 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 deﬁnition 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 fst(sdec(𝑘, 𝑧)) = 𝑡𝑎𝑔 then 𝑄 ∣ 𝑐(𝑦).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 N EW-C, N EW-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 R EWRITE 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.)

126

M.D. Ryan and B. Smyth / Applied pi Calculus

6. The conditional is evaluated and 𝒞 sends the value senc(𝑘, pair(𝑡𝑎𝑔, 𝑠)) to the adversary. 7. Observe that 𝑐⟨snd(sdec(𝑘, senc(𝑘, pair(𝑡𝑎𝑔, 𝑠))))⟩ ≡ 𝑐⟨𝑠⟩ and hence the adversary 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 previously executed.” Moreover, these events may contain arguments, which allow relationships 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 sufﬁcient 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 condition 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 {𝑀 /𝑒}. Deﬁnition 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

M.D. Ryan and B. Smyth / Applied pi Calculus

127

𝑃 ≜ 𝜈 𝑠𝑘𝒮 .𝜈 𝑠𝑘𝒞 .𝜈 𝑠. let 𝑝𝑘𝑆 = pk(𝑠𝑘𝒮 ) in let 𝑝𝑘𝐶 = pk(𝑠𝑘𝒞 ) in (𝑐⟨𝑝𝑘𝑆 ⟩ ∣ 𝑐⟨𝑝𝑘𝐶 ⟩ ∣ !𝑃𝒮 ∣ !𝑃𝒞 ) 𝑃𝒮 ≜ 𝑐(𝑥 𝑝𝑘).𝜈 𝑘.𝑠𝑡𝑎𝑟𝑡𝑒𝑑𝑆⟨pair(𝑥 𝑝𝑘, 𝑘)⟩ 𝑐⟨aenc(𝑥 𝑝𝑘, sign(𝑠𝑘𝒮 , 𝑘))⟩. 𝑐(𝑧).if fst(sdec(𝑘, 𝑧)) = 𝑡𝑎𝑔 then 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑𝑆⟨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 session 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 completed the protocol with 𝒮 using session key 𝑦 𝑘, where 𝑝𝑘𝒞 is his public key. Correspondence properties can now be deﬁned 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 correspondence 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 deﬁne the validity of a correspondence property in Deﬁnition 5. Intuitively, it ensures that if the event 𝑓 is executed, then the event 𝑔 must have been previously executed. Moreover, the parametrisation of the events must satisfy any relationships deﬁned by 𝑀, 𝑁 ; that is, the variables fv(𝑀 ) ∩ fv(𝑁 ) must be parametrised in the same way.

128

M.D. Ryan and B. Smyth / Applied pi Calculus

Deﬁnition 5 (Validity of correspondence property) Let 𝐸 be an equational theory, and 𝐴0 an extended process. We say that 𝐴0 satisﬁes the correspondence property 𝑓 ⟨𝑀 ⟩ ⇝ 𝑔⟨𝑁 ⟩ if for all execution paths 𝛼

𝛼

𝛼

1 2 𝑛 ∗ ∗ ∗ 𝐴1 →∗ −→→ ⋅ ⋅ ⋅ →∗ −−→→ 𝐴𝑛 , 𝐴0 →∗ −→→

and all index 𝑖 ∈ ℕ, substitution 𝜎 and variable 𝑒 such that 𝛼𝑖 = 𝜈 𝑒.𝑓 ⟨𝑒⟩ and 𝑒𝜑(𝐴𝑖 ) =𝐸 𝑀 𝜎, there exists 𝑗 ∈ ℕ and 𝑒′ such that 𝛼𝑗 = 𝜈 𝑒′ .𝑔⟨𝑒′ ⟩, 𝑒′ 𝜑(𝐴𝑗 ) =𝐸 𝑁 𝜎 and 𝑗 < 𝑖. Example 7 (Reasoning with correspondence) Consider the annotated Handshake protocol (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 arguments. 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 environment’s 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 occurrences of the rules S UBST and R EWRITE ). 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 Deﬁnition 5 are violated; we have 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑𝐶⟨𝑒3 ⟩, and although 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 deﬁnition of correspondence we have just discussed is insufﬁcient to capture injective relationships between events; making it unsuitable for certain authentication properties. 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].

M.D. Ryan and B. Smyth / Applied pi Calculus

129

Figure 2. Execution of Handshake protocol, part I (labelled semantics) 𝜈 𝑦 𝑝𝑘.𝑐⟨𝑦 𝑝𝑘⟩

1. 𝑃 −−−−−−−−−→

2.

𝑐(pk(𝑠𝑘𝑀 ))

𝐶[𝑐⟨pk(𝑠𝑘𝒮 )⟩ ∣ {pk(𝑠𝑘𝒞 )/𝑦 𝑝𝑘} ∣ 𝑐(𝑥 𝑝𝑘).𝜈 𝑘.𝑠𝑡𝑎𝑟𝑡𝑒𝑑𝑆⟨pair(𝑥 𝑝𝑘, 𝑘)⟩. 𝑐⟨aenc(𝑥 𝑝𝑘, sign(𝑠𝑘𝒮 , 𝑘))⟩. 𝑐(𝑧).if fst(sdec(𝑘, 𝑧)) = 𝑡𝑎𝑔 then 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑𝑆⟨pair(𝑘, eq(𝑥 𝑝𝑘, pk(𝑠𝑘𝒞 )))⟩.𝑄 ∣ 𝑐(𝑦). let 𝑦 ′ = adec(𝑠𝑘𝒞 , 𝑦) in let 𝑦 𝑘 = getmsg(𝑦 ′ ) in 𝑠𝑡𝑎𝑟𝑡𝑒𝑑𝐶⟨𝑦 𝑘⟩. if checksign(pk(𝑠𝑘𝒮 ), 𝑦 ′ ) = true then 𝑐⟨senc(𝑦 𝑘, pair(𝑡𝑎𝑔, 𝑠))⟩ 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑𝐶⟨pair(pk(𝑠𝑘𝒞 ), 𝑦 𝑘)⟩]

−−−−−−−→ 𝜈 𝑒1 .𝑠𝑡𝑎𝑟𝑡𝑒𝑑𝑆⟨𝑒1 ⟩

3. −−−−−−−−−−−→ 4.

𝜈 𝑥.𝑐⟨𝑥⟩

−−−−−→

𝜈 𝑘.𝐶[𝑐⟨pk(𝑠𝑘𝒮 )⟩ ∣ {pk(𝑠𝑘𝒞 )/𝑦 𝑝𝑘} ∣ {pair(pk(𝑠𝑘𝑀 ), 𝑘)/𝑒1 } ∣ {aenc(pk(𝑠𝑘𝑀 ), sign(𝑠𝑘𝒮 , 𝑘))/𝑥} ∣ 𝑐(𝑧).if fst(sdec(𝑘, 𝑧)) = 𝑡𝑎𝑔 then 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑𝑆⟨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 satisﬁes the correspondence 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒⟨𝑥⟩ ⇝ 𝑠𝑡𝑎𝑟𝑡⟨𝑥⟩, but permits two occurrences of the event 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒⟨𝑛⟩ to be matched by a single event 𝑠𝑡𝑎𝑟𝑡⟨𝑛⟩. Injective correspondence properties are denoted by the presence of the keyword inj. Deﬁnition 6 (Injective correspondence property) An injective correspondence property 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 satisﬁed. 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 𝑒, 𝑒′ .

130

M.D. Ryan and B. Smyth / Applied pi Calculus

Figure 3. Execution of Handshake protocol, part II (labelled semantics) 𝑐(aenc(𝑦 𝑝𝑘,adec(𝑠𝑘𝑀 ,𝑥)))

5. −−−−−−−−−−−−−−−−→

6.

≡

7.

−−−−−−−−−−−→

8.

→−−−−−→ −

9.

−−−−−−−−−−−−−→

𝜈 𝑘.𝐶[𝑐⟨pk(𝑠𝑘𝒮 )⟩ ∣ {pk(𝑠𝑘𝒞 )/𝑦 𝑝𝑘} ∣ {pair(pk(𝑠𝑘𝑀 ), 𝑘)/𝑒1 } ∣ {aenc(pk(𝑠𝑘𝑀 ), sign(𝑠𝑘𝒮 , 𝑘))/𝑥} ∣ 𝑐(𝑧).if fst(sdec(𝑘, 𝑧)) = 𝑡𝑎𝑔 then 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑𝑆⟨pair(𝑘, eq(pk(𝑠𝑘𝑀 ), pk(𝑠𝑘𝒞 )))⟩.𝑄 ∣ let 𝑦 ′ = adec(𝑠𝑘𝒞 , aenc(𝑦 𝑝𝑘, adec(𝑠𝑘𝑀 , 𝑥))) in let 𝑦 𝑘 = getmsg(𝑦 ′ ) in 𝑠𝑡𝑎𝑟𝑡𝑒𝑑𝐶⟨𝑦 𝑘⟩. if checksign(pk(𝑠𝑘𝒮 ), 𝑦 ′ ) = true then 𝑐⟨senc(𝑦 𝑘, pair(𝑡𝑎𝑔, 𝑠))⟩ 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑𝐶⟨pair(pk(𝑠𝑘𝒞 ), 𝑦 𝑘)⟩] 𝜈 𝑘.𝐶[𝑐⟨pk(𝑠𝑘𝒮 )⟩ ∣ {pk(𝑠𝑘𝒞 )/𝑦 𝑝𝑘} ∣ {pair(pk(𝑠𝑘𝑀 ), 𝑘)/𝑒1 } ∣ {aenc(pk(𝑠𝑘𝑀 ), sign(𝑠𝑘𝒮 , 𝑘))/𝑥} ∣ 𝑐(𝑧).if fst(sdec(𝑘, 𝑧)) = 𝑡𝑎𝑔 then 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑𝑆⟨pair(𝑘, eq(pk(𝑠𝑘𝑀 ), pk(𝑠𝑘𝒞 )))⟩.𝑄 ∣ 𝑠𝑡𝑎𝑟𝑡𝑒𝑑𝐶⟨𝑘⟩. if true = true then 𝑐⟨senc(𝑘, pair(𝑡𝑎𝑔, 𝑠))⟩ 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑𝐶⟨pair(pk(𝑠𝑘𝒞 ), 𝑘)⟩]

𝜈 𝑒2 .𝑠𝑡𝑎𝑟𝑡𝑒𝑑𝐶⟨𝑒2 ⟩

𝜈 𝑧.𝑐⟨𝑧⟩

𝜈 𝑒3 .𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑𝐶⟨𝑒3 ⟩

𝜈 𝑘.𝐶[𝑐⟨pk(𝑠𝑘𝒮 )⟩ ∣ {pk(𝑠𝑘𝒞 )/𝑦 𝑝𝑘} ∣ {pair(pk(𝑠𝑘𝑀 ), 𝑘)/𝑒1 } ∣ {aenc(pk(𝑠𝑘𝑀 ), sign(𝑠𝑘𝒮 , 𝑘))/𝑥} ∣ 𝑐(𝑧).if fst(sdec(𝑘, 𝑧)) = 𝑡𝑎𝑔 then 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑𝑆⟨pair(𝑘, eq(pk(𝑠𝑘𝑀 ), pk(𝑠𝑘𝒞 )))⟩.𝑄 ∣ { 𝑘 /𝑒 2 } ∣ {senc(𝑘, pair(𝑡𝑎𝑔, 𝑠))/𝑧 } ∣ {pair(pk(𝑠𝑘𝒞 ), 𝑘)/𝑒3 }]

Deﬁnition 7 (Validity of injective correspondence property) Let 𝐸 be an equational theory, and 𝐴0 an extended process. We say that 𝐴0 satisﬁes the injective correspondence property 𝑓 ⟨𝑀 ⟩ ⇝ inj 𝑔⟨𝑁 ⟩ if for all execution paths 𝛼

𝛼

𝛼

1 2 𝑛 ∗ ∗ ∗ 𝐴0 →∗ −→→ 𝐴1 →∗ −→→ ⋅ ⋅ ⋅ →∗ −−→→ 𝐴𝑛 ,

there exists a partial injective function ℎ : {1, . . . , 𝑛} − → {1, . . . , 𝑛} such that for all 𝑖 ∈ {1, . . . , 𝑛}, substitution 𝜎 and variable 𝑒 such that 𝛼𝑖 = 𝜈 𝑒.𝑓 ⟨𝑒⟩ and 𝑒𝜑(𝐴𝑖 ) =𝐸 𝑀 𝜎, then the following conditions are satisﬁed: (1) ℎ(𝑖) is deﬁned; (2) 𝛼ℎ(𝑖) = 𝜈 𝑒′ .𝑔⟨𝑒′ ⟩ for some 𝑒′ such that 𝑒′ 𝜑(𝐴ℎ(𝑖) ) =𝐸 𝑁 𝜎; and, (3) ℎ(𝑖) < 𝑖.

M.D. Ryan and B. Smyth / Applied pi Calculus

131

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 Handshake 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 attack 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 deﬁne strong notions of secrecy and privacy. A natural starting point for deﬁning 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 deﬁnition motivated above is hard to compute, and instead a stronger deﬁnition is often used. The stronger deﬁnition, 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 deﬁne it rigorously as follows.

132

M.D. Ryan and B. Smyth / Applied pi Calculus

Deﬁnition 8 (Observational equivalence) Observational equivalence (≈) is the largest symmetric relation ℛ between closed extended processes with the same domain such that 𝐴 ℛ 𝐵 implies: 1. if 𝐴 ⇓ 𝑐, then 𝐵 ⇓ 𝑐; →∗ 𝐵 ′ and 𝐴′ ℛ 𝐵 ′ for some 𝐵 ′ ; 2. if 𝐴 − →∗ 𝐴′ , then 𝐵 − 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 deﬁned 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 quantiﬁcation over contexts makes the deﬁnition 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 deﬁne ﬁ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: Deﬁnition 9 (Static equivalence) Two closed frames 𝜑 and 𝜓 are statically equivalent, ˜ and substitutions denoted 𝜑 ≈𝑠 𝜓, if dom(𝜑) = dom(𝜓) and there exists a set of names 𝑛 𝜎, 𝜏 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, 𝜑(𝐴) ≈𝑠 𝜑(𝐵).

M.D. Ryan and B. Smyth / Applied pi Calculus

133

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 statically 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, observational 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 equations 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 satisﬁes 𝑥 = 𝑚 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 satisﬁes pair(fst(𝑥), snd(𝑥)) = 𝑥 but the second one does not. As mentioned, static equivalence captures the static part of observational equivalence. The following deﬁnition of labelled bisimilarity captures the dynamic part. Deﬁnition 10 (Labelled bisimilarity) Labelled bisimilarity (≈𝑙 ) is the largest symmetric relation ℛ on closed extended processes such that 𝐴 ℛ 𝐵 implies: 1. 𝐴 ≈𝑠 𝐵; →∗ 𝐵 ′ and 𝐴′ ℛ 𝐵 ′ for some 𝐵 ′ ; 2. if 𝐴 − → 𝐴′ , then 𝐵 − 𝛼 𝛼 → 𝐴′ and fv(𝛼) ⊆ dom(𝐴) and bn(𝛼) ∩ fn(𝐵) = ∅; then 𝐵 − →∗ − →− →∗ 𝐵 ′ 3. if 𝐴 − and 𝐴′ ℛ 𝐵 ′ for some 𝐵 ′ . Clauses 2 and 3 of this deﬁnition correspond to classical notions of bisimilarity [42]. Notice the use of the “largest relation” construction, to allow us to insist that the processes 𝐴′ 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 possibilities 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 deﬁned 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𝛼 → 𝐴′ has the effect of removing the restriction on a bound channel name. That tion 𝐴 − 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 𝑎 =

134

M.D. Ryan and B. Smyth / Applied pi Calculus

𝑏 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 necessary to ﬁnd a symmetric relation ℛ that satisﬁes the conditions contained in Deﬁnition 10, such that 𝐴 ℛ 𝐵. Note that the ℛ we ﬁnd is not required to be the largest one. That is because the set of relations that satisﬁes the conditions contained in Deﬁnition 10 is closed under union. Therefore, the largest one is the union of them all. Any relation satisfying the conditions of Deﬁnition 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 , 𝐶 ˜ .(𝑃1 ∣ and names 𝑛 ˜ such that 𝑐 ∈ 𝑛 ˜ , we have 𝜈 𝑛 ˜ .(𝑐⟨𝑎⟩.𝑃1 ∣ 𝑐(𝑥).𝑃2 ) ∣ 𝐶 ≈𝑙 𝜈 𝑛 𝑃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 communication). Let 𝐴 ℛ 𝐵 hold if there exists a closed extended process 𝐶 ′ such that one of the following holds: ˜ .(𝑃1 ∣ 𝑃2 {𝑎/𝑥}) ∣ 𝐶 ′ ; or ∙ 𝐴 ≡ 𝜈𝑛 ˜ .(𝑐⟨𝑎⟩.𝑃1 ∣ 𝑐(𝑥).𝑃2 ) ∣ 𝐶 ′ and 𝐵 ≡ 𝜈 𝑛 ′ ∙ 𝐵 ≡ 𝜈𝑛 ˜ .(𝑐⟨𝑎⟩.𝑃1 ∣ 𝑐(𝑥).𝑃2 ) ∣ 𝐶 and 𝐴 ≡ 𝜈 𝑛 ˜ .(𝑃1 ∣ 𝑃2 {𝑎/𝑥}) ∣ 𝐶 ′ ; or ∙ 𝐴 ≡ 𝐵. One may show that ℛ satisﬁes the conditions contained in Deﬁnition 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 𝐴 ≈𝑠 𝐵. ˜ .(𝑃1 ∣ 𝑃2 {𝑎/𝑥}) ∣ 𝐶 ′ . In this (b) 𝐵 ≡ 𝜈 𝑛 ˜ .(𝑐⟨𝑎⟩.𝑃1 ∣ 𝑐(𝑥).𝑃2 ) ∣ 𝐶 ′ and 𝐴 ≡ 𝜈 𝑛 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 ∣ 𝜈𝑛 ˜ .(𝑃1 ∣ 𝑃2 {𝑎/𝑥}) ∣ 𝐶 , then let 𝐵 ≜ 𝐵. Otherwise, 𝐴′ ≡ 𝜈 𝑛 𝑐(𝑥).𝑃2 ) ∣ 𝐶 ′′ for some 𝐶 ′′ , in which case let 𝐵 ′ ≜ 𝜈 𝑛 ˜ .(𝑃1 ∣ 𝑃2 {𝑎/𝑥}) ∣ 𝐶 ′′ . ˜ .(𝑐⟨𝑎⟩.𝑃1 ∣ 𝑐(𝑥).𝑃2 ) ∣ 𝐶 ′ . Since (b) 𝐴 ≡ 𝜈 𝑛 ˜ .(𝑃1 ∣ 𝑃2 {𝑎/𝑥}) ∣ 𝐶 ′ and 𝐵 ≡ 𝜈 𝑛 ∗ ′ ′ 𝐵 → 𝐴, it follows that 𝐵 → 𝐴 , so let 𝐵 ≜ 𝐴′ . (c) 𝐴 ≡ 𝐵 and hence the result follows trivially by 𝐵 ′ ≜ 𝐴′ . In all cases we have 𝐴′ ℛ 𝐵 ′ , as required. 𝛼 → 𝐴′ . Again we have three cases: 3. Now suppose 𝐴 − (a) 𝐴 ≡ 𝜈 𝑛 ˜ .(𝑐⟨𝑎⟩.𝑃1 ∣ 𝑐(𝑥).𝑃2 ) ∣ 𝐶 ′ and 𝐵 ≡ 𝜈 𝑛 ˜ .(𝑃1 ∣ 𝑃2 {𝑎/𝑥}) ∣ 𝐶 ′ . Since ′ only the 𝐶 part is able to make a labelled transition, 𝐴′ ≡ 𝜈 𝑛 ˜ .(𝑐⟨𝑎⟩.𝑃1 ∣ ˜ .(𝑃1 ∣ 𝑃2 {𝑎/𝑥}) ∣ 𝐶 ′′ , 𝑐(𝑥).𝑃2 ) ∣ 𝐶 ′′ for some 𝐶 ′′ , in which case let 𝐵 ′ ≜ 𝜈 𝑛 𝛼 and we have 𝐵 − → 𝐵′.

M.D. Ryan and B. Smyth / Applied pi Calculus

135

(b) 𝐴 ≡ 𝜈 𝑛 ˜ .(𝑃1 ∣ 𝑃2 {𝑎/𝑥}) ∣ 𝐶 ′ and 𝐵 ≡ 𝜈 𝑛 ˜ .(𝑐⟨𝑎⟩.𝑃1 ∣ 𝑐(𝑥).𝑃2 ) ∣ 𝐶 ′ . Since ∗ 𝛼 ′ → 𝐴 , so let 𝐵 ′ ≜ 𝐴′ . 𝐵 → 𝐴, it follows that 𝐵 → − (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 deﬁnition of secrecy required that the secret was not obtained by the adversary. 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]. Intuitively, 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 adversary’s inability to learn any partial information about the secret. Strong secrecy is also useful to formalise ‘dictionary attacks’, also known as ‘guessing 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 𝑠, a deterministically encrypted with server’s public key 𝑝𝑘, that is, to send {∣𝑠∣}𝑝𝑘 , is vulnerable 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 a {∣𝑠′ ∣}𝑝𝑘 and comparing it with {∣𝑠∣}𝑝𝑘 . Suppose instead the server requires the user to a include a random nonce in the encryption, that is, to send {∣⟨𝑠, 𝑟⟩∣}𝑝𝑘 , 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 deﬁnitions [14,32]. Deﬁnition 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 deﬁnition 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 deﬁnition can be extended to the more general case.

136

M.D. Ryan and B. Smyth / Applied pi Calculus

Deﬁnition 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 authenticates 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 deﬁned 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 𝜈𝑠.𝜈𝑛.({(comm, 𝑛, mac(𝑠, (comm, 𝑛)))/𝑥} ∣ {𝑠/𝑧 }) ∕≈𝑠 𝜈𝑠′ .𝜈𝑠.𝜈𝑛.({(comm, 𝑛, mac(𝑠, (comm, 𝑛)))/𝑥} ∣ {𝑠′ /𝑧 }) 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 equivalencebased (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 relationship 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].

M.D. Ryan and B. Smyth / Applied pi Calculus

137

4.4. Vote privacy for electronic voting Electronic voting systems are being introduced, or trialled, in several countries to provide more efﬁcient voting procedures with an increased level of security. The applied pi calculus 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 ofﬁcers) can link a particular vote with the voter. Consider the following protocol, which is a simpliﬁcation 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 deﬁned 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 signatures; with this cryptographic primitive, an election ofﬁcer can sign a text without having seen it. The voter ﬁrst blinds the text and the ofﬁcer signs it. The voter can then unblind the message to recover the ofﬁcer’s signature on the text. We do not need to consider 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 ofﬁcer 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 deﬁned 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 ofﬁcer. The ofﬁcer checks the voter’s eligibility and also checks she has not already voted. If these checks succeed, then the ofﬁcer signs the blinded vote-nonce pair and sends it back to the voter. The voter can now unblind the signature, recovering the ofﬁcer’s signature on the vote-nonce pair. Once all voters have obtained the ofﬁcer’s signature in this way, they can anonymously submit the signed vote-nonce pair for counting. The protocol thus proceeds as follows: Voter

Ofﬁcer sign(𝑠𝑘𝑉 , blind(𝑟, pair(𝑣, 𝑛)))

⊲

⊳

sign(𝑠𝑘𝑂 , blind(𝑟, pair(𝑣, 𝑛)))

synch sign(𝑠𝑘𝑂 , pair(𝑣, 𝑛))

⊳

The purpose of the value 𝑛 is to allow the ofﬁcer to count the signed vote only once. The synchronisation point, denoted synch, ensures that every voter receives the ofﬁcer’s signature before any of them submit the unblinded value for counting. It is necessary to ensure vote privacy; without it, trafﬁc analysis might link the voter’s 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 ofﬁcer, and a channel 𝑣𝑜𝑡𝑒 for the ofﬁcer to declare the list of counted votes.

138

M.D. Ryan and B. Smyth / Applied pi Calculus

𝑃 ≜ 𝜈 𝑠𝑘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 ofﬁcer. Eligible(𝑥) checks whether the voter with public key 𝑥 is eligible and hasn’t 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 can’t 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 deﬁning 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 deﬁne the property of vote privacy. Since it should hold even if the ofﬁcer is corrupt, we can suppose that the ofﬁcer is part of the attacker, and we need not consider its formalisation as 𝑃𝑂 above. This means the secrecy of the ofﬁcer’s 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 ofﬁcers) 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:

M.D. Ryan and B. Smyth / Applied pi Calculus

139

𝜈 𝑠𝑦𝑛.𝜈 𝑠𝑦𝑛′ .(𝑃𝑉 {𝑠𝑘𝐴 /𝑠𝑘𝑉 , 𝑣𝑎 /𝑣} ∣ 𝑃𝑉 {𝑠𝑘𝐵 /𝑠𝑘𝑉 , 𝑣𝑏 /𝑣 } ∣ 𝑆) ≈𝑙 𝜈 𝑠𝑦𝑛.𝜈 𝑠𝑦𝑛′ .(𝑃𝑉 {𝑠𝑘𝐴 /𝑠𝑘𝑉 , 𝑣𝑏 /𝑣 } ∣ 𝑃𝑉 {𝑠𝑘𝐵 /𝑠𝑘𝑉 , 𝑣𝑎 /𝑣} ∣ 𝑆) To prove this equivalence, let us call the left hand side L HS, and the right hand side R HS. We need to show a relation ℛ satisfying the requirements of Deﬁnition 10 such that L HS ℛ R HS. As we have seen, the idea of ℛ is to relate successors of L HS and R HS that are expected to correspond to each other in the bisimulation. As L HS evolves, the corresponding evolution of R HS is the one that mimics 𝒜 moves in L HS with 𝒜 moves in R HS, and ℬ moves in L HS with ℬ moves in R HS, up to the synchronisation. After the synchronisation, 𝒜 moves in L HS are mimicked by ℬ moves in R HS, and ℬ moves in L HS are mimicked by 𝒜 moves in R HS. 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 L HS and R HS 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 L HS and R HS. Indistinguishability between the L HS and R HS with respect to the signed blind votes is due to the properties of blinding. After the synchronisation 𝒜 will reveal 𝑣𝑎 on the L HS and 𝑣𝑏 on the R HS (similarly ℬ will reveal 𝑣𝑏 on the L HS and 𝑣𝑎 on the R HS). 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 context of security protocols. In this section we brieﬂy 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 studied 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]. Correspondence properties have been presented in the context of authenticity [19], and subsequently 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 symbolic version of the applied pi calculus is introduced in [33]; by treating inputs symboli-

140

M.D. Ryan and B. Smyth / Applied pi Calculus

cally, it avoids potentially inﬁnite branching of processes due to inputs from the environment. 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 reading 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 Pervasive Systems (EP/F033540/1). This work was partly done while Ben Smyth was at ´ CNRS, D´epartement d’Informatique, Ecole Normale Sup´erieure, Paris, France with support from the Direction G´en´erale pour l’Armement (DGA). References [1] [2]

[3] [4] [5] [6]

[7] [8]

[9] [10]

[11] [12]

[13]

[14]

Mart´ın Abadi. Security Protocols and their Properties. In Friedrich L. Bauer and Ralf Steinbr¨uggen, editors, Foundations of Secure Computation, NATO Science Series, pages 39–60. IOS Press, 2000. Mart´ın Abadi and Bruno Blanchet. Analyzing Security Protocols with Secrecy Types and Logic Programs. In POPL’02: Proceedings of the 29th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 33–44. ACM Press, 2002. Mart´ın Abadi and Bruno Blanchet. Analyzing Security Protocols with Secrecy Types and Logic Programs. Journal of the ACM, 52(1):102–146, 2005. Mart´ın Abadi and Bruno Blanchet. Computer-Assisted Veriﬁcation of a Protocol for Certiﬁed Email. Science of Computer Programming, 58(1–2):3–27, 2005. Special issue SAS’03. Mart´ın Abadi, Bruno Blanchet, and C´edric Fournet. Just Fast Keying in the Pi Calculus. ACM Transactions on Information and System Security, 10(3):1–59, 2007. Mart´ın Abadi and V´eronique Cortier. Deciding knowledge in security protocols under equational theories. In ICALP’04: Proceedings of the 31st International Colloquium on Automata, Languages and Programming, volume 3142 of LNCS, pages 46–58. Springer, 2004. Mart´ın Abadi and V´eronique Cortier. Deciding knowledge in security protocols under equational theories. Theoretical Computer Science, 367(1–2):2–32, 2006. Mart´ın Abadi and C´edric Fournet. Mobile values, new names, and secure communication. In POPL’01: 28th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 104–115. ACM Press, 2001. Mart´ın Abadi and C´edric Fournet. Private email communication, 24th May 2006. Mart´ın Abadi and Andrew D. Gordon. A calculus for cryptographic protocols: the spi calculus. In CCS’97: 4th ACM conference on Computer and Communications Cecurity, pages 36–47. ACM Press, 1997. Mart´ın Abadi and Roger Needham. Prudent engineering practice for cryptographic protocols. IEEE Transactions on Software Engineering, 22(1):6–15, January 1996. Michael Backes, Catalin Hritcu, and Matteo Maffei. Automated Veriﬁcation of Remote Electronic Voting Protocols in the Applied Pi-Calculus. In CSF’08: 21st IEEE Computer Security Foundations Symposium, pages 195–209. IEEE Computer Society, 2008. Michael Backes, Matteo Maffei, and Dominique Unruh. Zero-Knowledge in the Applied Pi-calculus and Automated Veriﬁcation of the Direct Anonymous Attestation Protocol. In S&P’08: 29th IEEE Symposium on Security and Privacy, pages 202–215. IEEE Computer Society, 2008. Mathieu Baudet. Deciding security of protocols against off-line guessing attacks. In CCS’05: Proceedings of the 12th Conference on Computer and Communications Security, pages 16–25. ACM Press, 2005.

M.D. Ryan and B. Smyth / Applied pi Calculus

[15]

[16]

[17]

[18]

[19] [20] [21] [22]

[23] [24]

[25] [26]

[27] [28]

[29] [30] [31]

[32]

[33] [34] [35]

[36]

141

Mathieu Baudet, V´eronique Cortier, and St´ephanie Delaune. YAPA: A generic tool for computing intruder knowledge. In RTA’09: Proceedings of the 20th International Conference on Rewriting Techniques and Applications, volume 5595 of LNCS, pages 148–163. Springer, 2009. 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 39–48. IEEE Computer Society, 2009. Karthikeyan Bhargavan, Cedric Fournet, Andrew D. Gordon, and Stephen Tse. Veriﬁed Interoperable Implementations of Security Protocols. In CSFW’06: IEEE Computer Security Foundations Workshop, pages 139–152. IEEE Computer Society, 2006. Bruno Blanchet. An efﬁcient cryptographic protocol veriﬁer based on Prolog rules. In CSFW’01: Proceedings of the 14th IEEE Computer Security Foundations Workshop, pages 82–96. IEEE Computer Society, 2001. Bruno Blanchet. From Secrecy to Authenticity in Security Protocols. In SAS’02: Proceedings of the 9th International Static Analysis Symposium, volume 2477 of LNCS, pages 342–359. Springer, 2002. Bruno Blanchet. Automatic Proof of Strong Secrecy for Security Protocols. In S&P’04: 25th IEEE Symposium on Security and Privacy, pages 86–100. IEEE Computer Society, 2004. Bruno Blanchet. Automatic Veriﬁcation of Correspondences for Security Protocols. Journal of Computer Security, 17(4):363–434, 2009. Bruno Blanchet, Mart´ın Abadi, and C´edric Fournet. Automated veriﬁcation of selected equivalences for security protocols. In LICS’05: Proceedings of the 20th IEEE Symposium on Logic in Computer Science, pages 331–340. IEEE Computer Society, 2005. Bruno Blanchet, Mart´ın Abadi, and C´edric Fournet. Automated Veriﬁcation of Selected Equivalences for Security Protocols. Journal of Logic and Algebraic Programming, 75(1):3–51, 2008. Bruno Blanchet and Avik Chaudhuri. Automated Formal Analysis of a Protocol for Secure File Sharing on Untrusted Storage. In S&P’08: 29th IEEE Symposium on Security and Privacy, pages 417–431. IEEE Computer Society, 2008. Bruno Blanchet and Ben Smyth. ProVerif: Automatic Cryptographic Protocol Veriﬁer User Manual & Tutorial. Available from http://www.proverif.ens.fr/, 2010. Liqun Chen and Mark D. Ryan. Ofﬂine 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. Liqun Chen and Mark D. Ryan. Attack, solution and veriﬁcation for shared authorisation data in TCG TPM. In FAST’09: 6th Formal Aspects in Security and Trust, LNCS. Springer, 2009. S¸tefan Ciobˆac˘a, St´ephanie Delaune, and Steve Kremer. Computing knowledge in security protocols under convergent equational theories. In CADE’09: Proceedings of the 22nd International Conference on Automated Deduction, Lecture Notes in Artiﬁcial Intelligence, pages 355–370. Springer, 2009. V´eronique Cortier and St´ephanie Delaune. A method for proving observational equivalence. In CSF’09: 22nd IEEE Computer Security Foundations Symposium, pages 266–276. IEEE Computer Society, 2009. V´eronique Cortier, Micha¨el Rusinowitch, and Eugen Zˇalinescu. Relating two standard notions of secrecy. Logical Methods in Computer Science, 3(3), 2007. Morten Dahl, St´ephanie Delaune, and Graham Steel. Formal Analysis of Privacy for Vehicular MixZones. In ESORICS’10: 15th European Symposium on Research in Computer Security, volume 6345 of LNCS, pages 55–70. Springer, 2010. St´ephanie Delaune, Steve Kremer, and Mark D. Ryan. Composition of password-based protocols. In CSF’08: Proceedings of the 21st IEEE Computer Security Foundations Symposium, pages 239–251, Pittsburgh, PA, USA, 2008. IEEE Computer Society. St´ephanie Delaune, Steve Kremer, and Mark D. Ryan. Symbolic bisimulation for the applied pi calculus. Journal of Computer Security, 2009. St´ephanie Delaune, Steve Kremer, and Mark D. Ryan. Verifying Privacy-type Properties of Electronic Voting Protocols. Journal of Computer Security, 2009. St´ephanie Delaune, Mark D. Ryan, and Ben Smyth. Automatic veriﬁcation of privacy properties in the applied pi-calculus. In IFIPTM’08: Proceedings of the 2nd Joint iTrust and PST Conferences on Privacy, Trust Management and Security, volume 263 of IFIP Conference Proceedings, pages 263–278. Springer, 2008. Danny Dolev and Andrew C. Yao. On the security of public key protocols. Information Theory, 29:198– 208, 1983.

142 [37]

[38]

[39]

[40]

[41] [42] [43]

[44] [45] [46]

[47] [48]

M.D. Ryan and B. Smyth / Applied pi Calculus

Atsushi Fujioka, Tatsuaki Okamoto, and Kazui Ohta. A practical secret voting scheme for large scale elections. In AUSCRYPT’92: Advances in Cryptology, volume 718 of LNCS, pages 244–251. Springer, 1992. Steve Kremer and Mark D. Ryan. Analysis of an Electronic Voting Protocol in the Applied Pi-Calculus. In ESOP’05: Proceedings of the 14th European Symposium On Programming, volume 3444 of LNCS, pages 186–200. Springer, 2005. Steve Kremer, Mark D. Ryan, and Ben Smyth. Election veriﬁability in electronic voting protocols. In ESORICS’10: 15th European Symposium on Research in Computer Security, volume 6345 of LNCS, pages 389–404. Springer, 2010. An extended version of this paper appears in [45, Chapter 3]. Ralf K¨usters and Tomasz Truderung. An Epistemic Approach to Coercion-Resistance for Electronic Voting Protocols. In S&P’09: 30th IEEE Symposium on Security and Privacy, pages 251–266. IEEE Computer Society, 2009. Gavin Lowe. A hierarchy of authentication speciﬁcations. In CSFW’97: 10th IEEE workshop on Computer Security Foundations, pages 31–43. IEEE Computer Society, 1997. Robin Milner. Communicating and mobile systems: the 𝜋-calculus. Cambridge University Press, 1999. Aybek Mukhamedov, Andrew D. Gordon, and Mark D. Ryan. Towards a Veriﬁed Reference Implementation of the Trusted Platform Module. In 17th International Workshop on Security Protocols, LNCS. Springer, 2009. Mark D. Ryan and Ben Smyth. Applied pi calculus. Available from http://www.bensmyth.com/ publications/10applied-pi/, 2010. Ben Smyth. Formal veriﬁcation of cryptographic protocols with automated reasoning. PhD thesis, School of Computer Science, University of Birmingham, 2011. Ben Smyth, Mark D. Ryan, and Liqun Chen. Direct Anonymous Attestation (DAA): Ensuring privacy with corrupt administrators. In ESAS’07: 4th European Workshop on Security and Privacy in Ad hoc and Sensor Networks, volume 4572 of LNCS, pages 218–231, 2007. An extended version of this paper appears in [45, Chapter 4]. D. Syme, A. Granicz, and A. Cisternino. Expert F#. Apress, 2007. Trusted Computing Group. TPM Speciﬁcation version 1.2. Parts 1–3., 2007. Available from http: //www.trustedcomputinggroup.org/specs/TPM/.

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. doi:10.3233/978-1-60750-714-7-143

143

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 spicalculus processes. These fundamental security properties are usually studied independently. Our exercise of considering all of them in a uniform framework is interesting under different perspectives: (𝑖) it provides a general overview of how type theory can be applied to reason on security protocols; (𝑖𝑖) it illustrates and compares 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 signiﬁcantly simpliﬁed.

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 abstract interpretation [18] or control ﬂow analysis [33,12] aim at deﬁning sound abstractions 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 efﬁcient analyses which can certify the correctness of a protocol with respect to some target (security) property P: if the abstraction satisﬁes 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. Typebased reasoning is therefore particularly valuable, as it forces one to clarify protocol speciﬁcations by making explicit the underlying security mechanisms. A toy example. We consider Conﬁdentiality, 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 con1 Work partially supported by the initiative for excellence and the Emmy Noether program of the German federal government and by Miur’07 Project SOFT: “Security Oriented Formal Techniques”.

144

R. Focardi and M. Maffei / Types for Security Protocols

ﬁdentiality might be to impose that high-conﬁdential (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. Assuming 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 remain 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 succinct way to express these four cases. One attempt might be to equate Secret with Secure and Public with Insecure, but this would lead to an insecure channel being regarded as secure, obviously breaking conﬁdentiality. 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

145

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 security protocols dates back to Abadi’s 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 conﬁdentiality with a type system. One of the fundamental contributions is the methodology 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 noninterference: 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 technique 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 ℓ speciﬁes 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 KeySecret [𝑇 ], then the ciphertext comes from a well-typed process and the decrypted message has type 𝑇 ; if the key has type KeyPublic [𝑇 ], 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.

146

R. Focardi and M. Maffei / Types for Security Protocols

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 begin(𝑀 ) and end(𝑀 ), marking the begin and the end of a protocol session for authenticating message 𝑀 . Intuitively, a protocol guarantees authenticity if every end is preceded by a corresponding begin [28]. The type system was subsequently extended to handle conditional secrecy (a reﬁnement 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 veriﬁcation 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 veriﬁcation of authorization policies in security protocols [20]. The idea is to decorate the protocol with assumptions and assertions of the form assume 𝐶 and assert 𝐶, respectively, 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 compromised [21]. Backes et al. further reﬁned 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 implementations. For this reason, the analysis of executable code is crucial to provide endto-end security guarantees. Bengtson et al. [10] recently proposed a framework for the type-based analysis of authorization policies in F# implementations of security protocols. The type system is based on reﬁnement 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 deﬁne the syntax of a large fragment of F# by encoding. One important contribution of this work is the deﬁnition 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 veriﬁed by speciﬁc typing rules. They are instead deﬁned by symbolic libraries based on sealing [32,36,35] and veriﬁed 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 conﬁdentiality, integrity and authentication starting from pi-calculus processes, in which security is guaranteed via ideal (restricted) channels. This simpliﬁed setting allows us to introduce important concepts 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

147

R. Focardi and M. Maffei / Types for Security Protocols

𝑀, 𝑁, 𝐾 ::= 𝑥, 𝑦, 𝑧

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 deﬁned 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 beneﬁt 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 deﬁning a general setting where different contributions can be illustrated and understood. 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 conﬁdentiality and integrity. It is worth mentioning that recent language-based secure literature has extended imperative languages with cryptography allowing for the modelling 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 signiﬁcantly simpliﬁed 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 cryptography. It is essentially a polyadic pi-calculus [31] with a typing annotation for restricted 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, properties 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.

148

R. Focardi and M. Maffei / Types for Security Protocols

Structural Equivalence 𝑃 ≡𝑃 𝑃 ≡𝑄⇒𝑄≡𝑃

(𝜈𝑎 : 𝑇 ) 0 ≡ 0

𝑃 ≡𝑄, 𝑄≡𝑅⇒𝑃 ≡𝑅 𝑃 ≡𝑄⇒𝑃 ∣𝑅≡𝑄∣𝑅 𝑃 ≡ 𝑄 ⇒!𝑃 ≡!𝑄 𝑃 ≡ 𝑄 ⇒ (𝜈𝑎 : 𝑇 ) 𝑃 ≡ (𝜈𝑎 : 𝑇 ) 𝑄

𝑃 ∣0≡𝑃 𝑃 ∣𝑄≡𝑄∣𝑃 (𝑃 ∣ 𝑄) ∣ 𝑅 ≡ 𝑃 ∣ (𝑄 ∣ 𝑅) !𝑃 ≡ 𝑃 ∣ !𝑃 (𝜈𝑎 : 𝑇 ) (𝜈𝑏 : 𝑇 ′ ) 𝑃 ≡ (𝜈𝑏 : 𝑇 ′ ) (𝜈𝑎 : 𝑇 ) 𝑃 if 𝑎 ∕= 𝑏 (𝜈𝑎 : 𝑇 ) (𝑃 ∣ 𝑄) ≡ 𝑃 ∣ (𝜈𝑎 : 𝑇 ) 𝑄 if 𝑎 ∈ / fn(𝑃 )

Reduction ˜ ⟩.𝑃 ∣ 𝑁 (˜ ˜ /˜ 𝑁 ⟨𝑀 𝑥).𝑄 → 𝑃 ∣ 𝑄{𝑀 𝑥} if 𝑀 = 𝑀 then 𝑃 else 𝑄 → 𝑃 if 𝑀 = 𝑁 then 𝑃 else 𝑄 → 𝑄

(R ED S TRUCT ) 𝑃′ ≡ 𝑃

𝑃 →𝑄 𝑃 ′ → 𝑄′

𝑄 ≡ 𝑄′

if 𝑀 ∕= 𝑁

(R ED I/0) (R ED C OND 1) (R ED C OND 2)

(R ED R ES )

(R ED PAR )

𝑃 →𝑄

𝑃 →𝑄

(𝜈𝑎 : 𝑇 ) 𝑃 → (𝜈𝑎 : 𝑇 ) 𝑄

𝑃 ∣𝑅→𝑄∣𝑅

Table 2. Structural Equivalence and Reduction

Syntax. The syntax of the calculus is given in Table 1. For the sake of readabil˜ denote a sequence 𝑀1 , . . . , 𝑀𝑚 of terms and {𝑀 ˜ /˜ ity, we let 𝑀 𝑥} the substitution ˜ ˜ {𝑀1 /𝑥1 } . . . {𝑀𝑚 /𝑥𝑚 }. Intuitively, process 𝑁 ⟨𝑀 ⟩.𝑃 outputs the tuple of messages 𝑀 ˜ (where on channel 𝑁 and then behaves as 𝑃 ; 𝑁 (˜ 𝑥).𝑃 receives a tuple of messages 𝑀 ˜ and 𝑥 ˜ /˜ the arity of 𝑀 ˜ 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 deﬁned 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 structural 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 restriction, which essentially allows us to rearrange parallel compositions and restrictions in order to bring processes that should interact close to each other, to unfold replications, and to remove useless restrictions. Reduction → is deﬁned as the least relation on closed processes satisfying the rules in the second part of Table 2. Communication is synchronous: ˜ ⟩.𝑃 synchronizes with an input 𝑁 (˜ 𝑥).𝑄 on the same channel and then the output 𝑁 ⟨𝑀 ˜ /˜ reduces to 𝑃 ∣ 𝑄{𝑀 𝑥} (rule R ED I/0). The equality test if 𝑀 = 𝑁 then 𝑃 else 𝑄 reduces to 𝑃 if 𝑀 is equal to 𝑁 or to 𝑄 otherwise (rules R ED C OND 1 and 2). Moreover, reduction relation preserves ≡ (R ED S TRUCT ) and is closed with respect to restriction

R. Focardi and M. Maffei / Types for Security Protocols

149

(R ED R ES ) and parallel composition (R ED 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 conﬁdentiality and integrity together (see, e.g., [34]). Usually, the security level is a pair ℓ𝐶 ℓ𝐼 specifying, separately, the conﬁdentiality and integrity levels. We consider two possible levels: High (𝐻) and Low (𝐿). For example, 𝐻𝐻 denotes a high conﬁdentiality and high integrity value, while 𝐿𝐻 a public (low conﬁdentiality) and high integrity one. Intuitively, high conﬁdentiality values should never be read by opponents while high integrity values should not be modiﬁed by opponents, i.e., when we receive high integrity data we expect they originated at some trusted source. An important difference between conﬁdentiality and integrity HL 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 HH LL unsound, as any data from the opponent could erroneously be considered as coming from a trusted entity. Considering instead as low LH integrity some high integrity data is harmless, as this basically reduces the assumptions we can make on them. More formally, the conﬁdentiality and integrity preorders are such that 𝐿 ⊑𝐶 𝐻 and 𝐻 ⊑𝐼 𝐿. We let ℓ𝐶 and ℓ𝐼 range over {𝐿, 𝐻}, while we let ℓ range over the pairs ℓ𝐶 ℓ𝐼 with ℓ1𝐶 ℓ1𝐼 ⊑ ℓ2𝐶 ℓ2𝐼 iff ℓ1𝐶 ⊑𝐶 ℓ2𝐶 and ℓ1𝐼 ⊑𝐼 ℓ2𝐼 , 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 speciﬁed security level. Opponents. Processes representing opponents are characterized by type/level 𝐿𝐿 meaning that they can read from 𝐿𝐿 and 𝐿𝐻 while they can modify 𝐿𝐿 and 𝐻𝐿, reﬂecting the intuition that information may only ﬂow up in the lattice. In particular, opponents can only generate names of type 𝐿𝐿, as formalized below: Deﬁnition 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 conﬁdentiality 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 conﬁdentiality and integrity levels ℓ𝐶 and ℓ𝐼 . Similarly, given a mapping Γ from terms to types, we denote with ℒΓ (𝑀 ) the level in Γ of a certain term 𝑀 formally deﬁned as:

150

R. Focardi and M. Maffei / Types for Security Protocols

{ ℒΓ (𝑀 ) =

ℒ(Γ(𝑀 )) 𝐿𝐿

whenever 𝑀 ∈ dom(Γ) otherwise

As above, ℒC,Γ (𝑀 ) and ℒI,Γ (𝑀 ) respectively denote the conﬁdentiality 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 deﬁnition of secrecy is in the style of [2]. A process 𝑃 preserves the secrecy of a high conﬁdentiality 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 deﬁnition for channels of arity 1 (the extension to arity 𝑛 is immediate). Deﬁnition 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 conﬁdentiality 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 deﬁnition 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 process. Notice, to this purpose, that we have forbidden opponents to generate high integrity names. The formal deﬁnition follows:

R. Focardi and M. Maffei / Types for Security Protocols

E MPTY ∅⊢⋄

E NV

Γ⊢⋄

𝑀 ∈ / dom(Γ)

151

𝑇 = Cℓ [𝑇˜] implies ℓ = 𝐻𝐻

Γ, 𝑀 : 𝑇 ⊢ ⋄ Table 3. Core calculus: well-formedness of Γ.

Deﬁnition 3 (Integrity) 𝑃 preserves integrity if, for all opponents 𝑂, whenever 𝑃 ∣ 𝑂 →∗ (𝜈𝑏 : CHH [𝑇 ′ ]) (𝜈˜ 𝑎 : 𝑇˜) (𝑃 ′ ∣ 𝑏⟨𝑑⟩.𝑃 ′′ ) we have ℒI,Γ (𝑑) ⊑𝐼 ℒI (𝑇 ′ ), with HH ′ ˜ Γ = b : C [T ], ˜a : T . We now give an example of a process which breaks the above property. Example 1 Consider process (𝜈𝑏 : CHH [𝐿𝐻]) (𝑐(𝑥).𝑏⟨𝑥⟩ ∣ 𝑏(𝑦).𝑃 ). Intuitively, this process reads from the untrusted channel 𝑐 a value 𝑥 and forwards it on the trusted channel 𝑏. Since 𝑥 can be low integrity, this process violates the above property. Take, for example, the opponent 𝑐⟨𝑑⟩ and the reduction: (𝜈𝑏 : CHH [𝐿𝐻]) (𝑐(𝑥).𝑏⟨𝑥⟩ ∣ 𝑏(𝑦).𝑃 ) ∣ 𝑐⟨𝑑⟩ ≡ (𝜈𝑏 : CHH [𝐿𝐻]) (𝑐(𝑥).𝑏⟨𝑥⟩ ∣ 𝑏(𝑦).𝑃 ∣ 𝑐⟨𝑑⟩) → (𝜈𝑏 : CHH [𝐿𝐻]) (𝑏⟨𝑑⟩ ∣ 𝑏(𝑦).𝑃 ∣ 0) → (𝜈𝑏 : CHH [𝐿𝐻]) (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 (𝜈𝑏 : CHH [𝐿𝐻]) (𝑏⟨𝑑⟩ ∣ 𝑏(𝑦).𝑃 ∣ 0) which transmits over 𝑏 an unrestricted name 𝑑. We have, ℒI,Γ (𝑑) = 𝐿 ∕⊑𝐼 𝐻 = ℒI (𝐿𝐻), with Γ = b : CHH [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 deﬁned 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 𝑇 ≤ 𝑇 ′ speciﬁes when a value of type 𝑇 can be used in place of a value of type 𝑇 ′ , thus making the type system more permissive. Formally, ≤ is deﬁned as the least preorder such that:

152

R. Focardi and M. Maffei / Types for Security Protocols

ATOM Γ⊢⋄

𝑀 : 𝑇 in Γ

Γ⊢𝑀 :𝑇

S UBSUMPTION Γ ⊢ 𝑀 : 𝑇′

𝑇′ ≤ 𝑇

Γ⊢𝑀 :𝑇

Table 4. Core calculus: typing of terms.

ℓ1 ≤ ℓ2 whenever ℓ1 ⊑ ℓ2 𝐿𝐿 ≤ CLL [𝐿𝐿, . . . , 𝐿𝐿] Cℓ [𝑇˜] ≤ ℓ

(2)

The ﬁrst condition means that rising the data security level is harmless. 𝐿𝐿 ≤ CLL [𝐿𝐿, . . . , 𝐿𝐿] 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 speciﬁed in the typing environment, i.e., the channel type has not been derived via subsumption. In fact, the only channel types derivable by subtyping are the ones at level LL. Proposition 1 (High Channels) Γ ⊢ 𝑁 : CHH [𝑇˜] implies 𝑁 : CHH [𝑇˜] is in Γ. Untrusted LL channels can only be used to transmit untrusted messages. This is a consequence of the fact LL channels cannot be declared in Γ and are only derived via subsumption. Proposition 2 (Low Channels) Γ ⊢ 𝑁 : CLL [𝑇˜] 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.

153

R. Focardi and M. Maffei / Types for Security Protocols

S TOP

Γ⊢⋄ Γ⊢0

C OND

Γ⊢𝑀 :𝑇

PAR

Γ⊢𝑃

Γ⊢𝑄

Γ⊢𝑃

R ES

Γ ⊢!𝑃

Γ ⊢ (𝜈𝑎 : 𝑇 ) 𝑃

Γ⊢𝑃

Γ⊢𝑃 ∣𝑄 Γ ⊢ 𝑁 : 𝑇′

R EPL

Γ⊢𝑄

Γ, 𝑎 : 𝑇 ⊢ 𝑃

IN

Γ, 𝑥 ˜ : 𝑇˜ ⊢ 𝑃

Γ ⊢ if 𝑀 = 𝑁 then 𝑃 else 𝑄

O UT

˜ : 𝑇˜ Γ⊢𝑀

Γ ⊢ 𝑁 : Cℓ [𝑇˜]

Γ ⊢ 𝑁 (˜ 𝑥).𝑃

Γ ⊢ 𝑁 : Cℓ [𝑇˜] ˜ Γ ⊢ 𝑁 ⟨𝑀 ⟩.𝑃 Γ⊢𝑃

Table 5. Core calculus: typing processes.

Typing Processes. Table 5 dictates how processes should deal with typed channels and ˜ : 𝑇˜ for denoting ∀𝑖 ∈ [1, 𝑚], Γ ⊢ 𝑀𝑖 : 𝑇𝑖 . values. We use the concise notation Γ ⊢ 𝑀 Rules S TOP, PAR , R EPL , R ES and C OND simply check that the subprocesses and terms are well-typed under the same Γ, enriched with 𝑎 : 𝑇 in case of R ES. Intuitively, these rules do not directly impose any restriction. The only interesting rules are, in fact, I N and O UT 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 (𝜈𝑏 : CHH [𝐿𝐻]) (𝑐(𝑥).𝑏⟨𝑥⟩ ∣ 𝑏(𝑦).𝑃 ) 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 𝑐 : 𝐿𝐿, 𝑏 : CHH [𝐿𝐻] and we show that 𝑐(𝑥).𝑏⟨𝑥⟩ cannot be type-checked under Γ. Notice, in fact, that after type-checking the initial restriction, 𝑏 : CHH [𝐿𝐻] is added into Γ. Notice also that, via subsumption, from Γ ⊢ 𝑐 : 𝐿𝐿 and 𝐿𝐿 ≤ CLL [𝐿𝐿] we obtain Γ ⊢ 𝑐 : CLL [𝐿𝐿]. Formally, typing would proceed as follows (read it bottom-up):

O UT IN

Γ, 𝑥 : 𝐿𝐿 ⊢ 𝑥 : 𝐿𝐻 Γ ⊢ 𝑏 : CHH [𝐿𝐻] Γ, 𝑥 : 𝐿𝐿 ⊢ 𝑏⟨𝑥⟩

Γ ⊢ 𝑐 : CLL [𝐿𝐿]

Γ ⊢ 𝑐(𝑥).𝑏⟨𝑥⟩

The crucial part is that from 𝑥 : 𝐿𝐿 we can never prove 𝑥 : 𝐿𝐻 since 𝐿𝐿 ∕≤ 𝐿𝐻. The above example formally shows the importance of considering integrity levels contravariant, as previously discussed: a low-integrity variable can never be considered as highintegrity. Below we will formally proof that typing ensures integrity, thus processes violating integrity, as the above one, can never type-check. Example 3 Let us consider now a simple protocol where 𝐴 sends to 𝐵 a fresh message of level HH on a channel of type CHH [HH ]. The typing derivation for the process modelling this protocol is shown below (rule names are omitted for lack of space):

154

R. Focardi and M. Maffei / Types for Security Protocols

𝑐 : CHH [HH ], 𝑚 : HH ⊢ ⋄ 𝑐 : CHH [HH ], 𝑚 : HH ⊢ 0

𝑐 : CHH [HH ], 𝑥 : HH ⊢ ⋄

𝑐 : CHH [HH ], 𝑚 : HH ⊢ 𝑐⟨𝑚⟩

𝑐 : CHH [HH ], 𝑥 : HH ⊢ 0

𝑐 : CHH [HH ] ⊢ (𝜈𝑚 : HH ) 𝑐⟨𝑚⟩

𝑐 : CHH [HH ] ⊢ 𝑐(𝑥)

𝑐 : CHH [HH ] ⊢ (𝜈𝑚 : HH ) 𝑐⟨𝑚⟩ ∣ 𝑐(𝑥) ∅ ⊢ (𝜈𝑐 : CHH [HH ]) ((𝜈𝑚 : HH ) 𝑐⟨𝑚⟩ ∣ 𝑐(𝑥)) Notice that the variable 𝑥 has type HH , so our type system guarantees that what is received by 𝐵 is both at high conﬁdentiality 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 opponent’s 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

R. Focardi and M. Maffei / Types for Security Protocols

155

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 remaining ones are all trivial and left as an exercise to the reader. (𝜈𝑎 : 𝑇 ) 0 ≡ 0 We have Γ ⊢ (𝜈𝑎 : 𝑇 ) 0. This judgment can only be proved by R ES, which implies Γ, 𝑎 : 𝑇 ⊢ 0. By (3), Γ, 𝑎 : 𝑇 ⊢ ⋄. By Lemma 1 (Strengthening), we obtain Γ ⊢ ⋄. Finally, by S TOP, 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 S TOP and R ES. (𝜈𝑎 : 𝑇 ) (𝑃 ∣ 𝑄) ≡ 𝑃 ∣ (𝜈𝑎 : 𝑇 ) 𝑄 if 𝑎 ∈ / 𝑓 𝑛(𝑃 ) We know Γ ⊢ (𝜈𝑎 : 𝑇 ) (𝑃 ∣ 𝑄), which implies Γ, 𝑎 : 𝑇 ⊢ 𝑃 and Γ, 𝑎 : 𝑇 ⊢ 𝑄. By Lemma 1 (Strengthening), since 𝑎∈ / 𝑓 𝑛(𝑃 ), we get Γ ⊢ 𝑃 . By R ES 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 R ES. (𝜈𝑎 : 𝑇 ) (𝜈𝑏 : 𝑇 ′ ) 𝑃 ≡ (𝜈𝑏 : 𝑇 ′ ) (𝜈𝑎 : 𝑇 ) 𝑃 (𝑎 ∕= 𝑏) The judgment Γ ⊢ (𝜈𝑎 : 𝑇 ) (𝜈𝑏 : 𝑇 ′ ) 𝑃 can only be proved by R ES, 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 R ED C OND 1 and 2 are trivially proved by observing that Γ ⊢ if 𝑀 = 𝑁 then 𝑃 else 𝑄 requires Γ ⊢ 𝑃 and Γ ⊢ 𝑄. Case R ED I/O is proved by observing that Corollary 1 (Uniqueness of Channel ˜ : 𝑇˜ and ˜ : 𝑇˜ ⊢ 𝑄 and Γ ⊢ 𝑁 : Cℓ [𝑇˜] and Γ ⊢ 𝑀 Types), I N , and O UT imply Γ, 𝑥 ˜ /˜ Γ ⊢ 𝑃 . By applying Lemma 3 (Substitution), we obtain Γ ⊢ 𝑄{𝑀 𝑥} and, by PAR, we ˜ /˜ get Γ ⊢ 𝑃 ∣ 𝑄{𝑀 𝑥}. The inductive cases are all trivial. We just mention that (R ED S TRUCT) is based on item 1 of this lemma. ⊔ ⊓

156

R. Focardi and M. Maffei / Types for Security Protocols

𝑃, 𝑄, 𝑅, 𝑂 ::=

𝑀, 𝑁, 𝐾 ::= terms ... as in Table 1 ek(𝐾) vk(𝐾) ˜ ∣}s {∣𝑀 𝐾 ˜ ∣}a {∣𝑀 𝐾

˜ ]𝐾 [𝑀

encryption key veriﬁcation key sym encryption

processes

... as in Table 1 case 𝑀 of {∣˜ 𝑥∣}s𝐾 in 𝑃 sym decryption case 𝑀 of {∣˜ 𝑥∣}a𝐾 in 𝑃 asym decryption case 𝑀 of [˜ 𝑥]𝐾 in 𝑃 signature check

asym encryption digital signature

Table 6. Syntax for cryptographic messages and cryptographic operations

Secrecy and Integrity by typing. secrecy and integrity.

We ﬁnally prove that well-typed processes preserve

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(𝑂) = {˜ 𝑎} ˜ ⊢ 𝑂. Let fn(𝑂) ∖ dom(Γ) = {˜𝑏} be the free names of 𝑂 not occurring implies 𝑎 ˜ : 𝐿𝐿 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: 𝑎 : 𝑇˜) (𝑃 ′ ∣ 𝑏⟨𝑑⟩.𝑃 ′′ ). By Proposition 5 (Subject Secrecy Let 𝑃 ∣ 𝑂 →∗ (𝜈𝑑 : 𝑇 ) (𝜈˜ ′ 𝑎 : 𝑇˜) (𝑃 ′ ∣ 𝑏⟨𝑑⟩.𝑃 ′′ ) which implies congruence and reduction) we get Γ ⊢ (𝜈𝑑 : 𝑇 ) (𝜈˜ Γ′ , 𝑑 : 𝑇, 𝑎 ˜ : 𝑇˜ ⊢ 𝑏⟨𝑑⟩.𝑃 ′′ , by repeatedly applying R ES and ﬁnally by PAR. ˜ : 𝑇˜. By rule O UT we necessarily have that Γ′′ ⊢ 𝑏 : Cℓ [𝑇 ′ ] and Let Γ′′ = Γ′ , 𝑑 : 𝑇, 𝑎 ′′ ′ Γ ⊢ 𝑑 : 𝑇 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, Proposition 1 (High Channels) proves that 𝑏 : Cℓ [𝑇 ′ ] is in Γ′′ , thus also ℒC,𝑑:𝑇,˜𝑎:𝑇˜ (𝑏) = 𝐻, giving the thesis. 𝑎 : 𝑇˜) (𝑃 ′ ∣ 𝑏⟨𝑐⟩.𝑃 ′′ ). By Proposition 5 Integrity Let now 𝑃 ∣ 𝑂 →∗ (𝜈𝑏 : CHH [𝑇 ]) (𝜈˜ ′ (Subject congruence and reduction) we get Γ ⊢ (𝜈𝑏 : CHH [𝑇 ]) (𝜈˜ 𝑎 : 𝑇˜) (𝑃 ′ ∣ 𝑏⟨𝑐⟩.𝑃 ′′ ), ′ HH ′′ ˜ ˜ : 𝑇 ⊢ 𝑏⟨𝑐⟩.𝑃 , by repeatedly applying R ES and ﬁnally which implies Γ , 𝑏 : C [𝑇 ], 𝑎 by PAR. Let Γ′′ = Γ′ , 𝑏 : CHH [𝑇 ], 𝑎 ˜ : 𝑇˜. Rule O UT requires Γ′′ ⊢ 𝑏 : Cℓ [𝑇 ′ ] and Γ′′ ⊢ 𝑐 : 𝑇 ′ . By Corollary 1 (Uniqueness of Channel Types), we obtain that Cℓ [𝑇 ′ ] = CHH [𝑇 ], 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:CHH [T′ ],˜a:T˜ (𝑐) = ℒI (𝑇 ′′ ) we get the thesis. ⊔ ⊓

R. Focardi and M. Maffei / Types for Security Protocols

𝐾+

𝐾−

Symmetric encryption Asymmetric encryption

𝐾

𝐾

ek(𝐾)

𝐾

Digital signature

𝐾

vk(𝐾)

˜ ⟩ + of ⟨˜ case ⟨𝑀 𝑥⟩𝐾 − in 𝑃 𝐾

→

˜ /˜ 𝑃 {𝑀 𝑥}

157

(D EC /C HECK )

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 operations, as shown in Table 6. Term ek(𝐾) denotes the public encryption key corresponding to the private key 𝐾, and term vk(𝐾) is the public veriﬁcation key corresponding to the signing key 𝐾 (hence 𝐾 has to be kept secret, while ek(𝐾) and vk(𝐾) can be ˜ ∣}s , {∣𝑀 ˜ ∣}a , and [𝑀 ˜ ]𝐾 denote, respectively, the symmetric and asympublished); {∣𝑀 𝐾 𝐾 ˜ . Notice that we model metric encryption and the digital signature of the tuple of terms 𝑀 cryptographic schemes where encryption and veriﬁcation 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˜ ⟩𝐾 to denote a generic encryption/signature term when its exact venient to write ⟨𝑀 nature is unimportant. We will also use the notation 𝐾 + and 𝐾 − to respectively denote encryption/signature keys and their decryption/veriﬁcation counterparts, as speciﬁed in Table 7 together with the semantics of cryptographic operations. Intuitively, process case 𝑀 of ⟨˜ 𝑥⟩𝐾 − in 𝑃 tries to decrypt or check the signature of 𝑀 with key 𝐾 − ˜ /˜ ˜ ⟩𝐾 + , or gets stuck otherwise. and behaves as 𝑃 {𝑀 𝑥} if it succeeds, i.e., when 𝑀 is ⟨𝑀 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 ≜ (𝜈𝑘 : 𝑇𝑘 ) 𝑐⟨{∣[𝐴, 𝐵, 𝑘]𝑘𝐵 ∣}aek(𝑘𝐴 ) ⟩.𝑐(𝑥𝑒 ). case 𝑥𝑒 of {∣𝑥𝑚 ∣}s𝑘 in 0

158

R. Focardi and M. Maffei / Types for Security Protocols

The initiator 𝐵 generates a fresh session key 𝑘, signs 𝐴 and 𝐵’s identiﬁers 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 veriﬁes the enclosed signature, checks that the ﬁrst signed message is her own identiﬁer, 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 syntax 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 veriﬁcation keys. Example 5 Let us consider the process illustrated in Example 4. Type 𝑇𝑘 of the session key is SymKHH [HH ] as it is trusted (ℓ = HH ), symmetric (𝜇 = Sym) and transports HH terms. The type 𝑇𝐵 of 𝐵’s signing key 𝑘𝐵 is SigKHH [LL, LL, 𝑇𝑘 ] and the type of the corresponding (public) veriﬁcation key vk(𝑘𝐵 ) is VerKLH [LL, LL, 𝑇𝑘 ], since this trusted, i.e., high integrity, key-pair is used to sign two LL identiﬁers and a symmetric session key of type 𝑇𝑘 . The type 𝑇𝐴 of 𝐴’s decryption key 𝑘𝐴 is DecKHH [HH ] and the type of the corresponding encryption key ek(𝑘𝐴 ) is EncKLH [HH ]. This key-pair is indeed used to encrypt a signature which is at high conﬁdentiality, 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 deﬁnition 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 highconﬁdentiality 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 deﬁnition of ℒI,Γ (𝑀 ) as

R. Focardi and M. Maffei / Types for Security Protocols

159

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,Γ (𝐾) ⎧ 𝐻𝐻 ⎨ 𝐻 if Γ(𝐾) = 𝜇K [𝑇 ] and ℒI,Γ (𝑀 ) ⊑𝐼 ℒI (𝑇 ) = ℒI,Γ (⟨𝑀 ⟩𝐾 + ) ⎩ 𝐿 otherwise Intuitively, we want to ensure that high-integrity variables get replaced only by highintegrity terms. This is formalized by the following deﬁnition, which extends Deﬁnition 3 (Integrity) so to deal with cryptographic operations. Deﬁnition 4 (Integrity with Cryptography) 𝑃 preserves integrity if, for all opponents 𝑂, whenever 𝑎 : 𝑇˜) (𝑃 ′ ∣ 𝑏⟨𝑀 ⟩.𝑃 ′′ ) or 𝑃 ∣ 𝑂 →∗ (𝜈𝑏 : CHH [𝑇 ]) (𝜈˜ ∗ + 𝐻𝐻 𝑃 ∣ 𝑂 → (𝜈𝑘 : 𝜇K [𝑇 ]) (𝜈˜ 𝑎 : 𝑇˜) (𝑃 ′ ∣ case ⟨𝑀 ⟩𝑘+ of ⟨𝑥⟩𝑘− in 𝑃 ′′ ) then ℒI,Γ (𝑀 ) ⊑𝐼 ℒI (𝑇 ) with Γ = 𝑏 : CHH [𝑇 ], 𝑘+ : 𝜇K𝐻𝐻 [𝑇 ], 𝑎 ˜ : 𝑇˜. As already noticed, Γ is always guaranteed to be a function thanks to the implicit alpha renaming of bound names. The deﬁnition 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 system can 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 deﬁnition 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 reﬁned to also reason about integrity properties. Subtyping and Environment. Subtyping for keys is similar to the one for channels. Formally, the subtyping relation is deﬁned as the least preorder such that: . . . as in Equation 2 LL ≤ 𝜇KLL [LL, . . . , LL] 𝜇Kℓ [𝑇˜] ≤ ℓ

(5)

160

R. Focardi and M. Maffei / Types for Security Protocols

E NV

E MPTY

Γ ⊢𝒞 ⋄

∅ ⊢𝒞 ⋄

𝑇 = 𝜇Kℓ [. . .], Cℓ [. . .] ⇒ ℓ = 𝐻𝐻, 𝜇 ∈ {Sym, Dec, Sig}

𝑢∈ / dom(Γ)

Γ, 𝑢 : 𝑇 ⊢𝒞 ⋄ Table 8. Cryptographic calculus: well-formedness of Γ

E NC K EY

V ER K EY

Γ ⊢𝒞 𝐾 : DecKℓ𝐶 ℓ𝐼 [𝑇˜] Γ ⊢𝒞 ek(𝐾) : EncK𝐿ℓ𝐼 [𝑇˜]

S YM E NC

˜ : 𝑇˜ Γ ⊢𝒞 𝐾 : SymKℓ𝐶 ℓ𝐼 [𝑇˜] Γ ⊢𝒞 𝑀 s ˜ Γ ⊢𝒞 {∣𝑀 ∣}𝐾 : 𝐿ℓ𝐼

D IG S IG

Γ ⊢𝒞 𝐾 : SigKℓ𝐶 ℓ𝐼 [𝑇˜] Γ ⊢𝒞 vk(𝐾) : VerK𝐿ℓ𝐼 [𝑇˜]

A SYM E NC

˜ : 𝑇˜ Γ ⊢𝒞 𝐾 : EncKℓ𝐶 ℓ𝐼 [𝑇˜] Γ ⊢𝒞 𝑀 a ˜ Γ ⊢𝒞 {∣𝑀 ∣}𝐾 : 𝐿ℓ𝐼

Γ ⊢𝒞 𝐾 : 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 deﬁned 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 veriﬁcation 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, reﬂecting their asymmetric nature. Typing Terms. In Table 9 we give the typing rules for the new terms, namely derived keys, encryptions and signatures. E NC K EY says that if a decryption key 𝐾 is of type DecKℓ𝐶 ℓ𝐼 [𝑇˜], then the corresponding encryption key ek(𝐾) is of type EncK𝐿ℓ𝐼 [𝑇˜]. Notice that the conﬁdentiality level is 𝐿, since public keys are allowed to be known to the attacker, while the integrity level is inherited from the decryption key; V ER K EY does the same for veriﬁcation and signing keys. Ciphertexts are typed by S YM E NC and A SYM E NC. Ciphertexts can be output on public channels and consequently their conﬁdentiality level is 𝐿. Their integrity level, ˜ is required to be the instead, is the one of the key. The type of encrypted messages 𝑀 one speciﬁed in the type of key. Digital signatures are typed by D IG S IG. The only difference with respect to the encryption rules is that the obtained conﬁdentiality level is the ˜ : these messages can be maximum of the conﬁdentiality levels of the signed messages 𝑀 reconstructed from a signature using the public veriﬁcation key, thus it is important to keep track of the conﬁdentiality level of what is signed.

R. Focardi and M. Maffei / Types for Security Protocols

S YM D EC

Γ ⊢𝒞 𝐾 : SymKℓ [𝑇˜]

Γ ⊢𝒞 𝑀 : 𝑇

Γ ⊢𝒞 case 𝑀 of

A SYM D EC

Γ ⊢𝒞 𝐾 : DecKℓ [𝑇˜]

Γ ⊢𝒞 𝑀 : 𝑇

{∣˜ 𝑥∣}s𝐾

161

Γ, 𝑥 ˜ : 𝑇˜ ⊢𝒞 𝑃 in 𝑃

Γ, 𝑥 ˜ : 𝑇˜ ⊢𝒞 𝑃

ℒI (𝑇 ) = 𝐿 ⇒ Γ, 𝑥 ˜ : LL ⊢𝒞 𝑃

Γ ⊢𝒞 case 𝑀 of {∣˜ 𝑥∣}a𝐾 in 𝑃

S IGN C HECK Γ ⊢𝒞 𝑀 : 𝑇

Γ ⊢𝒞 𝐾 : VerKℓ𝐶 ℓ𝐼 [𝑇˜]

Γ, 𝑥 ˜ : 𝑇˜ ⊢𝒞 𝑃

ℒC (𝑇 ) = 𝐻 ⇒ ℓ𝐼 = 𝐻

Γ ⊢𝒞 case 𝑀 of [˜ 𝑥]𝐾 in 𝑃

N ONCE C HECK Γ ⊢𝒞 𝑀 : 𝑇

𝑛 : 𝑇 ′ in Γ

ℒ(𝑇 ′ ) ∕≤ ℒ(𝑇 )

Γ ⊢𝒞 𝑃2

Γ ⊢𝒞 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 S UBSUMPTION or E NC K EY /V ER K EY. 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 ⊢𝒞 ) Γ ⊢𝒞 𝑁 : 𝜇KLL [𝑇˜] 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 S UBSUMPTION, 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/veriﬁcation keys can only be derived via S UBSUMPTION, E NC K EY or V ER K EY, 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 untrusted 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 veriﬁcation keys is unique if we ﬁx the level to be 𝐿𝐻. In fact, being them public, they can also be typed at level 𝐿𝐿, reﬂecting their asymmetric nature. Since the latter property is not used in the proofs, we just state the former.

162

R. Focardi and M. Maffei / Types for Security Protocols

Proposition 10 (Uniqueness of Key Types for ⊢𝒞 ) If Γ ⊢𝒞 𝐾 : 𝜇Kℓ [𝑇˜] and Γ ⊢𝒞 𝐾 : ′ 𝜇′ Kℓ [𝑇˜′ ] 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 dictated 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 conﬁdentiality level is greater than or equal to the maximum conﬁdentiality level of the signed messages. This is important to preserve the secrecy of signed terms. Proposition 11 (Payload Type for ⊢𝒞 ) The following implications hold: ˜ ∣}s : 𝑇 and Γ ⊢𝒞 𝐾 : SymKℓ [𝑇˜] imply Γ ⊢𝒞 𝑀 ˜ : 𝑇˜. 1. Γ ⊢𝒞 {∣𝑀 𝐾 a ℓ ˜ ˜ ˜ : 𝑇˜ or ℒI (𝑇 ) = 𝐿 2. Γ ⊢𝒞 {∣𝑀 ∣}ek(𝐾) : 𝑇 and Γ ⊢𝒞 𝐾 : DecK [𝑇 ] imply Γ ⊢𝒞 𝑀 ˜ : 𝐿𝐿. and Γ ⊢𝒞 𝑀 ˜ ˜ : 𝑇˜ and 3. Γ ⊢𝒞 [𝑀 ]𝐾 : 𝑇 and Γ ⊢𝒞 𝐾 : SigKℓ [𝑇˜] imply Γ ⊢𝒞 𝑀 ⊔𝑇𝑖 ∈𝑇˜ ℒC (𝑇𝑖 ) ⊑𝐶 ℒC (𝑇 ). Typing Processes. We ﬁnally extend the type system with the rules for processes performing cryptographic operations, as shown in Table 10. S YM D EC 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 variables 𝑥 ˜ will only be replaced by values of type 𝑇˜. In fact, if the decryption succeeds, then ˜ ∣}s ; since this term can only be typed by S YM E NC 𝑀 is a ciphertext of the form {∣𝑀 𝐾 ℓ ˜ ˜ have types 𝑇˜. and 𝐾 has type SymK [𝑇 ], we know that 𝑀 A SYM D EC 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 ˜ ˜ ∣}a ciphertext {∣𝑀 ek(𝐾) might come from the adversary meaning that 𝑀 could be of type a ˜ LL. This might seem to be strange, since {∣𝑀 ∣}𝐾 can only be typed by A SYM E NC and ˜ must have the type speciﬁed in the type of the encryption key ek(𝐾). However, ek(𝐾) 𝑀 can be given type EncK𝐿ℓ𝐼 [𝑇˜] by E NC K EY as well as EncK𝐿𝐿 [LL, . . . , LL] via the subtyping relation EncK𝐿ℓ𝐼 [𝑇˜] ≤ 𝐿ℓ𝐼 ≤ 𝐿𝐿 ≤ EncK𝐿𝐿 [LL, . . . , LL], which allows the attacker to type public encryption (and veriﬁcation) 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 speciﬁed in the key type and therefore we can simply type-check the continuation process under this typing assumption. This shows how combining integrity and conﬁdentiality 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

R. Focardi and M. Maffei / Types for Security Protocols

163

the ciphertext is guaranteed by digital signature. An application of this rule is shown in Example 7. S IGN C HECK is similar to S YM D EC 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 conﬁdentiality and integrity, since it avoids that processes use 𝐿𝐿 keys to verify a signature that transports high conﬁdentiality data. In fact, that would downgrade the level to 𝐿𝐿 compromising secrecy. Finally, N ONCE C HECK 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 A SYM D EC in the case the type of some of the messages in the ciphertext sufﬁces 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

Γ

R ES R ES PAR

𝐴 : LL, 𝐵 : LL, 𝑐 : LL . . . , 𝑘𝐴 : DecKHH [HH ] . . . , 𝑘𝐵 : SigKHH [LL, LL, 𝑇𝑘 ]

⊢𝒞 Protocol (𝜈𝑘𝐴 : DecKHH [HH ]) (𝜈𝑘𝐵 : SigKHH [LL, LL, 𝑇𝑘 ]) (Initiator ∣ Responder)

where 𝑇𝑘 is SymKHH [HH ]. The two restrictions just introduce the bindings 𝑘𝐴 : 𝑇𝐴 and 𝑘𝐵 : 𝑇𝐵 . The same Γ is then used to independently type the initiator and the responder. Rules Applied

Γ

− R ES O UT . . . , 𝑘 : SymKHH [HH ] − IN A SYM D EC . . . , 𝑥𝑒 : LL . . . , 𝑥𝑚 : HH S TOP

⊢𝒞

Initiator (𝜈𝑘 : SymKHH [HH ]) 𝑐⟨{∣[𝐴, 𝐵, 𝑘]𝑘𝐵 ∣}aek(𝑘𝐴 ) ⟩ 𝑐(𝑥𝑒 ) case 𝑥𝑒 of {∣𝑥𝑚 ∣}s𝑘 in 0 0

In the initiator process, the restriction of the session key is typed by R ES, which introduces the type binding 𝑘 : SymKHH [HH ]. The output of {∣[𝐴, 𝐵, 𝑘]𝑘𝐵 ∣}aek(𝑘𝐴 ) is typed by O UT: in order to apply this rule, we have to prove that [𝐴, 𝐵, 𝑘]𝑘𝐵 is of type 𝐻𝐻 (D IG S IG) and {∣[𝐴, 𝐵, 𝑘]𝑘𝐵 ∣}aek(𝑘𝐴 ) is of type 𝐿𝐻 (A SYM E NC) and thus 𝐿𝐿 by subsumption. Notice that the ciphertext has to be given type 𝐿𝐿 since the type of 𝑐 in Γ is indeed 𝐿𝐿. The input of the response 𝑥𝑒 is typed by I N, which introduces the type binding 𝑥𝑒 : 𝐿𝐿. The decryption of the ciphertext is typed by S YM D EC, which introduces the type binding 𝑥𝑚 : HH , since HH is the type transported by key 𝑘. Process 0 is ﬁnally typed by S TOP.

164

R. Focardi and M. Maffei / Types for Security Protocols

Rules Applied

Γ

⊢𝒞

IN − . . . , 𝑥𝑒 : LL S YM D EC S IGN C HECK . . . , 𝑥𝑠 : LL / . . . , 𝑥𝑠 : 𝐻𝐻 . . . , 𝑥𝐴 : LL, 𝑥𝐵 : LL, 𝑥𝑘 : 𝑇𝑘 C OND R ES − . . . , 𝑚 : HH O UT

Responder 𝑐(𝑥𝑒 ). case 𝑥𝑒 of {∣𝑥𝑠 ∣}a𝑘𝐴 in case 𝑥𝑠 of [𝑥𝐴 , 𝑥𝐵 , 𝑥𝑘 ]vk(𝑘𝐵 ) in if 𝐴 = 𝑥𝐴 then (𝜈𝑚 : HH ) 𝑐⟨{∣𝑚∣}s𝑥𝑘 ⟩

In the responder process, the input of the challenge is typed by I N, which introduces the type binding 𝑥𝑒 : 𝐿𝐿. The decryption of this message is typed by A SYM D EC: Since the ciphertext is of low conﬁdentiality 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 S IGN C HECK independently of the type of 𝑥𝑠 . This rule introduces the bindings 𝑥𝐴 : 𝐿𝐿, 𝑥𝐵 : 𝐿𝐿, 𝑥𝑘 : 𝑇𝑘 , as speciﬁed in the type of 𝑘𝐵 . The equality test is typed by C OND and the generation of message 𝑚 by R ES. We ﬁnally type-check process 𝑐⟨{∣𝑚∣}s𝑥𝑘 ⟩ by O UT, showing that {∣𝑚∣}s𝑥𝑘 is of type 𝐿𝐿 by A SYM E NC 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 speciﬁed in the key, thus gaining precision in the analysis. We illustrate this technique on the following protocol: 𝐴

𝐵 [{∣𝑚∣}aek(𝑘

𝐵)

]𝑘𝐴

𝐶

/ {∣𝑚∣}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 conﬁdentiality 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 {∣𝑚∣}aek(𝑘𝐵 ) is typed at level 𝐿𝐻 since it has been generated with the high integrity encryption key ek(𝐾) of type EncK𝐿𝐻 [𝐻𝐻]. It can thus be signed with key 𝑘𝐴 . The obtained 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 {∣𝑚∣}aek(𝑘𝐵 ) obtained after signature veriﬁcation type 𝐿𝐻, as speciﬁed in the vk(𝑘𝐴 ) type VerK𝐿𝐻 [𝐿𝐻]. This allows us to give to decrypted message 𝑚 type HH , as speciﬁed 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

R. Focardi and M. Maffei / Types for Security Protocols

165

type SymK𝐻𝐻 [𝐻𝐻]. In the type system presented in [3], this protocol would not typecheck 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 N ONCE C HECK, which allows us to prune one of the typing branches introduced by A SYM D EC, in case the type of some of the decrypted messages sufﬁces to determine that the ciphertext does not come from the attacker. Let us consider the Needham-Schroeder-Lowe protocol: 𝐴

𝐵 o

{∣𝑛𝐵 ,𝐵∣}aek(𝑘

𝐴)

{∣𝑛𝐴 ,𝑛𝐵 ,𝐴∣}aek(𝑘 ) 𝐵

o

/

{∣𝑛𝐴 ∣}aek(𝑘′ ) 𝐴

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 identiﬁer. Let the two nonces 𝑛𝐴 , 𝑛𝐵 be given type 𝐻𝐻 and 𝐴’s identiﬁer 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 N ONCE C HECK, 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 encryption.) 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 + . . . + 𝑇˜𝑛 ] ˜ 𝑖 ) of type 𝑇˜𝑖 , which This type describes keys used to encrypt tagged payloads msg𝑖 (𝑀 is close in spirit to the tagged unions used in [23,24]. The calculus has to be ex˜ )∣}a and a decryption primitive of the form tended with a term of the form {∣msg𝑖 (𝑀 𝐾 a case 𝑀 of {∣msg𝑖 (˜ 𝑥)∣}𝐾 in 𝑃 , which checks at run-time that msg𝑖 is the tag of the messages encrypted in 𝑀 .

166

R. Focardi and M. Maffei / Types for Security Protocols

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 congruence 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 N ONCE C HECK rule, we know that Γ ⊢𝒞 if 𝑀 = 𝑛 then 𝑃1 else 𝑃2 , Γ ⊢𝒞 𝑀 : 𝑇 , Γ(𝑛) = 𝑇 ′ , ℒ(𝑇 ′ ) ∕≤ ℒ(𝑇 ), and Γ ⊢𝒞 𝑃2 . We prove that if 𝑀 = 𝑛 then 𝑃1 else 𝑃2 ∕→ 𝑃1 , i.e., by R ED C OND 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 ˜ ⟩𝐾 + of ⟨˜ case ⟨𝑀 𝑥⟩𝐾 − in 𝑃

→

˜ /˜ 𝑃 {𝑀 𝑥}

˜ ⟩𝐾 + of ⟨˜ 𝑥⟩𝐾 − in 𝑃 . The three rules for proving this By hypothesis, Γ ⊢𝒞 case ⟨𝑀 ˜ ⟩𝐾 + : judgment are S YM D EC, A SYM D EC and S IGN C HECK. 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 Γ, 𝑥 𝑥}, as 𝑀 ˜ : 𝑇˜ ⊢𝒞 𝑃 , by the substitution lemma, we obtain Γ ⊢𝒞 𝑃 {𝑀 desired. Asymmetric decryption. Rule A SYM D EC additionally requires variables to be typed 𝐿𝐿, i.e., Γ, 𝑥 ˜ : LL ⊢𝒞 𝑃 , when ℒI (𝑇 ) = 𝐿. By Proposition 11 (Payload Type for ⊢𝒞 )(2), ˜ : 𝑇˜ or ℒI (𝑇 ) = 𝐿 ∧ Γ ⊢𝒞 𝑀 ˜ : LL. Since Γ, 𝑥 ˜ : 𝑇˜ ⊢𝒞 𝑃 and we know that Γ ⊢𝒞 𝑀 Γ, 𝑥 ˜ : 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 V ER K EY, which implies Γ ⊢𝒞 ˜ : 𝑇˜. By 𝐾 : SigKℓ𝐶 𝐻 [𝑇˜]. By Proposition 11 (Payload Type for ⊢𝒞 )(3) we have Γ ⊢𝒞 𝑀 ˜ 𝑥}, as desired. the substitution lemma, we obtain Γ ⊢𝒞 𝑃 {𝑀 /˜ If, instead, ℓ = 𝐿𝐿, by Proposition 7 (Low Keys for ⊢𝒞 ) we must have 𝑇˜ = LL, . . . , LL, and the judgment might derive either from V ER K EY or from S UBSUMPTION. Anyway,

R. Focardi and M. Maffei / Types for Security Protocols

167

at some point of the derivation of Γ ⊢𝒞 vk(𝐾) : VerK𝐿𝐿 [𝑇˜] we know it has been applied V ER K EY as it is the only rule for typing term vk(𝐾). This implies Γ ⊢𝒞 𝐾 : ˜ : 𝑇˜′ and SigKℓ [𝑇˜′ ]. Thus, by Proposition 11 (Payload Type for ⊢𝒞 )(3) we have Γ ⊢𝒞 𝑀 ′ ℒC (𝑇 ) = ⊔𝑇 ′ ∈𝑇˜′ ℒC (𝑇 ). Now recall that rule S IGN C HECK requires that ℒC (𝑇 ) = 𝐻 implies ℓ𝐼 = 𝐻. Since we have taken ℓ𝐼 = 𝐿 we know that ℒC (𝑇 ) = 𝐿. From ℒC (𝑇 ) = ⊔𝑇 ′ ∈𝑇˜′ ℒC (𝑇 ′ ) we get ∀𝑇 ′ ∈ 𝑇˜′ , ℒC (𝑇 ′ ) = 𝐿 which implies ℒ(𝑇 ′ ) ≤𝒞 𝐿𝐿 ˜ : 𝑇˜′ and and also 𝑇 ′ ≤𝒞 𝐿𝐿 (since we always have 𝑇 ≤𝒞 ℒ(𝑇 )). From Γ ⊢𝒞 𝑀 ˜ S UBSUMPTION we thus get Γ ⊢𝒞 𝑀 : LL. By the substitution lemma, we obtain Γ ⊢𝒞 𝑃 {𝑀/𝑥}, as desired. ⊔ ⊓ Secrecy and Integrity of cryptographic protocols. The following lemma relates the previously deﬁned 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 integrity 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: 𝑎 : 𝑇˜) (𝑃 ′ ∣ case ⟨𝑀 ⟩𝑘+ of ⟨𝑥⟩𝑘− in 𝑃 ′′ ) 𝑃 ∣ 𝑄 →∗ (𝜈𝑘 + : 𝜇K𝐻𝐻 [𝑇 ]) (𝜈˜ 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 R ES 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 Γ′′ ⊢𝒞 𝑘 + : 𝜇′ Kℓ [𝑇 ′ ], 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 operation. Therefore by Proposition 11 (Payload Type for ⊢𝒞 ) we get Γ′′ ⊢𝒞 𝑀 : 𝑇 . Lemma 4 (Integrity) ﬁnally gives ℒI,Γ′′ (𝑀 ) ⊑𝐼 ℒI (𝑇 ).

168

R. Focardi and M. Maffei / Types for Security Protocols

The proof for the other reduction: 𝑎 : 𝑇˜) (𝑃 ′ ∣ 𝑐⟨𝑀 ⟩.𝑃 ′′ ) 𝑃 ∣ 𝑂 →∗ (𝜈𝑐 : CHH [𝑇 ]) (𝜈˜ 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 veriﬁer. In particular, we focus on a variant of the agreement property [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 effect 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 deﬁnitions proposed by Gavin Lowe in [28], namely agreement. Intuitively, “a protocol guarantees to a veriﬁer 𝐴 agreement with a claimant 𝐵 on a set of data items 𝑑𝑠 if, whenever 𝐴 (acting as veriﬁer) completes a run of the protocol, apparently 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 veriﬁer 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 handshakes. A nonce handshake is composed of two messages, the challenge sent by the veriﬁer to the claimant and the response sent by the claimant to the veriﬁer. Both the challenge and the response contain a random value (called nonce) freshly generated by the veriﬁer: the nonce guarantees the freshness of the response, which entails the freshness 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 assertion begin𝑁 (𝑀 ˜;𝑁 ˜) end assertion end𝑁 (𝑀

R. Focardi and M. Maffei / Types for Security Protocols

169

˜ 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: Deﬁnition 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˜; 𝑁 ˜ ) ∣ 𝑄. Otherwise the ular, they are never of the form !𝑃 with 𝑃 ≡ (𝜈˜ 𝑎 : 𝑇˜) end𝑁 (𝑀 deﬁnition 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 reﬁne 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. Deﬁnition 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 opponents. This property, called robust agreement, is stated below. Deﬁnition 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 ≜ (𝜈𝑘 : 𝑇𝑘 ) 𝑐⟨{∣[𝐴, 𝐵, 𝑘]𝑘𝐵 ∣}aek(𝑘𝐴 ) ⟩.𝑐(𝑥𝑒 ). 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 identiﬁers 𝐴 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 𝐴 conﬁrms the reception of the identiﬁers 𝑥𝐴 , 𝑥𝐵 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. ⊔ ⊓

170

R. Focardi and M. Maffei / Types for Security Protocols

˜ ) ∣ Resp (𝑀 ˜)∣𝑀 = 𝑁 𝐹, 𝐸 ::= fresh(𝑁 ) ∣ Chal𝑁 (𝑀 𝑁 𝑇 ::= . . . 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 deﬁned 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 ˜ ) witnesses a challenge to authenticate messages 𝑀 ˜ end assertions. The effect Chal𝑁 (𝑀 ˜ ) belongs to the effect associated to a with a fresh nonce 𝑁 . In particular, if Chal𝑁 (𝑀 particular protocol point, then we know that at run-time, whenever that protocol point is ˜ with nonce reached, a party has sent (or is allowed to send) a challenge to authenticate 𝑀 ˜ ˜ 𝑁 . Similarly, the effect Resp𝑁 (𝑀 ) witnesses a response to authenticate messages 𝑀 with nonce 𝑁 . Finally, 𝑀 = 𝑁 witnesses that 𝑀 is equal to 𝑁 . Intuitively, the restric˜ ). The latter justiﬁes a begin (𝑀 ˜;𝑁 ˜) tion of nonce 𝑁 justiﬁes fresh(𝑁 ) and Chal𝑁 (𝑀 𝑁 ˜ ˜ assertion, which in turn justiﬁes Resp𝑁 (𝑁 ). The effects fresh(𝑁 ), Chal𝑁 (𝑀 ), and ˜ ) together justify the assertion end𝑁 (𝑀 ˜;𝑁 ˜ ), which annotates the end of a Resp𝑁 (𝑁 ˜ have been sent in the challenge challenge-response protocol based on nonce 𝑁 where 𝑀 ˜ 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 justiﬁed. The scope of 𝑥, 𝑥 ˜ is 𝐹 , where 𝑥 is a binder for the (symmetric, encryption, or veriﬁcation) 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 justiﬁed, i.e., without providing any authentication guarantee.

R. Focardi and M. Maffei / Types for Security Protocols

171

A-E NV E MPTY ∅ ⊢𝒜 ⋄

Γ ⊢𝒜 ⋄ 𝑢∈ / dom(Γ) 𝑇 = Cℓ [. . .], 𝜇Kℓ(⋅) [ . . . ∣ . . . ] ⇒ ℓ = 𝐻𝐻, 𝜇 ∈ {Sym, Dec, Sig} Γ, 𝑢 : 𝑇 ⊢𝒜 ⋄

A-E FF

Γ ⊢𝒜 ⋄

fnfv(𝐹 ) ⊆ dom(Γ) Γ, 𝐹 ⊢𝒜 ⋄

Table 12. Well-formedness of Environments

The typing rules for the well-formedness of environments are shown in Table 12. A-E NV is the natural extension of E NV, while A-E FF 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 responder’s key pair is used by well-typed parties only for encrypting messages at high conﬁdentiality and high integrity, that is the signature generated by the initiator. The type 𝑇𝐵 says that the initiator’s key pair is only used to sign triples composed of two public and low integrity identiﬁers 𝑧𝐴 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 conﬁdential 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ℓ [˜ ˜ ˜ ˜ ˜ 𝑥, 𝐾 ′ /𝑥} occur in 𝑀 (𝑥) 𝑥 : 𝑇 ∣ 𝐹 ], that the effects 𝐹 {𝑀 /˜ the typing environment (cf. A-S YM E NC, A-A SYM E NC, A-S IGN). 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 veriﬁcation 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 veriﬁcation key. Characterizing Keys and Ciphertexts. We now see how the properties of keys and ciphertexts stated for type system ⊢𝒞 can be smoothly extended to type system ⊢𝒜 . We ﬁrst extend Proposition 6 (High Keys for ⊢𝒞 ) to dependent key types.

172

R. Focardi and M. Maffei / Types for Security Protocols

A-ATOM Γ ⊢𝒜 ⋄

𝑀 : 𝑇 in Γ

A-E NC K EY

A-S UBSUMPTION Γ ⊢𝒜 𝑀 : 𝑇 ′

Γ ⊢𝒜 𝑀 : 𝑇

ℓ𝐶 ℓ𝐼 Γ ⊢𝒜 𝐾 : DecK(𝑥) [˜ 𝑥 : 𝑇˜ ∣ 𝐹˜ ]

𝑇′ ≤ 𝑇

𝐿ℓ Γ ⊢𝒜 ek(𝐾) : EncK(𝑥)𝐼 [˜ 𝑥 : 𝑇˜ ∣ 𝐹˜ ]

Γ ⊢𝒜 𝑀 : 𝑇

A-V ER K EY

ℓ ℓ

𝐶 𝐼 Γ ⊢𝒜 𝐾 : SigK(𝑥) [˜ 𝑥 : 𝑇˜ ∣ 𝐹˜ ]

𝐿ℓ

Γ ⊢𝒜 vk(𝐾) : VerK(𝑥)𝐼 [˜ 𝑥 : 𝑇˜ ∣ 𝐹˜ ]

A-S YM E NC

ℓ𝐶 ℓ𝐼 Γ ⊢𝒜 𝐾 : SymK(𝑥) [˜ 𝑥 : 𝑇˜ ∣ 𝐹˜ ]

Γ

A-A SYM E NC

˜ ∣}s ⊢𝒜 {∣𝑀 𝐾

ℓ ℓ

𝐶 𝐼 Γ ⊢𝒜 𝐾 : EncK(𝑥) [˜ 𝑥 : 𝑇˜ ∣ 𝐹˜ ]

Γ

A-S IGN ˜ : 𝑇˜ Γ ⊢𝒜 𝑀

˜ : 𝑇˜ Γ ⊢𝒜 𝑀 : 𝐿ℓ𝐼

˜ : 𝑇˜ Γ ⊢𝒜 𝑀

˜ ∣}a ⊢𝒜 {∣𝑀 𝐾

˜ /˜ 𝐹˜ {𝑀 𝑥, 𝐾/𝑥} ∈ eff(Γ)

˜ /˜ 𝐹˜ {𝑀 𝑥, 𝐾/𝑥} ∈ eff(Γ)

: 𝐿ℓ𝐼

ℓ ℓ

𝐶 𝐼 Γ ⊢𝒜 𝐾 : 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 ℓ ∈ {𝐿𝐿, 𝐻𝐻}. 𝑥 : 𝑇˜ ∣ 𝐹˜ ] with 𝜇 ∈ {Enc, Ver} Proposition 16 (Public Keys for ⊢𝒜 ) Γ ⊢𝒜 𝑁 : 𝜇Kℓ(𝑥) [˜ 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ℓ [𝑇˜′ ]. 𝑥 : 𝑇˜ ∣ 𝐹˜ ] and Proposition 18 (Uniqueness of Key Types for ⊢𝒜 ) If Γ ⊢𝒞 𝐾 : 𝜇Kℓ(𝑥) [˜ ′ Γ ⊢𝒞 𝐾 : 𝜇′ Kℓ(𝑥) [˜ 𝑥 : 𝑇˜′ ∣ 𝐹˜′ ] with 𝜇 ∈ {Sym, Sig, Dec} and ∣𝑇˜∣ = ∣𝑇˜′ ∣ then ℓ = ℓ′ , 𝑇˜ = 𝑇˜′ , and 𝐹˜ = 𝐹˜′ . When ℓ = ℓ′ = 𝐻𝐻, we also have 𝜇 = 𝜇′ .

R. Focardi and M. Maffei / Types for Security Protocols

173

Finally, we characterize the type of encrypted (or signed) messages, in the same style as Proposition 11 (Payload Type for ⊢𝒞 ). Notice that the effects in the key type must belong to the typing environment used to type-check the ciphertext (or the signature). Proposition 19 (Payload Type for ⊢𝒜 ) The following implications hold: ˜ ˜ ˜ ∣}s : 𝑇 and Γ ⊢𝒜 𝐾 : SymKℓ [˜ ˜ ˜ 1. If Γ ⊢𝒜 {∣𝑀 𝐾 (𝑥) 𝑥 : 𝑇 ∣ 𝐹 ], then Γ ⊢𝒜 𝑀 : 𝑇 and ˜ /˜ 𝐹˜ {𝐾/𝑥, 𝑀 𝑥} ∈ eff(Γ). ℓ ˜ ∣}a ˜ : 𝑇˜ 𝑥 : 𝑇˜ ∣ 𝐹˜ ], then Γ ⊢𝒜 𝑀 2. If Γ ⊢𝒜 {∣𝑀 ek(𝐾) : 𝑇 and Γ ⊢𝒜 𝐾 : DecK(𝑥) [˜ ˜ ˜ ˜ and 𝐹 {ek(𝐾)/𝑥, 𝑀 /˜ 𝑥} ∈ eff(Γ), or ℒI (𝑇 ) = 𝐿 and Γ ⊢𝒜 𝑀 : 𝐿𝐿. ˜ ]𝐾 : 𝑇 and Γ ⊢𝒜 𝐾 : SigKℓ [˜ ˜ ˜ ˜ ˜ 3. If Γ ⊢𝒜 [𝑀 (𝑥) 𝑥 : 𝑇 ∣ 𝐹 ], 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-S TOP 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 justiﬁed 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 justiﬁed 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-R EPL checks that the typing environment contains no fresh effects, since we want to prevent multiple end assertions with the same nonce. A-R ES says that the restriction ˜ ), fresh(𝑎) in the continuation process 𝑃 . Notice (𝜈𝑎 : 𝑇 ) 𝑃 justiﬁes the effects Chal𝑎 (𝑀 that the type system is not syntax-directed since A-R ES can add an arbitrary preﬁx of ˜ ), fresh(𝑎) to the typing environment and the 𝑀 ˜ ’s are non-deterministically Chal𝑎 (𝑀 chosen. A-I N, and A-O UT do not modify the effects. A-S YM D EC, A-A SYM D EC, A𝑥⟩𝐾 − in 𝑃 S IG C HECK say that the decryption (or signature veriﬁcation) case 𝑀 of ⟨˜ 𝑦 : 𝑇˜ ∣ 𝐹˜ ] justiﬁes the effect 𝐹˜ {𝐾 ′ /𝑦, 𝑥 ˜/˜ 𝑦 } in the continuation with a key of type 𝜇Kℓ(𝑦) [˜ 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 veriﬁcation key, respectively. A-C OND type-checks the equality test if 𝑀 = 𝑁 then 𝑃 , justifying in the typing environment of the continuation process the equality 𝑀 = 𝑁 . A-B EGIN type-checks the ˜;𝑁 ˜ ), requiring that the terms 𝑀 ˜ have indeed been received begin assertion begin𝑁 (𝑀 ˜ in a challenge with nonce 𝑁 (i.e., Chal𝑁 (𝑀 ) belongs to the typing environment). Sim˜;𝑁 ˜ ), requiring that the terms 𝑀 ˜ ilarly, A-E ND type-checks the end assertion end𝑛 (𝑀 ˜ 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𝑛 (𝑀 ˜ ), and fresh(𝑛) as well as effects proving the equality between 𝑛 and 𝑁 ). Resp𝑁 (𝑁

174

R. Focardi and M. Maffei / Types for Security Protocols

A-PAR A-S TOP Γ ⊢𝒜 ⋄

Γ∣𝐸𝑃 , 𝑄 ⊢𝒜 𝑃 Γ∣𝐸𝑄 , 𝑃 ⊢𝒜 𝑄 𝐸𝑃 ∪ 𝐸𝑄 = eff(Γ) 𝐸𝑃 ∩ 𝐸𝑄 = {𝑓 ∈ eff(Γ) ∣ ∄𝑁.𝑓 = fresh(𝑁 )}

Γ ⊢𝒜 0

Γ ⊢𝒜 𝑃 ∣ 𝑄

A-R EPL Γ ⊢𝒜 𝑃

A-R ES

Γ ⊢𝒜 !𝑃

A-I N

Γ, 𝑥 ˜ : 𝑇˜ ⊢𝒜 𝑃

Γ ⊢𝒜 (𝜈𝑎 : 𝑇 ) 𝑃

A-O UT

Γ ⊢𝒜 𝑁 : Cℓ [𝑇˜]

˜ : 𝑇˜ Γ ⊢𝒜 𝑀

Γ ⊢𝒜 𝑁 (˜ 𝑥).𝑃

A-S YM D EC

Γ ⊢𝒜 𝐾 : SymKℓ(𝑦) [˜ 𝑦 : 𝑇˜ ∣ 𝐹˜ ]

Γ ⊢𝒜 𝑀 : 𝑇

˜ ), fresh(𝑎) Γ′ ⪯ Chal𝑎 (𝑀

Γ, 𝑎 : 𝑇, Γ′ ⊢𝒜 𝑃

∄𝑁.fresh(𝑁 ) ∈ eff(Γ)

{∣˜ 𝑥∣}s𝐾

Γ ⊢𝒜 case 𝑀 of

Γ ⊢𝒜 𝑁 : Cℓ [𝑇˜]

Γ ⊢𝒜 𝑃

˜ ⟩.𝑃 Γ ⊢ 𝒜 𝑁 ⟨𝑀

Γ, 𝑥 ˜ : 𝑇˜, 𝐹˜ {𝐾/𝑦, 𝑥 ˜/˜ 𝑦 } ⊢𝒜 𝑃 in 𝑃

A-A SYM D EC

Γ ⊢𝒜 𝑀 : 𝑇 Γ ⊢𝒜 𝐾 : DecKℓ(𝑦) [˜ 𝑦 : 𝑇˜ ∣ 𝐹˜ ] Γ, 𝑥 ˜ : 𝑇˜, 𝐹˜ {ek(𝐾)/𝑦, 𝑥 ˜/˜ 𝑦 } ⊢𝒜 𝑃 ℒI (𝑇 ) = 𝐿 ⇒ Γ, 𝑥 ˜ : 𝐿𝐿 ⊢𝒜 𝑃 Γ ⊢𝒜 case 𝑀 of {∣˜ 𝑥∣}a𝐾 in 𝑃

A-S IG C HECK

Γ ⊢𝒜 𝑀 : 𝑇 Γ ⊢𝒜 𝐾 : VerKℓ(𝑦) [˜ 𝑦 : 𝑇˜ ∣ 𝐹˜ ] Γ, 𝑥 ˜ : 𝑇˜, 𝐹˜ {𝐾/𝑦, 𝑥 ˜/˜ 𝑦 } ⊢𝒜 𝑃 ℒC (𝑇 ) = 𝐻 ⇒ ℓ𝐼 = 𝐻 Γ ⊢𝒜 case 𝑀 of [˜ 𝑥]𝐾 in 𝑃

A-C OND

Γ ⊢𝒜 𝑀 : 𝑇

Γ ⊢𝒜 𝑁 : 𝑇 ′

Γ, 𝑀 = 𝑁 ⊢𝒜 𝑃

Γ ⊢𝒜 𝑄

Γ ⊢𝒜 if 𝑀 = 𝑁 then 𝑃 else 𝑄

A-N ONCE C HECK Γ ⊢𝒜 𝑀 : 𝑇

Γ(𝑛) = 𝑇 ′

ℒ(𝑇 ′ ) ∕≤ ℒ(𝑇 )

Γ ⊢𝒜 𝑃2

Γ ⊢𝒜 if 𝑀 = 𝑛 then 𝑃1 else 𝑃2

A-B EGIN

˜ ) ∈ eff(Γ) Chal𝑁 (𝑀 Γ ⊢𝒜

A-E ND

𝑛 =Γ 𝑁

˜ ) ⊆ dom(Γ) fnfv(𝑁 ˜;𝑁 ˜) begin (𝑀

Γ ⊢𝒜 ⋄

𝑁

˜ ), Resp (𝑁 ˜ ) ∈ eff(Γ) fresh(𝑛), Chal𝑛 (𝑀 𝑁 ˜ ˜ Γ ⊢𝒜 end𝑛 (𝑀 ; 𝑁 )

Γ ⊢𝒜 ⋄

Notation: ˜ ) s.t. 𝑃 ≡ begin (𝑀 ˜;𝑁 ˜ ) ∣ 𝑃 ′ }. 𝑃 = {Resp𝑁 (𝑁 𝑁 / 𝐸; (Γ, 𝐹 )∣𝐸 = Γ∣𝐸 , 𝐹 if 𝐹 ∈ 𝐸. ∅∣𝐸 = ∅; (Γ, 𝑥 : 𝑇 )∣𝐸 = Γ∣𝐸 , 𝑥 : 𝑇 ; (Γ, 𝐹 )∣𝐸 = Γ∣𝐸 if 𝐹 ∈ Γ ⪯ Γ′ iff Γ is a, possibly empty, preﬁx of Γ′ . =Γ is the smallest equivalence relation on terms such that if 𝑁 = 𝑀 ∈ Γ then 𝑁 =Γ 𝑀. Table 14. Typing Rules for Processes.

R. Focardi and M. Maffei / Types for Security Protocols

175

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(Γ)

A-R ES A-R ES A-PAR

∅ ∅ ∅

⊢𝒜 Protocol (𝜈𝑘𝐴 : 𝑇𝐴 ) (𝜈𝑘𝐵 : 𝑇𝐵 ) (Initiator ∣ Responder)

The two restrictions do not involve nonces, so they do not increase the effect. ⊢𝒜 Initiator

Rules Applied

eff(Γ)

A-R ES A-O UT A-I N A-S YM D EC A-E ND

− fresh(𝑘), Chal𝑘 (𝐴, 𝐵) − − . . . , Resp𝑘 (𝑥𝑚 )

(𝜈𝑘 : 𝑇𝑘 ) 𝑐⟨{∣[𝐴, 𝐵, 𝑘]𝑘𝐵 ∣}aek(𝑘𝐴 ) ⟩ 𝑐(𝑥𝑒 ) case 𝑥𝑒 of {∣𝑥𝑚 ∣}s𝑘 in end𝑘 (𝐴, 𝐵; 𝑥𝑚 )

In the initiator process, the restriction of the session key is typed by A-R ES, which introduces the effects fresh(𝑘) and Chal𝑘 (𝐴, 𝐵). The output of {∣[𝐴, 𝐵, 𝑘]𝑘𝐵 ∣}aek(𝑘𝐴 ) is typed by A-O UT: in order to apply this rule, we have to prove that [𝐴, 𝐵, 𝑘]𝑘𝐵 is of type 𝐻𝐻 (A-S IGN) and {∣[𝐴, 𝐵, 𝑘]𝑘𝐵 ∣}aek(𝑘𝐴 ) is of type 𝐿𝐻 (A-A SYM E NC) 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-I N , which does not change the effects. The decryption of the ciphertext is typed by A-S YM D EC, 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-E ND. Rules Applied

eff(Γ)

A-I N A-A SYM D EC A-S IG C HECK A-C OND A-R ES A-B EGIN A-O UT

− − − Chal𝑥𝑘 (𝑥𝐴 , 𝑥𝐵 ) . . . , 𝐴 = 𝑥𝐴 − . . . , Resp𝑥𝑘 (𝑚)

⊢𝒜 Responder 𝑐(𝑥𝑒 ). case 𝑥𝑒 of {∣𝑥𝑠 ∣}a𝑘𝐴 in case 𝑥𝑠 of [𝑥𝐴 , 𝑥𝐵 , 𝑥𝑘 ]vk(𝑘𝐵 ) in if 𝐴 = 𝑥𝐴 then (𝜈𝑚 : 𝐻𝐻) begin𝑥𝑘 (𝑥𝐴 , 𝑥𝐵 ; 𝑚) ∣ 𝑐⟨{∣𝑚∣}s𝑥𝑘 ⟩

In the responder process, the input of the challenge and the decryption do not modify the effect. A-S IG C HECK introduces the effect Chal𝑥𝑘 (𝑥𝐴 , 𝑥𝐵 ), as speciﬁed in the type VerK𝐿𝐻 (𝑧) [𝑧𝐴 : 𝐿𝐿, 𝑧𝐵 : 𝐿𝐿, 𝑧𝑘 : 𝑇𝑘 ∣ Chal𝑧𝑘 (𝑧𝐴 , 𝑧𝐵 )] of vk(𝑘𝐵 ). The equality test is typed by A-C OND and the generation of the message to authenticate by A-R ES. Since the typing environment contains the effect Chal𝑥𝑘 (𝑥𝐴 , 𝑥𝐵 ), we can type-check begin𝑥𝑘 (𝑥𝐴 , 𝑥𝐵 ; 𝑚) by A-B EGIN . Rule A-Par allows us to exploit the effect Resp𝑥𝑘 (𝑚) derived from the begin assertion when typing 𝑐⟨{∣𝑚∣}s𝑥𝑘 ⟩. A-O UT is applied by showing that {∣𝑚∣}s𝑥𝑘 is of type 𝐿𝐿 (by A-A SYM E NC and subsumption), which in turn requires that the effect Resp𝑥𝑘 (𝑚) belongs to the current typing environment. ⊔ ⊓

176

R. Focardi and M. Maffei / Types for Security Protocols

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

𝐵

o

{∣𝑛𝐵 ,𝐵∣}aek(𝑘 ) 𝐴

begin𝑛𝐵 (; 𝐴, ek(𝑘𝐵 ), 𝑛𝐴 )

/

{∣𝑛𝐴 ,𝑛𝐵 ,𝐴∣}aek(𝑘 ) 𝐵

end𝑛𝐵 (; 𝐴, ek(𝑘𝐵 ), 𝑛𝐴 ) begin𝑛𝐴 (𝐴, ek(𝑘𝐵 ), 𝑛𝐵 ; )

o

{∣𝑛𝐴 ∣}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 identiﬁer in the correspondence assertions, since 𝐵’s identiﬁer 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 identiﬁed via his own public key. 6.3. Properties of the Type System We extend the strengthening lemma to effects by showing that removing duplicate effects 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 Γ, Γ′ {𝑀/𝑥} ⊢𝒜 𝒥 {𝑀/𝑥}.

R. Focardi and M. Maffei / Types for Security Protocols

177

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 AS YM E NC , A-A SYM E NC and A-S IGN cases by observing that, by syntactic restriction, 𝑥 : 𝑇˜ ∣ 𝐹˜ ] implies ∄𝑁.fresh(𝑁 ) ∈ 𝐹˜ . ⊔ ⊓ Γ ⊢ 𝐾 : 𝜇Kℓ(𝑥) [˜ Finally, we show that type bindings and effects can be swapped as long as the wellformedness 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 deﬁnition of the structural equivalence relation. When the type system is dependent, this rule is problematic 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-R ES 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(𝑃 ). ˜ ), fresh(𝑎), which can only be We have Γ, 𝑎 : 𝑇, Γ′ ⊢𝒜 𝑃 ∣ 𝑄, with Γ′ ⪯ Chal𝑎 (𝑀 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 from 𝑄 all the response effects with occurrences of 𝑎. Since 𝑎 ∈ / fn(𝑃 ) and thus 𝑎 ∈ / fn(𝑃 ), we can apply Lemma 9 (Exchange) to get Γ∣𝐸𝑄 , 𝑃 , 𝑎 : 𝑇, Γ′∣𝐸𝑄 ⊢𝒜 𝑄. By A-R ES, we obtain Γ∣𝐸𝑄 , 𝑃 ⊢𝒜 (𝜈𝑎 : 𝑇 ) 𝑄. By A-PAR, we ﬁnally get Γ ⊢𝒜 𝑃 ∣ (𝜈𝑎 : 𝑇 ) 𝑄. Conversely, Γ ⊢𝒜 𝑃 ∣ (𝜈𝑎 : 𝑇 ) 𝑄 can only be proved by A-PAR, which implies Γ∣𝐸𝑃 , (𝜈𝑎 : 𝑇 ) 𝑄 ⊢𝒜 𝑃 and Γ∣𝐸𝑄 , 𝑃 ⊢𝒜 (𝜈𝑎 : 𝑇 ) 𝑄, with 𝐸𝑃 ∪ 𝐸𝑄 = eff(Γ) and 𝐸𝑃 ∩ 𝐸𝑄 = {𝑓 ∈ eff(Γ) ∣ ∄𝑁.𝑓 = fresh(𝑁 )}.

178

R. Focardi and M. Maffei / Types for Security Protocols

The judgment Γ∣𝐸𝑄 , 𝑃 ⊢𝒜 (𝜈𝑎 : 𝑇 ) 𝑄 can only be proved by A-R ES, which implies ˜ ), fresh(𝑎). Γ∣𝐸𝑄 , 𝑃 , 𝑎 : 𝑇, Γ′ ⊢𝒜 𝑄, with Γ′ ⪯ Chal𝑎 (𝑀 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 ˜ ) and 𝑄 ∖ (𝜈𝑎 : 𝑇 ) 𝑄 to the typing environment used to type-check 𝑃 , thus Chal𝑎 (𝑀 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-R ES, 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: (R ED R ES ) Straightforward, by A-R ES and induction hypothesis. (R ED 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-B EGIN 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 Γ ⊢𝒜 𝑄 ∣ 𝑅. ˜ ⟩.𝑃 ∣ 𝑁 (˜ ˜ /˜ ˜ ⟩.𝑃 ∣ 𝑁 (˜ 𝑥).𝑄 → 𝑃 ∣ 𝑄{𝑀 𝑥} and Γ ⊢𝒜 𝑁 ⟨𝑀 𝑥).𝑄. R ED I/O We have 𝑁 ⟨𝑀 ˜ ⟩.𝑃 = Since this typing judgment can only by proved by A-PAR and 𝑁 ⟨𝑀 ˜ ⟩.𝑃 and Γ∣𝐸 ⊢𝒜 𝑁 (˜ 𝑁 (˜ 𝑥).𝑄 = ∅, we have Γ∣𝐸𝑃 ⊢𝒜 𝑁 ⟨𝑀 𝑥).𝑄. 𝑄 ˜ : 𝑇˜ with Γ∣𝐸 ⊢𝒜 𝑁 : Cℓ [𝑇˜] and Γ∣𝐸 ⊢𝒜 By A-Out, we must have Γ∣𝐸𝑃 ⊢𝒜 𝑀 𝑃 𝑃 𝑃. By A-I N 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 ˜ /˜ 𝑥}. By PAR, (Weakening for ⊢𝒜 ), we get Γ∣𝐸𝑃 , 𝑄 ⊢𝒜 𝑃 and Γ∣𝐸𝑄 , 𝑃 ⊢𝒜 𝑄{𝑀 ˜ /˜ we get Γ ⊢𝒜 𝑃 ∣ 𝑄{𝑀 𝑥}. ˜ ⟩𝐾 + of ⟨˜ ˜ /˜ (R ED D EC /C HECK ) We have case ⟨𝑀 𝑦 ⟩𝐾 − in 𝑃 → 𝑃 {𝑀 𝑦 }. ˜ 𝑦 ⟩𝐾 − in 𝑃 . The three rules for provBy hypothesis, Γ ⊢𝒜 case ⟨𝑀 ⟩𝐾 + of ⟨˜ ing this judgment are A-S YM D EC, A-A SYM D EC and A-S IG C HECK. They all ˜ ⟩𝐾 + : 𝑇 and Γ ⊢𝒜 𝐾 − : 𝜇Kℓ [˜ ˜ ˜ require Γ ⊢𝒜 ⟨𝑀 ˜ : (𝑥) 𝑥 : 𝑇 ∣ 𝐹 ] 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.

R. Focardi and M. Maffei / Types for Security Protocols

179

Symmetric decryption By Proposition 19 (Payload Type for ⊢𝒜 )(1), we have ˜ : 𝑇˜ and 𝐹˜ {𝐾/𝑥, 𝑀 ˜ /˜ 𝑦 } ∈ eff(𝐸). Γ ⊢𝒜 𝑀 ′ ˜ ˜ 𝑥} ⊢𝒜 𝑃 , by Lemma 7 (Substitution for ⊢𝒜 ) we Since Γ, 𝑦˜ : 𝑇 , 𝐹 {𝐾 /𝑥, 𝑦˜/˜ ˜ /˜ ˜ /˜ 𝑦 }. 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 𝑃 guarantees 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 Γ′ ⊢𝒜 𝑄. ˜;𝑁 ˜ ) ∣ 𝑄′ , then Chal𝑁 (𝑀 ˜ ), Resp𝑁 (𝑁 ˜ ) and fresh(𝑁 ) belong If 𝑄 ≡ (𝜈˜ 𝑎 : 𝑇˜) end𝑁 (𝑀 to the typing environment used to type-check the end assertion (cf. rule A-E ND). The presence of the fresh effect implies 𝑁 ∈ ˜ 𝑎. The presence of the response effect implies ˜ ′; 𝑁 ˜ ) ∣ 𝑄′′ for some 𝑀 ˜ ′ , 𝑄′′ . We must have that Chal𝑁 (𝑀 ˜ ′ ) belongs 𝑄′ ≡ begin𝑁 (𝑀 to the typing environment used to type-check the begin assertion. Since the ˜ 𝑎’s are pairwise 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 𝑀 ˜;𝑁 ˜ ) in 𝑄′′ , since each We also know that there are no other occurrences of end𝑁 (𝑀 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 M. Abadi. Secrecy by typing in security protocols. Journal of the ACM, 46(5):749–786, 1999. 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 25–41. 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 25–41. Springer-Verlag, 2001. [4] M. Abadi and B. Blanchet. Secrecy types for asymmetric communication. Theoretical Computer Science, 298(3):387–415, 2003.

[1] [2]

180 [5] [6] [7] [8]

[9] [10]

[11] [12] [13] [14]

[15] [16] [17]

[18]

[19]

[20]

[21]

[22] [23] [24] [25]

[26]

[27]

R. Focardi and M. Maffei / Types for Security Protocols

M. Abadi and B. Blanchet. Analyzing security protocols with secrecy types and logic programs. Journal of the ACM, 52(1):102–146, 2005. M. Abadi and A. D. Gordon. A calculus for cryptographic protocols: The spi calculus. Information and Computation, 148(1):1–70, 1999. A. Askarov, D. Hedin, and A. Sabelfeld. Cryptographically-masked ﬂows. Theoretical Computer Science, 402(2-3):82–101, August 2008. 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 101–116. ACM Press, 2007. M. Backes, C. Hri¸tcu, and M. Maffei. Type-checking zero-knowledge. In 15th ACM Conference on Computer and Communications Security (CCS 2008), pages 357–370. ACM Press, 2008. J. Bengtson, K. Bhargavan, C. Fournet, A. D. Gordon, and S. Maffeis. Reﬁnement types for secure implementations. In Proc. 21th IEEE Symposium on Computer Security Foundations (CSF), pages 17– 32. IEEE Computer Society Press, 2008. B. Blanchet. Automatic veriﬁcation of security protocols: formal model and computational model, 2008. Habilitation thesis. C. Bodei, M. Buchholtz, P. Degano, F. Nielson, and H. R. Nielson. Static validation of security protocols. Journal of Computer Security, 13(3):347–390, 2005. M. Bugliesi, R. Focardi, and M. Maffei. Authenticity by tagging and typing. In Proc. 2nd ACM Workshop on Formal Methods in Security Engineering (FMSE), pages 1–12. ACM Press, 2004. 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 112–125. IEEE Computer Society Press, 2005. M. Bugliesi, R. Focardi, and M. Maffei. Dynamic types for authentication. Journal of Computer Security, 15(6):563–617, 2007. M. Centenaro and R. Focardi. Information ﬂow security of multi-threaded distributed programs. In ACM SIGPLAN PLAS’08, pages 113–124, June 8 2008. 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 (ESORICS’09), LNCS, September 2009. To appear. P. Cousot and R. Cousot. Abstract interpretation: a uniﬁed lattice model for static analysis of programs by construction or approximation of ﬁxpoints. In Proc. 4th Symposium on Principles of Programming Languages (POPL), pages 238–252. ACM Press, 1977. R. Focardi and M. Maffei. Types for security protocols. Technical Report CS-2010-3, University of Venice, 2010. Available at http://www.lbs.cs.uni-saarland.de/resources/ types-security.pdf. 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 141–156. Springer-Verlag, 2005. 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 31–45. IEEE Computer Society Press, 2007. C. Fournet and T. Rezk. Cryptographically sound implementations for typed information-ﬂow security. In POPL’08, pages 323–335. ACM Press, 2008. A. D. Gordon and A. Jeffrey. Authenticity by typing for security protocols. Journal of Computer Security, 11(4):451–519, 2003. A. D. Gordon and A. Jeffrey. Types and effects for asymmetric cryptographic protocols. Journal of Computer Security, 12(3):435–484, 2004. 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 186–201. Springer-Verlag, 2005. 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 202–216. SpringerVerlag, 2005. P. Laud. On the computational soundness of cryptographically masked ﬂows. In POPL’08, pages 337– 348. ACM Press, January 10-12 2008.

R. Focardi and M. Maffei / Types for Security Protocols

181

[28] G. Lowe. “A Hierarchy of Authentication Speciﬁcations”. In Proc. 10th IEEE Computer Security Foundations Workshop (CSFW), pages 31–44. 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 55–63. 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 Speciﬁcation, pages 203–246, 1993. [32] J. Morris. Protection in programming languages. Communications of the ACM, 16(1):15–21, 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):5–19, January 2003. [35] E. Sumii and B. Pierce. A bisimulation for dynamic sealing. Theoretical Computer Science, 375(13):169–192, 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 192–206. IEEE Computer Society, 2007. [38] T. Y. C. Woo and S. S. Lam. A lesson on authentication protocol design. Operation Systems Review, 28(3):24–37, 1994.

182

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. doi:10.3233/978-1-60750-714-7-182

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 concepts of PCL, including a protocol programming language, the semantics of protocol 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 semantics involving honest and unconstrained principals. Other papers on PCL provide 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 protocols 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 analyzes 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 reasoning that does not explicitly mention the actions of a network attacker. Intuitively, “direct reasoning” means that we draw conclusions about the eﬀect of a protocol from the individual 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 eﬀect, 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.

A. Datta et al. / Protocol Composition Logic

183

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 predicates, such as Send(T, msg), Receive(T, msg), NewNonce(T, msg), Dec(T, msgencr , K), Verify(T, msgsigned , 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 message. One class of secrecy properties can be speciﬁed using the predicate Has(T, msg), which intuitively means that msg is built from constituents that T either generated or received 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 annotating 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 protocol programs. PCL also addresses temporal concepts directly, both through modal formulas that refer speciﬁcally 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 protocols that is used in explicit reasoning about actions of a protocol and an attacker, such as with Paulson’s inductive method [34] and Schneider’s rank function method described in Chapter “Security analysis using rank functions in CSP” and [42]. An advantage of PCL is that each proof component identiﬁes 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 certiﬁcates 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 simpliﬁed handshake protocol used in other chapters. We present PCL syntax and its symbolic-execution semantics in a semi-formal way, as if we were encoding PCL in a logical framework. The

184

A. Datta et al. / Protocol Composition Logic

a A → B : A, B, ksk(A) pk(B) B → A : {|s|}sk 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 example, diﬀerent 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 unformalized 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 diﬀerent ways in diﬀerent papers, as part of both a basic research project to ﬁnd eﬀective ways of proving properties of protocols, and as part of an ongoing eﬀort to carry out case studies on practical protocols, each of which may require diﬀerent cryptographic functions or make diﬀerent infrastructure assumptions. Therefore, this chapter is intended to explain PCL, show how its syntax and semantics may be deﬁned, 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 msgK for the digital signature of msg with the signing key K. For protocols that assume a public-key infrastructure, we write pk (Alice) for Alice’s public encryption key, dk (Alice) for the corresponding private key known only to Alice, sk (Alice) for Alice’s private signing key, and vk (Alice) for the corresponding publicly known signature veriﬁcation key. When needed, m1 , . . . , mn 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 deﬁnition, 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 diﬀerent roles. Because each of the opera-

A. Datta et al. / Protocol Composition Logic

185

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 clariﬁed 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 simpliﬁes 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 speciﬁc 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 simpliﬁes reasoning about a protocol role. For each pair of principals A and B, the program executed by initiator A to communicate 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 principal names A and B, and send the encryption of this message. Because digital signatures do not provide conﬁdentiality, 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 veriﬁcation 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. Speciﬁcally, the responder thread receives 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 initiator’s message, 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 proceed further. If possible, the responder thread then retrieves the ﬁrst, second, and third components of the triple that is the message plaintext, and veriﬁes the digital signature using the principal name A sent in the message. If the signature veriﬁes, and the second component of the plaintext tuple matches the responder’s principal name, then the responder generates a new nonce s, encrypts it under k, and sends the result. An assert

186

A. Datta et al. / Protocol Composition Logic

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 deﬁned, the ﬁrst argument is treated as the principal who executes the role. The diﬀerence 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 deﬁnition 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 abbreviations and notational conventions that make the roles easier to read. For example, Figure 3 uses a few syntactical simpliﬁcations to deﬁne the same roles as Figure 2. Speciﬁcally, we use a pattern-matching form idA, idB, k := texta to set three locations to the three components of a tuple, as abbreviation for the three assignments using 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 identiﬁers are typed, and the type of locations is diﬀerent 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 confusing aspect of match is that its eﬀect depends on the context: because A and B are previously deﬁned, this example match is an assert about them, while because k is not previously deﬁned, 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 assertion 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.

A. Datta et al. / Protocol Composition Logic

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; }

187

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

AuthResp

⎛ ⎞ Honest(idA[T] ) ∧ idA[T] B ⎜⎜⎜ ⎛ ⎟⎟⎟ ⎞ ⎜⎜⎜ ⎜ ⎟⎟ [T] ∃T : T .pname = idA ⎟ ⎟ ⎜ ⎟⎟⎟⎟⎟⎟⎟ : true[Resp(B)]T ⎜⎜⎜⎜ ⎜⎜⎜ [T] [T] ⎜⎜⎝⇒ ⎜⎜⎜∧Send(T , enca ) Receive(T, enca )⎟⎟⎟⎟⎟⎟⎠ ⎠ ⎝ ∧Receive(T, enca[T] ) Send(T, encb[T] ) Figure 4. Property AuthResp

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 speciﬁcally, we deﬁne 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 eﬀect 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 other’s 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 AuthResp is shown in Figure 4. Note that the last line on the right of AuthResp 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 AuthInit can be deﬁned easily.) Intuitively, AuthResp 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 diﬀerent principal from B.

188

A. Datta et al. / Protocol Composition Logic

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 consider diﬀerent types of keys as subtypes of the type key of keys, for example, and similarly 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 deﬁned by a set of roles and setup assumptions. In Table 2, we deﬁne 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 deﬁned 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 deﬁned 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 conditions 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 keypair, 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 decryption keys, sgn_key for signing keys, and ver_key for signature veriﬁcation keys. The technical machinery for restricting use of certain setup keys involves an additional type conf_key of conﬁdential keys that cannot be released by honest principals, and conﬁdential subtypes of each of the ﬁve key types. For example, the type conf_asym_dec_key of conﬁdential asymmetric decryption keys is a subtype of both asym_dec_key and conf_key. Similarly, the type conf_sgn_key of conﬁdential signing keys is a subtype of both sgn_key and conf_key. More generally, any conﬁdential key type conf_xyz_key is a subtype of both the corresponding unrestricted key type xyz_key and conf_key.

A. Datta et al. / Protocol Composition Logic

189

The speciﬁc 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 speciﬁcations 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 from sending 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 reveal 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 conﬁdentiality 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 protocols that may require shared symmetric keys. For example, one form of key setup assumptions 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 possible in principle, the present formulation using a set of key functions (and key constants) and a set of sharing assumptions is suﬃcient 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 speciﬁc logical systems, we discuss a speciﬁc framework brieﬂy because it allows us to deﬁne 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 pairing, functions (to represent variable binding, as in quantiﬁed 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 allowing expressions of one type to be used as expressions of another without syntactic conversion functions. The logical framework we use, which might be called an order-sorted logical framework, has the following grammar:

190

A. Datta et al. / Protocol Composition Logic

type ::= basic_type | type × . . . × type | type → type | List(type) | Setﬁn (type) term ::= f ct_symb : type | variable : type | term1 . . . termn | πi term | λ variable : typev . term | term term1 . . . termn (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 expressions, function application, or additional forms for deﬁning 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 speciﬁc type, if f : type1 → type2 and x : type1 , then f x : type2 . A lambda expression λvar:typev . exp deﬁnes the function that, given argument var, has value exp. If var has type typev and term has type typet , then (λvar : typev . term) has type typev → typet . We will not use lambda expressions in PCL, except that lambda is used as a binding operator to express parameterization (of protocol roles) and quantiﬁcation (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 type1 type2 to indicate that type1 is a subtype of type2 . In this case, an expression of type type1 can be used as an expression of type type2 . A particular detail that we adopt from order-sorted algebra [19] for convenience is the use of “type retracts”. If type1 type2 , then an expression of the supertype type2 can sometimes be used as an expression of the subtype type1 , 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 diﬀerent 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 diﬀerent 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 identiﬁer. Each thread may assign values to local variables that we give type location, so that we may distinguish assignable variables from logical variables (“program constants”) 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 diﬀerent types of assertions about pro-

A. Datta et al. / Protocol Composition Logic

191

Table 1. PCL Types type name

meta-variables

nonce sym_key, conf_sym_key

N1 , N2 , . . . K1 , K2 , . . .

asym_enc_key, conf_asym_enc_key

K1 , K2 , . . .

asym_dec_key, conf_asym_dec_key sgn_key, conf_sgn_key

K1 , K2 , . . . K1 , K2 , . . .

ver_key, conf_ver_key

K1 , K2 , . . .

conf_key

K1 , K2 , . . .

key

K1 , K2 , . . .

principal_name

Pname1 , Pname2 , . . . ; X1 , Y2 , . . . ; A1 , B2 , . . . rname1 , rname2 , . . .

role_name

act1 , act2 , . . . tid1 , tid2 , . . .

action thread_id

oc1 , oc2 , . . . msg1 , msg2 , . . . af1 , af2 , . . . ϕ1 , ϕ2 , . . . ; ψ1 , ψ2 , . . .

location message action_formula nonmodal_formula formula

Φ1 , Φ2 , . . . ; Ψ1 , Ψ2 , . . . fml1 , fml2 , . . .

statement

stm1 , stm2 , . . .

modal_formula

Table 2. PCL Type abbreviations type name : abbreviation

meta-variables

thread : principal_name × role_name × List(principal_name) × thread_id principal : principal_name × List(key)

T1 , T2 , . . . Princ1 , Princ2 , . . .

role : role_name × List(basicseq) protocol : Setﬁn (List(principal_name) → role) event : thread_id × action

actseq1 , actseq2 , . . . basicseq1 , basicseq2 , . . . role1 , role2 , . . . P1 , P2 , . . . ev1 , ev2 , . . .

store : thread_id × location → message

st1 , st2 , . . .

run : Setﬁn (principal) × Setﬁn (thread)

R1 , R 2 , . . .

actionseq : List(action) basicseq : List(action)

× 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 inﬁx 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 deﬁnitions, 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 reﬂexive, transitive, and antisymmetric. PCL uses the following subtype relationships:

192

A. Datta et al. / Protocol Composition Logic

conf_sym_key sym_key conf_asym_enc_key asym_enc_key conf_asym_dec_key asym_dec_key conf_sgn_key sgn_key conf_ver_key ver_key conf_sym_key, conf_asym_enc_key, . . . , conf_ver_key conf_key principal_name, nonce, key, ×ni=1 message action_formula nonmodal_formula, modal_formula

key key key key key conf_key key message nonmodal_formula formula

Here, n may be any non-negative integer. Some clariﬁcation may be useful regarding product types: ×0i=1 message denotes the empty product type for message; its only member is :message; thus the empty tuple is a message. The types deﬁned in this section include types used in writing PCL protocols, types used in writing assertions about them, and types used in deﬁning the symbolic execution semantics of protocols. The type protocol itself is used to characterize the deﬁnition 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 diﬀerently. In the semantics section we deﬁne honesty of principals by requiring honest principals to execute zero or more basic sequences. In eﬀect, 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 externally visible action (such as sending a message) of that sequence. We consider the division of a role into basic sequences part of the deﬁnition 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 deﬁned 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.) Instead 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 generated keys that merit discussion. In principle, there are several ways that cryptographic

A. Datta et al. / Protocol Composition Logic

193

Table 3. Constant symbols in PCL symbol

type

ky1 , ky2 , . . . ; k1 , k2 , . . . Alice, Bob, Charlie, . . . ; A, B, C, . . .

key principal_name

Init, Resp, . . . 1, 2, . . .

role_name thread_id

x, y, siga, encb, texta, idB, k, s, . . . ‘’, ‘a’, ‘ca’, ‘hello’, . . . (all strings)

location message

true, false

nonmodal_formula

Table 4. Function symbols for PCL actions function symbol

type

! encmsg

location → message message × asym_enc_key → message

decmsg semsg semsg sdmsg sdmsg sgnmsg unsgnmsg send receive newnonce enc

message × asym_dec_key → message message × nonce → message message × sym_key → message message × nonce → message message × sym_key → message message × sgn_key → message message → message message → action location → action location → action location × message × asym_enc_key → action

dec se se sd sd sign

location location location location location location

unsign verify assign assert

× message × asym_dec_key → action × message × nonce → action × message × sym_key → action × message × nonce → action × message × sym_key → action × message × sgn_key → action

location × message → action message × ver_key → action location × message → action 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 separate randomness from key generation. We consider nonce generation n := newnonce as a symbolic version of choosing a bitstring uniformly at random from bitstrings of appropriate 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 distribution to a bitstring chosen from a distribution appropriate for the encryption/signature algorithm. For symmetric key operations the KeyGen algorithm generates just one key;

194

A. Datta et al. / Protocol Composition Logic

Table 5. Fully functional syntax vs. PCL syntax for cryptographic functions Fully functional syntax

PCL syntax

Description

encmsg(msg, K)

{|msg|}aK −a msgencr

Asymmetric encryption Symmetric encryption by nonce

sdmsg(msgencr , K)

{|msg|}sN {|msg|}sK −s msgencr N−s msg

sgnmsg(msg, K)

msgK

Signature

unsgnmsg(msgsigned )

msgsigned −

Stripping oﬀ the signature

decmsg(msgencr , K) semsg(msg, N) semsg(msg, K) sdmsg(msgencr , N)

K

encr K

Asymmetric decryption Symmetric encryption by pre-shared key Symmetric decryption by nonce Symmetric decryption by pre-shared key

Table 6. Equations in PCL Equation

Types of variables used in equation

πi v1 , v2 , . . . , vi−1 , vi , vi+1 , . . . , vk = vi

−a {|msg|}a = msg

[k ∈ N+ , i ∈ {1, 2, . . . , k}; v1 : type1 , v2 : type2 , . . . , vk : typek ]

K1

K2

−s {|msg|}sN = msg −N s {|msg|}sK = msg K

msgK − = msg

[K1 : asym_enc_key, K2 : asym_dec_key, msg : message, where (K1 ,K2 ) is an asymmetric encryption-decryption keypair] [N : nonce, msg : message] [K : sym_key, msg : message] [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 generates 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 operations 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 decrypt 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 treatment of dynamically-generated keys, we assume separate encryption/decryption operations that do not incorporate KeyGen. The threads themselves are conﬁgured 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 k→t t→s [38,37] we denoted these keys as kc→k X,Y , kX,Y and k X,Y respectively, between the two principals 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-

A. Datta et al. / Protocol Composition Logic

195

Table 7. Fully functional syntax vs. PCL syntax for actions fully functional syntax

PCL syntax

Description

!(oc) send(msg)

!oc send msg

Contents of assignable location Send message

receive(oc) newnonce(oc)

oc := receive oc := newnonce

Receive message and store in oc Generate nonce and store in oc

enc(oc, msg, K) dec(oc, msgencr , K)

oc := enc msg, K

Asymmetric encrypt and store in oc

se(oc, msg, N)

oc := dec msgencr , K oc := se msg, N

Asymmetric decrypt and store in oc Symmetric encrypt and store in oc

se(oc, msg, K) sd(oc, msgencr , N)

oc := se msg, K

Symmetric encrypt and store in oc

oc := sd msgencr , N

Symmetric decrypt and store in oc

sign(oc, msg, K)

oc := sd msgencr , K oc := sign msg, K

Symmetric decrypt and store in oc Sign message and store in oc

unsign(oc, msgsigned )

oc := unsign msgsigned

Store plaintext of signed message in oc

verify(msgsigned , K)

verify msgsigned , K oc := msg assert: msg1 = msg2

Verify signed message Assign to storable oc Equality check

sd(oc, msgencr , K)

assign(oc, msg) assert(msg1 , msg2 )

ecution and cannot occur in roles because of the typing discipline. Due to typing constraints (speciﬁcally, 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 depends 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 conﬁdentiality. If K has type conf_key, then K cannot occur in any assignment 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 expression occurs in a role assigned to a speciﬁc thread. The Sto(·, ·) function (in Table 8) has a thread parameter and may occur in formulas but not in roles. The key conﬁdentiality condition given above allows a role to encrypt a message with a conﬁdential key and send it, as in the sequence of actions oc := enc msg, K; send !oc. The reason this conforms to the syntactic key conﬁdentiality condition is that enc’s argument signature is location × message × asym_enc_key; i.e., the third argument is required to have a key type. Semantically, this preserves conﬁdentiality of the key because encrypting a message with a key does not produce a message from which the key can be

196

A. Datta et al. / Protocol Composition Logic

recovered. The key conﬁdentiality condition does not allow oc := enc K1 , K2 , in which a conﬁdential key K1 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 conﬁdentiality condition is designed to be a conservative syntactic restriction on roles (to be followed by honest principals) that prevents export of conﬁdential 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 • R.pset := π1 R, R.tset := π2 R, R.elist := π3 R, R.st := π4 R 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 diﬀer in their principal names is a condition on feasibility of runs, to be deﬁned later), and we use (1-based) numbered indices in record notation for list members for legibility’s 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 deﬁnitions 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. Quantiﬁers are regarded as function symbols of speciﬁc 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 formulas 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 representing 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 R = Sprinc , Sth , 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 principals, threads, events, and store form a run that could occur as an execution of a protocol.

A. Datta et al. / Protocol Composition Logic

197

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 thread × message → action_formula

Assign Assert

inﬁx

thread × message × message → action_formula action_formula × action_formula→ nonmodal_formula

Fresh

thread × message → nonmodal_formula

Has

thread × message → nonmodal_formula

FirstSend

thread × message × message → nonmodal_formula

Atomic

= =

inﬁx inﬁx inﬁx

thread → nonmodal_formula

Start Honest

¬ ∧

message → nonmodal_formula message × message → nonmodal_formula message × message → nonmodal_formula thread × thread → nonmodal_formula

Modal

¬ϕ inﬁx ϕ [actseq]T ψ

|=

P : R |= fml

principal_name → nonmodal_formula nonmodal_formula → nonmodal_formula nonmodal_formula × nonmodal_formula→ nonmodal_formula nonmodal_formula × actionseq × thread× nonmodal_formula → modal_formula protocol × run × formula → statement Table 9. Quantiﬁers in PCL

quantiﬁers

type

∀run ∀thread

(run → statement) → statement

∀principal_name

(principal_name → statement) → statement

∀key

(key → statement) → statement

∀message

(message → statement) → statement

∀type

(type → formula) → formula

(thread → statement) → statement

(for all types type)

We therefore deﬁne the set of feasible runs of a protocol to characterize the well-formed runs in our model of protocol execution and attack. After preliminary deﬁnitions in Subsection 4.1, we deﬁne the semantics of protocols in Subsection 4.2. Subsection 4.3 gives an inductive deﬁnition of the semantic relation P : R |= ϕ, stating that the formula ϕ holds on a feasible run R of protocol P.

198

A. Datta et al. / Protocol Composition Logic

4.1. Preliminary deﬁnitions Properties of runs. Recall that each thread T ∈ Sth of a run R = Sprinc , Sth , 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 P, where each role deﬁnes a sequence of actions. The events in the event list eventlist are pairs tid, act of actions by speciﬁc 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 deﬁne 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 R, we deﬁne the set GenMsgR (tid) of messages that thread tid can send out in run R without performing additional explicit actions. Our protocol programming 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 principal 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 GenMsgR (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)} ⊆ GenMsgR (tid) • principal names: Princ ∈ R.pset ⇒ Princ.pname ∈ GenMsgR (tid) • own keys: T.pname = Princ.pname ∧ K ∈ Princ.klist ⇒ K ∈ GenMsgR (tid) • other principals’ keys: For all Princ ∈ R.pset : Setup(T, pk (Princ.pname)) ⇒ pk (Princ.pname) ∈ GenMsgR (tid) Setup(T, dk (Princ.pname)) ⇒ dk (Princ.pname) ∈ GenMsgR (tid) Setup(T, sk (Princ.pname)) ⇒ sk (Princ.pname) ∈ GenMsgR (tid) Setup(T, vk (Princ.pname)) ⇒ vk (Princ.pname) ∈ GenMsgR (tid) • stored messages: R.st(tid, oc) deﬁned ⇒ R.st(tid, oc) ∈ GenMsgR (tid) 2. Inductive cases: • tupling: msg1 ∈ GenMsgR (tid)∧msg2 ∈ GenMsgR (tid)∧. . .∧msgk ∈ GenMsgR (tid) ⇒ msg1 , msg2 , . . . , msgk ∈ GenMsgR (tid) • projection: . . . , msg, . . . ∈ GenMsgR (tid) ⇒ msg ∈ GenMsgR (tid) We deﬁne the so-called Dolev-Yao closure of a set of messages. Although we do not use the Dolev-Yao closure to deﬁne the set of runs, we do use it to characterize the

A. Datta et al. / Protocol Composition Logic

199

semantics of the Has predicate and to establish soundness of the proof system. The capability of the Dolev-Yao attacker are characterized by a deduction system. In the following 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. msg : DY K : DY K : asym_enc_key {|msg|}aK : DY

{|msg|}aK : DY K : DY AKeyPair(K’,K) msg : DY

msg : DY N : DY N : nonce {|msg|}sN : DY

{|msg|}sN : DY N : DY N : nonce msg : DY

msg : DY K : DY K : sym_key {|msg|}sK : DY

{|msg|}sK : DY K : DY K : sym_key msg : DY

msg : DY K : DY K : sgn_key msgK : DY

msgK : DY K : sgn_key msg : DY

msg , . . . , msgn : DY 1 msg1 , . . . , msgn : DY

msg1 , . . . , msgn : DY msgi : DY

The side condition AKeyPair(K , K) above means that (K ,K) is an asymmetric encryptiondecryption 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 deﬁne the set DolevYao(M) of messages that a symbolic Dolev-Yao [14] attacker can generate from M as follows: msg0 ∈ DolevYao(M) iﬀ msg0 : 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 locations to receive messages and perform internal actions such as encryption or decryption. 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 R.st(tid, oc) for run R and thread_id tid. For simplicity, we use the notation R[msg] to refer to the meaning of message msg in run R. 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 R[msg] has a straightforward inductive deﬁnition, with R[Sto(T, oc)] = R.st(tid, oc) as one base case. Since the other base cases and all inductive cases are trivial, the meaning of a message is the result of substituting values for locations. For actions, which ]act, where the substitution of a lambda exmay contain !oc, we write [ λoc.R.st(tid,oc) ! 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.

200

A. Datta et al. / Protocol Composition Logic

Since threads generate new nonces and keys, we need a deﬁnition that allowsus to see which symbols are not new relative to a run R prev = Sprinc , Sth , eventlist, store . Before giving this deﬁnition, we need some other deﬁnitions, concerning the - (congruence-) and the - (subterm-) relations: • Canonical form of messages: The equations in Table 6 form a conﬂuent and terminating 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 msg1 msg2 to express that the messages msg1 and msg2 are equal modulo the equational theory presented in Table 6, or equivalently, msg1 and msg2 have the same canonical form. (We use instead of = to avoid confusion with nonmodal_formulas.) • : We write msg1 msg2 to indicate that the canonical form of msg1 is a subterm of the canonical form of msg2 . Using the -relation, we can now say “key K occurs in R” if: • K ∈ Princ.klist for some Princ occurring in Sprinc , • K occurs in some role obtained by applying the parameterized role named T.rname to its role parameters T.rpars for thread T ∈ Sth , • K msg for some msg in eventlist, • K msg for some tid, oc, msg ∈ R.st The deﬁnition of “nonce N occurs in R” is analogous. Finally, we give a number of auxiliary deﬁnitions that we will need later to state the semantics of the Honest formula and of modal_formulas: • R1 : R2 : . . . : Rn : We say that R1 : R2 : . . . : Rn is a division of run R if: ∗ ∗ ∗ ∗

Ri .pset = R.pset for 1 ≤ i ≤ n, Ri .tset = R.tset for 1 ≤ i ≤ n, Ri .elist is an initial segment of Ri+1 .elist for 1 ≤ i < n, Ri .st contains only the mappings deﬁned by Ri .elist, for 1 ≤ i ≤ n.

The run components are cumulative because this simpliﬁes 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. • diﬀerence: If events1 is an initial segment of events2 , their diﬀerence (events2 \ events1 ) is the sequence of events such that events1 : (events2 \ events1 ) = events2 . • matching: We say that an event ev matches an action act in run R if ev.act [ λloc.R.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 P is deﬁned inductively. Recall that a run R 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 deﬁnition imposes conditions on the initial conﬁguration before protocol execution begins. For example, the principal names and

A. Datta et al. / Protocol Composition Logic

201

thread identiﬁers must be unique and each thread’s role name must be one of the roles of protocol P. The list of events and the store of the run are initially both empty. The inductive case of the deﬁnition describes how one feasible run R prev can be extended to form another feasible run R, by an action performed by one of the threads. Generally, an action may occur only when certain conditions are satisﬁed. An action has the eﬀect of appending the associated event to the list of events in R 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 R is that the message should be generable by the thread following the deﬁnition of GenMsgR (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., R.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 R.pnames for the set of principal names and R.tids for the set of thread ids in R = Sprinc , Sth , . . . , i.e., R.pnames = {pn | ∃Princ ∈ Sprinc : Princ.pname = pn} and R.tids = {tid | ∃T ∈ Sth : T.tid = tid}. Base case. An empty run R = Sprinc , Sth , , { } is feasible for any protocol P, 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 Sprinc diﬀer in their principal_name: ∀ Pnamei , keylisti , Pname j , keylist j ∈ Sprinc : Pnamei = Pname j ⇒ keylisti = keylist j • The keylist for each principal in Sprinc has the keys named in the setup assumptions, each of the type speciﬁed 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 diﬀer in their thread_ids: ∀Ti , T j ∈ Sth: (Ti T j ) ⇒ Ti .tid T j .tid • Every parameterized role of any thread (instantiated with the respective role parameters) is in protocol P: ∀T ∈ Sth : ∃prm_role ∈ P : (prm_role(T.rpars)).rname = T.rname • The set of principal_names in Sprinc is exactly the set of principals of threads in Sth : R.pnames = {Pname | ∃T ∈ Sth : T.pname = Pname}

202

A. Datta et al. / Protocol Composition Logic

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

{}

oc := newnonce

msg ∈ GenMsgR (tid) N : nonce does not occur in R.

oc := enc msg, K

{tid, oc, N} { tid, oc, {|msg|}aK }

oc := dec {|msg|}aK , K

{tid, oc, msg}

oc := se msg, N

{ tid, oc, {|msg|}sN }

oc := se msg, K

{ tid, oc, {|msg|}sK }

oc := sd {|msg|}sN , N

{tid, oc, msg}

oc := sd {|msg|}sK , K

{tid, oc, msg}

oc := sign msg, K

{ tid, oc, msgK }

K : asym_enc_key ∈ GenMsgR (tid) msg ∈ GenMsgR (tid) K : asym_dec_key ∈ GenMsgR (tid) ((K ,K) is an asymmetric encr.-decr. keypair) {|msg|}aK ∈ GenMsgR (tid) N : nonce ∈ GenMsgR (tid) msg ∈ GenMsgR (tid) K : sym_key ∈ GenMsgR (tid) msg ∈ GenMsgR (tid) N : nonce ∈ GenMsgR (tid) {|msg|}sN ∈ GenMsgR (tid) K : sym_key ∈ GenMsgR (tid) {|msg|}sK ∈ GenMsgR (tid) K : sgn_key ∈ GenMsgR (tid) msg ∈ GenMsgR (tid)

oc := unsign msgK

{tid, oc, msg}

msgK ∈ GenMsgR (tid)

verify msgK , K

{}

oc := msg

{tid, oc, msg}

K : ver_key ∈ GenMsgR (tid) ((K ,K) is a sig.-verif. keypair) msgK ∈ GenMsgR (tid) msg ∈ GenMsgR (tid)

assert: msg1 = msg2

{}

msg1 ∈ GenMsgR (tid) ∧ msg2 ∈ GenMsgR (tid) msg1 msg2 .

Inductive case. If R prev = Sprinc , Sth , eventlist, store is a feasible run for protocol P, then R = Sprinc , Sth , eventlist :tid, act, store ∪ newassgns is a feasible run for P, where the symbol : indicates list concatenation, tid ∈ R.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 deﬁned below in Section 4.3). 4.3. Truth of statements In this section, we present an inductive deﬁnition of the semantic relation P : R |= ϕ stating that the formula ϕ holds on a feasible run R of protocol P. Truth of statements involving nonmodal formulas is deﬁned as follows: • P : R |= Send(T, msg): (1) T is a thread of R. (2) T executed a send msg action such that R[msg] msg . • P : R |= Receive(T, msg): (1) T is a thread of R. (2) T executed a oc := receive action such that R[msg] R.st(T.tid, oc).

A. Datta et al. / Protocol Composition Logic

203

• P : R |= NewNonce(T, msg): (1) T is a thread of R. (2) T executed a oc := newnonce action such that R[msg] R.st(T.tid, oc). • P : R |= Enc(T, msg, K): (1) T is a thread of R. (2) T executed a oc := enc msg , K action such that R[msg] msg and R[K] K . • P : R |= Dec(T, msgencr , K): (1) T is a thread of R. (2) T executed a oc := dec msgencr , K action such that R[msgencr ] msgencr and R[K] K . • P : R |= Se(T, msg, N): (1) T is a thread of R. (2) T executed a oc := se msg , N action such that R[msg] msg and R[N] N . • P : R |= Se(T, msg, K): (1) T is a thread of R. (2) T executed a oc := se msg , K action such that R[msg] msg and R[K] K . • P : R |= Sd(T, msgencr , N): (1) T is a thread of R. (2) T executed a oc := sd msgencr , N action such that R[msgencr ] msgencr and R[N] N . • P : R |= Sd(T, msgencr , K): (1) T is a thread of R. (2) T executed a oc := sd msgencr , K action such that R[msgencr ] msgencr and R[K] K and R[K] K . • P : R |= Sign(T, msg, K): (1) T is a thread of R. (2) T executed a oc := sign msg , K action such that R[msg] msg and R[K] K . • P : R |= Unsign(T, msgsigned ): (1) T is a thread of R. (2) T executed a oc := unsign msgsigned action such that R[msgsigned ] msgsigned . • P : R |= Verify(T, msgsigned , K): (1) T is a thread of R. (2) T executed a verify msgsigned , K action such that R[msgsigned ] msgsigned and R[K] K . • P : R |= Assign(T, msg): (1) T is a thread of R. (2) T executed a oc := msg action such that R[msg] msg . • P : R |= Assert(T, msg1 , msg2 ): (1) T is a thread of R. (2) T executed an assert: msg1 = msg2 action such that R[msg1 ] msg1 as well as R[msg2 ] msg2 . • P : R |= af1 af2 : (1) P : R |= af1 and P : R |= af2 are both true. (2) Both af1 and af2 are action_formulas (Send, Receive, NewNonce, . . . ), not necessarily of the same type. (3) There exist (send, receive, newnonce, . . . ) actions, labeled act1 and act2 , in (possibly distinct) threads tid1 and tid2 corresponding to af1 and af2 , respectively (with “correspondence” as naturally deﬁned in accordance with the truth conditions of the respective (Send, Receive, NewNonce, . . . ) action_formulas above), such that tid1 , act1 occurs before tid2 , act2 within R.elist. • P : R |= Fresh(T, msg): (1) T is a thread of R. (2) P : R |= NewNonce(T, msg) is true. (3) ∀msg: (P : R |= Send(T, msg )) ⇒ R[msg] R[msg ]. • P : R |= Has(T, msg): (1) T is a thread of R. (2) R[msg] ∈ DolevYao(GenMsgR (T.tid)), where Princ is the principal executing thread tid. • P : R |= FirstSend(T, msg1 , msg2 ): (1) T is a thread of R. (2) R[msg1 ] R[msg2 ] ∧ (P : R |= Send(T, msg2 )). (3) For all messages msg3 such that R[msg1 ] msg3 and T.tid, send msg3 ∈ R.elist, there must be an earlier event T.tid, send msg2 with R[msg2 ] msg2 . In words, while T need not be the ﬁrst thread to send out a message containing msg1 , the ﬁrst send by T containing msg1 must be a send of msg2 . • P : R |= Atomic(msg): R[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 R[msg] is atomic. • P : R |= msg1 msg2 : R[msg1 ] R[msg2 ]. • P : R |= msg1 = msg2 : R[msg1 ] R[msg2 ]. • P : R |= T1 = T2 : T1 and T2 are identical. • P : R |= Start(T): (1) T is a thread of R. (2) thread T did not execute any actions: act: T.tid, act ∈ R.elist. • P : R |= Honest(Pname): (1) Pname is a principal_name of R: Pname ∈ R.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 [basicseq1 ; basicseq2 ; . . . ; basicseqk ] is an ini-

204

A. Datta et al. / Protocol Composition Logic

tial sequence of role.bseqs and R.elist|T matches (basicseq1 : basicseq2 : . . . : basicseqk ), 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 designated role. In particular, no thread can deviate from or stop in the middle of a basic sequence. (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.) • P : R |= ¬ϕ: P : R |= ϕ is not true. • P : R |= ϕ ∧ ψ: P : R |= ϕ and P : R |= ψ are both true. • P : R |= ∀type v : fml: For all ground instances a of v : type we have P : R |= [ av ]fml, where [ av ]fml is the formula obtained by substituting all occurrences of v in fml by a.

Truth of statements involving modal formulas is deﬁned as follows: • P : R |= ϕ [actseq]T ψ: For all divisions (R1 : R2 : R3 ) of run R, the following holds: If P : R1 |= ϕ is true, and ((R2 .elist)|T \ (R1 .elist)|T ) matches actseq, then P : R2 |= ψ 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 suﬃcient 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 assertions 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 suﬃces to prove that ψ ⇒ ψ . We do not give formal proof rules for deducing implications 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 logically simpler than modal formulas. As a result, PCL reduces formal reasoning about protocols 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 developed 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 R3 does not appear in this deﬁnition.

A. Datta et al. / Protocol Composition Logic

205

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 diﬀerent 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 R[msg] of a message depends on the store of the run, with R[Sto(T, oc)] = R.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 Γ P γ if γ is provable from the formulas in Γ, the basic axioms and inference rules of the proof system and the honesty rule just for protocol P. We write Γ |=P γ if for any feasible run R of protocol P the following holds: If P : R |= Γ, then P : R |= γ. We write Γ |= γ if for any protocol P, we have Γ |=P γ. 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 Γ P γ, then Γ |=P γ. 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 diﬀerent classes of protocols and properties. 5.1. Axiom Schemas The axiom schemas presented below can be divided up into the following categories: AA0–AA4 state properties that hold in a state as a result of executing (or not executing) certain actions; AN1–AN4 capture properties of nonces; KEY states which thread possesses what key, in eﬀect, axiomatizing protocol setup assumptions, while HAS axiomatizes 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) another; P1 and P2 state that the truth of certain predicates is preserved under speciﬁc further actions; and FS1 and FS2 support reasoning about the temporal ordering of actions performed by diﬀerent 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)|}aSto(T,K)

206

A. Datta et al. / Protocol Composition Logic

• true [actseq; oc := dec msg, K; actseq ]T Sto(T, msg) = {|Sto(T, oc)|}aSto(T,K) • true [actseq; oc := se msg, N; actseq ]T Sto(T, oc) = {|Sto(T, msg)|}sSto(T,N) • true [actseq; oc := se msg, K; actseq ]T Sto(T, oc) = {|Sto(T, msg)|}sSto(T,K) • true [actseq; oc := sd msg, N; actseq ]T Sto(T, msg) = {|Sto(T, oc)|}sSto(T,N) • true [actseq; oc := sd msg, K; actseq ]T Sto(T, msg) = {|Sto(T, oc)|}sSto(T,K) • true [actseq; oc := sign msg, K; actseq ]T Sto(T, oc) = Sto(T, msg)Sto(T,K) • true [actseq; oc := unsign msg; actseq ]T Sto(T, oc) = Sto(T, msg)− • true [actseq; verify msgsigned , K; actseq ]T Sto(T, msgsigned ) = Sto(T, msgsigned )− Sto(T,K) • true [actseq; oc := msg; actseq ]T Sto(T, oc) = Sto(T, msg) • true [actseq; assert: msg1 = msg2 ; actseq ]T Sto(T, msg1 ) = Sto(T, msg2 )

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 msgsigned , K; actseq ]T Verify(T, Sto(T, msgsigned ), Sto(T, K)) • true [actseq; oc := msg; actseq ]T Assign(T, Sto(T, msg)) • true [actseq; assert: msg1 = msg2 ; actseq ]T Assert(T, Sto(T, msg1 ), Sto(T, msg2 )) 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 speciﬁes 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 ¬Sd(T, msg, N) •Start(T) [ ]T ¬Send(T, msg) •Start(T) [ ]T ¬Receive(T, msg) •Start(T) [ ]T ¬Sd(T, msg, K) •Start(T) [ ]T ¬NewNonce(T, msg) •Start(T) [ ]T ¬Sign(T, msg, K) •Start(T) [ ]T ¬Enc(T, msg, K) •Start(T) [ ]T ¬Unsign(T, msg) •Start(T) [ ]T ¬Dec(T, msg, K) •Start(T) [ ]T ¬Verify(T, msg, K) •Start(T) [ ]T ¬Se(T, msg, N) •Start(T) [ ]T ¬Assign(T, msg) •Start(T) [ ]T ¬Se(T, msg, K) •Start(T) [ ]T ¬Assert(T, msg1 , msg2 )

A. Datta et al. / Protocol Composition Logic

207

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 symbol “>” 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 satisﬁes 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 msga ; actseq; send msgb ]T Send(T, Sto(T, msga )) Send(T, Sto(T, msgb )) • true [send msga ; actseq; ocb := receive]T Send(T, Sto(T, msga ))Receive(T, Sto(T, ocb )) • true [send msga ; actseq; ocb := newnonce]T Send(T, Sto(T, msga ))NewNonce(T, Sto(T, ocb )) • true [oca := receive; actseq; send msgb ]T Receive(T, Sto(T, oca ))Send(T, Sto(T, msgb )) • true [oca := receive; actseq; ocb := receive]T Receive(T, Sto(T, oca ))Receive(T, Sto(T, ocb )) • true [oca := receive; actseq; ocb := newnonce]T Receive(T, Sto(T, oca ))NewNonce(T, Sto(T, ocb )) • true [oca := newnonce; actseq; send msgb ]T NewNonce(T, Sto(T, oca ))Send(T, Sto(T, msgb )) • true [oca := newnonce; actseq; ocb := receive]T NewNonce(T, Sto(T, oca ))Receive(T, Sto(T, ocb )) • true [oca := newnonce; actseq; ocb := newnonce]T NewNonce(T, Sto(T, oca ))NewNonce(T, Sto(T, ocb )) • similarly for other action_formulas

Proof: The semantics of -nonmodal_formulas is deﬁned by the temporal order between the indicated newnonce, send, or receive (or other) actions. However, the required 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(T1 , msg) ∧ NewNonce(T2 , msg) ⇒ T1 = T2 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 executed 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)

208

A. Datta et al. / Protocol Composition Logic

Axiom schemas KEY. The axiom schemas for possession and secrecy of keys distributed according to the protocol setup assumptions depend on the setup assumptions. For any key function xk, if the setup assumptions include the speciﬁcation ∀(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, msg1 ) ∧ Has(T, msg2 ) ∧ . . . ∧ Has(T, msgk ) ⇒ Has(T, msg1 , msg2 , . . . , msgk ) • ∀k ∈ N : > Has(T, msg1 , msg2 , . . . , msgk ) ⇒ Has(T, msg1 ) ∧ Has(T, msg2 ) ∧ . . . ∧ Has(T, msgk ) • ∀K : asym_enc_key : > Has(T, msg) ∧ Has(T, K) ⇒ Has(T, {|msg|}aK ) • ∀(K, K ) such that (K, K ) is an asymmetric encryption-decryption key pair : > Has(T, {|msg|}aK ) ∧ Has(T, K ) ⇒ Has(T, msg) • ∀N : nonce : > Has(T, msg) ∧ Has(T, N) ⇒ Has(T, {|msg|}sN ) • ∀K : sym_key : > Has(T, msg) ∧ Has(T, K) ⇒ Has(T, {|msg|}sK ) • Has(T, {|msg|}sN ) ∧ Has(T, N) ⇒ Has(T, msg) • Has(T, {|msg|}sK ) ∧ Has(T, K) ⇒ Has(T, msg) • ∀K : sgn_key : > Has(T, msg) ∧ Has(T, K) ⇒ Has(T, msgK ) • Has(T, msgK ) ⇒ Has(T, msg)

Axiom schema SEC. For protocols with conﬁdential 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|}apk(B) , dk (B)) ⇒ T.pname = B Axiom schema VER. For protocols with conﬁdential 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:

A. Datta et al. / Protocol Composition Logic

209

• Honest(A)∧Verify(T, msgsk(A) , vk (A)) ⇒ ∃T : T .pname = A∧Sign(T , msg, sk (A)) Proof: Let R be any run. If R |= Verify(T, msgsk(A) , vk (A)), then by deﬁnition T executed a verify msgsigned , K action such that R[msgsk(A) ] msgsigned and R[vk (A)] K . By the verify-clause in the deﬁnition of feasibility of runs, we know that msgsigned must have been of the form msg1 K1 with msg1 K1 ∈ GenMsgR (T.tid). Because of msg1 K1 = msgsigned R[msgsk(A) ], it follows that msg1 msg and K1 sk (A). Let R1 be the minimum-length run such that R = R1 : R2 and msg1 K1 msgC ∈ GenMsgR1 (T2 .tid) for some thread T2 and containing message msgC . By the way GenMsg is deﬁned, there has to be such a ﬁrst time. By analyzing the set of possible last actions in R1 , it follows that the last action in R1 is some oc2 := sign msg2 , K2 action such that msg1 K1 R.st(T2 .tid, oc2 ) = msg2 K2 (stored messages clause, GenMsg deﬁnition; sign-clause, feasibility of runs). That the ﬁrst time can’t have been immediately after something else (projection, receive, . . . ) can be shown rigorously through an inductive argument; for instance it couldn’t have been a receive action for a message containing msg1 K1 because then there must have been an earlier corresponding send action, contradicting minimality of R1 . The oc2 := sign msg2 , K2 action could only have been executed by thread T2 if at that time it was the case that K2 ∈ GenMsgR (T2 .tid). We also know that msg2 msg and K2 sk (A) (because of msg1 msg and K1 sk (A) (both established above) and msg2 K2 msg1 K1 ). Thus, from the action execution we ﬁrst get R |= Sign(T2 , msg2 , K2 ), which leads us to R |= Sign(T2 , msg, sk (A)) (transitivity of congruence relations and truth conditions of the Sign predicate). From (1) sk (A) K2 ∈ GenMsgR (T2 .tid), (2) Honest(A) (here, ﬁnally honesty comes into play), and (3) sk (A) : conf_sgn_key (from our setup assumptions), it follows that T2 .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 message is contained in another: • msg msg • msg . . . , msg, . . . • msg {|msg|}aK ∧ K {|msg|}aK • msg {|msg|}sN ∧ N {|msg|}sN s s • msg {|msg|}K ∧ K {|msg|}K • msg msgK ∧ K msgK 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 msg1 ∧ msg msg2 ∧ . . . ∧ msg msgn ∧ msg msg1 , msg2 , . . . , msgn ⇒ msg msg1 , msg2 , . . . , msgn • msg msg ∧ msg K ∧ msg {|msg|}aK ⇒ msg {|msg|}aK • msg msg ∧ msg N ∧ msg {|msg|}sN ⇒ msg {|msg|}sN • msg msg ∧ msg K ∧ msg {|msg|}sK ⇒ msg {|msg|}sK • msg msg ∧ msg K ∧ msg msgK ⇒ msg msgK 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 ϕ

210

A. Datta et al. / Protocol Composition Logic

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, msg1 ) [send msg2 ]T (msg1 Sto(T, msg2 ) ⇒ NewNonce(T, msg1 )∧FirstSend(T, msg1 , Sto(T, msg2 ))) Proof: For the action_formula FirstSend to hold, two conditions must be fulﬁlled: (1) msg1 Sto(T, msg2 ). (2) There is an instance of thread T sending out Sto(T, msg2 ) such that this is the ﬁrst instance of any message being sent out such that msg1 is a part of it. Condition (1) holds by the way the axiom schema is stated. Condition (2) holds because before the send action, msg1 was fresh. Axiom schema FS2. If a thread ﬁrst sent a nonce msg1 as part of msg2 and another thread received a msg3 containing msg1 , then the receive action occurred after the send action: • ((NewNonce(T1 , msg1 ) ∧ FirstSend(T1 , msg1 , msg2 )) ∧(T1 T2 ∧ msg1 msg3 ∧ Receive(T2 , msg3 )) ⇒ Send(T1 , msg2 ) Receive(T2 , msg3 ) Proof: T1 is the thread in which msg1 originates and msg2 is the ﬁrst term sent to the adversary that contains msg1 . Therefore no message containing msg1 is in the Dolev-Yao closure of the adversary before the send event Send(T1 , msg2 ). Since T2 is diﬀerent from T1 , msg1 cannot have been originated in it. Therefore, since T2 knows the message msg3 which contains msg1 , it must have received a message msg from the adversary containing msg1 . As observed before, this is only possible after T1 sent out msg2 . Therefore Send(T1 , msg2 ) Receive(T2 , msg3 ) is true in this R. 5.2. Rule Schemas The rule schemas include generic rules G1–G4 for reasoning about program preconditions 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 ψ

ψ ⇒ ψ

A. Datta et al. / Protocol Composition Logic

211

Rule schema G4. True non-modal formulas spawn modal formulas as their postcondition: ψ ϕ [actseq]T ψ

Rule schema SEQ. Stringing together two action sequences if post-condition of the former 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 (R1 : R2 : R3 ) of run R, the following hold: 1. P : R1 |= ϕ1 2. (R2 .elist|T \ R1 .elist|T ) matches actseq : actseq Then, it is possible to ﬁnd a division (R1 : R2 : R2 ) of run R2 such that: 1. (R2 .elist|T \ R1 .elist|T ) matches actseq. 2. (R2 .elist|T \ (R1 : R2 ).elist|T ) matches actseq . Then by the ﬁrst premise we get P : R2 |= ϕ2 , and therefore by the second premise we get P : R2 |= ϕ3 . That is, P : R2 |= ϕ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 invariance 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 Bob’s 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 deﬁnition in our framework, means “follows one or more roles of the protocol”. 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 principal may perform, then the property holds for every honest principal. An example property 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 honesty rule includes a set of formulas constructed from the set of roles of the protocol in a systematic way. One semantic assumption that is eﬀectively built into the honesty rule is that every honest thread that starts a basic sequence complete all of the actions in the basic sequence. 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 speciﬁcation – the protocol designer, or the protocol analyst who takes a protocol description and formulates 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

212

A. Datta et al. / Protocol Composition Logic

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 P are of type List(principal_name) → role. We now state the honesty rule: Start(T) [ ]T ϕ

∀p ∈ 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 quantiﬁers 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 R 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 basicseq1 , basicseq2 , · · · , basicseqk (in the order executed). Then it is possible to ﬁnd a division (R0 : R1 : . . . : Rk ) of run R, such that R0 .elist|T is empty, and for all i ∈ {1, 2, . . . , k}, the list of events (Ri .elist|T \ R(i−1) .elist|T ) matches the action sequence basicseqi . By the ﬁrst premise we have P : R0 |= ϕ. By successively applying all parts of the second premise, we ﬁrst get P : R1 |= ϕ, then P : R2 |= ϕ, and ﬁnally P : Rk |= ϕ. The latter is identical to P : R |= ϕ, quod erat demonstrandum.

6. Analysis of the Handshake Protocol In this section, we present the PCL authentication proof for the handshake protocol introduced 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 complete 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,

A. Datta et al. / Protocol Composition Logic

213

in this chapter, we prove authentication from the responder’s point of view only because of space constraints. The authentication property AuthResp is deﬁned in Figure 4. The actions in the modal formula AuthResp 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 postcondition 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 system to analyze secrecy properties has been developed for an earlier syntax and semantics of PCL [38,39] but is not covered in this chapter. SecrecyInit : true[Init(A, B)]T (Honest(A) ∧ Honest(B) ∧ A B ∧Has(T , k) ⇒ T .pname = A ∨ T .pname = B) (An analogous property SecrecyResp can be deﬁned 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 AuthResp The main idea of the proof is that the responder veriﬁes a signature using the public veriﬁcation 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 veriﬁed 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 veriﬁed message, then the initiator must have done speciﬁc actions in a speciﬁc order that lets us complete the proof. The main steps2 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 principal, 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. Speciﬁcally, we show that B veriﬁed A’s signature siga. We then use the signature veriﬁcation 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

214

A. Datta et al. / Protocol Composition Logic

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 prove3 (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 suﬃciently link the Initiator and Responder. Speciﬁcally, the provable version of (4) asserts that any honest message signer will ﬁrst send the signed message under a speciﬁc encryption key (written pk (Tall .rpars.2)): Honest(Tall .pname) ∧ Sign(Tall , Tall .pname, k[Tall ] , sk (Tall .pname)) [Tall ] ⇒ NewNonce (Tall , k ) a [Tall ] [Tall ] sk(T .pname) ∧FirstSend Tall , k , Tall .pname, k all

pk(Tall .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] )

a ∧FirstSend T , k[T] , idA[T] , k[T] sk(idA[T] ) 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 diﬀerent 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 A’s 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.

215

A. Datta et al. / Protocol Composition Logic

AA0 AA1, (1)

(1) true [Resp(T.pname)]T siga[T] = idA[T] , T.rpars.1, k[T] sk(idA[T] ) [T] [T] [T] true [Resp(T.pname)]T Verify T, idA , T.rpars.1, k sk(idA[T] ) , vk idA (2)

VER, (2)

[T]

true [Resp(T.pname)]T Honest(idA ) ⇒ ∃T : T .pname = idA[T] ∧ Sign T , idA[T] , T.rpars.1, k[T] , sk idA[T] (3)

AA2, AA1, AN3, Honest(Tall .pname) ∧ Sign(Tall , Tall .pname, Tall .rpars.2, k[Tall ] , sk (Tall .pname)) P2.1, FS1, IN, SEQ, AA3, P1, HON

⇒ NewNonce(Tall , k[Tall ] )

a ∧ FirstSend Tall , k[Tall ] , Tall .pname, Tall .rpars.2, k[Tall ] sk(Tall .pname)

pk(Tall .rpars.2)

(4)

(3), (4)

true [Resp(T.pname)]T Honest(idA[T] ) ⇒ ∃T : T .pname = idA[T] ∧ NewNonce(T , k[T] )

a ∧ FirstSend T , k[T] , idA[T] , T.rpars.1, k[T] sk(idA[T] )

pk(T.rpars.1)

AA0, AA1, IN, (1)

a true [Resp(T.pname)]T k[T] idA[T] , T.rpars.1, k[T] sk(idA[T] ) a ∧ Receive T, idA[T] , T.rpars.1, k[T] sk(idA[T] )

pk(T.rpars.1)

(6)

pk(T.rpars.1)

FS2, AA0, (1), (5), (6) AA4, (7)

(5)

true [Resp(T.pname)]T Honest(idA[T] ) ⇒ ∃T : (T .pname = idA[T] ∧ (T T ⇒ Send(T , enca[T] ) Receive(T, enca[T] ))) true [Resp(T.pname)]T Honest(idA ) ∧ idA [T]

[T]

(7)

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 Authresp

7. Protocol Composition Principals may participate in multiple protocols in parallel (e.g. SSL and IPSec), possibly using the same keys. In this section, we deﬁne 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

216

A. Datta et al. / Protocol Composition Logic

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 involves 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 P1 , P2 have compatible setup assumptions if the same setup conditions are given in both protocols for every key function that is common to both. For example, P1 may assume public keys, and P2 may assume shared symmetric keys (of diﬀerent names). Alternately, both may use the same setup assumptions. However, two protocols do not have compatible setup assumptions if one assumes a key is conﬁdential and the other allows the key to be sent by honest principals. Lemma 7.1 If P1 , P2 have compatible setup assumptions, then the PCL assertions provable about Pi are unchanged if the setup assumptions of Pi are replaced by the union of the setup assumptions of P1 and P2 . Deﬁnition (Parallel Composition) If P1 , P2 have compatible setup assumptions, then their parallel composition P1 | P2 is deﬁned 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 deﬁnition above, a principal 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 suﬃcient 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 P1 and P2 . P1 Ψ1 and P2 Ψ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: P1 Γ1 and Γ1 Ψ1 and P2 Γ2 and Γ2 Ψ2

A. Datta et al. / Protocol Composition Logic

217

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 P Γ and Γ γ, then P γ. Since P1 Γ1 and P2 Γ2 were already proved in step 1, in this step it is suﬃcient to show that P1 Γ2 and P2 Γ1 . By Lemma 7.2 below, we therefore have P1 |P2 Γ1 ∪ Γ2 . From this and the formulas from step 3, we can conclude that the security properties of P1 and P2 are preserved under their parallel composition. P1 |P2 Ψ1 and P1 |P2 Ψ2 Lemma 7.2 If P1 Ψ and P2 Ψ, then P1 |P2 Ψ, where the last step in the proof of Ψ in both P1 and P2 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 P1

and P2 using the honesty rule. By the deﬁnition of the honesty rule, for i = 1, 2 we have Pi Start(T) [ ]T ϕ, and for all p ∈ Pi and for all basicseq ∈ (p(T.rpars)).bseqs we have Pi ϕ [basicseq]T ϕ. Every basic sequence basicseq of a role in P1 | P2 is a basic sequence of a role in Pi for i = 1, 2. It follows that P1 |P2 ϕ [basicseq]T ϕ and, therefore, by the application of the honesty rule, P1 |P2 Honest(T.pname) ⇒ ϕ. Theorem 7.3 If P1 Γ and P2 Γ and Γ Ψ, then P1 |P2 Ψ. 8. Related Work A variety 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 diﬀerences 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 logics [4], most approaches involve explicit reasoning about possible attacker actions. Finally, while security properties are interpreted over individual traces in the majority of these methods, in the process calculi-based techniques, security is deﬁned by an equivalence relation between a real protocol and an ideal protocol, which is secure by construction. Inspite of these diﬀerences, 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 designed to be a logic for authentication, with relevant secrecy concepts. Both logics an-

218

A. Datta et al. / Protocol Composition Logic

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 diﬀers 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 speciﬁcally 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, modeltheoretic semantics was deﬁned, the interpretation and use of concepts like “believes” and “jurisdiction” remained unclear. Finally, PCL formulas refer to speciﬁc 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 methods use the same trace-based model of protocol execution and attack; proofs use induction and provable protocol properties hold for an unbounded number of sessions. One diﬀerence is the level of abstraction. Paulson reasons explicitly about traces including possible intruder actions whereas basic reasoning principles are codiﬁed in PCL as axioms and proof rules. Proofs in PCL are signiﬁcantly shorter and do not require any explicit reasoning about an intruder. Finally, while Paulson’s 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 chapter, 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 eﬀects 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 axioms 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 protocols. 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 chapter, 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

A. Datta et al. / Protocol Composition Logic

219

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 preconditions or postconditions, PCL provides an approach for fully formal proofs of security 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 contributing towards the formulation of PCL, and Michael Backes, Changhua He, JeanPierre Seifert, Mukund Sundararajan and Mathieu Turuani for collaborating on case studies that improved the logic. Computational PCL began as joint work with Ante Derek, Vitaly Shmatikov, Mathieu Turuani, and Bogdan Warinschi.

References [1]

[2] [3] [4] [5]

[6]

[7]

[8]

[9] [10]

[11]

[12]

[13] [14]

M. Abadi and A. Gordon. A calculus for cryptographic protocols: the spi calculus. Information and Computation, 148(1):1–70, 1999. Expanded version available as SRC Research Report 149 (January 1998). Martín Abadi and Cédric Fournet. Mobile values, new names, and secure communication. In 28th ACM Symposium on Principles of Programming Languages, pages 104–115, 2001. M. Bellare and P. Rogaway. Entity authentication and key distribution. In Advances in Cryprtology Crypto ’93 Proceedings, pages 232–249. Springer-Verlag, 1994. M. Burrows, M. Abadi, and R. Needham. A logic of authentication. ACM Transactions on Computer Systems, 8(1):18–36, 1990. 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 109–125. IEEE, 2003. Anupam Datta, Ante Derek, John C. Mitchell, and Dusko Pavlovic. Secure protocol composition (extended abstract). In Proceedings of ACM Workshop on Formal Methods in Security Engineering, pages 11–23, 2003. Anupam Datta, Ante Derek, John C. Mitchell, and Dusko Pavlovic. Abstraction and reﬁnement in protocol derivation. In Proceedings of 17th IEEE Computer Security Foundations Workshop, pages 30–45. IEEE, 2004. Anupam Datta, Ante Derek, John C. Mitchell, and Dusko Pavlovic. Secure protocol composition. In Proceedings of 19th Annual Conference on Mathematical Foundations of Programming Semantics. ENTCS, 2004. Anupam Datta, Ante Derek, John C. Mitchell, and Dusko Pavlovic. A derivation system and compositional logic for security protocols. Journal of Computer Security, 13(3):423–482, 2005. 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 311–358. Electronic Notes in Theoretical Computer Science, 2007. 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 Colloquium on Automata, Languages and Programming (ICALP ’05), Lecture Notes in Computer Science, pages 16–29. Springer-Verlag, 2005. Anupam Datta, Ante Derek, John C. Mitchell, and Bogdan Warinschi. Computationally sound compositional logic for key exchange protocols. In Proceedings of 19th IEEE Computer Security Foundations Workshop, pages 321–334. IEEE, 2006. W. Diﬃe, P. C. Van Oorschot, and M. J. Wiener. Authentication and authenticated key exchanges. Designs, Codes and Cryptography, 2:107–125, 1992. D. Dolev and A. Yao. On the security of public-key protocols. IEEE Transactions on Information Theory, 2(29), 1983.

220 [15] [16] [17] [18] [19] [20]

[21] [22] [23]

[24] [25]

[26] [27] [28] [29] [30] [31] [32] [33] [34] [35]

[36] [37]

[38]

[39]

A. Datta et al. / Protocol Composition Logic

N. A. Durgin, P. D. Lincoln, J. C. Mitchell, and A. Scedrov. Undecidability of bounded security protocols. In Workshop on Formal Methods and Security Protocols, 1999. Nancy Durgin, Patrick Lincoln, John Mitchell, and Andre Scedrov. Multiset rewriting and the complexity of bounded security protocols. J. Comput. Secur., 12(2):247–311, 2004. Nancy Durgin, John C. Mitchell, and Dusko Pavlovic. A compositional logic for protocol correctness. In Proceedings of 14th IEEE Computer Security Foundations Workshop, pages 241–255. IEEE, 2001. Nancy Durgin, John C. Mitchell, and Dusko Pavlovic. A compositional logic for proving security properties of protocols. Journal of Computer Security, 11:677–721, 2003. Joseph A. Goguen and José Meseguer. Order-sorted algebra i: Equational deduction for multiple inheritance, overloading, exceptions and partial operations. Theor. Comput. Sci., 105(2):217–273, 1992. Li Gong, Roger Needham, and Raphael Yahalom. Reasoning About Belief in Cryptographic Protocols. In Deborah Cooper and Teresa Lunt, editors, Proceedings 1990 IEEE Symposium on Research in Security and Privacy, pages 234–248. IEEE Computer Society, 1990. David Harel, Dexter Kozen, and Jerzy Tiuryn. Dynamic Logic. Foundations of Computing. MIT Press, 2000. Robert Harper, Furio Honsell, and Gordon D. Plotkin. A framework for deﬁning logics. In LICS, pages 194–204. IEEE Computer Society, 1987. 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 2–15, 2005. C. A. R. Hoare. An axiomatic basis for computer programming. Communications of the ACM, 12(10):576–580, 1969. 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 776–793. Springer-Verlag, 1999. G. Lowe. Some new attacks upon security protocols. In Proceedings of 9th IEEE Computer Security Foundations Workshop, pages 162–169. IEEE, 1996. Z. Manna and A. Pnueli. Temporal Veriﬁcation of Reactive Systems: Safety. Springer-Verlag, 1995. C. Meadows. The NRL protocol analyzer: An overview. Journal of Logic Programming, 26(2):113–131, 1996. C. Meadows. Open issues in formal methods for cryptographic protocol analysis. In Proceedings of DISCEX 2000, pages 237–250. IEEE, 2000. J. C. Mitchell, V. Shmatikov, and U. Stern. Finite-state analysis of ssl 3.0. In Proceedings of the Seventh USENIX Security Symposium, pages 201–216, 1998. J.C. Mitchell, M. Mitchell, and U. Stern. Automated analysis of cryptographic protocols using Murϕ. In Proc. IEEE Symp. Security and Privacy, pages 141–151, 1997. R.M. Needham and M.D. Schroeder. Using encryption for authentication in large networks of computers. Communications of the ACM, 21(12):993–999, 1978. L.C. Paulson. Mechanized proofs for a recursive authentication protocol. In Proceedings of 10th IEEE Computer Security Foundations Workshop, pages 84–95, 1997. L.C. Paulson. Proving properties of security protocols by induction. In Proceedings of 10th IEEE Computer Security Foundations Workshop, pages 70–83, 1997. 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 468–483. Springer-Verlag, 2004. A. W. Roscoe. Modelling and verifying key-exchange protocols using CSP and FDR. In 8th IEEE Computer Security Foundations Workshop, pages 98–107. IEEE Computer Soc Press, 1995. Arnab Roy, Anupam Datta, Ante Derek, and John C. Mitchell. Inductive proofs of computational secrecy. In Joachim Biskup and Javier Lopez, editors, ESORICS, volume 4734 of Lecture Notes in Computer Science, pages 219–234. Springer, 2007. 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. 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,

A. Datta et al. / Protocol Composition Logic

[40] [41] [42] [43] [44] [45]

221

2008. Volume based on presentations at Summer School 2007, Formal Logical Methods for System Security and Correctness, Marktoberdorf, Germany, 2008. Arnab Roy, Anupam Datta, and John C. Mitchell. Formal proofs of cryptographic security of DiﬃeHellman-based protocols. In Trustworthy Global Computing (TGC), pages 312–329. Springer, 2007. S. Schneider. Security properties and CSP. In IEEE Symp. Security and Privacy, 1996. Steve Schneider. Verifying authentication protocols with csp. IEEE Transactions on Software Engineering, pages 741–58, 1998. D. Song. Athena: a new eﬃcient automatic checker for security protocol analysis. In Proceedings of 12th IEEE Computer Security Foundations Workshop, pages 192–202. IEEE, 1999. P. Syverson and P.C. van Oorschot. On unifying some cryptographic protocol logics. In Proceedings of 7th IEEE Computer Security Foundations Workshop, pages 14–29, 1994. 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.

222

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. doi:10.3233/978-1-60750-714-7-222

Shapes: Surveying Crypto Protocol Runs1 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 conﬁdentiality 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 formalized in the strand space authentication tests.

1. Initial Examples We develop here a search technique for ﬁnding the minimal, essentially different executions possible in a protocol, starting from some initial behavioral assumptions. This search gives counterexamples to false authentication and conﬁdentiality assertions. Alternatively, 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 Blanchet’s Simple Example Protocol [2] (see Fig. 1), and then proceed to formalize and justify them. Blanchet’s 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.

223

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

{∣{∣𝑘∣}sk(𝐴) ∣}pk(𝐵) O ∙

{∣𝑠∣}𝑘 +3 ∙ Figure 1.

SEP :

{∣{∣𝑘∣}sk(𝐴) ∣}pk(𝐵) ∙

{∣𝑠∣}𝑘 O +3 ∙

Blanchet’s 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 deﬁning 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 activity 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

224

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

{∣{∣𝑘∣}sk(𝐴) ∣}pk(𝐵) o non = {pk(𝐵)

∙ o

∙ −1

}

𝑘

unique = {𝑘}

Figure 2. Skeleton 𝔸0 : Disclosure of 𝑘?

transformed forms. An adversary’s 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. −1 2. When 𝐵’s private decryption key pk(𝐵) is compromised: An adversary can then extract the signed unit from {∣{∣𝑘∣}sk(𝐴) ∣}pk(𝐵) , check the signature, and extract 𝑘. It is irrelevant whether 𝐵 does this (“𝐵 is dishonest”) or whether 𝐵’s secret −1 pk(𝐵) 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 always 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 𝑘, somehow 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 −1 nor case 2 above applies, i.e. 𝑘 is uniquely originating and pk(𝐵) is non-originating, −1 which we express as unique = {𝑘} and non = {pk(𝐵) }. 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 deﬁned 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 −1 ∈ non excludes this. If the adversary could be lucky enough to re-originate pk(𝐵) the same 𝑘, then this re-origination would be an earliest transmission unprotected by

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

225

{∣{∣𝑘∣}sk(𝐴) ∣}pk(𝐵) . The assumption unique = {𝑘} excludes this. Thus, any earliest transmission 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 retransmitted; 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 message 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 several times. After a nonce has been transmitted inside the encryption {∣𝑡1 ∣}𝐾1 and received 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?

226

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

∙

/ 𝑡0

∙ o

{∣𝑠∣}𝑘

non = {pk(𝐵)

−1

}

unique = {𝑘}

Figure 3. Skeleton 𝔹; 𝑡0 is {∣{∣𝑘∣}sk(𝐴) ∣}pk(𝐵)

𝑡0

∙ ∙ o

/

{∣𝑠∣}𝑘

≺

𝑘

≻

∙←

or

𝔹1 non = {pk(𝐵)

𝔹2 −1

}

∙ ∙ o

𝑡0

/

{∣𝑠∣}𝑘

≺ ≻

{∣{∣𝑘∣}sk(𝐶) ∣}pk(𝐷) {∣𝑠∣}𝑘

o

/ ∙ ∙

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 disclosure 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 , and—since 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

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

∙ ∙ o

𝑡0

/

𝑡0

≺

{∣𝑠∣}𝑘

≻ −1

non = {pk(𝐵)

}

{∣𝑠∣}𝑘

o

227

/ ∙ ∙

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 fulﬁlls its goals, from the point of view of an initiator 𝐴. In the step from ℂ to ℂ21 , we used an additional principle:

228

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

𝑡0 O ∙

⋅→

𝑠 ∙

{∣𝑠∣}𝑘 +3 ∙

−1

non = {pk(𝐵)

∙ ∙ o }

𝑡0

/

𝑡0

≺

{∣𝑠∣}𝑘

≻

{∣𝑠∣}𝑘

o

/ ∙ ∙

𝑠 ∙

unique = {𝑘, 𝑠}

Figure 6. Skeletons ℂ and ℂ21

∙ ∙ o

𝑡0

/

{∣𝑠∣}𝑘

𝑡0

≺ ≻

{∣𝑠∣}𝑘

o

−1

non = {pk(𝐵)

}

/ ∙ ∙

∙

∙

𝑠 ≻

𝑘

unique = {𝑘, 𝑠}

Figure 7. Dead skeleton ℂ211

𝑡0

/ ∙

⋅→

∙

{∣{∣𝑘∣}sk(𝐴) ∣}pk(𝐶)

/

≺

𝑡0

/ ∙

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 message 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 nonoriginating, 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.

229

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

{∣{∣𝑘ˆ𝐵∣}sk(𝐴) ∣}pk(𝐵) O ∙ Figure 9.

{∣{∣𝑘 ˆ𝐵∣}sk(𝐴) ∣}pk(𝐵)

/ ∙

{∣{∣𝑘ˆ𝐵∣}sk(𝐴) ∣}pk(𝐵)

{∣𝑠∣}𝑘 +3 ∙ SEPC :

⋅→

∙

{∣𝑠∣}𝑘 O +3 ∙

the Simple Example Protocol Corrected

∙

{∣{∣𝑘 ˆ𝐵∣}sk(𝐴) ∣}pk(𝐵)

/

≺

{∣{∣𝑘 ˆ𝐵∣}sk(𝐴) ∣}pk(𝐵)

/ ∙

sk(𝐴), pk(𝐵)−1 ∈ non Figure 10. Skeleton 𝔼: 𝐵’s Point of View, and its shape 𝔼1

We may more proﬁtably 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 initiator’s name is 𝐴, and the parameter representing the session key has the value 𝑘. However, we know nothing about the remaining parameter appearing in an initiator’s ﬁ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 𝐶, unlike 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 decrypt 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 conﬁdential. 1.3. Correcting SEP Principles 1.1 and 1.3 are central to protocol design [9] as well as to protocol analysis [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 sufﬁces to add 𝐵’s name to this critical 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.

230

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

Our correction of SEP is tighter or more minimal than Blanchet’s [2], where the signed unit {∣𝑘ˆ𝐴ˆ𝐵∣}sk(𝐴) is used. The occurrence of 𝐴 is unnecessary here. Principle 1.3 helped identify exactly the parameters need to appear in the critical term to achieve the protocol reﬁnement. 1.4. Goals of this Chapter Blanchet’s Simple Example Protocol has illustrated the idea that, from a particular starting 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 behavior of the regular (uncompromised) participants, which—when combined with some activity of the adversary—yields 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 transmissions that help to explain the messages that have been received (Case 2 of Principles 1.1 and 1.3). And we can add information by identifying different parameters, as we identiﬁed 𝐶 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 theory—speciﬁed, 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 reﬁnement leading to shapes: 1. The search steps are sound (Thm. 6.7), so that—when we take a step—every possible execution compatible with the assumptions before the step is still compatible 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 enumerate an inﬁnite set of shapes. If one of these is a counterexample to a goal, then we certainly learn the goal is false. However, if a goal is in fact true, but 𝔸 has inﬁnitely 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. Athena’s representation included adversary behavior as well as regular strands. Athena used a more straightforward backward search, in which the tool seeks all possible transmission points—whether adversary actions or regular strands—for each component of a reception node that cannot yet be explained.

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

231

Athena later incorporated an early version of the authentication test method (Principles 1.1 and 1.3) to prune its search [15]. Cremers’s Scyther [5,4] reﬁned Athena’s 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 homomorphisms—as we will call them—between them, and about executions. 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 modiﬁed form of the Trusted Computing Group’s protocol for constructing certiﬁcates for Attestation Identity Keys [1]. This suggests 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 characterize when a skeleton is an execution (Thm. 5.5). Section 6 deﬁnes 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.1–2.3. Sections 2.4 and 2.5 deﬁne 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. Deﬁnition 2.1 Let X be an inﬁnite 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 MX [B] of messages is freely generated from X, B by two operations: Tagged Tupling If tag ∈ TAG and 𝑡1 , . . . , 𝑡𝑘 ∈ MX [B], for 𝑘 ≥ 0, then the tagged 𝑘-tuple tag 𝑡1 ˆ . . . ˆ𝑡𝑘 is in MX [B].

232

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

Encryption If 𝑡1 , 𝑡2 ∈ MX [B], then their encryption {∣𝑡1 ∣}𝑡2 ∈ MX [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 MX [B] as an algebra, because we are interested in its homomorphisms. We focus on its homomorphisms MX [B] → MX [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]. Deﬁnition 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 deﬁned for all 𝑡 ∈ M by the conditions: 𝛼(𝑎) = 𝜂(𝑎), 𝛼(𝑥) = 𝜒(𝑥),

if 𝑎 ∈ B if 𝑥 ∈ X

𝛼({∣𝑡0 ∣}𝑡1 ) = {∣𝛼(𝑡0 )∣}𝛼(𝑡1 ) 𝛼(tag 𝑡1 ˆ . . . ˆ𝑡𝑛 ) = tag 𝛼(𝑡1 )ˆ . . . ˆ𝛼(𝑡𝑛 )

Indeterminates 𝑥 are untyped “blank slots,” replaceable by any message. Tags remain constant under homomorphisms. Messages are abstract syntax trees: Deﬁnition 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 undeﬁned. 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 deﬁned, 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(𝐵) .

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

233

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 sufﬁces 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 functions 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 respectively. invk with domain signature keys ∪ public keys, yielding values called veriﬁcation keys and private decryption keys resp. We deﬁne the inverse function 𝑎−1 so that sk(nm(𝑗))−1 =invk(sk(nm(𝑗))) pk(nm(𝑗))−1 =invk(pk(nm(𝑗)))

invk(sk(nm(𝑗)))−1 =sk(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 homomorphisms can send them to any value in MX [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 𝑡 ∈ M—written params(𝑡)—are all of its subexpressions 𝑠 ∈ PARAMS. Lemma 2.4 1. Each message 𝑡 has ﬁnitely many parameters params(𝑡); and 2. Letting 𝛼, 𝛽 : MX [B] → MX [B], if (i) params(𝑡) ⊆ X ∪ B, and (ii) for all 𝑣 ∈ params(𝑡), 𝛼(𝑣) = 𝛽(𝑣), then 𝛼(𝑡) = 𝛽(𝑡). 2.3. Properties of Homomorphisms Deﬁnition 2.5 Consider homomorphisms 𝛼, 𝛽, 𝜄 between subalgebras of MX [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 𝛼 uniﬁes 𝑣, 𝑤.

234

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

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 deﬁnition, 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 speciﬁc as 𝛼, and write 𝛼 ≤𝑠 𝛾. In clause 4, 𝜅 may be deﬁned only on a subalgebra such as the range of 𝜄, and likewise 𝜄 in clause 5 may be deﬁned only on the range of 𝛼. A preorder means a reﬂexive, 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 deﬁned on MX𝑖 [B𝑖 ]. First, 𝛼 is injective: if 𝛼(𝑡) = 𝛼(𝑡′ ), then since 𝑡 = 𝛽(𝛼(𝑡)) = 𝛽(𝛼(𝑡′ )) = 𝑡′ , 𝑡 = 𝑡′ . Moreover, letting X𝑗 = 𝛼(X𝑖 ) and B𝑗 be generated from 𝛼(PARAMS(B𝑖 )), we have 𝛼 surjective onto MX𝑗 [B𝑗 ]. Thus, 𝛼 is an isomorphism 𝛼 : MX𝑖 [B𝑖 ] → MX𝑗 [B𝑗 ], and has an inverse 𝜅 : MX𝑗 [B𝑗 ] → MX𝑖 [B𝑖 ]. 2. Differing by a renaming is reﬂexive 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. Deﬁne ascore(𝛼, 𝑎), for 𝑎 ∈ PARAMS, to be ∣{𝑏 ∈ PARAMS : 𝛼(𝑏) = 𝑎}∣ − 1. Deﬁne xscore(𝛼, 𝑥), for 𝑥 ∈ X, to be number of encryptions and concatenations in 𝛼(𝑥) plus the number of multiple occurrences of basic values and indeterminates in 𝛼(𝑥). Deﬁne 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(𝛼, 𝑥, 𝑦).

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

235

Then score is non-negative, and well deﬁned when 𝛼 is ﬁnitely generated. Moreover, when 𝛼 ≤𝑠 𝛾, and 𝛾 is ﬁnitely generated, score(𝛼) ≤ score(𝛾). If score(𝛼) = score(𝛾), then 𝛼, 𝛾 differ by a renaming. Hence, . . . ≤𝑠 𝛼𝑖 ≤𝑠 . . . ≤𝑠 𝛼1 ≤𝑠 𝛼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 𝛾 uniﬁes messages 𝑣, 𝑤 if 𝛾(𝑣) = 𝛾(𝑤), and 𝛾 is a most general uniﬁer for 𝑣, 𝑤 if in addition, whenever 𝛾 ′ uniﬁes 𝑣, 𝑤, then 𝛾 ≤𝑠 𝛾 ′ . Lemma 2.8 1. Assume 𝑣, 𝑤 ∈ M have a common instance. There exists a ﬁnitely generated 𝛾 which is a most general uniﬁer of 𝑣 and 𝑤. 2. Let 𝑣 = 𝛼(𝑢) and 𝑤 = 𝛽(𝑢). Then 𝛼, 𝛽 have a most speciﬁc common generalization 𝛾 for 𝑢. That is, there is a ﬁnitely generated 𝛾 such that: (a) For some 𝛼1 , 𝑣 = (𝛼1 ∘ 𝛾)(𝑢), (b) For some 𝛽1 , 𝑤 = (𝛽1 ∘ 𝛾)(𝑢), and (c) if 𝛾 ′ satisﬁes Clauses 2a–2b, then 𝛾 ′ ≤𝑠 𝛾. Lemmas 2.4, 2.6–2.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 MX [B] satisﬁes 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 uniﬁers cover the common instances of any two messages, and where a ﬁnite set of homomorphisms replace the most speciﬁc common generalization of Clause 2. Sometimes the adversary has useful additional operations on basic values, and some additional authentication test patterns must be deﬁned on the basic values. By contrast, in algebras with exclusive-or (e.g.), which may be applied to tuples or encryptions 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 reﬂexive 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 execution—uniquely originating values—formalize 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 𝐾, 𝐾 ∕⊑

236

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

𝑡 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 retransmitted 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 messages to nodes and strands cumulatively. Suppose that 𝑠 is a strand of length ℓ, and 𝑖 ≤ ℓ; then params(𝑠) = params(𝑠 ↓ ℓ) where params(𝑠 ↓ 𝑖) =

∪

params(msg(𝑠 ↓ 𝑗)).

0<𝑗≤𝑖

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 A protocol Π 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, 6–7. 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 certiﬁcate authority role always uses a non-originating signing key. In modeling SEP, role origination constraints were not needed; we assumed only that particular values in a skeleton were non-originating or uniquely originating. There was no

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

237

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 syntactically unconstrained messages received from protocol peers, or passed down as parameters 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 constraintsolving approaches—originating with [13]—that variables in constraint sequences always 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 indeterminate, 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 respectively non-originating in 𝔸. More formally: Deﬁnition 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(𝑛).

238

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

All of the “skeletons” in Figs. 2–10 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 formalize these operations in Section 3.4. 3.1. Realized Skeletons A skeleton is realized if its strands can really happen, without any other regular behavior. 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 generated by that time. The adversary behavior must not violate the skeleton’s 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 transmit 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: Deﬁnition 3.2 An adversary strand has any of the following forms: M𝑎 : ⟨+𝑎⟩ where 𝑎 is a basic value C: ⟨−𝑔 ⇒ ⋅ ⋅ ⋅ ⇒ −ℎ ⇒ +tag 𝑔ˆ . . . ˆℎ⟩ E: ⟨−𝐾 ⇒ −ℎ ⇒ +{∣ℎ∣}𝐾 ⟩

M𝑔 : ⟨+𝑔⟩ where 𝑔 is an indeterminate S: ⟨−tag 𝑔ˆ . . . ˆℎ ⇒ +𝑔 ⇒ ⋅ ⋅ ⋅ ⇒ +ℎ⟩ 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 justiﬁes 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. Deﬁnition 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(𝑛) = 𝑡.

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

239

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 𝔸. Deﬁnition 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 transmission 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 adversary 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. However, 𝔻1 requires an adversary web that decrypts {∣{∣𝑘∣}sk(𝐴) ∣}pk(𝐶) using the decryption −1 key pk(𝐶) , 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 satisﬁed 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 adversary strands never precede destructive ones [14,3,12]. When the keys may include compound messages, there is a weaker normal form: Every path within the web either traverses a key being used for encryption or decryption on an adversary strand, or else traverses destructive strands before any constructive strands. In such a web, every message is a member of the ﬁnite set: {𝑡 : 𝑡 ≪ msg(𝑚) ∨ ∃𝑛 ∈ 𝑃 . 𝑡 ≪ msg(𝑛)}.

240

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

3.2. Homomorphisms Our intuitive notion of enrichment will be formalized by homomorphisms among skeletons or preskeletons. A preskeleton homomorphism has two components. One is a homomorphism 𝛼 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 𝜙(𝑛). Deﬁnition 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: originates at 𝑛 ∈ nodes𝔸 , then 𝛼(𝑎) originates at 𝜙(𝑛).

If 𝑎 ∈ unique𝔸 and 𝑎

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. 3–4 illustrate a pair of homomorphisms 𝔹 ⋅→ 𝔹1 and 𝔹 ⋅→ 𝔹2 . In each of these homomorphisms, 𝔹 is included into a larger

241

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

∙

{∣{∣𝑘∣}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 artiﬁcial but simple example. A message homomorphism mapping 𝐴, 𝐷 to the same value permits the two transmission nodes of 𝔸1 to be identiﬁed 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 isomorphism 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 describes a non-empty set that does not include itself. Deﬁnition 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 inﬁnite set of executions. Since 𝔸 is nondead, 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,

242

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

we can again rename 2𝔹 to (2𝔹)′ , taking a union to obtain 4𝔹 = 2𝔹 ∪ (2𝔹)′ . We can repeat this process ad inﬁnitum. 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 𝐾. 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 inﬁnite 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 informative. 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 immediately 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: CPSA’s

Deﬁnition 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 𝐽}. CPSA’s 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.

243

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

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 Lagrange’s 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 𝐾𝑗 ≤n . . . 𝐾0 be an inﬁnite descending chain of homomorphisms in the ≤n ordering, as in the following diagram, where each 𝐻𝑖 is node-injective: U :𝔸 _ PPUPUPUPUUUU zz PPP UUUU 𝐾0 z PPP UUUU z 𝐾𝑗 z PPP UUUU z ⋅⋅⋅ }zz UUUU PPP 𝐾1 ⋅⋅⋅ UU* ( / ... / 𝔹𝑗+1 / 𝔹𝑗 / 𝔹1 / 𝔹0 𝐾𝑗+1

... 𝐻𝑗+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 renamings. 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 𝑆𝐻 satisﬁes (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 ) deﬁned 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 sufﬁces to show that if any of them is inﬁnite, then it contains isomorphic members. Let’s 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 homomorphism 𝛽 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 inﬁnite, there is a single 𝔻 with inﬁnitely 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 𝐽.

244

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

6. Non-emptiness of min(𝒞) follows from well-foundedness. Observe that if 𝐻 ∈ 𝒞 ∖ min(𝒞), then there is some 𝐽 ∈ min(𝒞) such that 𝐽 ≤n 𝐻. Since 𝒞 is a characterization, 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 deﬁnition 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 welldeﬁned to within isomorphism. Deﬁnition 3.12 The shapes for a skeleton 𝔸, written shapes(𝔸), are the members of the nodewise minimum characterization for 𝔸. The shapes(𝔸) form a well-deﬁned set of homomorphisms (to within isomorphism), since we may apply Lemma 3.11, Clauses 6–7 to the characterization 𝒞 containing all homomorphisms from 𝔸 to realized skeletons. 𝔸 is dead iff shapes(𝔸) = ∅. We may now justify Principle 1.4 directly from the deﬁnitions. 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 from 𝔸 which identify 𝑛0 and 𝑛1 .

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

245

Proof: 1. Deﬁne 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 𝔹 satisﬁes 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. Deﬁne 𝔹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 uniﬁable 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 𝑎, 𝑛0 ∕⪯𝔸 𝑛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. ⊔ ⊓ Deﬁnition 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.

246

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

𝑥ˆekc

o

aicˆkeyrec

/ TPM ∙ ∙ o

𝐼 ˆ𝐾 ˆ𝑥ˆekc

𝐼 ˆ𝐾 ˆ𝑥ˆekc

/

{∣aic∣}EK

∙

o

{∣aic∣}EK

/ PCA ∙

STORE aicˆkeyrec

/ ∙

aic = {∣aic 𝐼 ˆ𝐾 ˆ𝑥∣}sk(PCA) ekc = {∣ekc MFˆEK∣}sk(MF) keyrec = {∣aikrec 𝐾, 𝐾 −1 ∣}SRK Figure 12. Modiﬁed Anonymous Identity Protocol MAIP

is not strong enough as formulated. It does not cover all the transformations that protocols 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 Group’s 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 certiﬁcate for an AIK veriﬁcation 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 certiﬁcate authority that prepares certiﬁcates on AIKs will prepare a certiﬁcate 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 certiﬁcate aic using a public encryption key EK. That key is accompanied by a certiﬁcate from the TPM’s manufacturer saying that the matching decryption key EK−1 is itself a long-term TPMresident value. A TPM liberates the AIK certiﬁcate from this encryption only if it holds the signature key 𝐾 −1 matching the key 𝐾 in the certiﬁcate. The (slightly modiﬁed) protocol is shown in Fig. 12. Non-Origination Assumptions. We associate two non-origination assumptions with the PCA’s transmission node in this protocol. 1. When the PCA accepts an endorsement key certiﬁcate {∣ekc MFˆEK∣}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 nonoriginating. 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.

247

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

aicˆkeyrec

/ ∙

𝐼 ˆ𝐾 ˆ𝑥ˆekc

⋅→

o

𝔸1 aicˆkeyrec

𝔸0 non(𝔸0 ) = {sk(PCA)}

{∣aic∣}EK

/ 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 TPM’s transformation to free the aic from its encryption is not an instance of Principle 1.3. The digitally signed unit must be received before being retransmitted. Thus, Principle 1.3, Clause 2 cannot apply. Moreover, Principle 1.1 does not apply. The AIK 𝐾 may be a freshly chosen value, but it has already been transmitted outside 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 adversary 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, 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: 4 Observe that in 𝔸 we have added sk(MF), EK−1 to the keys assumed non-originating, in accord with the 1 origination constraint we associated with the PCA role.

248

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

𝐼 ˆ𝐾 ˆ𝑥ˆekc

/ PCA

o aicˆkeyrec

/ ∙

{∣aic∣}EK

⋅→

/ TPM ∙

∙

𝔸1

o

∙ o aicˆkeyrec

𝔸2 / {∣aic∣}EK

/ PCA

⪯ ર

∙

{∣aic∣}EK

o

aicˆkeyrec

∙ / ∙

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 encrypted 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 encrypted forms {∣𝑡1 ∣}𝐾1 , . . . , {∣𝑡𝑗 ∣}𝐾𝑗 —so that this is the empty list—then the ﬁrst disjunct is unsatisﬁable. 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 differences 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 deﬁnitions, 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

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

249

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: Deﬁnition 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 𝑡0

and

𝑘 ⊙𝑆1 𝑡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 Deﬁnition 5.2 Let 𝑐 be a basic value or an encryption, and 𝑆 be a set of encryptions. Cut(𝑐, 𝑆, 𝔸), the cut for 𝑐, 𝑆 in 𝔸, is deﬁned 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. 6–7, it is Cut(𝑠, 𝑆3 , ℂ𝑖 ), with 𝑆3 = {{∣𝑠∣}𝑘 }. The cuts driving the MAIP analysis, shown in Figs. 13–14, are (again with 𝑆2 = {{∣aic∣}EK }) Cut(aic, ∅, 𝔸0 ) and Cut(aic, 𝑆2 , 𝔸0 ). Deﬁnition 5.3 A node 𝑛1 ∈ 𝑄 = Cut(𝑐, 𝑆, 𝔸), is solved in 𝑄, iff

250

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

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. 13–14). 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 originates 𝑎 sufﬁces. If 𝑎 ∈ 𝑃 , then the empty web sufﬁces. Since msg(𝑛1 ) = 𝑎, by the deﬁnition of skeleton, 𝑎 ∕∈ non𝔸 . Thus, assume 𝑎 ∈ unique𝔸 and 𝑎 originates before 𝑛1 in 𝔸, and the subset 𝑃 𝑎 = {𝑡 ∈ 𝑃 : 𝑎 ⊑ 𝑡} is non-empty. If some concatenation 𝑡0 ˆ𝑡1 ∈ 𝑃 𝑎 , 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-deﬁned, and by the assumption solved. By the deﬁnition 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 sufﬁces. If 𝑃 contains any concatenations, we reduce them as before. Thus, assume 𝑃 consists only of encryptions. Letting 𝑃 𝑒 = {𝑡 ∈ 𝑃 : {∣𝑡0 ∣}𝐾 ⊑ 𝑡}, Cut({∣𝑡0 ∣}𝐾 , 𝑃, 𝔸) is well-deﬁned, and since {∣𝑡0 ∣}𝐾 ∕∈ 𝑃 𝑒 , it has no solution by a

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

251

transmission node. Hence, either Lsn[𝐾] ⪯ 𝑛1 or else Lsn[𝐾1−1 ] ⪯ 𝑛1 where some {∣𝑡1 ∣}𝐾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 adding—for 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 minimal 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 {∣𝑡∣}𝐾 −1 ∈ 𝛼𝐻 (𝑆). 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: Deﬁnition 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

252

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

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 listener 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 sufﬁce. Let [⋅] choose a canonical representative from each isomorphism class of homomorphisms; i.e. (i) if 𝐽 ≤n 𝐻 ≤n 𝐽, then [𝐻] = [𝐽], and (ii) [𝐻] ≤n 𝐻 ≤n [𝐻]. We write 𝜇(𝑆) to compose [⋅] with min (Def. 3.10); i.e. deﬁne 𝜇(𝑆) = {[𝐺] : 𝐺 ∈ 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. ⊔ ⊓ Deﬁnition 6.3 When 𝑄 = Cut(𝑐, 𝑆, 𝔸) and 𝑛1 is an unsolved minimal node in 𝑄, then deﬁne 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:

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

𝔸 𝐾0

𝔸0

253

𝐻

1/ dd de edededepdep82 𝔹O dededededede d d p d d e d p d e d e d 𝐿𝑘−1 𝐿𝑘 ddddd𝐿0 deee𝐿1 e pp dddddedededeeeeeeeee d d d d d d d dd / 𝔸1 e / ... / 𝔸𝑘−1 / 𝔸𝑘 𝐽1

𝐽2

𝐽𝑘−1

𝐽𝑘

Figure 15. Cohort members 𝐽𝑖 and nodewise-injective 𝐿𝑖

1. nodes(𝔹𝐻 ) = ran(𝜙𝐻 ) ∪ {𝑚0 : 𝑚0 ⇒∗ 𝑚1 }; 2. ⪯𝔹𝐻 is the least ordering that extends 𝜙𝐻 (⪯𝔸 ), satisﬁes 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 𝜙𝐻 (⪯𝔸 ), satisﬁes 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. Namely—modulo omission of listener strands—by solving tests we can reach all of the shapes. We allow an initial step in which some strands of 𝔸 are identiﬁed; 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 solutions ⟨𝐽𝑖 : 𝔸𝑖−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 𝑚 = 𝛾(𝜌 ↓ 𝑗), and 𝜌 has origination assumptions (see p. 25), we in fact have 1 non𝔹𝐻 = 𝛼𝐻 (non𝔸 ) ∪ 𝛾(role_non(𝜌 ↓ 𝑗)) and unique𝔹𝐻 = 𝛼𝐻 (unique𝔸 ) ∪ 𝛾(role_non(𝜌 ↓ 𝑗)).

254

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

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 identiﬁed all the pairs that 𝜙𝐻 does. Now suppose that 𝔸𝑖 , 𝐿𝑖 has been deﬁned. 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. Deﬁne 𝐿𝑖+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, CPSA’s intermediate steps use listener nodes that it will discard when reporting a shape. We deﬁne fringe to trim out these listener nodes that will eventually be discarded.

Deﬁnition 6.6 When 𝐻 : 𝔸 ⋅→ 𝔹, deﬁne trim(𝐻) = [𝜙𝐻 , 𝛼ℎ ] : 𝔸 ⋅→ 𝔹′ where 𝒩 = {𝑛 ∈ nodes(𝔹) : ∃𝑚 ∈ nodes(𝔸) . 𝑛 = 𝜙𝐻 (𝑚) ∨ 𝑛 is not a listener node} 𝔹′ = ⟨𝒩 , (⪯𝔹 ∣`𝒩 × 𝒩 ), non𝔹 , unique𝔹 ⟩. Deﬁne trim(ℱ) = {trim(𝐻) : 𝐻 ∈ ℱ}. A set ℱ of homomorphisms is a fringe for 𝒞 iff every 𝐾 ∈ 𝒞 factors through trim(ℱ). Deﬁne Targets(ℱ) = {𝔹 : (𝐹 : 𝔸 ⋅→ 𝔹) ∈ ℱ }. This theorem follows from the deﬁnitions 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 𝐹 : 𝔸 ⋅→ 𝔹.

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

255

6.3. The CPSA Algorithm Thm. 6.7 provides motivation for CPSA ’s algorithm. CPSA uses breadth-ﬁrst search starting 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 𝐺
ideas in the cohort computation are due to John Ramsdell and Paul Rowe.

256

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

The CPSA algorithm is thus ﬁnitely branching; by Thm. 6.7 it never discards any possibilities, 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 speciﬁcally about the design and implementation of CPSA elsewhere. We believe that the Authentication Test Principle is central to cryptographic protocols. 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 illustrated 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 protocol 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 protocol 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] [2]

[3]

[4]

[5] [6]

[7]

[8]

[9]

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. Bruno Blanchet. Vériﬁcation automatique de protocoles cryptographiques: modèle formel et modèle calculatoire. Automatic veriﬁcation of security protocols: formal model and computational model. Mémoire d’habilitation à diriger des recherches, Université Paris-Dauphine, November 2008. 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 (P ROCOMET), 1998. Cas J.F. Cremers. Unbounded veriﬁcation, falsiﬁcation, and characterization of security protocols by pattern reﬁnement. In ACM Conference on Computer and Communications Security (CCS), pages 119– 128, New York, NY, USA, 2008. ACM. C.J.F. Cremers. Scyther - Semantics and Veriﬁcation of Security Protocols. Ph.D. dissertation, Eindhoven University of Technology, 2006. 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 106–121. Springer-Verlag, September 2007. 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 523–538, 2007. 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. Joshua D. Guttman. Authentication tests and disjoint encryption: a design method for security protocols. Journal of Computer Security, 12(3/4):409–433, 2004.

J.D. Guttman / Shapes: Surveying Crypto Protocol Runs

[10]

[11]

[12]

[13]

[14] [15]

[16] [17]

[18]

[19]

[20]

257

Joshua D. Guttman. Cryptographic protocol composition via the authentication tests. In Luca de Alfaro, editor, Foundations of Software Science and Computation Structures (FOSSACS), number 5504 in LNCS, pages 303–317. Springer, 2009. Joshua D. Guttman. Fair exchange in strand spaces. In M. Boreale and S. Kremer, editors, SecCo: 7th International Workshop on Security Issues in Concurrency, EPTCS. Electronic Proceedings in Theoretical Computer Science, Sep 2009. Joshua D. Guttman and F. Javier Thayer. Authentication tests and the structure of bundles. Theoretical Computer Science, 283(2):333–380, June 2002. Conference version appeared in IEEE Symposium on Security and Privacy, May 2000. Jonathan K. Millen and Vitaly Shmatikov. Constraint solving for bounded-process cryptographic protocol analysis. In 8th ACM Conference on Computer and Communications Security (CCS ’01), pages 166–175. ACM, 2001. Lawrence C. Paulson. Proving properties of security protocols by induction. In 10th IEEE Computer Security Foundations Workshop, pages 70–83. IEEE Computer Society Press, 1997. 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. Dag Prawitz. Natural Deduction: A Proof-Theoretic Study. Almqvist and Wiksel, Stockholm, 1965. John D. Ramsdell and Joshua D. Guttman. CPSA: A cryptographic protocol shapes analyzer. In Hackage. The MITRE Corporation, 2009. http://hackage.haskell.org/package/cpsa; see esp. doc subdirectory. John D. Ramsdell, Joshua D. Guttman, and Paul D. Rowe. The CPSA Speciﬁcation: 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. Dawn Xiaodong Song. Athena: a new efﬁcient automated checker for security protocol analysis. In Proceedings of the 12th IEEE Computer Security Foundations Workshop. IEEE Computer Society Press, June 1999. F. Javier Thayer, Jonathan C. Herzog, and Joshua D. Guttman. Strand spaces: Proving security protocols correct. Journal of Computer Security, 7(2/3):191–230, 1999.

258

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. doi:10.3233/978-1-60750-714-7-258

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 systems. 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 offthe-shelf framework which can be customised for particular domains through additional domain-speciﬁc constructions and theory. This chapter introduces the application 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 communication of a message m over channel trans.A.B. Messages will themselves have some speciﬁc structures (to include encryption and signing), and are drawn from a deﬁned set of messages. Processes are described using a language comprised of a number of process constructors: Preﬁx 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∣}sK → P(m).

S. Schneider / Security Analysis Using Rank Functions in CSP

259

Termination The process STOP indicates termination (or deadlock): this process can perform no further events. Choice If P(i) is a ﬁnite or inﬁnite 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 ∣∣∣ P(i) is the interleaving of all of the P(i) processes. All of i 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 synchronisation 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 deﬁned recursively, using (parameterised) process names: the deﬁnition N(p) = ˆ P(p) deﬁnes 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: ⟨e1 , . . . , en ⟩. 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. Speciﬁcations are concerned with allowable system behaviours. A trace speciﬁcation will describe which traces are allowable, and a CSP system can then be checked against the speciﬁcation 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 deﬁned on traces as follows: a precedes b = (last(tr) = b ⇒ a in tr) where last(tr) is the last event in trace tr (undeﬁned if tr = ⟨⟩), and a in tr means that a appears somewhere in the trace tr. Then (a → b → STOP) sat a precedes b

260

S. Schneider / Security Analysis Using Rank Functions in CSP

2. Protocol modelling and veriﬁcation 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 property to be considered. In order to judge the CSP model against the speciﬁcation 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 { A → B : [A.B.k]sk(A) B→A:

pk(B)

s {∣s∣}k

[k fresh]

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 deﬁne the set of possible messages 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 identiﬁers, shared keys, and plain text are available as message components. We deﬁne the space of messages as follows, and consider all messages in the CSP model to come from this set: M1 , M2 ::= I (∈ USER) S (∈ PLAIN) K (∈ KEY) M1 .M2 s {∣M∣}K {∣M∣}apk(I) [M]sk(I)

messages agent identities plaintext shared keys concatenation of messages symmetric encryption of message M by key K asymmetric encryption of message M by agent I’s public key signing of message M with agent I’s signature key

We assume sets USER of user identiﬁers; 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 particular 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 j’s public key, and transmits it to j. A then awaits a message encrypted with the key k. A’s run of the protocol may be described in CSP as follows: }a { INITA (k) = □ trans.A!j! [A.j.k]sk(A) j pk(j)

→

s rec.A.j?{∣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

261

S. Schneider / Security Analysis Using Rank Functions in CSP

PAIRING

U NPAIRING

S ⊢ m1 S ⊢ m2 S ⊢ m1 ⋅ m2

M EMBER

S⊢m

S ⊢ m1 ⋅ m2 S ⊢ m1 S ⊢ m2

S UBSET

T RANSITIVE CLOSURE

S′ ⊢ m [S′ ⊆ S] S⊢m

[m ∈ S]

S′ ⊢ m

D ECRYPTION 1

E NCRYPTION 1

S⊢m

∀ s′ ∈ S′.S ⊢ s′ S⊢m s

S⊢k

S ⊢ {∣m∣}k S⊢k S⊢m

s

S ⊢ {∣m∣}k

D ECRYPTION 2

E NCRYPTION 2

a

S ⊢ {∣m∣}pk(i)

S⊢m

a

S⊢m

S ⊢ {∣m∣}pk(i) S IGNING

[i ∕= A, B]

M ESSAGE E XTRACTION

S⊢m [i ∕= A, B] S ⊢ [m]sk(i)

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 encrypted with his public key pk(B). That message contains a key k, which B then uses to encrypt a response s. }a { RESPB(s) = rec.B?i? [i.B.k]sk(i) pk(B)

s

→ trans.B!i!{∣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 recipient; and messages received come from the attacker. The attacker can also divert, invent, 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 decryption 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 attacker’s knowledge. Figure 2 gives the rules that govern how the attacker can generate new messages: ⊢ is deﬁned 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 D ECRYPTION 2 and S IGNING encapsulate the assumption that the attacker controls any users other than A and B.

262

S. Schneider / Security Analysis Using Rank Functions in CSP

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}) □

□

i∈USER j∈USER m∣S⊢m

rec!i!j!m → ENEMY(S)

This deﬁnes the threat model in terms of attacker capabilities. Correctness in the context of this attacker indicates that there are no attacks from an 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, spooﬁng, combining, dissecting, and replaying messages. However, the key point in this model is that the attacker is unable to attack the cryptographic mechanisms. The deﬁnition 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 deﬁne ENEMY to be ENEMY(IK). A model of a single run of the protocol with A as initiator and B as responder, with speciﬁc key kAB and secret sAB will be: SYS = (INITA (kAB ) ∣∣∣ RESPB (sAB )) ∣[ 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. Speciﬁcation Having developed the model of the protocol, we now consider 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 conﬁdent that the protocol was indeed run with B. From B’s point of view, B wishes to be conﬁdent that a protocol run apparently with A was indeed with A.

S. Schneider / Security Analysis Using Rank Functions in CSP

A

}a { [A.B.k]sk(A)

263

B

pk(B)

respgo.B.A.s.k

s {∣s∣}k

initdone.A.B.s.k

Figure 2. Introducing speciﬁcation 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 speciﬁcation 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 speciﬁcations 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 B’s 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 speciﬁcation 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 INITA and RESPB are adjusted to incorporate these speciﬁcation events: }a { INITA (kAB ) = trans.A!B! [A.B.kAB]sk(A) pk(B)

→

s rec.A.B?{∣s∣}kAB

→ initdone.A.B.s.kAB → STOP }a { RESPB(sAB ) = rec.B?j? [j.B.k]sk(j)

pk(B)

→ respgo.B.j.sAB.k s

→ trans.B!j!{∣sAB ∣}k → STOP

264

S. Schneider / Security Analysis Using Rank Functions in CSP

The authentication property from A’s point of view is that whenever the signal even initdone.A.B.s.k occurs with speciﬁc 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 speciﬁcation 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 speciﬁcation—they are modelling points in the protocol rather than communications that the attacker can engage in. A violation 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 completed, 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 kAB and text sAB , and consider authentication with respect to these. The form of speciﬁcation SYS is required to satisfy is then: respgo.B.A.kAB.sAB precedes initdone.A.B.kAB.sAB which states that any trace in which the initdone event appears must have the corresponding 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 USERi 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. 2. 3. 4.

∀ m ∈ IK.𝜌(m) > 0 ∀ S ⊆ MESSAGE.(𝜌(S) > 0 ∧ S ⊢ m) ⇒ 𝜌(m) > 0 𝜌(b) ⩽ 0 ∀ i.(USERi ∣[ a ]∣ Stop) sat 𝜌(tr ↾ rec) > 0 ⇒ 𝜌(tr) > 0

then (∣∣∣ USERi ) ∣[ trans, rec ]∣ ENEMY sat a precedes b. □ i 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 USERi blocked on a is that if only positive rank messages are received, then no nonpositive rank message should be produced. The proof of the theorem is given in [Sch98b].

S. Schneider / Security Analysis Using Rank Functions in CSP

265

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 speciﬁcation the challenge is to identify a suitable 𝜌 that meets the conditions. Identiﬁcation of such a 𝜌 establishes correctness of the protocol with respect to that speciﬁcation. 2.3. Application of the theorem We require in this particular case that: every message in IK has positive rank; if every message in a set S has positive rank, and S ⊢ m, then m has positive rank; initdone.A.B.kAB.sAB does not have positive rank; INITA (kAB ) maintains positive rank: if it has only received messages of positive rank then it only outputs messages of positive rank. Note that INIT(kAB ) ∣[ respgo.B.A.sAB.kAB ]∣ STOP = INITA (kAB ); 5. RESPB (sAB ) ∣[ respgo.B.A.sAB.kAB ]∣ 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 RESPB with the respgo event blocked. 1. 2. 3. 4.

If we can ﬁnd a rank function that meets all these conditions, then we will have established that SYS satisﬁes respgo.B.A.kAB.sAB precedes initdone.A.B.kAB.sAB , 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 kAB ∕∈ 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.kAB.sAB does not have positive rank, by deﬁnition of 𝜌. 4. INITA (kAB ) maintains positive rank. It outputs a single protocol message, which has positive rank; and it can only perform the ﬁnal initdone.A.B.sAB.kAB event if it has previously received a message of rank 0: a message encrypted with kAB . 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 RESPB : RESPB (sAB ) ∣[ respgo.B.A.sAB.kAB ]∣ STOP }a { = rec.B?j? [j.B.k]sk(j) → if (j = A ∧ k = kAB ) pk(B) then STOP else respgo.B.j.sAB .k s → trans.B!j!{∣sAB ∣}k → STOP The only time B can send a message of rank 0 is when the received key k is in fact kAB . In this case we must have j ∕= A to reach that point in the restricted protocol.

266

S. Schneider / Security Analysis Using Rank Functions in CSP

𝜌(i) = 1 𝜌(s) = 1 { 0 if k = kAB 𝜌(k) = 1 otherwise 𝜌(m1 .m2 ) = min{𝜌(m1 ).𝜌(m2 )} { 0 if k = kAB s 𝜌({∣m∣}k ) = 𝜌(m) otherwise { 1 if i = B ∧ m = [A.B.k′ ]sk(A) a 𝜌({∣m∣}pk(i) ) = 𝜌(m) otherwise { 0 if m = i.B.kAB 𝜌([m]sk(i) ) = 𝜌(m) otherwise { 0 if sig = initdone.A.B.sAB.kAB 𝜌(sig) = 1 otherwise Figure 3. A rank function for authentication

}a { But then the rank of the received message is 0: 𝜌( [j.B.k]sk(j)

pk(B)

) = 0. Hence

transmission of a message of rank 0 follows receipt of a message of rank 0. Thus RESPB (sAB ) ∣[ respgo.B.A.sAB.kAB ]∣ STOP maintains positive rank. We can conclude that A’s run of the protocol authenticates B. 2.4. Protocol simpliﬁcation If the participants are removed from message 1 of the protocol, then we obtain the simpliﬁed (ﬂawed) version: }a { A → B : [k]sk(A)

pk(B)

s

B → A : {∣s∣}k

We will consider how this simpliﬁcation affects the correctness proof. The natural change to make to the rank function is to change the message in the deﬁnition of 𝜌 to follow the change in the protocol, resulting in the following alternative clauses (the other clauses are unaffected): { 𝜌({∣m∣}apk(i) ) = { 𝜌([m]sk(i) ) =

1 if i = B ∧ m = [k′ ]sk(A) 𝜌(m) otherwise 0 if m = kAB 𝜌(m) otherwise

267

S. Schneider / Security Analysis Using Rank Functions in CSP

The models for analysis also change to reﬂect the simpler ﬁrst message: INITA (kAB )

}a { = trans.A!B! [kAB ]sk(A)

pk(B)

s

→ rec.A.B?{∣s∣}kAB → initdone.A.B.s.kAB → STOP

RESPB(sAB ) ∣[ respgo.B.A.sAB.kAB ]∣ STOP }a { → if (j = A ∧ k = kAB ) = rec.B?j? [k]sk(j) pk(B) then STOP else respgo.B.j.sAB .k s → trans.B!j!{∣sAB ∣}k → STOP We ﬁnd that the revised rank function with the revised CSP models still meets all the rank function properties. Thus the simpliﬁed (ﬂawed!) protocol still establishes the authentication property that A authenticates B, and they agree on the session key kAB and the secret message sAB . Although ﬂawed in other ways, it still provides this authentication property. 3. Responder authenticating initiator The previous section veriﬁed 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 suitable model of a protocol run is deﬁned in CSP, this time from the responder’s point of view; a rank function is identiﬁed which meets the properties of the rank function theorem, 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 A’s ﬁ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 B’s use of the ﬁrst protocol message in authenticating the initiator. We therefore ﬁx the user A that B is responding to, and the key kAB 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.kAB. We therefore obtain the following processes for the initiator and the responder, which should maintain positive 𝜌 for any proposed rank function 𝜌: INITA ∣[ initgo.A.B.kAB ]∣ STOP =

□j,k if j = B ∧ k = kAB then STOP

}a { else initgo.A.j.k → trans.A!j! [A.j.k]sk(A)

pk(j)

s

→ rec.A.j?{∣s∣}k → STOP

268

S. Schneider / Security Analysis Using Rank Functions in CSP

A

initgo.A.B.k

}a { [A.B.k]sk(A)

pk(B)

B

respdone.B.A.k

s {∣s∣}k

Figure 4. Introducing speciﬁcation events for B authenticating A

RESPB (sAB , kAB ) = }a { rec.B.A? [A.B.kAB]sk(A)

pk(B)

s

→ respdone.B.A.kAB → trans.B!A!{∣sAB ∣}kAB → STOP

The following rank function meets all the conditions of the rank function theorem: 𝜌(i) = 1 𝜌(s) = 1 𝜌(k) = 1 𝜌(m1 .m2 ) = min{𝜌(m1 ).𝜌(m2 )} 𝜌({∣m∣}sk ) = 𝜌(m) 𝜌({∣m∣}apk(i) ) = 𝜌(m) { 0 if i = A ∧ m = A.B.kAB 𝜌([m]sk(i) ) = 𝜌(m) otherwise { 0 if sig = respdone.B.A.kAB 𝜌(sig) = 1 otherwise This rank function captures the requirement that the enemy cannot generate or obtain the message [A.B.kAB]sk(A) , even if it knows kAB (note that 𝜌(kAB ) = 1, allowing for the enemy to be able to generate it). This fact is sufﬁcient to guarantee to B that A must have initiated the protocol run with B, with key kAB , establishing authentication. 3.1. Protocol simpliﬁcation As previously, if the participants are removed from message 1 of the protocol, then we obtain the simpliﬁed version: }a { A → B : [k]sk(A) s

B → A : {∣s∣}k

pk(B)

269

S. Schneider / Security Analysis Using Rank Functions in CSP

The revised CSP protocol descriptions are: INITA ∣[ initgo.A.B.kAB ]∣ STOP =

□j,k if j = B ∧ k = kAB then STOP

}a { else initgo.A.j.k → trans.A!j! [k]sk(A)

pk(j)

RESPB(sAB , kAB ) = }a { rec.B.A? [kAB ]sk(A)

pk(B)

s

→ rec.A.j?{∣s∣}k → STOP

s

→ respdone.B.A.kAB → trans.B!A!{∣sAB ∣}kAB → STOP

The natural change to the rank function is in the clause for signed messages, which becomes: { 0 if i = A ∧ m = kAB a 𝜌({∣m∣}sk(i) ) = 𝜌(m) otherwise However, we now ﬁnd that INITA ∣[ initgo.A.B.kAB ]∣ STOP no longer meets condition 4 of the rank }atheorem, since if k = kAB and j ∕= B then it can communicate { function trans.A.j. [kAB ]sk(A) and thus transmit a communication of rank 0 without having pk(j)

ﬁ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 “Introduction” Figure 1: B accepts the ﬁrst message as evidence that A has initiated the protocol with B, but in fact A might have initiated it with a different party. We write the attack as follows:

𝛽:

}a { A → E : [kAB ]sk(A) }pk(E) { a E(A) → B : [kAB ]sk(A)

𝛽:

B → E(A) : {∣s0 ∣}skAB

𝛼:

pk(B)

where E(A) represents E masquerading as A. The predicate initgo.A.B.kAB precedes respdone.B.A.kAB is not met by the trace corresponding to this attack. The ‘conﬁrmation’ signal respdone.B.A.kAB is in fact preceded by initgo.A.E.kAB. Hence the authentication property is not satisﬁed by the simpliﬁed 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).

270

S. Schneider / Security Analysis Using Rank Functions in CSP

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 them—if 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 analysis for SECRECY INIT is very similar. 4.1. Modeling for secrecy analysis The intruder’s 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 sufﬁcient to provide a rank function such that s has rank 0. Secrecy is concerned with the impossibility of a particular communication, rather than establishing a precedence relationship between two events. Usefully, 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 participant 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. Observe that in this case no additional speciﬁcation events need to be introduced, and since imp is not in the alphabet of any process, restricting the system’s 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. RESPB 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. INITA (k0 ) =

}a { [A.j.k0 ]sk(A)

□j trans.A!j!

pk(j)

RESPB (s0 ) = }a { rec.B.A? [A.B.k]sk(A)

pk(B)

s

→ rec.A.j?{∣s∣}k0 → STOP

s

→ trans.B!A!{∣s0 ∣}k → STOP

The secret sent by B is s0 , so any suitable rank function will necessarily assign s0 a rank of 0. Observe that here we must assume that s0 ∕∈ 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 { 0 if s = s0 𝜌(s) = 1 otherwise

S. Schneider / Security Analysis Using Rank Functions in CSP

{ 𝜌(k) =

271

0 if k = k0 1 otherwise

𝜌(m1 .m2 ) = min{𝜌(m1 ).𝜌(m2 )} { 1 if k = k0 ∧ s = s0 s 𝜌({∣m∣}k ) = 𝜌(m) otherwise { 1 if i = B ∧ m = [A.B.k0 ]sk(A) a 𝜌({∣m∣}pk(i) ) = 𝜌(m) otherwise { 0 if i = A ∧ m = A.B.k 𝜌([m]sk(i) ) = 𝜌(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 how the 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 simpliﬁed version For the simpliﬁed version of the protocol, the natural change to make to the rank function is to simplify the messages in the deﬁnition of 𝜌, resulting in the following alternative clauses (the other clauses are unaffected): { a 𝜌({∣m∣}pk(i) )

= {

𝜌([m]sk(i) ) =

1 if i = B ∧ m = [k0 ]sk(A) 𝜌(m) otherwise 0 if i = A ∧ m = k(∈ KEY) 𝜌(m) otherwise

However, we now ﬁnd that condition 4 for a rank function }a holds: INITA can { no longer immediately transmit a message of rank 0: the message [k0 ]sk(A) . In this case this pk(E)

leads us to the following attack:

𝛽:

}a { A → E : [k0 ]sk(A) }pk(E) { a E(A) → B : [k0 ]sk(A)

𝛽:

B → E(A) : {∣s0 ∣}k0

𝛼:

s

pk(B)

The responder relies on the contents of the ﬁrst message (i.e. the session key) being secret. However, in the simpliﬁed case it might have gone to another party before reaching the responder, hence the protocol is ﬂawed with respect to responder secrecy. In the original version, the inclusion of the identiﬁers A and B are sufﬁcient for B to know that A encrypted the ﬁrst message with B’s public key, ensuring secrecy of the session key and hence the payload.

272

S. Schneider / Security Analysis Using Rank Functions in CSP

5. Multiple runs In general, several concurrent overlapping runs of the protocol might take place, and protocol 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 deﬁned, 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: INITC (k) =

□j trans.C.j.

}a { [C.j.k]sk(C)

pk(j)

s

→ rec.C.j?{∣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: RESPC (s) = }a { rec.C?i? [i.C.k]sk(i)

pk(C

s

→ respgo.C.i.s.k → trans.C!i!{∣s∣}k → STOP

A general participant C can then engage in arbitrarily many protocol runs concurrently as sender and receiver. This is captured as the interleaving of initiator and responder runs: USERC = (∣∣∣

k∈KEYC

INITC (k)) ∣∣∣ (∣∣∣

s∈MSGC

RESP(s))

Observe that in this description each initiator run has a different key k, and each responder run has a different message s. Each agent C has its own set of fresh keys KEYC and messages MSGC , and in the model these will be pairwise disjoint so any fresh key or message 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.sAB.kAB precedes initdone.A.B.sAB.kAB : 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 USERC to be reduced to individual runs. These rules follow from the trace semantics of general choice and general interleaving [Ros97,Sch99]. Checking that USERC ∣[ respgo.B.A.sAB.kAB ]∣ STOP sat maintains 𝜌 then reduces (by rule I NTERLEAVING of Figure 5) to checking the following: ∙ that each INITC (k) ∣[ respgo.B.A.sAB.kAB ]∣ STOP sat maintains 𝜌; ∙ that each RESPC (s) ∣[ respgo.B.A.sAB .kAB ]∣ STOP sat maintains 𝜌.

273

S. Schneider / Security Analysis Using Rank Functions in CSP

I NTERLEAVING

C HOICE

∀ i.(Pi sat maintains 𝜌)

∣∣∣i Pi sat maintains 𝜌

∀ i.(Pi sat maintains 𝜌)

□i Pi sat maintains 𝜌

Figure 5. Composition rules for maintains 𝜌

These each reduce to consideration of the possible cases. We will work through INITC (k) as an example. INITC (k) sat maintains 𝜌 as long as the initiating }a message has positive rank. Thus { by rule C HOICE we must show that [C.j.k]sk(C) has positive rank, for any C, j, pk(j)

and k ∈ KEYC .

}a { ∙ Case 1: If j = B and C = A and k = kAB then 𝜌( [C.j.k]sk(C)

the deﬁnition of 𝜌. { }a ∙ Case 2: Otherwise 𝜌( [C.j.k]sk(C)

pk(j)

pk(j)

) = 1 from

) = 𝜌([C.j.k]sk(C) )

∙ Subcase 2.1: If j = B and k = kAB , then C = A. This follows from the fact that kAB ∈ KEYC for some unique C, but for the particular key kAB we know that kAB ∈ KEYA . Hence j = B, k = kAB , and C = A. But this is case 1, so Subcase 2.1 is impossible. ∙ Subcase 2.2: j ∕= B or k ∕= kAB . Then 𝜌([C.j.k]sk(C) ) = 𝜌(C.j.k). If k = kAB then C = A, and we also have from the model that kAB is the key used in a session A initiates with B, thus we have j = B, contradicting the condition for} the case. { a Otherwise k ∕= kAB , so 𝜌(k) = 1. Then 𝜌(C.j.k) = 1, so 𝜌( [C.j.k]sk(C) )= pk(j)

1 as required.

}a { In all cases therefore we have that 𝜌( [C.j.k]sk(C)

pk(j)

) = 1, establishing that

INITC (k) sat maintains 𝜌. A similar consideration of the cases in the responder deﬁnition establishes that each RESPC (s) ∣[ respgo.B.A.kAB.sAB ]∣ STOP sat maintains 𝜌. Combining all these results yields that USERC ∣[ respgo.B.A.kAB.sAB ]∣ 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 veriﬁcation 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,

274

S. Schneider / Security Analysis Using Rank Functions in CSP

SBS09]), and also shown how secrecy can be speciﬁed. 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 another common mechanism used within security protocols to provide assurances of freshness 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 allowed 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 from repudiating 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 sufﬁcient evidence to convince a third party that the other protocol party must have participated—essentially 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 from the 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 inﬁnity), 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 established 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).

S. Schneider / Security Analysis Using Rank Functions in CSP

275

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 possibilities 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 Gong’s protocol built around exclusive-or [Gon89] was presented in [Sch02]. Exclusive-or has several properties, 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-deﬁned in the context of the equations: if two (differently constructed) messages are equal, then they should have the same rank. Since rank functions tend to be deﬁned by induction over the BNF for constructing messages, establishing well-deﬁnedness is an additional requirement. This approach was also used in [DS07] for a class of group Difﬁe-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 deﬁnitions of rank functions, CSP descriptions of protocol participants, and veriﬁcation 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 constructs a minimal function whose positive messages include those of the enemy’s initial knowledge, are closed under the message generation rules, and are closed under the protocol 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 veriﬁed. 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.

276

S. Schneider / Security Analysis Using Rank Functions in CSP

References 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 protocols. In tpHOL, 1997. [DS07] Rob Delicata and Steve Schneider. An algebraic approach to the veriﬁcation of a class of difﬁehellman protocols. Int. J. Inf. Sec., 6(2-3):183–196, 2007. [DY83] D. Dolev and A.C. Yao. On the security of public key protocols. IEEE Transactions on Information 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 veriﬁcation 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 veriﬁcation. 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 protocols. In IEEE International Conference on Advanced Information Networking and Applications Workshops (AINAW’07), 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 veriﬁcation of authentication protocols on an unbounded network. In CSFW, pages 132–143, 2000. [Low97] Gavin Lowe. A hierarchy of authentication speciﬁcations. 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 Analysis 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 3–17, 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):741–758, 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 FMOODS’02: Formal Methods for Open Object-based Distributed Systems, 2002. [SD04] S. Schneider and R. Delicata. Verifying security protocols: An application of CSP. In Communicating Sequential Processes: the First 25 Years, pages 243–263, 2004. [Del06]

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. doi:10.3233/978-1-60750-714-7-277

277

Computational Soundness - The Case of Difﬁe-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 reﬂect appealing 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 computational soundness result that extends the original work of Abadi and Rogaway. We show that it is possible to reason about computational indistinguishability of distributions 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 Difﬁe-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 characterize 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. Furthermore, 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 efﬁciently (i.e. run in time polynomial in some security parameter), but are otherwise allowed to

278

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

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. Speciﬁcally, 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 Difﬁe-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 difﬁcult 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 assuming security of primitives, and the rather limited adversary imply that the symbolic security proofs do not have clear implications for actual implementations. However, proofs can be, and usually are, quite rigorous. More importantly, symbolic analysis may beneﬁt 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 beneﬁt from the rigourousness speciﬁc to symbolic methods, a signiﬁcant research effort attempts to investigate the links between symbolic and computational methods for security analysis. The goal is to tame the complexity speciﬁc to computational models via symbolic techniques. Existing research falls along two main directions. Symbolic reasoning with computational semantics. One research direction aims to directly apply the methods and techniques speciﬁc to symbolic approaches to computational 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 primitives.

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

279

Computational soundness. The second research direction is to determine if and under what conditions proofs carried out in symbolic models imply security under computational 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, Pﬁtzmann, and Waidner [3] and by Micciancio and Warinschi [28]. Numerous other results have built upon these works by considering variations 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 computational ones. In turn, this relation between symbolic and computational executions entails computational soundness theorems: a protocol that is secure symbolically, is also secure computationally. 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 computational soundness result. 1.3. An extension of the Abadi-Rogaway logic with Difﬁe-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 Rogaway’s seminal result illustrates quite well the potential of the computational soundness approach. The simpler setting of a passive adversary enables relatively simple proofs, and the particular extension that we analyze 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) using 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 relation) have associated distributions that are computationally indistinguishable. This result implies that one can reason symbolically about indistinguishability of computational distributions. The extension that we present considers an extended class of protocols where symmetric encryptions keys may also be derived via (general) Difﬁe-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.

280

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

A generalization of the Difﬁe-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 difﬁculties 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 deﬁnitions. More speciﬁcally, 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 chapter 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 computational 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 example, a Difﬁe-Hellman key of the form g𝑥1 𝑥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 arbitrary 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 efﬁcient algorithm can determine from which of the two distributions a given bitstring has been sampled. The formal deﬁnition that we give below (as well as the deﬁnitions 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 inﬁnity). Instead, concrete bounds on the running time of the adversary are translated into concrete bounds

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

281

on the probability that the adversary is able to accomplish a speciﬁc task. One beneﬁt is that one can ﬁx a security parameter and thus avoid working with families of primitives. 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. Deﬁnition 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 𝜖: $ (𝒟) = Pr[𝑥 ← 𝑋 : 𝒟(𝑥) = 1] − Pr[𝑦 ← 𝑌 : 𝒟(𝑦) = 1] Advind <𝜖 𝑋,𝑌 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 encryption 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 obtaining 𝑚 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 deﬁnitional approach of Bellare et al. [8] and of Abadi and Rogaway [1]. The idea is to deﬁne 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

282

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

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 notion1 . Deﬁnition 2 (IND-CPA∗ security) Let Π = (𝒦𝒢, ℰ, 𝒟) be a symmetric encryption scheme and 𝜂 some ﬁxed security parameter. We deﬁne the advantage of an adversary 𝒜 by ∗

-cpa (𝒜) = Advind Π [ ] [ ] $ $ = Pr 𝑘 ← 𝒦𝒢 : 𝒜ℰ(𝑘,⋅) = 1 − Pr 𝑘 ← 𝒦𝒢 : 𝒜ℰ(𝑘,0) = 1 . We say that an encryption scheme (𝒦𝒢, ℰ, 𝒟) is (𝜖, 𝑡)-IND-CPA∗ -secure if for any ad-cpa∗ (𝒜) < 𝜖. versary 𝒜 running in time 𝑡 it holds that: Advind Π 2.3. The Decisional Difﬁe-Hellman assumption Fix a cyclic group 𝔾 of order 𝑞 and let 𝑔 be a generator of 𝔾. Informally, the Decisional Difﬁe-Hellman assumption states that it is difﬁcult to distinguish a triple (𝑔𝑥1 , 𝑔 𝑥2 , 𝑔 𝑟 ) from (𝑔 𝑥1 , 𝑔 𝑥2 , 𝑔 𝑥1 𝑥2 ) when 𝑥1 , 𝑥2 , 𝑟 are chosen uniformly at random. Deﬁnition 3 (The Decisional Difﬁe-Hellman assumption) Let 𝔾 be a group of order 𝑞 and 𝔤 a generator of 𝔾. For an algorithm 𝒜 deﬁne its advantage against the Decisional Difﬁe-Hellman problem in 𝔾 by [ ] $ ind-ddh (𝒜) = Pr 𝑥1 , 𝑥2 ← ℤ𝑞 : 𝒜(𝔤𝑥1 , 𝔤𝑥2 , 𝔤𝑥1 𝑥2 ) = 1 Adv𝔾 [ ] $ − 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 ind-ddh (𝒜) < 𝜖. that Adv𝔾 1 To obtain the standard IND-CPA security notion one replaces in the following deﬁnition the oracle ℰ(𝑘, 0) with the oracle ℰ(𝑘, 0∣⋅∣ ) that when queried with message 𝑚 returns the encryption of the all 0 string of length ∣𝑚∣.

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

283

3. A generalization of the Decisional Difﬁe-Hellman assumption In this section we present a generalization of the standard Decisional Difﬁe-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 , 𝔤𝑥1 𝑥2 𝑥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 combinations 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 difﬁcult. In this section we conﬁrm 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 adversary 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 independent 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 sufﬁciently 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 coefﬁcients 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 positive 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

284

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

𝑣𝑎𝑟(𝑃 ) = {𝑋1 , 𝑋2 , 𝑋3 , 𝑋4 } and 𝑚𝑜𝑛(𝑃 ) = {𝑋2 , 𝑋1 𝑋3 , 𝑋1 𝑋4 }. XXX For a monomial 𝑚 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 𝑋2 𝑋3 are power-free but 𝑋1 + 𝑋22 is not. We write PF(ℤ𝑞 [𝑋1 , 𝑋2 , . . . , 𝑋𝑛 ]) for the set of power-free polynomials with variables {𝑋1 , . . . , 𝑋𝑛 } and coefﬁcients in ℤ𝑞 . The results that we present only hold for such polynomials, so in the remainder of the chapter, otherwise speciﬁed, 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, 2, . . . , 𝑛}

𝑖=1

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 Difﬁe-Hellman assumptions [12], the parallel Difﬁe-Hellman assumption [11], the General Difﬁe-Hellman Exponent (GDHE) [10], the Square Exponent [26,19,36], the Inverse Exponent [33] and many others. The assumption is given in the next deﬁnition. Deﬁnition 4 (The (𝑃, 𝑄)-Decisional Difﬁe-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 deﬁne the advantage of an algorithm 𝒜 against the (𝑃, 𝑄)-DDH problem by (𝑃,𝑄)-ddh (𝒜) Adv𝔾

[ ] [ ] P(𝜏 ),Q(𝜏 ) P(𝜏 ),R(𝜏 ) = Pr 𝒜 = 1 − Pr 𝒜 = 1

where the probabilities are taken over the coins of 𝒜 and over the map 𝜏 selected uniformly at random from the maps from {𝑋1 , 𝑋2 , . . . , 𝑋𝑛 } ∪ 𝑅 → ℤ𝑞 . We say that the

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

285

(𝜖, 𝑡)-(𝑃, 𝑄)-DDH assumption holds in 𝔾 or, alternatively, that the (𝑃, 𝑄)-DDH assumption 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 nontrivial challenge is related to solving the Decisional Difﬁe-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 deﬁne several quantities. The following deﬁnitions from [13] are somewhat technical and can be safely skipped. Deﬁne the graph 𝐺(𝑃,𝑄) whose vertexes are the elements of 𝑚𝑜𝑛(𝑃 ∪𝑄), the monomials 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 deﬁned by ∑ ( ) 𝑜𝑟𝑑(𝑚) − 1 𝑜𝑟𝑑+ 𝑃 (𝑄) = 𝑚∈𝑚𝑜𝑛+ 𝑃 (𝑄)

The set nm(𝑃, 𝑄) of non-maximal elements of 𝑚𝑜𝑛+ 𝑃 (𝑄) is the set of monomials 𝑚 ∈ 2 (𝑄) such that there exists a strict super-monomial 𝑚′ 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 efﬁciency that is quantiﬁed 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 ( ( ∣nm(𝑃,𝑄)∣ )( )) + (𝑄) + 2 − 1 . 𝑛 + 𝑜𝑟𝑑 (𝑄) and 2𝑡′ = 𝑡. 𝜖′ = 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). Nevertheless, 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 𝑚′ .

286

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

4. A Symbolic Logic for Difﬁe-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 polynomials over variables in Exponents with coefﬁcients in ℤ𝑞 . Notice that 𝑞 is an arbitrary but ﬁxed natural number, and is a parameter of the symbolic language that we deﬁne here. Messages are terms in the set Msg deﬁned by the grammar: Basic ::= SKeys ∣ gPoly ∣ Nonce Keys ::= SKeys ∣ ℎ(gPoly ) s

Msg ::= Basic ∣ (Msg, Msg) ∣ {∣Msg∣}Keys In the above deﬁnition g and ℎ are symbols different form all other symbols. They represent a generator for some group and a key derivation function, respectively. The second deﬁning rule for Keys indicates that we consider encryption keys that are either generated by the key generation algorithm of an encryption scheme, or are derived from group elements using the key derivation function. s When an element 𝐾 of Keys occurs in an expression of the form {∣𝑡∣}𝐾 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 associative 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.

T HE SYMBOLIC ADVERSARY. The messages that an adversary can compute from a given set of terms are captured via a deduction relation ⊢⊆ 𝒫(Msg) × Msg. For 𝑆 ⊂ Msg

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

𝑆⊢𝐸

𝐸∈𝑆

287

𝑆 ⊢ (𝐸1 , 𝐸2 )

𝑆 ⊢ (𝐸1 , 𝐸2 )

𝑆 ⊢ 𝐸 1 , 𝑆 ⊢ 𝐸2

𝑆 ⊢ 𝐸1

𝑆 ⊢ 𝐸2

𝑆 ⊢ (𝐸1 , 𝐸2 )

𝑆⊢g

𝑆 ⊢ g 𝑝 , 𝑆 ⊢ g𝑞

1

𝑆 ⊢ g𝜆𝑝+𝑞

𝑆 ⊢ {∣𝐸∣}ℎ(g𝑝 ) , 𝑆 ⊢ g𝑝

s

𝑆 ⊢ {∣𝐸∣}s𝐾 , 𝑆 ⊢ 𝐾

𝑆⊢𝐸

𝑆⊢𝐸

Figure 1. Rules for deﬁning 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 deﬁned 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: s

s

g𝑋1 , g𝑋2 , {∣𝐾∣}ℎ(g𝑋1 +𝑋2 ) ⊢ 𝐾 but g𝑋1 , g𝑋2 , {∣𝐾∣}ℎ(g𝑋1 𝑋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𝑋1 𝑋2 which is required for decryption.

PATTERNS FOR EXPRESSIONS . The information that an adversary obtains from a symbolic 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 subexpressions that occur encrypted under keys that the adversary cannot derive from 𝐸) by the symbol □ (undecryptable). For an expression 𝐸 ∈ Msg its pattern is deﬁned by the inductive rules in Figure 2. Example 2 For example, the pattern of the expression s

s

s

s

g𝑋1 , g𝑋2 , {∣𝐾1 ∣}ℎ(g𝑋1 𝑋2 ) , {∣𝐾2 ∣}𝐾1 , {∣𝐾3 ∣}ℎ(g𝑋1 +𝑋2 ) , {∣𝐾4 ∣}𝐾3 is

288

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys ′ ′ pattern(𝐸 ) ( ) = 𝐸) ( pattern((𝐸1 , 𝐸2)) = pattern(𝐸1 ), pattern(𝐸2 ) pattern({∣𝐸 ′ ∣}s𝐾 ) = {∣pattern(𝐸 ′ )∣}s𝐾 pattern({∣𝐸 ′ ∣}s𝐾 =) {∣□∣}s𝐾 pattern {∣𝐸 ′ ∣}sℎ(g𝑝 ) = {∣pattern(𝐸 ′ )∣}sℎ(g𝑝 ) ) ( s s pattern {∣𝐸 ′ ∣}ℎ(g𝑝 ) = {∣□∣}ℎ(g𝑝 )

if 𝐸 ′ ∈ Basic if if if if

𝐸 𝐸 𝐸 𝐸

⊢𝐾 ∕⊢ 𝐾 ⊢ g𝑝 ∕⊢ g𝑝

Figure 2. Rules for deﬁning the pattern of expression 𝐸. In the above 𝑝 ranges over Poly and 𝐾 ranges over SKeys. s

s

s

s

g𝑋1 , g𝑋2 , {∣□∣}ℎ(g𝑋1 𝑋2 ) , {∣□∣}𝐾1 , {∣𝐾3 ∣}ℎ(g𝑋1 +𝑋2 ) , {∣𝐾4 ∣}𝐾3

E XPRESSION EQUIVALENCE . We aim to deﬁne 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 deﬁnition of patterns) is therefore deﬁned 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 patterns 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𝑋1 𝑋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 relations 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 injective renamings of polynomials that deﬁne 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 appropriate 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.

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

289

Deﬁnition 5 (Linear dependence preserving renamings) Let 𝑃 ⊆ Poly be an arbitrary 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𝑋1 𝑋2 ) and 𝜎 : poly(𝐸) → Poly the map deﬁned 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. Deﬁnition 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 𝜎1 𝜎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 deﬁne the relation ≺𝐸 on the set SKeys ∪ Poly (restricted 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 deﬁning formally acyclic expressions. Deﬁnition 7 (Acyclic expression) An expression 𝐸 is acyclic if the two following conditions are satisﬁed: 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.

290

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

Algorithm pat(E) 𝑖 ← 0; 𝒦 ← uKeys(𝐸); 𝑛 ←∣ 𝒦 ∣; 𝐸𝑖 ← 𝐸 while 𝒦 ∕= ∅ do select an element 𝐾 maximal in 𝒦 with respect to ≺𝐸 s s 𝐸𝑖+1 ← 𝐸𝑖 [{∣ ∣}𝐾 → {∣□∣}𝐾 ] 𝒦 ← 𝒦 ∖ {𝐾} 𝑖←𝑖+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}s cryption key are linearly dependent, as for example in g𝑋1 , g𝑋1 +𝑋2 ℎ(g𝑋2 ) . It can be easily shown that the occurrence of such a ciphertext can reveal the encryption key without contradicting the security of the encryption scheme. This condition can be further relaxed 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 Deﬁnition 7 only for simplicity. For acyclic expressions we give in Figure 3 an algorithmic procedure for computing 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 algorithm works as follows. It selects an arbitrary unrecoverable key that does not occur encrypted 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 s s an encryption {∣𝑡∣}𝐾 with {∣□∣}𝐾 . 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. T ERMS AS DISTRIBUTIONS . Computationally, each element of Msg (and more generally, any pattern) is interpreted as a distribution. For example, elements of SKeys represent (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𝑋1 𝑋2 ) represents the distribution of keys obtained by applying a key derivation function to the group element 𝔤𝑥1 𝑥2 for rans dom 𝑥1 and 𝑥2 . A slightly more complex example is the expression: (g𝑥 , g𝑦 , {∣𝐾∣}ℎ(g𝑥𝑦 ) ) that represents the distribution of a conversation between two parties that ﬁrst exchange a Difﬁe-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

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

291

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 ⟩ 𝑝(𝑋1 ,𝑋2 ,...,𝑋𝑛 ) 𝑝(𝜏 (𝑋1 ),𝜏 (𝑋2 ),...,𝜏 (𝑋𝑛 )) then 𝑒 ← 𝔤 If 𝐸 = g $ $ s If 𝐸 = {∣𝐸1 ∣}𝐾 then 𝑚 ← Gen(𝐸1 , 𝜏 ); 𝑒 ← ℰ(𝜏 (𝐾), 𝑚) $ $ s If 𝐸 = {∣𝐸1 ∣}ℎ(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 randomized 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 associated 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 unspeciﬁed, and 𝑒1 and 𝑒2 are sampled according to 𝐸1 and 𝐸2 , respecs tively. Similarly, expression {∣𝐸1 ∣}𝐾 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. Speciﬁcally, 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

292

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

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 simplicity – a similar result can be obtained for IND-CPA security, by reﬁning the pattern deﬁnition [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 difﬁcult. 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 difﬁculty. Deﬁnition 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 signiﬁcant 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 execution of the algorithm. The expressions are such that 𝐸0 = 𝐸 and 𝐸𝑛 = pattern(𝐸). First, notice that it is sufﬁcient 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𝑖 𝑡𝑖 .

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

293

To see this, consider an adversary 𝒜 that runs in time 𝑡. Then, we have that: [ ] [ ] $ $ Pr 𝑥 ← 𝐷𝑛 : 𝒜(𝑥) = 1 − Pr 𝑥 ← 𝐷0 : 𝒜(𝑥) = 1 ≤ ≤

𝑛 [ ] [ ] ∑ $ $ Pr 𝑥 ← 𝐷𝑖 : 𝒜(𝑥) = 1 − Pr 𝑥 ← 𝐷𝑖−1 : 𝒜(𝑥) = 1 𝑖=1

≤ 𝑛 ⋅ max 𝜖𝑖 𝑖

where the ﬁrst inequality follows by triangle inequality and the last one from the assumption on the distributions. Let 𝐸0 , 𝐸1 , . . . , 𝐸𝑛 be the sequence of expressions computed by the algorithm. Recall that 𝐸𝑖+1 = 𝐸𝑖 [{∣ ∣}s𝐾 → {∣□∣}s𝐾 ] for some 𝐾 ∈ Keys. We show that this transformation does not signiﬁcantly 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. s s To argue that distributions of [ 𝐸]] and [ 𝐸[{∣ ∣}𝐾 → {∣□∣}𝐾 ]]] are close we differentiate between the case when 𝐾 is in SKeys and when 𝐾 is in ℎ(gPoly ). 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 signiﬁcantly. 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 (𝜖𝔾 , 𝑡𝔾 )-difﬁcult in 𝔾 then: s

s

[ 𝐸]] ≈𝜖,𝑡 [ 𝐸[{∣ ∣}ℎ(g𝑝0 ) → {∣ ∣}𝐾0 ]]] for 𝜖 = 𝜖𝔾 and 𝑡 = 𝑡𝔾 − 𝑡𝑠𝑖𝑚𝒞 , for some constant 𝑡𝑠𝑖𝑚𝒞 . We now explain how to use the previous two lemmas to conclude that the distance s s between distributions 𝐸𝑖 and 𝐸𝑖+1 is small. If 𝐸𝑖+1 = 𝐸𝑖 [{∣ ∣}𝐾 → {∣□∣}𝐾 ] and 𝐾 ∈ SKeys it follows by Lemma 3 that: [ 𝐸𝑖 ] Π,𝔾 ≈𝜖Π ,(𝑡Π −𝑡𝑠𝑖𝑚ℬ ) [ 𝐸𝑖+1 ] Π,𝔾

(1)

294

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys s

s

The case when 𝐸𝑖+1 = 𝐸𝑖 [{∣ ∣}ℎ(g𝑝 ) → {∣□∣}ℎ(g𝑝 ) ] is slightly more complex, as it is not directly covered by the above lemmas. Nevertheless, we can use the transformations in the lemmas to "emulate" the transformation above. Speciﬁcally, to simus s late the result of the transformation {∣ ∣}ℎ(g𝑝 ) → {∣□∣}ℎ(g𝑝 ) on an expression one can s s apply, sequentially, the following three transformations: {∣ ∣}ℎ(g𝑝 ) → {∣ ∣}𝐾0 where 𝐾0 ∈ SKeys is a key that does not occur in the expression, then the transformation s s s s {∣ ∣}𝐾0 → {∣□∣}𝐾0 , followed by the transformation {∣ ∣}𝐾0 → {∣ ∣}ℎ(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. s s s s Let 𝐸𝑖0 = 𝐸𝑖 , 𝐸𝑖1 = 𝐸𝑖 [{∣ ∣}ℎ(g𝑝0 ) → {∣ ∣}𝐾0 ], 𝐸𝑖2 = 𝐸𝑖1 [{∣ ∣}𝐾0 → {∣□∣}𝐾0 ], and 𝐸𝑖3 = 𝐸𝑖2 [{∣ ∣}s𝐾0 → {∣ ∣}sℎ(g𝑝0 ) ]. Notice that 𝐸𝑖3 = 𝐸𝑖+1 . Since each of the three transformations 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 ] s

s

The last result follows since 𝐸2𝑖 = 𝐸3𝑖 [{∣ ∣}𝐾0 → {∣ ∣}ℎ(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 Deﬁnition 8, the above problem is also (𝜖, 𝑡)-hard in 𝔾.

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

295

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 deﬁnition, the two expressions are equivalent if their patterns are related via bijective renamings of keys and nonces, and ldprenamings of polynomials, it is sufﬁcient to show that such renamings do not signiﬁcantly change the distribution associated to a pattern. Before we give the proof we introduce two useful lemmas. The ﬁrst lemma simpliﬁes 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 speciﬁcally, 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 access 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 coefﬁcients 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" oracle, 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 , . . . , 𝑝𝑡 }):

296

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

Adversary ℰ 𝒪1 ,𝒪2 (𝐸) $ 𝜏 ← Init(𝐸) For 𝑖 ∈ {1, 2, . . . , 𝑡} do $ set 𝜏 (g𝑝𝑖 ) ← 𝑂2 (𝑖) $ 𝑒 ← mGen𝒪1 ,𝒪2 (𝐸, 𝜏 ) Return 𝒟(𝑒) Algorithm mGen𝒪1 ,𝒪2 (𝐸, 𝜏 ) If 𝐸 ∈ SKeys ∪ Nonce ∪ {□} then 𝑒 ← 𝜏 (𝐸) $ $ If 𝐸 = (𝐸1 , 𝐸2 ) then 𝑒1 ← mGen(𝐸1 , 𝜏 ); 𝑒2 ← mGen(𝐸2 , 𝜏 ); 𝑒 ← ⟨𝑒1 , 𝑒2 ⟩ If 𝐸 = g𝑝(𝑋1 ,𝑋2 ,...,𝑋𝑛 ) then ∑𝑡 , 𝜆2 , . . . , 𝜆𝑡 such that 𝑝 = 𝑖=1 𝜆𝑖 ⋅ 𝑝𝑖 let 𝜆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 , . . . , 𝑝𝑡 })-DDH assumption. It uses procedure mGen which makes use of the oracle of ℰ.

(𝑃,𝑄)-DDH

Adv𝔾

] [ [ ] = 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 , . . . , 𝑝𝑡 })-DDH is (𝜖𝔾 , 𝑡𝔾 )⊔ ⊓ difﬁcult, 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 renamings of nonces and keys, as well as injective ldp renamings do not signiﬁcantly 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 𝜎2 𝜎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 associates distributions to bitstrings does not depend on the particular symbols used in

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

297

the expression. It is therefore sufﬁcient 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, 𝜎3−1 ; 𝜎 : 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 𝜎3−1 ; 𝜎 satisfy the conditions of the same lemma so we get that [ 𝐸𝜎3 ] Π,𝔾 ≈𝜖𝔾 ,𝑡𝔾 −𝑡𝑠𝑖𝑚ℰ [ 𝐸𝜎3−1 ; 𝜎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 𝜎1 𝜎2 𝜎3 ). Therefore we have the following sequence of equivalences: [ 𝐸2 ] ≈𝜖1 ,𝑡1 [ pattern(𝐸2 )]] ≈𝜖2 ,𝑡2 [ pattern(𝐸2 𝜎1 𝜎2 𝜎3 )]] = [ pattern(𝐸1 )]] ≈𝜖3 ,𝑡3 [ 𝐸1 ] . where the ﬁrst and last equivalences follow from Theorem 2, the second equivalence follows by Lemma 6, and the third equality from the assumptions that 𝐸1 and 𝐸2 are symbolically 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 expression: ( s s ) 𝐸(𝐹 ) = g𝑋1 , g𝑋2 , g𝑋3 , g𝑋1 𝑋2 , g𝑋1 𝑋3 , g𝑋2 𝑋3 , {∣𝐾∣}ℎ(g𝑋1 𝑋2 𝑋3 ) , {∣𝐹 ∣}𝐾 where 𝐹 is some arbitrary expression. Expression 𝐸 represents the transcript of the executions of the following (toy) protocol: three parties with secret keys 𝑋1 , 𝑋2 and 𝑋3 ﬁrst agree on a common secret key ℎ(g𝑋1 𝑋2 𝑋3 ) (by broadcasting the ﬁrst 6 messages in the expression). Then, one of the parties generates a new key 𝐾 which it broadcasts to the

298

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

other parties encrypted under ℎ(g𝑋1 𝑋2 𝑋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 sufﬁcient to show that the distributions associated to the expressions 𝐸(𝐹 ) and 𝐸(0) are indistinguishable. Although conceptually simple, a full cryptographic proof would require several reductions (to DDH and security of encryption), and most likely would involve at least one hybrid argument (for proving the security of encrypting 𝐾 under ℎ(𝑔 𝑋1 𝑋2 𝑋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. 3–22. [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. 16–29. [3] M. Backes, B. Pﬁtzmann, and M. Waidner. A composable cryptographic library with nested operations. In CCS 2003, pp. 220–230. [4] F. Bao, R. Deng, and H. Zhu. Variations of Difﬁe-Hellman problem. In ICICS 2003, pp. 301–312. [5] G. Barthe, B. Gregoire, R. Janvier, and S. Zanella Béquelin. A framework for language-based cryptography 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. 259–274. [7] M. Bellare and P. Rogaway. The game-playing technique and the security of triple encryption. in CRYPTO 2006, pp. 409–426. [8] M. Bellare, A. Desai, E. Jokipii, and Ph. Rogaway. A concrete security treatment of symmetric encryption: Analysis of the DES modes of operation. In FOCS 1997, pages 394–403. [9] M. Blum and S. Micali. How to generate cryptographically strong sequences of pseudo-random bits. SIAM J. of Computing, 13:850–864, 1984. [10] D. Boneh, X. Boyen, and E.-J. Goh. Hierarchical identity based encryption with constant size ciphertext. In EUROCRYPT 2005, pp. 440–456. [11] E. Bresson, O. Chevassut, and D. Pointcheval. Group Difﬁe-Hellman key exchange secure against dictionary attacks. In ASIACRYPT 2002, pp. 497–514. [12] E. Bresson, O. Chevassut, and D. Pointcheval. The group Difﬁe-Hellman problems. In SAC 2002, pp. 325–338. [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. 482–499. [14] M. Burmester and Y. Desmedt. A secure and efﬁcient conference key distribution system (extended abstract). In EUROCRYPT 1994, pp. 275–286. [15] B. Blanchet and D. Pointcheval. Automated security proofs with sequences of games. In CRYPTO 2006, pp. 537–554. [16] R. Canetti. Universally composable security: A new paradigm for cryptographic protocols. In FOCS 2001, pages 136–145. [17] R. Canetti. Towards realizing random oracles: Hash functions that hide all partial information. In CRYPTO 1997, pp. 455–469. [18] Y. Chevalier, R. Küsters, M. Rusinowitch, and M. Turuani. Deciding the Security of Protocols with Difﬁe-Hellman Exponentiation and Products in Exponents. In FSTTCS 2003, pp. 124–135. [19] D. Coppersmith and I. Shparlinski. On polynomial approximation of the discrete logarithm and the Difﬁe-Hellman mapping. J. of Cryptology, 13(2):339–360, 2000. [20] V. Cortier, S. Kremer and B. Warinschi. A Survey of Symbolic Methods in Computational Analysis of Cryptographic Systems. J. of Automated Reasoning.

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

299

[21] R. Cramer and V. Shoup. A practical public key cryptosystem provably secure against adaptive chosen ciphertext attack. In CRYPTO 1998, pp. 13–25. [22] D. Dolev and A. Yao. On the security of public key protocols. IEEE IT, 29(12):198–208, 1983. [23] T. ElGamal. A public key cryptosystem and a signature scheme based on discrete logarithm. IEEE IT, 31(4):469–472, 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. Difﬁe-Hellman oracles. In CRYPTO 1996, pp. 268–282. [27] D. Micciancio and S. Panjwani. Adaptive security of symbolic encryption. In TCC 2005, pp. 245–263. [28] D. Micciancio and B. Warinschi. Soundness of formal encryption in the presence of active adversaries. In TCC’04, pp. 133–151. [29] D. Micciancio and B. Warinschi. Completeness theorems for the Abadi-Rogaway logic of encrypted expressions. J. of Computer Security, 12(1):99–129, 2004. Preliminary version in WITS 2002. [30] J. Millen and V. Shmatikov. Symbolic protocol analysis with products and Difﬁe-Hellman exponentiation. In CSFW 2003, pp. 47–61. [31] M. Naor and O. Reingold. Number-theoretic constructions of efﬁcient pseudo-random functions. In FOCS 1997, pp. 458–467. [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):451–475, 2003. [33] A.-R. Sadeghi and M. Steiner. Assumptions related to discrete logarithms: Why subtleties make a real difference. In EUROCRYPT 2001, pp. 244–261. [34] V. Shoup. Lower bounds for discrete logarithms and related problems. In EUROCRYPT 1997, pp. 256–266. [35] V. Shoup. Sequences of games: a tool for taming complexity of security proofs. Cryptology ePrint Archive 2004/332. 2 [36] I. Shparlinski. Security of most signiﬁcant bits of 𝑔 𝑥 . IPL, 83(2):109–113, 2002. [37] M. Steiner, G. Tsudik, and M. Waidner. Difﬁe-Hellman key distribution extended to group communication. In ACM CCS 1996, pp. 31–37.

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 signiﬁcantly. 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. s s Given a distinguisher for distributions [ 𝐸]] and [ 𝐸[{∣ ∣}𝐾0 → {∣□∣}𝐾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 s s 𝑒 is sampled according to [ 𝐸[{∣ ∣}𝐾0 → {∣ ∣}𝐾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 modiﬁed generation algorithm mGen.) The sample 𝑒 that is

300

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

Algorithm mGen𝒪 (𝐸, 𝐾0 , 𝜏 ) If 𝐸 ∈ SKeys ∪ Nonce ∪ {□} then 𝑒 ← 𝜏 (𝐸) $ $ If 𝐸 = (𝐸1 , 𝐸2 ) then 𝑒1 ← Gen(𝐸1 , 𝜏 ); 𝑒2 ← Gen(𝐸2 , 𝜏 ); 𝑒 ← ⟨𝑒1 , 𝑒2 ⟩ 𝑝(𝑋1 ,𝑋2 ,...,𝑋𝑛 ) 𝑝(𝜏 (𝑋1 ),𝜏 (𝑋2 ),...,𝜏 (𝑋𝑛 )) If 𝐸 = g then 𝑒 ← 𝔤 $ $ s If 𝐸 = {∣𝐸1 ∣}𝐾 and 𝐾 ∕= 𝐾0 then 𝑚 ← Gen(𝐸1 , 𝜏 ); 𝑒 ← ℰ(𝜏 (𝐾), 𝑚); $ $ s If 𝐸 = {∣𝐸1 ∣}𝐾 and 𝐾 = 𝐾0 then 𝑚 ← Gen(𝐸1 , 𝜏 ); 𝑒 ← 𝒪(𝑚); $ s If 𝐸 = {∣𝐸1 ∣}ℎ(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 satisﬁes 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. s s This means that 𝑒 produced by mGen is sampled from 𝐸[{∣ ∣}𝐾0 → {∣□∣}𝐾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: ∗

-cpa (ℬ) = Advind Π [ ] [ ] = Pr ℬ ℰ𝑘 (⋅) = 1 − Pr ℬ ℰ𝑘 (0) = 1 [ ] [ ] $ $ s s ≥ Pr 𝑥 ← [ 𝐸]] : 𝒟(𝑥) = 1 − Pr 𝑥 ← [ 𝐸[{∣ ∣}𝐾0 → {∣□∣}𝐾0 ] : 𝒟(𝑥) = 1]] The right hand-side of the last inequality is exactly the advantage of 𝒟 in distinguishing s s distributions [ 𝐸]] and 𝐸[{∣ ∣}𝐾0 → {∣□∣}𝐾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 s [ 𝐸]] ≈𝑡,𝜖 [ 𝐸[{∣ ∣}𝐾0 → {∣□∣}𝐾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 signiﬁcantly changing the distribution of the expression. More precisely, we show how to turn a distinguisher 𝒟 between distributions [ 𝐸]] and [ 𝐸[{∣ ∣}sℎ(g𝑝0 ) →

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

301

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 𝐸 ∈ SKeys ∪ Nonce ∪ {□} then 𝑒 ← 𝜏 (𝐸) $ $ 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 polynomials 𝑝 ∈ 𝑃 , 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(𝐸) algorithm to obtain an interpretation for all of the symbols that occur in 𝐸 and then recursively 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 distributed according to [ 𝐸]]. In the fake game the value returned is 𝑔 𝑟 for a random exponent 𝑟. 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 s s key. It follows that in this case 𝑒 is distributed according to [ 𝐸[{∣ ∣}ℎ(g𝑝 ) → {∣ ∣}𝐾0 ]]] for some 𝐾0 that does not occur in 𝐸. We therefore have that: (𝑃,𝑄)-ddh Adv𝔾 (𝒞) = [ Real ] [ ] = Pr 𝒞 (𝑃,𝑄) = 1 − Pr 𝒞 Fake(𝑃,𝑄) = 1 [ ] [ ] $ $ = Pr 𝑒 ← [ 𝐸]] : 𝒟(𝑒) = 1 − Pr 𝑒 ← [ 𝐸[{∣ ∣}sℎ(g𝑝 ) → {∣ ∣}s𝐾0 ]]] : 𝒟(𝑒) = 1

302

E. Bresson et al. / Computational Soundness: The Case of Difﬁe-Hellman Keys

Notice that the last term is the advantage that 𝒟 has in distinguishing between distribus s tions [ 𝐸]] and [ 𝐸[{∣ ∣}ℎ(g𝑝 ) → {∣ ∣}𝐾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 𝑡 = 𝑡𝔾 − 𝑡𝑠𝑖𝑚𝒞 . ⊔ ⊓

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.

303

Author Index Blanchet, B. Bresson, E. Comon-Lundh, H. Cortier, V. Datta, A. Delaune, S. Focardi, R. Guttman, J.D. Kremer, S. Lakhnech, Y. Lowe, G. Maffei, M.

86 277 35 v, 1 182 35 143 222 v, 1 277 62 143

Mazaré, L. Millen, J.K. Mitchell, J.C. Roy, A. Rusinowitch, M. Ryan, M.D. Schneider, S. Smyth, B. Stiller, S.H. Turuani, M. Warinschi, B.

277 35 182 182 13 112 258 112 182 13 277