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 855 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 field of security protocols. Such protocols aim at securing communications over a public network. Small flaws 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 flaws 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 flaw 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 verification 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 finding bugs in protocols. Many errors have indeed been identified using formal methods, demonstrating their usefulness. At the end of the ’90s more foundational questions were investigated: the general undecidability results for automated verification of security protocols have been refined and decidable classes of protocols and restrictions yielding decidability were identified 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 finding flaws. When the focus shifted from finding flaws 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 difficulties of security protocol verification but also enabled the development of efficient 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 confidentiality. 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 benefits. There exist today many formalisms and approaches which have each their own benefits. The aim of this book is to give an overview of the state of the art of the field by showing some of the most influential developments in this field.

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 first 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, verifies 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


[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 first protocols that was discovered to be flawed 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 first message (due to the encryption of the first message with B’s public key). Similarly, freshness of the nonce N B should convince B that the third message originates from A.

4


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) , fixes the protocol. 2. Formal models One of the main advantages of formal methods is to provide a clear, well-defined 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


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 five 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 reflect 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 reflect 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, Diffie-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 unified model would enable better comparisons between each result but such a unified 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 fine grained and expressive as possible in order to better reflect protocol behaviors. One the other hand, models have to remain relatively simple in order to allow the design of (automatic) decision procedures.

6


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 verification. In this book most of these models will be described in more details. Early models. One of the first 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 reflect 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 first 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-


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 definition 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 definition 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 verification techniques have been developed for these two properties. Secrecy Secrecy is one of the most standard properties: a protocol ensures the confidentiality of some data s if this data is only known to participants which are entitled to access the data. It is usually specified using a reachablity-based property: a protocol is said to preserve the confidentiality 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 specified 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 specified as reachability properties, more complex properties such as privacy-like properties usually require the use of equivalence-based definitions. Strong secrecy, described above, is a first example of an equivalence-based definition. 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 definitions of anonymity have been proposed [Aba02,SH02,Low02]. In particular, the definition proposed by Shmatikov

8


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 specified 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 verification 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 first mean to recover decidability is to consider a bounded number of sessions, that is, to consider a limited (fixed in advance) number of executions of the protocol. The chapter “Verifying a bounded number of sessions and its complexity” presents one of the first 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 field of security protocol verification. 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 sufficient 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 specified 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 verification 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 verification


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 defined by Schneider and presented in the chapter “Security analysis using rank functions in CSP”. Formal models differ significantly from computational ones. In modern cryptography, security definitions 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 confidential information in reasonable (polynomial) time with non negligible probability. This notion of security seems to better reflect the class of attacks that can be mounted in practice. However, security proof are error-prone and difficult to automate. Computational and symbolic models have been developed separately since the 80s. They seem a priori very distinct and difficult 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 Diffie-Helman keys” illustrates this new line of research by presenting a soundness result between symbolic and cryptographic equivalences for Diffie-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 Verification (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 Verification, 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]


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 verification 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 verification 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 verification 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 efficient cryptographic protocol verifier 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 verifier based on resolution theorem proving (invited tutorial). In 20th International Conference on Automated Deduction (CADE-20), Tallinn, Estonia, July 2005. [Bla08] Bruno Blanchet. Vérification automatique de protocoles cryptographiques : modèle formel et modèle calculatoire. Automatic verification 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 first-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-


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: Verification, falsification, and analysis of security protocols. In Computer Aided Verification, 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 definition 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 fixing 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 specification. 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]


Catherine Meadows. Language generation and verification 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 diffie-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 finite 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. Defining 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 first-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.


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 finite number of sessions (fixed 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 fixed 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 verification 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 verification 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 flaw 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 finite 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 simplified. The main result of this chapter states that for a fixed 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 simplification rules to be applied to intruder constraints ([8]). Although this result is of a theoretical flavor, 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 flaw 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 flawed protocols can be attacked with small faked messages. Layout of the chapter: We first 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 finding 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 specified 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 modifications. 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 finite and denoted by 𝐴𝑡𝑜𝑚𝑠. It contains names for principals and atomic keys from the set 𝐾𝑒𝑦𝑠. Since we have a finite 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 modifies them and forwards them to the receiver under the identity of the official 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 defined 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 reflexive 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 infinitely many data only known to him with simple encryptions. For instance he can construct an infinite 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 first 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 𝜎 defined 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 specified 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 specification. A protocol is given with a finite 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 finite set (𝑊𝐴 , 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 definitions. The #System section defines 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 first uses of model checkers to analyse security protocols are due to Millen et al. [MCF87] and Meadows [Mea96]. Roscoe was the first 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 first 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


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 Diffie-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 find such attacks. The theory of data independence, as applied to CSP, was developed in [Laz99]. Roscoe first 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 Refinement—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.


[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ć. 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 fixing 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 specifications. 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 Verification 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


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 verifier ProVerif. It is fully automatic, efficient, and can handle an unbounded number of sessions and an unbounded message space. It supports various cryptographic primitives defined 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 verification, security protocols, Horn clauses, secrecy.

Introduction Security protocols can be verified 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 first 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 verifier 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 efficient 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 verifier does not find a flaw in the protocol, then there is no flaw. The verifier 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 efficient and precise. It can handle a wide variety of cryptographic primitives defined by rewrite rules or by equations, including shared-key and public-key cryptography (encryption and signatures), hash functions, and the Diffie-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 finite set remains and applies a decision procedure. ∙ Monniaux [80] introduced a verification 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 verifier (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-flow 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 first defined for secrecy for shared-key protocols, then extended to message authenticity and public-key protocols [37], with a polynomial complexity. ∙ Most protocol verifiers 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


𝑀, 𝑁 ::= 𝑥 𝑎[𝑀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 first verification 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 figure, 𝑥 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


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 identifier 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 identifiers 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 first 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 defined 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, defined 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 defined similarly: ∙ For signatures, we use a constructor sign and write sign(𝑚, sk ) for the message 𝑚 signed under the secret key sk . A destructor getmess defined 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, defined by sdecrypt(sencrypt(𝑚, 𝑘), 𝑘) → 𝑚. ∙ A one-way hash function is represented by a constructor ℎ (and no destructor).

90


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


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 first 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 first 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 sufficient 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 defined 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 fifth message for instance can contain elements received in the first message. The hypotheses summarize the history of the exchanged messages.

92


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.


93

1.5. Approximations The reader can notice that our representation of protocols is approximate. Specifically, 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 first 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 efficient verifier, which will be able to handle larger and more complex protocols. Another advantage is that the verifier 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 verifier: 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 first 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 flows

94


or flows 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 first 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 first message pencrypt(sign(𝑘, sk 𝐴 [ ]), pk(𝑎[ ])), decrypts it, reencrypts it under pk(sk 𝐵 [ ]), and sends it to 𝐵. For 𝐵, this message looks like the first message of a session between 𝐴 and 𝐵, so 𝐵 replies with sencrypt(s, 𝑘), which the attacker can decrypt since it obtains 𝑘 from the first message. Hence, the obtained derivation corresponds to the known attack against this protocol. fix the protocol by adding the { In contrast, if}we a public key of 𝐵 in the first message [⟨pk 𝐵 , 𝑘⟩]sk 𝐴 pk , attacker(s) is not derivable 𝐵 from the clauses, so the fixed protocol preserves the secrecy of s. Next, we formally define 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. Definition 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 defined as follows, as illustrated in Figure 3. Definition 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 finite tree defined 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.


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 verifier 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 first define resolution: when the conclusion of a clause 𝑅 unifies 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 defined as follows:

96


Definition 3 Let 𝑅 and 𝑅′ be two clauses, 𝑅 = 𝐻 ⇒ 𝐶, and 𝑅′ = 𝐻 ′ ⇒ 𝐶 ′ . Assume that there exists 𝐹0 ∈ 𝐻 ′ such that 𝐶 and 𝐹0 are unifiable and 𝜎 is the most general unifier of 𝐶 and 𝐹0 . In this case, we define 𝑅 ∘𝐹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: Definition 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 unified in the resolution are selected. We will therefore choose the selection function to reduce the number of possible unifications 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 unified will all facts of the form attacker(𝑀 ). Therefore, we should avoid selecting them. So a basic selection function is a function sel 0 that satisfies 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 first phase transforms the initial set of clauses into a new one that derives the same facts. The second phase uses a depth-first search to determine whether a fact can be derived or not from the clauses. The first phase, saturate(ℛ0 ), contains 3 steps. ∙ The first 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 fixpoint 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):


97

First phase: saturation saturate(ℛ0 ) = 1. ℛ ← ∅. For each 𝑅 ∈ ℛ0 , ℛ ← elim({𝑅} ∪ ℛ). 2. Repeat until a fixpoint is reached for each 𝑅 ∈ ℛ such that sel (𝑅) = ∅, for each 𝑅′ ∈ ℛ, for each 𝐹0 ∈ sel (𝑅′ ) such that 𝑅 ∘𝐹0 𝑅′ is defined, ℛ ← elim({𝑅 ∘𝐹0 𝑅′ } ∪ ℛ). 3. Return {𝑅 ∈ ℛ ∣ sel (𝑅) = ∅}. Second phase: backward depth-first search ⎧ ∅ if ∃𝑅′ ∈ ℛ, 𝑅′ ⊒ 𝑅    ⎨{𝑅} otherwise, if sel (𝑅) = ∅ deriv(𝑅, ℛ, ℛ1 ) = ∪ ′ ′  {deriv(𝑅 ∘ 𝑅, {𝑅} ∪ ℛ, ℛ ) ∣ 𝑅 ∈ ℛ1 , 𝐹0 1   ⎩ ′ 𝐹0 ∈ sel (𝑅) such that 𝑅 ∘𝐹0 𝑅 is defined } 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-first 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


an element 𝐹0 of the hypothesis of 𝑅. So 𝑅 is replaced with 𝑅′ ∘𝐹0 𝑅 (third case of the definition of deriv). The fact 𝐹0 is chosen using the selection function sel . (Hence deriv derives the hypothesis of 𝑅 using a backward depth-first 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 definition of deriv. The transformation of 𝑅 described above is repeated until one of the following two conditions is satisfied: ∙ 𝑅 is subsumed by a clause in ℛ: we are in a cycle; we are looking for instances of facts that we have already looked for (first case of the definition of deriv); ∙ sel (𝑅) is empty: we have obtained a suitable clause 𝑅 and we return it (second case of the definition 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 satisfies (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 first 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 satisfies (3) and 𝐹 is closed, then 𝐹 is derivable from ℛ0 if and only if derivable(𝐹, saturate(ℛ0 )) ∕= ∅. Proof: The first part of the theorem is obvious from Lemmas 1 and 2. The first particular case is also an obvious consequence. For the second particular case, if 𝐹 is derivable from ℛ0 , then derivable(𝐹, saturate(ℛ0 )) ∕= ∅ by the first particular case. For the converse, suppose that derivable(𝐹, saturate(ℛ0 )) ∕= ∅. Then derivable(𝐹, saturate(ℛ0 )) contains a clause 𝐻 ⇒ 𝐶. By definition of derivable, 𝐶 is an instance of 𝐹 , so 𝐶 = 𝐹 , and sel (𝐻 ⇒ 𝐶) = ∅, so all elements of 𝐻 are of the form attacker(𝑥𝑖 ) for some variable


𝐶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 first need to prove a few preliminary lemmas. The first 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 defined, 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 unifiable, so 𝑅 ∘𝐹0 𝑅′ is defined. Let 𝜎 ′ be the most general unifier 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


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, ℛ satisfies 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 defined. In this case, 𝑅 ∘𝐹0 𝑅′ is subsumed by a clause in ℛ. Proof: To prove the first property, let 𝑅 ∈ ℛ0 . We show that, after the addition of 𝑅 to ℛ, 𝑅 is subsumed by a clause in ℛ. In the first 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 first property. In order to prove the second property, we just need to notice that the fixpoint 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 defined, 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 𝜂 ′′ .


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 𝐷′ satisfies 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 definition 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 satisfies 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 defined 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 definition 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 definition of deriv(𝑅1 , ℛ′ , ℛ1 ) has been applied, and not the first 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 find a derivation in 𝒟 that has fewer nodes than 𝐷1 . This is a contradiction, so sel (𝑅′ ) = ∅, hence deriv(𝑅′ , ℛ, ℛ1 ) = {𝑅′ } (second case of the definition of deriv), so 𝑅′ ∈ derivable(𝐹, ℛ1 ). The other clauses of this derivation are in ℛ1 . By definition 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


2.3. Optimizations The resolution algorithm uses several optimizations, in order to speed up resolution. The first two are standard, while the last three are specific 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 satisfied for some value of 𝑥. Decomposition of data constructors A data constructor is a constructor 𝑓 of arity 𝑛 that comes with associated destructors 𝑔𝑖 for 𝑖 ∈ {1, . . . , 𝑛} defined 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 verifier. (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 verifier 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].


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-flaw 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, efficient in practice, but approximate. Arapinis and Duflot [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 defined cryptographic primitives by associating rewrite rules to destructors. Another way of defining primitives is by equational theories, as in the applied

104


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 DiffieHellman key agreements. The Diffie-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 verification approach can be extended to handle some equational theories. For example, the Diffie-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 satisfied. 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 Diffie-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 definition 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 definition 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 first 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 unification, so it remains efficient. However, it also has limitations; for example, it cannot handle associative functions, such as XOR, because it would generate an infinite number of rewrite rules for the destructors. Recently, other treatments of equations that can handle XOR and Diffie-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 Diffie-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


105

of sessions, and to [76,45,65,78] for other treatments of Diffie-Hellman key agreements, using unification 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 specification 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 specifications, 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 specification. 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 verifier 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: flawed 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 flawed versions of the Woo-Lam shared-key protocol. The other protocols were verified in less than one second each on a Pentium M 1.8 GHz [30].

106


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 verification of a certified 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 filesystem Plutus [67] with ProVerif, which allowed us to discover and fix 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 verification 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 verified using correspondences, while secrecy of keys corresponds to strong secrecy. ∙ ProVerif was also used for verifying a certified email web service [74], a certified 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.


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 certification 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 verification 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 efficient 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 verification of a protocol for certified 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. Certified 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. Duflot. 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]


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 verification 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 verification 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 file 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 verified 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. Verified 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. Verified 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. Verified 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 efficient cryptographic protocol verifier 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 verification of correspondences for security protocols. Report arXiv:0802.3444v1, 2008. Available at http://arxiv.org/abs/0802.3444v1. B. Blanchet. Vérification 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 verification of correspondences for security protocols. Journal of Computer Security, 17(4):363–434, July 2009. B. Blanchet, M. Abadi, and C. Fournet. Automated verification 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 file sharing on untrusted storage. In IEEE Symposium on Security and Privacy, pages 417–431. IEEE, May 2008. B. Blanchet and A. Podelski. Verification 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 flow analysis for the 𝜋-calculus. In International Conference on Concurrency Theory (CONCUR’98), volume 1466 of LNCS, pages 84–98.


[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 verification. In 9th International Conference on Computer Aided Verification (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 Diffie-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 first-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 sufficient. 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 Refinements of Resolution. PhD thesis, Technische Universiteit Delft, Oct. 1995. G. Denker, J. Meseguer, and C. Talcott. Protocol specification 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. Diffie 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 definite 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 verification. In 17th International Conference on Automated Deduction (CADE-17), volume 1831 of LNCS, pages 271–290. Springer, June 2000. J. C. Godskesen. Formal verification 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]


J. Goubault-Larrecq. A method for automatic cryptographic protocol verification (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 Verification, 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 Diffie-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 flaw 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 file 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. Certified 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 Diffie-Hellman exponentiation. In 22nd IEEE Computer Security Foundations Symposium (CSF’09), pages 157–171. IEEE, July 2009. G. Lowe. Breaking and fixing 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 unification algorithm for the group Diffie-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 DiffieHellman 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. Efficient 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


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 first-order logic. In 16th International Conference on Automated Deduction (CADE-16), volume 1632 of Lecture Notes in Artificial 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 Scofflaws, pages 319–355. ACM Press and Addison-Wesley, Oct. 1997.

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 verification, 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: ∙ Certified email [4]; ∙ Privacy properties [38,34,12,40], and election-verifiability 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 file 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 𝑠𝑘𝒞 , verifies 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 specification 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 first message. With this correction, ℳ is not able to re-use the signed key from 𝒮 in his session with 𝒞.

114


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 specifically 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 fixed 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 defined by means of an equational theory. 2.1. Syntax and informal semantics The calculus assumes an infinite set of names, an infinite set of variables and a signature Σ consisting of a finite 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.


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 infinite 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


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 infinite 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 defined 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 confirmed [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 define 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


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 defined 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(𝑥, 𝑧), 𝑦)⟩) ∣ (𝜈 𝑠.{𝑠/𝑥}) ∣ {ℎ(𝑥, 𝑠′ )/𝑧 }) defined 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 identifiers 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 defined 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


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 defined for fst, snd. The Handshake protocol can now be captured in our calculus as the process 𝑃 , defined 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 first 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.


119

Figure 1. Properties of equality modulo the equational theory Given an equational theory 𝐸 the following properties are satisfied for all terms 𝐿, 𝑀, 𝑁 , functions 𝑓 of arity 𝑙, substitutions 𝜎 and names 𝑚, 𝑛: 1. 𝑀 = 𝑁 ∈ 𝐸 ⇒ 𝑀 =𝐸 𝑁 2. Equivalence relation: ∙ Reflexivity: 𝑀 =𝐸 𝑀 ∙ 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 verifies 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 confirms 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 defined 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 defined over the signature Σ (sometimes written 𝑀, 𝑁 ∈ 𝑇Σ ). This allows us to capture relationships between primitives defined in Σ. We define 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


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 define context 𝐶[ ] to be an extended process with a hole. We obtain 𝐶[𝐴] as the result of filling 𝐶[ ]’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 final rule, R EWRITE, allows terms that are equal modulo the equational theory to be swapped as desired.


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 flow 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 defined 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, quantification over all contexts is typically required, which can be difficult in practice. The labelled operational semantics we now present aim to eliminate universal quantification of the context. 𝛼 → 𝐵, where 𝛼 is a label The labelled semantics defines 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


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


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 first 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 find 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


𝜈 𝑠.(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 𝑠 first: 𝐴 ≡ 𝜈 𝑠′ .(𝑐(𝑥).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 definitions 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. Definition 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 “!”. Definition 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 Definition 2, the process 𝐶[𝑐⟨𝑀 ⟩.𝑅] is capable of outputting the term 𝑀 on the free channel 𝑐 in one further step. Note that the definition 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 𝑠.


125

Definition 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 definition 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 definition 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


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 figure 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 sufficient 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 {𝑀 /𝑒}. Definition 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


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 defined 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 define the validity of a correspondence property in Definition 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 defined by 𝑀, 𝑁 ; that is, the variables fv(𝑀 ) ∩ fv(𝑁 ) must be parametrised in the same way.

128


Definition 5 (Validity of correspondence property) Let 𝐸 be an equational theory, and 𝐴0 an extended process. We say that 𝐴0 satisfies 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 first 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 figures): 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 Definition 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 definition of correspondence we have just discussed is insufficient to capture injective relationships between events; making it unsuitable for certain authentication properties. For example, consider a financial 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].


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 satisfies 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. Definition 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 satisfied. 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


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

Definition 7 (Validity of injective correspondence property) Let 𝐸 be an equational theory, and 𝐴0 an extended process. We say that 𝐴0 satisfies 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 satisfied: (1) ℎ(𝑖) is defined; (2) 𝛼ℎ(𝑖) = 𝜈 𝑒′ .𝑔⟨𝑒′ ⟩ for some 𝑒′ such that 𝑒′ 𝜑(𝐴ℎ(𝑖) ) =𝐸 𝑁 𝜎; and, (3) ℎ(𝑖) < 𝑖.


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 define strong notions of secrecy and privacy. A natural starting point for defining 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 definition motivated above is hard to compute, and instead a stronger definition is often used. The stronger definition, 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 define it rigorously as follows.

132


Definition 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 defined 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 quantification over contexts makes the definition 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 define first. Intuitively, two frames are statically equivalent if no ‘test’ 𝑀 = 𝑁 can tell them apart, where 𝑀 and 𝑁 have variables that are substituted from the frame. Formally: Definition 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, 𝜑(𝐴) ≈𝑠 𝜑(𝐵).


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 first one satisfies 𝑥 = 𝑚 but the second one does ∙ {𝑚/𝑥} ≈ not. ∙ 𝜈 𝑘.{𝑘/𝑥} ∣ 𝜈 𝑠.{𝑠/𝑦 } ≈𝑠 𝜈 𝑘.({hash(pair(𝑎, 𝑘))/𝑥} ∣ {hash(pair(𝑏, 𝑘))/𝑦 }. ∙ 𝜈 𝑘.{𝑘/𝑥} ∣ 𝜈 𝑠.{𝑠/𝑦} ∕≈𝑠 𝜈 𝑘.({𝑘/𝑥} ∣ {hash(𝑘)/𝑦 }), since the second one satisfies hash(𝑥) = 𝑦 and the first one does not. ∙ 𝜈 𝑠.{pair(𝑠, 𝑠)/𝑥} ∕≈𝑠 𝜈 𝑠.{𝑠/𝑥}, since the first one satisfies pair(fst(𝑥), snd(𝑥)) = 𝑥 but the second one does not. As mentioned, static equivalence captures the static part of observational equivalence. The following definition of labelled bisimilarity captures the dynamic part. Definition 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 definition 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 defined 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


𝑏 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 find a symmetric relation ℛ that satisfies the conditions contained in Definition 10, such that 𝐴 ℛ 𝐵. Note that the ℛ we find is not required to be the largest one. That is because the set of relations that satisfies the conditions contained in Definition 10 is closed under union. Therefore, the largest one is the union of them all. Any relation satisfying the conditions of Definition 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 ℛ satisfies the conditions contained in Definition 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 𝐵 − → 𝐵′.


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 definition 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 finds 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 definitions [14,32]. Definition 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 definition 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 definition can be extended to the more general case.

136


Definition 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 defined 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].


137

4.4. Vote privacy for electronic voting Electronic voting systems are being introduced, or trialled, in several countries to provide more efficient 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 officers) can link a particular vote with the voter. Consider the following protocol, which is a simplification 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 defined 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 officer can sign a text without having seen it. The voter first blinds the text and the officer signs it. The voter can then unblind the message to recover the officer’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 officer 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 defined 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 officer. The officer checks the voter’s eligibility and also checks she has not already voted. If these checks succeed, then the officer signs the blinded vote-nonce pair and sends it back to the voter. The voter can now unblind the signature, recovering the officer’s signature on the vote-nonce pair. Once all voters have obtained the officer’s signature in this way, they can anonymously submit the signed vote-nonce pair for counting. The protocol thus proceeds as follows: Voter

Officer sign(𝑠𝑘𝑉 , blind(𝑟, pair(𝑣, 𝑛)))

⊲

⊳

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

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

⊳

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

138


𝑃 ≜ 𝜈 𝑠𝑘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 officer. 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 defining 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 define the property of vote privacy. Since it should hold even if the officer is corrupt, we can suppose that the officer is part of the attacker, and we need not consider its formalisation as 𝑃𝑂 above. This means the secrecy of the officer’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 officers) 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:


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 Definition 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 briefly 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âc˘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


cally, it avoids potentially infinite 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 finite 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épartement d’Informatique, Ecole Normale Supérieure, Paris, France with support from the Direction Générale 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üggen, 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 Verification of a Protocol for Certified Email. Science of Computer Programming, 58(1–2):3–27, 2005. Special issue SAS’03. Mart´ın Abadi, Bruno Blanchet, and Cédric 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éronique 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éronique Cortier. Deciding knowledge in security protocols under equational theories. Theoretical Computer Science, 367(1–2):2–32, 2006. Mart´ın Abadi and Cédric 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édric 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 Verification 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 Verification 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.


[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éronique Cortier, and Stéphanie 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örn 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. Verified Interoperable Implementations of Security Protocols. In CSFW’06: IEEE Computer Security Foundations Workshop, pages 139–152. IEEE Computer Society, 2006. Bruno Blanchet. An efficient cryptographic protocol verifier 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 Verification of Correspondences for Security Protocols. Journal of Computer Security, 17(4):363–434, 2009. Bruno Blanchet, Mart´ın Abadi, and Cédric Fournet. Automated verification 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édric Fournet. Automated Verification 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 Verifier User Manual & Tutorial. Available from http://www.proverif.ens.fr/, 2010. Liqun Chen and Mark D. Ryan. Offline 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 verification for shared authorisation data in TCG TPM. In FAST’09: 6th Formal Aspects in Security and Trust, LNCS. Springer, 2009. S¸tefan Ciobâc˘a, Stéphanie 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 Artificial Intelligence, pages 355–370. Springer, 2009. Véronique Cortier and Stéphanie Delaune. A method for proving observational equivalence. In CSF’09: 22nd IEEE Computer Security Foundations Symposium, pages 266–276. IEEE Computer Society, 2009. Véronique Cortier, Michaël Rusinowitch, and Eugen Zˇalinescu. Relating two standard notions of secrecy. Logical Methods in Computer Science, 3(3), 2007. Morten Dahl, Stéphanie 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éphanie 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éphanie Delaune, Steve Kremer, and Mark D. Ryan. Symbolic bisimulation for the applied pi calculus. Journal of Computer Security, 2009. Stéphanie Delaune, Steve Kremer, and Mark D. Ryan. Verifying Privacy-type Properties of Electronic Voting Protocols. Journal of Computer Security, 2009. Stéphanie Delaune, Mark D. Ryan, and Ben Smyth. Automatic verification 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]


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 verifiability 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üsters 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 specifications. 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 Verified 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 verification 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 Specification version 1.2. Parts 1–3., 2007. Available from http: //www.trustedcomputinggroup.org/specs/TPM/.


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 significantly simplified.

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 flow analysis [33,12] aim at defining 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 efficient analyses which can certify the correctness of a protocol with respect to some target (security) property P: if the abstraction satisfies 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 flaws 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 specifications by making explicit the underlying security mechanisms. A toy example. We consider Confidentiality, 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

fidentiality might be to impose that high-confidential (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 find 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 confidentiality. A more appropriate way to find 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-


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 confidentiality 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 confidentiality 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 ℓ specifies 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


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 refinement 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 verification 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 verification 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 refined the expressivity of the type system to reason about protocols based on zero-knowledge proofs [9]. Even if security protocols are properly designed, security flaws 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 refinement 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 define the syntax of a large fragment of F# by encoding. One important contribution of this work is the definition 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 verified by specific typing rules. They are instead defined by symbolic libraries based on sealing [32,36,35] and verified 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 confidentiality, integrity and authentication starting from pi-calculus processes, in which security is guaranteed via ideal (restricted) channels. This simplified 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


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

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 defined 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 final type-system is much simpler than the ones in literature (e.g., [15,23,24]). We feel that this is mainly due to the benefit 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 defining 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 confidentiality 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 significantly simplified 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


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 𝑃 ; finally, 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 defined 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 defined as the least relation satisfying the rules reported in the first 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 defined 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


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 confidentiality and integrity together (see, e.g., [34]). Usually, the security level is a pair ℓ𝐶 ℓ𝐼 specifying, separately, the confidentiality and integrity levels. We consider two possible levels: High (𝐻) and Low (𝐿). For example, 𝐻𝐻 denotes a high confidentiality and high integrity value, while 𝐿𝐻 a public (low confidentiality) and high integrity one. Intuitively, high confidentiality values should never be read by opponents while high integrity values should not be modified by opponents, i.e., when we receive high integrity data we expect they originated at some trusted source. An important difference between confidentiality 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 confidentiality 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 specified security level. Opponents. Processes representing opponents are characterized by type/level 𝐿𝐿 meaning that they can read from 𝐿𝐿 and 𝐿𝐻 while they can modify 𝐿𝐿 and 𝐻𝐿, reflecting the intuition that information may only flow up in the lattice. In particular, opponents can only generate names of type 𝐿𝐿, as formalized below: Definition 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 confidentiality 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 confidentiality and integrity levels ℓ𝐶 and ℓ𝐼 . Similarly, given a mapping Γ from terms to types, we denote with ℒΓ (𝑀 ) the level in Γ of a certain term 𝑀 formally defined as:

150


{ ℒΓ (𝑀 ) =

ℒ(Γ(𝑀 )) 𝐿𝐿

whenever 𝑀 ∈ dom(Γ) otherwise

As above, ℒC,Γ (𝑀 ) and ℒI,Γ (𝑀 ) respectively denote the confidentiality 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 definition of secrecy is in the style of [2]. A process 𝑃 preserves the secrecy of a high confidentiality 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 definition for channels of arity 1 (the extension to arity 𝑛 is immediate). Definition 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 confidentiality 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 definition 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 definition follows:


E MPTY ∅⊢⋄

E NV

Γ⊢⋄

𝑀 ∈ / dom(Γ)

151

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

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

Definition 3 (Integrity) 𝑃 preserves integrity if, for all opponents 𝑂, whenever 𝑃 ∣ 𝑂 →∗ (𝜈𝑏 : CHH [𝑇 ′ ]) (𝜈˜ 𝑎 : 𝑇˜) (𝑃 ′ ∣ 𝑏⟨𝑑⟩.𝑃 ′′ ) we have ℒI,Γ (𝑑) ⊑𝐼 ℒI (𝑇 ′ ), with HH ′ ˜ Γ = b : C [T ], ã : 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 defined 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 𝑇 ≤ 𝑇 ′ specifies when a value of type 𝑇 can be used in place of a value of type 𝑇 ′ , thus making the type system more permissive. Formally, ≤ is defined as the least preorder such that:

152


ATOM Γ⊢⋄

𝑀 : 𝑇 in Γ

Γ⊢𝑀 :𝑇

S UBSUMPTION Γ ⊢ 𝑀 : 𝑇′

𝑇′ ≤ 𝑇

Γ⊢𝑀 :𝑇

Table 4. Core calculus: typing of terms.

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

(2)

The first 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 specified 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


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


𝑐 : 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 confidentiality 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


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


𝑃, 𝑄, 𝑅, 𝑂 ::=

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

˜ ]𝐾 [𝑀

encryption key verification 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 finally 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 finally 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 finally 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′ ],ã:T˜ (𝑐) = ℒI (𝑇 ′′ ) we get the thesis. ⊔ ⊓


𝐾+

𝐾−

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 verification 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 verification 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/verification counterparts, as specified 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 first 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


The initiator 𝐵 generates a fresh session key 𝑘, signs 𝐴 and 𝐵’s identifiers 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 verifies the enclosed signature, checks that the first signed message is her own identifier, 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 verification 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) verification key vk(𝑘𝐵 ) is VerKLH [LL, LL, 𝑇𝑘 ], since this trusted, i.e., high integrity, key-pair is used to sign two LL identifiers 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 confidentiality, 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 definition 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 highconfidentiality 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 definition of ℒI,Γ (𝑀 ) as


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 definition, which extends Definition 3 (Integrity) so to deal with cryptographic operations. Definition 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 definition 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 definition 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 refined to also reason about integrity properties. Subtyping and Environment. Subtyping for keys is similar to the one for channels. Formally, the subtyping relation is defined as the least preorder such that: . . . as in Equation 2 LL ≤ 𝜇KLL [LL, . . . , LL] 𝜇Kℓ [𝑇˜] ≤ ℓ

(5)

160


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 defined 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 verification 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, reflecting 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 confidentiality 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 verification 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 confidentiality level is 𝐿. Their integrity level, ˜ is required to be the instead, is the one of the key. The type of encrypted messages 𝑀 one specified 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 confidentiality level is the ˜ : these messages can be maximum of the confidentiality levels of the signed messages 𝑀 reconstructed from a signature using the public verification key, thus it is important to keep track of the confidentiality level of what is signed.


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/verification 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 verification keys is unique if we fix the level to be 𝐿𝐻. In fact, being them public, they can also be typed at level 𝐿𝐿, reflecting their asymmetric nature. Since the latter property is not used in the proofs, we just state the former.

162


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 confidentiality level is greater than or equal to the maximum confidentiality 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 finally 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 specified 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 verification) 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 first 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 specified in the key type and therefore we can simply type-check the continuation process under this typing assumption. This shows how combining integrity and confidentiality 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


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 verification of a signature. The condition ℒC (𝑇 ) = 𝐻 ⇒ ℓ𝐼 = 𝐻 is crucial for the soundness of our type system that combines confidentiality and integrity, since it avoids that processes use 𝐿𝐿 keys to verify a signature that transports high confidentiality 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 fit 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 suffices 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 finally typed by S TOP.

164


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 confidentiality 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 specified in the type of 𝑘𝐵 . The equality test is typed by C OND and the generation of message 𝑚 by R ES. We finally 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 specified 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 confidentiality 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 verification type 𝐿𝐻, as specified in the vk(𝑘𝐴 ) type VerK𝐿𝐻 [𝐿𝐻]. This allows us to give to decrypted message 𝑚 type HH , as specified 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


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 suffices 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 ′ first 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 identifier. Let the two nonces 𝑛𝐴 , 𝑛𝐵 be given type 𝐻𝐻 and 𝐴’s identifier 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


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,


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 defined 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 finally 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 first 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 finally 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) finally gives ℒI,Γ′′ (𝑀 ) ⊑𝐼 ℒI (𝑇 ).

168


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 verifier. 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 definitions proposed by Gavin Lowe in [28], namely agreement. Intuitively, “a protocol guarantees to a verifier 𝐴 agreement with a claimant 𝐵 on a set of data items 𝑑𝑠 if, whenever 𝐴 (acting as verifier) 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 verifier 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 verifier 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 verifier to the claimant and the response sent by the claimant to the verifier. Both the challenge and the response contain a random value (called nonce) freshly generated by the verifier: 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𝑁 (𝑀


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: Definition 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𝑁 (𝑀 definition 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 refine 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. Definition 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. Definition 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 identifiers 𝐴 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 𝐴 confirms the reception of the identifiers 𝑥𝐴 , 𝑥𝐵 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


˜ ) ∣ 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 defined 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 justifies a begin (𝑀 ˜;𝑁 ˜) tion of nonce 𝑁 justifies fresh(𝑁 ) and Chal𝑁 (𝑀 𝑁 ˜ ˜ assertion, which in turn justifies 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 justified. The scope of 𝑥, 𝑥 ˜ is 𝐹 , where 𝑥 is a binder for the (symmetric, encryption, or verification) 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 justified, i.e., without providing any authentication guarantee.


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 confidentiality 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 identifiers 𝑧𝐴 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 confidential 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 verification 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 verification 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 first extend Proposition 6 (High Keys for ⊢𝒞 ) to dependent key types.

172


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 𝜇 = 𝜇′ .


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 justified 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 justified 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 (𝜈𝑎 : 𝑇 ) 𝑃 justifies the effects Chal𝑎 (𝑀 that the type system is not syntax-directed since A-R ES can add an arbitrary prefix 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 verification) case 𝑀 of ⟨˜ 𝑦 : 𝑇˜ ∣ 𝐹˜ ] justifies 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 verification 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


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, prefix of Γ′ . =Γ is the smallest equivalence relation on terms such that if 𝑁 = 𝑀 ∈ Γ then 𝑁 =Γ 𝑀. Table 14. Typing Rules for Processes.


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 specified 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


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 identifier in the correspondence assertions, since 𝐵’s identifier 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 identified 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 Γ, Γ′ {𝑀/𝑥} ⊢𝒜 𝒥 {𝑀/𝑥}.


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 finally 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 definition 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 finally get Γ ⊢𝒜 𝑃 ∣ (𝜈𝑎 : 𝑇 ) 𝑄. Conversely, Γ ⊢𝒜 𝑃 ∣ (𝜈𝑎 : 𝑇 ) 𝑄 can only be proved by A-PAR, which implies Γ∣𝐸𝑃 , (𝜈𝑎 : 𝑇 ) 𝑄 ⊢𝒜 𝑃 and Γ∣𝐸𝑄 , 𝑃 ⊢𝒜 (𝜈𝑎 : 𝑇 ) 𝑄, with 𝐸𝑃 ∪ 𝐸𝑄 = eff(Γ) and 𝐸𝑃 ∩ 𝐸𝑄 = {𝑓 ∈ eff(Γ) ∣ ∄𝑁.𝑓 = fresh(𝑁 )}.

178


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


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 finally 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]


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 flows. 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. Refinement 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 verification 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 flow 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 unified lattice model for static analysis of programs by construction or approximation of fixpoints. 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-flow 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 flows. In POPL’08, pages 337– 348. ACM Press, January 10-12 2008.


181

[28] G. Lowe. “A Hierarchy of Authentication Specifications”. 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 Specification, 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-flow 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


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 find bugs in a protocol design. After bugs found using model checking are eliminated, PCL can be used to find additional problems or prove that no further vulnerabilities exist. While model checking generally only analyzes protocol execution up to some finite 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 effect 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 effect, that if a principal creates a nonce (unguessable random number), and another principal receives a message containing it, then the first principal must have first 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 specified 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 specifically 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 identifies 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 certificates 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 simplified 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 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, different 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 different ways in different papers, as part of both a basic research project to find effective ways of proving properties of protocols, and as part of an ongoing effort to carry out case studies on practical protocols, each of which may require different cryptographic functions or make different infrastructure assumptions. Therefore, this chapter is intended to explain PCL, show how its syntax and semantics may be defined, 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 verification 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 first 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 first 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 definition, 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 different roles. Because each of the opera-


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 figure itself and what needs to be clarified 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 figure would be used for a protocol in which A and B both know k in advance and B only accepts the first 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 simplifies 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 specific 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 simplifies 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 confidentiality, 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 verification 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. Specifically, 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 first, second, and third components of the triple that is the message plaintext, and verifies the digital signature using the principal name A sent in the message. If the signature verifies, 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


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 defined, the first argument is treated as the principal who executes the role. The difference between the first parameter and the other parameters is that private keys associated with the first 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 definition 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 simplifications to define the same roles as Figure 2. Specifically, 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 identifiers are typed, and the type of locations is different 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 effect depends on the context: because A and B are previously defined, this example match is an assert about them, while because k is not previously defined, 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.


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 specifically, we define 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 effect 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 defined 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 different principal from B.

188


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 different 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 defined by a set of roles and setup assumptions. In Table 2, we define 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 defined 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 defined 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 five 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 verification keys. The technical machinery for restricting use of certain setup keys involves an additional type conf_key of confidential keys that cannot be released by honest principals, and confidential subtypes of each of the five key types. For example, the type conf_asym_dec_key of confidential asymmetric decryption keys is a subtype of both asym_dec_key and conf_key. Similarly, the type conf_sgn_key of confidential signing keys is a subtype of both sgn_key and conf_key. More generally, any confidential key type conf_xyz_key is a subtype of both the corresponding unrestricted key type xyz_key and conf_key.


189

The specific 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 specifications 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 find it convenient to make this assumption from the outset and eliminate the need to prove separately that the protocol preserves confidentiality 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 sufficient 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 specific logical systems, we discuss a specific framework briefly because it allows us to define 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 quantified formulas), finite lists, and finite 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


type ::= basic_type | type × . . . × type | type → type | List(type) | Setfin (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 finite lists and finite sets. Terms, also called “expressions”, are either basic constants (symbols chosen below for PCL), lambda expressions, function application, or additional forms for defining or using finite lists or finite sets. The logical framework we use has standard typing rules. For example, writing term : type to mean a term has a specific type, if f : type1 → type2 and x : type1 , then f x : type2 . A lambda expression λvar:typev . exp defines 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 quantification (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 flexibility, we use separate types for nonces (unguessable fresh values generated during protocol execution), and different 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 different 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 identifier. 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 different types of assertions about pro-


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 : Setfin (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 : Setfin (principal) × Setfin (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 Setfin (·). The binary infix constructors × and → create product types and functional mappings, respectively; the unary constructors List(·) and Setfin (·) create lists and finite sets, respectively. PCL also uses type abbreviations, presented in Table 2. These are non-constructive definitions, 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 reflexive, transitive, and antisymmetric. PCL uses the following subtype relationships:

192


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 clarification 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 defined in this section include types used in writing PCL protocols, types used in writing assertions about them, and types used in defining the symbolic execution semantics of protocols. The type protocol itself is used to characterize the definition 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 first 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 differently. In the semantics section we define honesty of principals by requiring honest principals to execute zero or more basic sequences. In effect, 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 finish 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 definition 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 first action of the basic sequence. In figures, 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 defined 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


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


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 off 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 first 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 configured 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-


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 (specifically, 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 confidentiality. 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 specific thread. The Sto(·, ·) function (in Table 8) has a thread parameter and may occur in formulas but not in roles. The key confidentiality condition given above allows a role to encrypt a message with a confidential key and send it, as in the sequence of actions oc := enc msg, K; send !oc. The reason this conforms to the syntactic key confidentiality 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 confidentiality of the key because encrypting a message with a key does not produce a message from which the key can be

196


recovered. The key confidentiality condition does not allow oc := enc K1 , K2 , in which a confidential 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 confidentiality condition is designed to be a conservative syntactic restriction on roles (to be followed by honest principals) that prevents export of confidential 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 differ in their principal names is a condition on feasibility of runs, to be defined 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 definitions 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. Quantifiers are regarded as function symbols of specific 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 finite set of principals, a finite set of threads, a finite 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.


197

Table 8. Function symbols for PCL assertions function symbol

PCL notation

type

Sto

thread × location → message

Send

thread × message → action_formula

Receive


NewNonce


Enc

thread × message × key → action_formula

Dec


Se

thread × message × nonce → action_formula

Se


Sd

thread × message × nonce → action_formula

Sd


Sign


Unsign


Verify

thread × message × key → action_formula thread × message → action_formula

Assign Assert

infix

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

= =

infix infix infix

thread → nonmodal_formula

Start Honest

¬ ∧

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

Modal

¬ϕ infix ϕ [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. Quantifiers in PCL

quantifiers

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 define the set of feasible runs of a protocol to characterize the well-formed runs in our model of protocol execution and attack. After preliminary definitions in Subsection 4.1, we define the semantics of protocols in Subsection 4.2. Subsection 4.3 gives an inductive definition of the semantic relation P : R |= ϕ, stating that the formula ϕ holds on a feasible run R of protocol P.

198


4.1. Preliminary definitions 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 defines a sequence of actions. The events in the event list eventlist are pairs tid, act of actions by specific 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 define 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 define 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) defined ⇒ 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 define the so-called Dolev-Yao closure of a set of messages. Although we do not use the Dolev-Yao closure to define the set of runs, we do use it to characterize the


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 define the set DolevYao(M) of messages that a symbolic Dolev-Yao [14] attacker can generate from M as follows: msg0 ∈ DolevYao(M) iff 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 definition, 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


Since threads generate new nonces and keys, we need a definition that allowsus to see which symbols are not new relative to a run R prev = Sprinc , Sth , eventlist, store . Before giving this definition, we need some other definitions, concerning the - (congruence-) and the - (subterm-) relations: • Canonical form of messages: The equations in Table 6 form a confluent 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 definition of “nonce N occurs in R” is analogous. Finally, we give a number of auxiliary definitions 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 defined by Ri .elist, for 1 ≤ i ≤ n.

The run components are cumulative because this simplifies 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. • difference: If events1 is an initial segment of events2 , their difference (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 defined inductively. Recall that a run R consists of a finite set of principals, a finite set of threads, a list of events and a store. Intuitively, the base case of the inductive definition imposes conditions on the initial configuration before protocol execution begins. For example, the principal names and


201

thread identifiers 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 definition 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 satisfied. An action has the effect 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 definition 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 differ 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 specified 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 differ 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


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 defined below in Section 4.3). 4.3. Truth of statements In this section, we present an inductive definition 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 defined 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).


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 defined 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 first thread to send out a message containing msg1 , the first 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


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 defined 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 sufficient 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 suffices 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 definition.


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 different 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 finite 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 different 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 effect, 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 specific further actions; and FS1 and FS2 support reasoning about the temporal ordering of actions performed by different 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


• 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 specifies 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 )


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 satisfies 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 defined 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


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 specification ∀(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 specification ∀(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 confidential 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 confidential 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:


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 definition T executed a verify msgsigned , K action such that R[msgsk(A) ] msgsigned and R[vk (A)] K . By the verify-clause in the definition 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 defined, there has to be such a first 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 definition; sign-clause, feasibility of runs). That the first 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 first 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, finally 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


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 first” when it is fresh and the first 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 fulfilled: (1) msg1 Sto(T, msg2 ). (2) There is an instance of thread T sending out Sto(T, msg2 ) such that this is the first 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 first 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 first 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 different 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 ψ

ψ ⇒ ψ


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 find 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 first 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 definition 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 first 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 effectively 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 specification – 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 first determining whether the conditions exist

212


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 quantifiers in this rule expand to a finite conjunction, and thus the rule can be applied in a finite 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 find 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 first premise we have P : R0 |= ϕ. By successively applying all parts of the second premise, we first get P : R1 |= ϕ, then P : R2 |= ϕ, and finally 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 specifically, 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,


213

in this chapter, we prove authentication from the responder’s point of view only because of space constraints. The authentication property AuthResp is defined 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 defined 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 verifies a signature using the public verification 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 verified 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 verified message, then the initiator must have done specific actions in a specific 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 first 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. Specifically, we show that B verified A’s signature siga. We then use the signature verification 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 first sent k as part of the first 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


1. For the second basic sequence of Init and the first 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 first 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 first 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 first 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 flawed 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 sufficiently link the Initiator and Responder. Specifically, the provable version of (4) asserts that any honest message signer will first send the signed message under a specific 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 different 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


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 define 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


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 different names). Alternately, both may use the same setup assumptions. However, two protocols do not have compatible setup assumptions if one assumes a key is confidential 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 . Definition (Parallel Composition) If P1 , P2 have compatible setup assumptions, then their parallel composition P1 | P2 is defined 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 definition 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 sufficient 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 first 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


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 sufficient 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 definition 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 differences among these approaches. While most model-checking tools can only analyze a finite 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 defined by an equivalence relation between a real protocol and an ideal protocol, which is secure by construction. Inspite of these differences, 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


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 differs 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 specifically 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 defined, the interpretation and use of concepts like “believes” and “jurisdiction” remained unclear. Finally, PCL formulas refer to specific 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 difference is the level of abstraction. Paulson reasons explicitly about traces including possible intruder actions whereas basic reasoning principles are codified in PCL as axioms and proof rules. Proofs in PCL are significantly 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 effects 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 five to twenty messages, in part because PCL proofs appear to be relatively short (for formal proofs). The logic has


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 refinement 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. Diffie, 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]


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 defining 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 Verification 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,


[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 DiffieHellman-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 efficient 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


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 finite. Given a finite set of shapes for 𝔸, it is evident whether a security goal such as authentication or confidentiality holds for 𝔸. In this paper, we describe a search that finds 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 finding the minimal, essentially different executions possible in a protocol, starting from some initial behavioral assumptions. This search gives counterexamples to false authentication and confidentiality 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 finite 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 defining 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 first 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


{∣{∣𝑘∣}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 definition. 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 defined 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


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 first 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 first 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


∙

/ 𝑡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


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

228


𝑡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


{∣{∣𝑘ˆ𝐵∣}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 profitably 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 first 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 first node, i.e. the name of the intended responder. Since this value is unconstrained, we fill 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 confidential. 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 suffices 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


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 refinement. 1.4. Goals of this Chapter Blanchet’s Simple Example Protocol has illustrated the idea that, from a particular starting point, one can find 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 finds 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 identified 𝐶 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—specified, 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 refinement 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 finitely branching (Thm. 6.8), so that each step produces only finitely many new skeletons to explore. 3. The search steps are complete (Thm. 6.5), so that every shape is reached by some finite sequence of search steps. These results do not imply decidability for security goals, since the search may enumerate an infinite 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 infinitely many shapes, then we cannot be sure it is true at any finite 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.


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] refined 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 modified form of the Trusted Computing Group’s protocol for constructing certificates 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 defines 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 define 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. Definition 2.1 Let X be an infinite 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


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]. Definition 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 defined 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: Definition 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 undefined. 2. A path 𝑝 is a sequence in {ℓ, 𝑟}∗ . We write cons(𝑓, 𝑝) for the sequence whose first 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 defined, 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(𝐵) .


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 suffices 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 verification keys and private decryption keys resp. We define 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 finitely 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 Definition 2.5 Consider homomorphisms 𝛼, 𝛽, 𝜄 between subalgebras of MX [B]. 1. A parameter 𝑣 ∈ PARAMS is a source parameter of 𝛼 iff 𝛼(𝑣) ∕= 𝑣. 2. 𝛼 is finitely generated iff it has finitely many source parameters. 3. Messages 𝑣, 𝑤 ∈ M have a common instance iff 𝛼(𝑣) = 𝛼(𝑤) for some 𝛼, in which case 𝛼 unifies 𝑣, 𝑤.

234


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 definition, 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 specific as 𝛼, and write 𝛼 ≤𝑠 𝛾. In clause 4, 𝜅 may be defined only on a subalgebra such as the range of 𝜄, and likewise 𝜄 in clause 5 may be defined only on the range of 𝛼. A preorder means a reflexive, 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 defined 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 reflexive 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 finitely generated 𝛾, the set {𝛼 : 𝛼 ≤𝑠 𝛾} contains only finitely 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. Define ascore(𝛼, 𝑎), for 𝑎 ∈ PARAMS, to be ∣{𝑏 ∈ PARAMS : 𝛼(𝑏) = 𝑎}∣ − 1. Define xscore(𝛼, 𝑥), for 𝑥 ∈ X, to be number of encryptions and concatenations in 𝛼(𝑥) plus the number of multiple occurrences of basic values and indeterminates in 𝛼(𝑥). Define 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(𝛼, 𝑥, 𝑦).


235

Then score is non-negative, and well defined when 𝛼 is finitely generated. Moreover, when 𝛼 ≤𝑠 𝛾, and 𝛾 is finitely generated, score(𝛼) ≤ score(𝛾). If score(𝛼) = score(𝛾), then 𝛼, 𝛾 differ by a renaming. Hence, . . . ≤𝑠 𝛼𝑖 ≤𝑠 . . . ≤𝑠 𝛼1 ≤𝑠 𝛼0 can have only finitely many non-isomorphic members. Indeed, when score(𝛾) = 𝑘 + 1, there are only ⊔ ⊓ finitely many non-isomorphic 𝛼 ≤𝑠 𝛾 such that score(𝛼) = 𝑘. A homomorphism 𝛾 unifies messages 𝑣, 𝑤 if 𝛾(𝑣) = 𝛾(𝑤), and 𝛾 is a most general unifier for 𝑣, 𝑤 if in addition, whenever 𝛾 ′ unifies 𝑣, 𝑤, then 𝛾 ≤𝑠 𝛾 ′ . Lemma 2.8 1. Assume 𝑣, 𝑤 ∈ M have a common instance. There exists a finitely generated 𝛾 which is a most general unifier of 𝑣 and 𝑤. 2. Let 𝑣 = 𝛼(𝑢) and 𝑤 = 𝛽(𝑢). Then 𝛼, 𝛽 have a most specific common generalization 𝛾 for 𝑢. That is, there is a finitely generated 𝛾 such that: (a) For some 𝛼1 , 𝑣 = (𝛼1 ∘ 𝛾)(𝑢), (b) For some 𝛽1 , 𝑤 = (𝛽1 ∘ 𝛾)(𝑢), and (c) if 𝛾 ′ satisfies 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 finite set of parameters, such that the resulting MX [B] satisfies 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 finite set of unifiers cover the common instances of any two messages, and where a finite set of homomorphisms replace the most specific common generalization of Clause 2. Sometimes the adversary has useful additional operations on basic values, and some additional authentication test patterns must be defined 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 reflexive 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


𝑡 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 𝑁0 are the identity. Thus, all of the 𝐻𝑖 for 𝑖 > 𝑁0 are inclusion maps. But a skeleton has only finitely many subskeletons. 4. Suppose that 𝑆𝐻 satisfies (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 ) defined by 𝜓(𝑛) = 𝜙−1 2 (𝜙1 (𝑛)). If also 𝑅(𝐾2 , 𝐾1 ), 𝜓 is bijective. Let 𝑆(𝐾1 ) = {𝐾2 : 𝑅(𝐾1 , 𝐾2 ) ∧ 𝑅(𝐾2 , 𝐾1 )}. Since there are only finitely many 𝑅-equivalence classes 𝑆(𝐾), it suffices to show that if any of them is infinite, 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 finite number of clean 𝔻. Thus, if 𝑆(𝐾1 ) is infinite, there is a single 𝔻 with infinitely 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


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 definition 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 welldefined to within isomorphism. Definition 3.12 The shapes for a skeleton 𝔸, written shapes(𝔸), are the members of the nodewise minimum characterization for 𝔸. The shapes(𝔸) form a well-defined 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 definitions. 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 “fix” those situations. When they can be fixed 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 .


245

Proof: 1. Define 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 𝔹 satisfies 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. Define 𝔹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 unifiable 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 first 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 first kind, we reduce the number of nodes. At each step of the second kind, we reduce the number of incomparable nodes. ⊔ ⊓ Definition 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 first proof of Lemma 3.15.

246


𝑥êkc

o

aicˆkeyrec

/ TPM ∙ ∙ o

𝐼 ˆ𝐾 ˆ𝑥êkc


/

{∣aic∣}EK

∙

o

{∣aic∣}EK

/ PCA ∙

STORE aicˆkeyrec

/ ∙

aic = {∣aic 𝐼 ˆ𝐾 ˆ𝑥∣}sk(PCA) ekc = {∣ekc MFÊK∣}sk(MF) keyrec = {∣aikrec 𝐾, 𝐾 −1 ∣}SRK Figure 12. Modified 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 first 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 certificates 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 certificate for an AIK verification 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 certificate authority that prepares certificates on AIKs will prepare a certificate 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 certificate aic using a public encryption key EK. That key is accompanied by a certificate 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 certificate from this encryption only if it holds the signature key 𝐾 −1 matching the key 𝐾 in the certificate. The (slightly modified) 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 certificate {∣ekc MFÊK∣}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


aicˆkeyrec

/ ∙


⋅→

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 first 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



/ 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 first 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 first disjunct is unsatisfiable. 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 definitions, 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


249

which transmits 𝑐 or 𝑒 outside 𝑆, although earlier nodes on the same strand contained the critical value only within 𝑆 (if at all). There are only finitely 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: Definition 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 first 𝑡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 Definition 5.2 Let 𝑐 be a basic value or an encryption, and 𝑆 be a set of encryptions. Cut(𝑐, 𝑆, 𝔸), the cut for 𝑐, 𝑆 in 𝔸, is defined 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 ). Definition 5.3 A node 𝑛1 ∈ 𝑄 = Cut(𝑐, 𝑆, 𝔸), is solved in 𝑄, iff

250


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 𝑎 suffices. If 𝑎 ∈ 𝑃 , then the empty web suffices. Since msg(𝑛1 ) = 𝑎, by the definition 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-defined, and by the assumption solved. By the definition 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 suffices. If 𝑃 contains any concatenations, we reduce them as before. Thus, assume 𝑃 consists only of encryptions. Letting 𝑃 𝑒 = {𝑡 ∈ 𝑃 : {∣𝑡0 ∣}𝐾 ⊑ 𝑡}, Cut({∣𝑡0 ∣}𝐾 , 𝑃, 𝔸) is well-defined, and since {∣𝑡0 ∣}𝐾 ∕∈ 𝑃 𝑒 , it has no solution by a


251

transmission node. Hence, either Lsn[𝐾] ⪯ 𝑛1 or else Lsn[𝐾1−1 ] ⪯ 𝑛1 where some {∣𝑡1 ∣}𝐾1 ∈ 𝑃 𝑒 . In the first 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: Definition 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


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 suffice. 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. define 𝜇(𝑆) = {[𝐺] : 𝐺 ∈ 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. ⊔ ⊓ Definition 6.3 When 𝑄 = Cut(𝑐, 𝑆, 𝔸) and 𝑛1 is an unsolved minimal node in 𝑄, then define cohort(𝑛1 , 𝑄) = 𝜇{𝐾 : 𝐾 solves 𝑛1 , 𝑄}. Lemma 6.4 If 𝐻 ∈ cohort(𝑛1 , 𝑄) and 𝐻 is a solution: by destruction, then 𝜙𝐻 is surjective, ⪯𝔹𝐻 = 𝜙(⪯𝔸 ), non𝔹𝐻 = 𝛼𝐻 (non𝔸 ), and unique𝔹𝐻 = 𝛼𝐻 (unique𝔸 ). Moreover, 𝛼𝐻 is ≤𝑠 -minimal among 𝛽 such that 𝛽(𝑐) ⊙𝛽(𝑆) 𝛽(msg(𝑛1 )). by transmission, then there is exactly one transmission node 𝑚1 ⪯𝔹𝐻 𝜙𝐻 (𝑛1 ) that is minimal in 𝐻(𝑄). Moreover:


𝔸 𝐾0

𝔸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 𝜙𝐻 (⪯𝔸 ), satisfies 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 𝜙𝐻 (⪯𝔸 ), satisfies 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 identified; 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

Formal Models and Techniques for Analyzing Security Protocols

Formal Correctness of Security Protocols

Techniques for Analyzing Food Aroma

Scalable Techniques for Formal Verification

Scalable Techniques for Formal Verification

Apoptosis Techniques and Protocols

Melanoma Techniques and Protocols

Microwave Techniques and Protocols

fMRI Techniques and Protocols

Security Protocols

Musculoskeletal Models and Techniques

Mobile Broadband Multimedia Networks: Techniques, Models and Tools for 4g. Techniques, Models and Tools for 4G

Formal Techniques for Distributed Systems - FORTE 2011

Analyzing Tabular Data: Loglinear and Logistic Models for Social Researchers

RFID Security: Techniques, Protocols and System-On-Chip Design

RFID Security: Techniques, Protocols and System-On-Chip Design

Microfluidic Techniques: Reviews And Protocols

Microfluidic Techniques: Reviews And Protocols

Transgenesis Techniques Principles and Protocols

Microfluidic Techniques: Reviews And Protocols

Transgenesis Techniques Principles and Protocols

Transgenesis Techniques. Principles and Protocols

Transgenesis Techniques: Principles and Protocols

Apoptosis: Techniques and Protocols (Neuromethods)

Models of Computation and Formal Languages

Diplomacy Games: Formal Models and International Negotiations

Formal Techniques for Networked and Distributed Systems - FORTE 2002

Security Protocols XVI

Security Protocols, 10 conf

Formal Models and Techniques for Analyzing Security Protocols

Formal Correctness of Security Protocols

Techniques for Analyzing Food Aroma

Scalable Techniques for Formal Verification

Scalable Techniques for Formal Verification

Apoptosis Techniques and Protocols

Melanoma Techniques and Protocols

Microwave Techniques and Protocols

fMRI Techniques and Protocols

Security Protocols

Musculoskeletal Models and Techniques

Mobile Broadband Multimedia Networks: Techniques, Models and Tools for 4g. Techniques, Models and Tools for 4G

Formal Techniques for Distributed Systems - FORTE 2011

Analyzing Tabular Data: Loglinear and Logistic Models for Social Researchers

RFID Security: Techniques, Protocols and System-On-Chip Design

RFID Security: Techniques, Protocols and System-On-Chip Design

Microfluidic Techniques: Reviews And Protocols

Microfluidic Techniques: Reviews And Protocols

Transgenesis Techniques Principles and Protocols

Microfluidic Techniques: Reviews And Protocols

Transgenesis Techniques Principles and Protocols

Transgenesis Techniques. Principles and Protocols

Transgenesis Techniques: Principles and Protocols

Apoptosis: Techniques and Protocols (Neuromethods)

Models of Computation and Formal Languages

Diplomacy Games: Formal Models and International Negotiations

Formal Techniques for Networked and Distributed Systems - FORTE 2002

Security Protocols XVI

Security Protocols, 10 conf

Recommend Documents