aa r X i v : . [ c s . CR ] F e b On the Protocol Composition Logic PCL ∗ Manuscript
Cas Cremers
Department of Computer Science, ETH Zurich, 8092 Zurich, Switzerland [email protected]
October 30, 2018
Abstract
A recent development in formal security protocol analysis is the Protocol Composition Logic(PCL). We identify a number of problems with this logic as well as with extensions of thelogic, as defined in [DDMP05,HSD + Formally establishing properties of security protocols has been investigated extensively during thelast twenty years, but a definite model and a corresponding method for security protocol analysishas remained elusive thus far.The most successful approaches to security protocol analysis have been focused on toolsfor finding attacks, which are often based on bounded model checking or constraint solving,e.g. [Low97a, ABB + honesty rule . This kind of reasoning also allows the protocol logic to dealwith protocol composition and refinement, where proofs can be reused. PCL has been extendedwith several features in further work, such as an extension for hash functions in [HSD +
05] thatwas used for a modular correctness proof of IEEE 802.11i and TLS. ∗ This work was supported by the Hasler Foundation, ManCom project 2071.
1n this paper, we identify a number of problems with PCL as defined in [DDMP05, Dat05,Der06, DDMR07, HSD +
05, He05]. They have implications for the scope of PCL, a number ofclaimed formal proofs, and several extensions to the base model. In particular, we show thatin contrast with the claims in e.g. the introduction of [DDMR07], PCL as defined in [DDMP05,Dat05, Der06, DDMR07] cannot be used to prove common authentication properties of protocolsthat do not include signatures. We show that a number of claimed proofs in PCL cannot becorrect because (a) there is no way to establish preceding actions in a thread, and (b) there isno way to express type restrictions in PCL. With respect to existing PCL extensions, we identifytwo problems: the Diffie-Hellman extension from [DDMP05, Dat05, Der06, DDMR07] does notcorrectly capture the algebraic behaviour of Diffie-Hellman-like protocols, and the extension forhash functions from [HSD +
05, He05] is not sound. Some of these problems can be resolved byminor modifications to PCL, but other problems require further investigation. Our observationssuggest that it is at least required to make changes to existing axioms, to introduce new axioms,and to add a mechanism for a type system.The purpose of this paper is to identify some of the challenges that need to be addressed inorder to make a logic like PCL work. We hope it will contribute to the improvement of PCL,and will lead to a better understanding of some of the pitfalls of designing a compact and usableformal logic for security protocols.
The scope of this paper.
The presentation of this paper is inherently difficult, not least be-cause there are a number of different papers on PCL, which vary in notation and technical details.Many ideas were already present in precursors of PCL, e.g. [DMP01, DMP03], but these variantsuse different concepts than later versions of PCL. These early variants in [DMP01, DMP03] haveno notion of thread (a.k.a. process, run, or role instance), and events are bound to agents. Morerecent versions of PCL bind events to threads of agents, and therefore distinguish between severalthreads of the same agent. PCL versions of the latter type can be found in [DDMP03b,DDMP03a,DDMP04b, DDMP04a]. Subsequently, [DDMP03b, DDMP03a, DDMP04b, DDMP04a] have beenclaimed to be either subsumed, or revised and extended, by more recent works [DDMP05, Dat05,Der06, DDMR07]. Hence we choose here to focus on [DDMP05, Dat05, Der06, DDMR07], whichcontain similar descriptions of PCL. Throughout this paper we write basic PCL to refer to[DDMP05, Dat05, Der06, DDMR07]. The publications on basic PCL describe the fundamentalpart of PCL that focusses on authentication. In general, the comments in this paper apply tobasic PCL. The comments in Section 4.2 apply only to the extensions found in [HSD +
05, He05].Our comments here do not cover the recent extensions to basic PCL for the analysis of secrecy, asfound in [RDD + Syntax and page references.
In order to pinpoint our observations to specific formulas, weselect a specific version of PCL to refer to. We have chosen the most recent description of PCL from2007 as found in [DDMR07]. In particular, we will use [DDMR07] as a reference for the syntax ofPCL formulas, and to provide specific page references. Hence we use [DDMR07] as the referencepaper to present the problems with basic PCL from the papers [DDMP05,Dat05,Der06,DDMR07].For the technical details, in particular the formulas, we assume the reader is at least some-what familiar with one of the papers from [DDMP05, Dat05, Der06, DDMR07] or [He05, HSD + Acknowledgements.
The author would like to thank David Basin, Anupam Datta, FelixKlaedtke, Sjouke Mauw, Simon Meier, John C. Mitchell, Arnab Roy and the anonymous refereesfor useful discussions and feedback on earlier versions of this paper.2
Preliminaries
The purpose of this section is to recall some PCL notions that are required to interpret theforthcoming sections. We use the syntax from [DDMR07]. This partial summary of PCL isincomplete, and we encourage the reader to use the original papers for reference.The structure of PCL is as follows: first notation is introduced to define terms, which in turnare used to define protocols. For such protocols, an execution model is defined, assigning to eachprotocol a set of possible execution histories, called runs . Then, a protocol logic is defined inorder to reason about (sets of) runs of a protocol. This logic is proven sound with respect to theexecution model. This means that if one proves a property in terms of the protocol logic, suchas
Receive ( . . . , m ), then a similar property should hold for the corresponding set of runs in theexecution model, such as “ receive . . . , m has occurred in the protocol run”. We touch uponthese elements below. Terms.
A term system is introduced that contains constants (nonces, names, keys, etc.),variables, and compound terms such as tuples, encryptions, and signatures.
Protocols.
In PCL, a protocol Q is defined as a set of roles. Each role ρ ∈ Q is defined asa list of actions. Examples of possible actions can be found in the actions column of Table 1,and correspond respectively to sending terms, receiving terms, generating fresh terms, encryption,decryption, and signature verification. Each role is partitioned into a set of basic sequences . A basicsequence BS i of a role ρ is a contiguous subsequence of ρ that starts with either the first action of ρ or a receive action, and of which the other actions are not receive actions. The basic sequencesintuitively represent the idea that agents only block at receive actions, and execute all otheractions immediately, allowing one to regard basic sequences as atomic actions in some respects.The notion of basic sequences therefore roughly corresponds to the notion of step-compression inother models, e.g. [BMV03]. The basic sequences of a protocol are defined as the union of thebasic sequences of each of its roles, and hence each action of a role of a protocol occurs in exactlyone of its basic sequences.Observe that although some versions of PCL have two distinct actions receive (for reading aterm from the network without parsing) and match (for parsing a term and blocking if it is not asexpected), these two actions are in many proofs collapsed together into a single receive actionthat receives and matches terms at the same time. Execution model.
An execution model is defined for protocols (in terms of cords ). Actionsare executed by agents , with names like ˆ X, ˆ Y . A subset of these agents, defined as HONEST ( C )(where C is the initial configuration of the system), are called the honest agents , and execute theirprotocol roles as expected. The agents may execute each protocol role any number of times; eachsuch instance of a role is called a thread (in other formalisms, this notion is known as a strand, or aprocess, or a run). Threads are usually denoted by symbols such as X, Y, Z : a sequence of actions P executed within a thread X is written as [ P ] X . The notation ˆ X is often used to denote theagent executing the thread X . Informally, if the agent ˆ X is honest, [ P ] X is a sequence of actionsfrom a protocol role. The agents that are not part of HONEST ( C ) can execute so-called intruderroles, in line with the common Dolev-Yao intruder model. In the context of this execution model,the protocol description Q gives rise to a set of runs denoted by Runs ( Q ). A run is typicallydenoted by R , and corresponds to a sequence of actions as executed by threads. A run representsa possible execution history of the system. Protocol logic.
For each of the actions that can occur in a run, a corresponding actionpredicate is defined. Some examples are given in the right column of Table 1. The protocol logic The hat notationˆis used in at least two different interpretations in both [DDMP05] and [DDMR07]. In somecases X is used to denote a particular thread, and ˆ X is then interpreted as the agent that executes that thread,as e.g. can be seen in the usage of Y in the SEC axiom [DDMR07, page 327], replicated here on page 6. Thus, inone interpretationˆcan be regarded as a function from a thread to an agent. However, in other cases ˆ X is used todenote a particular agent, and X is then interpreted as “any thread executed by the agent ˆ X ”, as in the honestyrule HON [DDMR07, page 329], and the
VER axiom [DDMR07, pp. 329–330], replicated here on page 5. Inthis second interpretation, X is a variable that ranges over all threads executed by the agent ˆ X , and ˆ X effectivelyexpresses a domain restriction on X . X ) send ˆ X, ˆ Y , m
Send ( X, m ) receive ˆ X, ˆ Y , m
Receive ( X, m ) new x Gen ( X, x ) enc m, K enct = ENC K {| m |} Encrypt ( X, enct ) dec enct, K enct = ENC K {| m |} Decrypt ( X, enct ) verify sigt, m, K sigt = SIG K {| m |} Verify ( X, sigt ) Has ( X, m ) Honest ( ˆ X ) Contains ( bigt, smallt )Table 1: Some examples of PCL actions, action predicates, terms, and their relations. Here ˆ X, ˆ Y denote agents, m, x, enct, sigt, bigt, smallt denote terms, and X denotes a thread.is extended with logical connectives, a predicate to reason about the ordering of actions in a run( < ), as well as predicates to reason about the knowledge of threads.One of the predicates of the logic is the Honest predicate, which is closely related to the set
HONEST ( C ). For a run R , Honest ( ˆ X ) is used to denote that ˆ X ∈ HONEST ( C ) and “all threadsof ˆ X are in a ‘pausing’ state in R ” [DDMR07, page 325]. This is a technicality that is needed tomake the honesty rule (which is not described here) work.One predicate of interest for this paper is the Contains predicate, which is used to reason aboutthe relation between two terms. In particular,
Contains ( t , t ) is defined by means of the subtermrelation ⊆ in [DDMR07, page 323], stating that t contains t as a subterm. The subterm relation ⊆ is never formally defined. Here we assume that the subterm relation is defined syntactically . Inparticular, we assume that a signature such as SIG ˆ X {| m |} contains m , i.e. Contains ( SIG ˆ X {| m |} , m )holds. Note that this assumption only plays a role in the construction of a particular counterex-ample in Section 3.3, and does not influence any of our general observations.Using the protocol logic, one aims to establish properties of all runs of a protocol. A run R ofa protocol Q that satisfies a property φ is denoted as Q, R | = φ . If all runs of a protocol Q satisfy φ , we write Q | = φ . If a formula φ is provable using the logic by using any PCL axioms except thehonesty rule, we write ⊢ φ , which expresses that φ holds for all protocols. For formulas provableusing the axioms and the honesty rule for a protocol Q , we write ⊢ Q φ , which expresses that φ holds for the protocol Q .In the remainder of this paper we use the following convention: All formulas that are numberedare ours. All unnumbered formulas, including the named axioms, are copied from PCL papers, inwhich case the source paper and page number is given. In this section, we address two problems with basic PCL as defined in [DDMP05, Dat05, Der06,DDMR07]. First, we identify in Section 3.1 a strong restriction on the scope of basic PCL. Then,we identify two missing proof mechanisms that seem to be necessary to prove simple protocolscorrect in Sections 3.2 and 3.3. The
Honest predicate serves within the honesty rule as an encoding of the atomic nature of basic sequences. Observe that if we would alternatively assume that the subterm relation involves only tuple projection, as seemsto be suggested by the
CON axiom [DDMP05, page 444], i.e. t ⊆ t ′ ≡ ( t = t ′ ) ∨ ( ∃ t ′′ .t ′ = ( t, t ′′ ) ∨ t ′ = ( t ′′ , t )),then e.g. the P2 and VER axioms in [DDMP05, DDMR07] are unsound, because respectively the fresh value andthe signature might be sent as part of an encrypted term, and decrypted by an agent that knows the key. .1 Authentication properties only provable for signature protocols In basic PCL [DDMP05, Dat05, Der06, DDMR07], the possibility of proving authentication prop-erties is limited to protocols that use signatures.Proving an authentication property such as aliveness or agreement requires a proof of existenceof actions of another agent. In basic PCL, there is only one axiom that allows for a conclusionof that type. The precondition of this axiom can only be met by protocols that use signatures.As a consequence, if a protocol does not use signatures, the existence of a communication partnercannot be proven within the logic.This is surprising, as PCL was “initially designed as a logic of authentication” [DDMR07, page313], and it is stated in the abstract of the paper that “PCL [. . . ] has been applied to a numberof industry standards including SSL/TLS, IEEE 802.11i [. . . ]” [DDMR07, page 311, abstract].These protocols consist of many subprotocols that do not rely only on signatures, but also rely onsymmetric key cryptography and symmetric MACs.The problem occurs for all authentication properties that imply the existence of a communica-tion partner. This includes aliveness or any form of agreement from [Low97b], matching conver-sations from [BR94], or synchronisation from [CMdV06]. The matching conversations property isthe authentication property used within basic PCL [DDMR07, page 331]. All these properties areof the form: φ ( X ) ⊃ ∃ Y.ψ ( Y ) (1)where typically, φ ( X ) denotes that thread X executes a role that authenticates another role. Sucha property states that if a thread X executes actions of a certain role (e.g. all actions of an initiatorrole), then there exists a thread Y that has executed some actions of another role (e.g. the first twoactions of a responder role), and possibly some further condition holds. This is captured in ψ ( Y ).Note that both the weak and strong authentication properties in the example of [DDMR07, page331] belong to this class of authentication properties.In order to prove such a property, it is required to prove the existence of a thread. Examinationof all axioms of the logic reveals that only one axiom allows for the conclusion of the existence ofa thread, which is the VER axiom [DDMR07, page 327]:
VER
Honest ( ˆ X ) ∧ Verify ( Y, SIG ˆ X {| x |} ) ∧ ˆ X = ˆ Y ⊃∃ X. Send ( X, m ) ∧ Contains ( m, SIG ˆ Y {| x |} )Because this axiom has the signature verification predicate Verify in the precondition, it can onlybe used for signature protocols. Hence there is no way to prove the existence of another threadfor protocols without signatures.
Other comments regarding non-signature protocols.
Whilst introducing new axioms forestablishing thread existence for non-signature protocols is non-trivial, there is a related problemwith the inconsistent use of symmetric/asymmetric cryptography. In basic PCL, there is only onetype of encryption operator, and only a single key set, in the sense that the rules for encryptionand decryption do not distinguish between different types of keys. This suggests that either onlysymmetric, or only asymmetric encryption is supported.The definitions of the reaction rules [DDMR07, page 318], the action formulas [DDMR07, page324] and the
Has predicate [DDMR07, pp.324–325] all indicate that one encrypts and decrypts amessage using the same key, e.g.:
Has i +1 ( A, ENC K {| m |} ) if Has i ( A, m ) and
Has i ( A, K ) Has i +1 ( A, m ) if
Has i ( A, ENC K {| m |} ) and Has i ( A, K )The same assumption, that one encrypts and decrypts with the same key, can be found in axiom
AR3 [DDMR07, page 327]. Without explaining the full details of the notation of this axiom, wewant to point out that the key K is used as the key to decrypt a message encrypted with K : AR3 a ( x ) [ y := dec x, K ] X a ( ENC K {| y |} ) 5owever, the idea that symmetric encryption is intended seems to be contradicted by the SEC axiom [DDMR07, page 327], which states that there is only one agent that can decrypt a messageencrypted with a key, along the lines of asymmetric encryption:
SEC
Honest ( ˆ X ) ∧ Decrypt ( Y, ENC ˆ X {| x |} ) ⊃ ( ˆ Y = ˆ X )Combined with the definition of the Has predicate, one is lead to conclude that the only one whocan create the encrypted message that occurs in the
SEC axiom, is the agent that can decrypt it.
In order to prove any authentication property of the form of (1) for a protocol that does not use sig-natures, one needs to introduce consistent machinery for symmetric and asymmetric cryptographyand several new axioms.In basic PCL, protocols like Needham-Schroeder-Lowe and many key establishment protocolscannot be modeled, and even if they could be, no authentication proofs could be given for them.Similarly, it is impossible to use basic PCL as defined in [DDMP05, Dat05, Der06, DDMR07] toprove the authentication properties of the protocols “SSL/TLS, IEEE 802.11i” [DDMR07, page311, abstract]. In order to prove authentication of these protocols, one is required to introduceadditional axioms. The problem can be split into three subparts. First, symmetric and asymmetric cryptography mustbe dealt with consistently. Second, basic PCL must be extended with axioms that enable provingauthentication properties (existence of a thread) for symmetric cryptography. Third, resolving theproblem for public-key encryption protocols (which includes many key agreement protocols, andthe well-known Needham-Schroeder-Lowe protocol) requires the introduction of additional theory.We first address the two easier problems before turning to public-key encryption.
Dealing consistently with symmetric and asymmetric cryptography.
The first require-ment for resolving this problem is to split symmetric and asymmetric encryption either by hav-ing two types of encrypt/decrypt actions as in e.g. [ABB + Has predicate, andrequires the addition of further
ARx axioms and an alternative for the
SEC axiom. Most ofthe additions are trivial, but introduce additional complexity into the logic and possibly also theexecution model.
Proving authentication for protocols using symmetric encryption or keyed hashes.
The axiom for signature protocols deals with the simplest possible case of authentication bycryptography: the signature of an honest agent can be used immediately to conclude that thereexists a thread executed by this agent. If that agent differs from any agent executing the currentlyknown threads, this implies the existence of another thread. This conclusion is based on the factthat only one agent has the private key needed to perform the signature.For symmetric encryption and keyed hashes there is usually a notion of symmetry: in mostcases, two agents share a symmetric key. Thus, if a symmetric key K shared by two honest agentsˆ X and ˆ Y , occurs in a message of a thread X , there are two candidates for the agent who createdthe message. If we can exclude that the message was generated in thread X executed by ˆ X , wecan derive the existence of another thread Y that must have created it.The authors of PCL have explored a variant of this route for e.g. the extensions needed for thekeyed-hash based protocols in [HSD + Observe that in a precursor of PCL in [DMP03] there is a proof of Needham-Schroeder-Lowe, but this logichas only asymmetric cryptography, and has no notion of threads or processes. roving authentication for public-key encryption protocols. If we assume that basicPCL is extended to consistently deal with public-key encryption, the authentication propertiesstill cannot be proven, as we lack an axiom for establishing thread existence as pointed outpreviously. Contrary to signatures or symmetric-key cryptography, there is no easy solution withan axiom based on honest agents only, because the public keys are also known to the intruder. Ifa message encrypted with the public key of an honest agent ˆ X occurs, no conclusion can be drawnabout the sender or creator of the message. Thus we must also consider the possibility that themessage was sent by the adversary.A first step towards a solution would be to introduce an axiom in the protocol logic, alongthe lines of Lemma 2.3 [DDMR07, page 321] of the execution model. In fact, such an axiom waspresent in a precursor of basic PCL. In [DMP03, page 701] one can find axiom AR1 which, whenrecast in the basic PCL model, would read
AR1 [ receive t ] X ∃ Z. Send ( Z, t ) (This axiom is not in basic PCL) (2)A second axiom that might be adapted for proving these properties is the
SRC axiom in [DMP03,page 703].Unfortunately, for either of these axioms, authentication proofs would require either furthermachinery to prove that Z is executed by an honest agent, or explicit reasoning about the intruder,as the sender thread Z need not be executed by an honest agent. This type of reasoning is notsupported by basic PCL, and would require a significant amount of additional machinery. By the definition of the PCL execution model, threads of honest agents start at the beginning ofa role description, and always execute the actions in the order given by the role. Thus, if one canestablish that a thread of an honest agent has executed the n th action of a role, it should also bepossible to conclude a similar result about preceding actions within the logic: in particular, oneshould be able to conclude that the preceding n − send action that a receive actionmust have occurred previously, but only if both actions occur within the same basic sequence.However, if one wants to prove that given a basic sequence, an action has occurred from anotherbasic sequence, there are no rules to enable this type of reasoning. The consequence of not having a means of establishing preceding actions is that some claimedproofs do not seem to be correct. For example, observe the initiator role of the Q CR protocol[DDMR07, page 315]. In order to prove invariants for the protocol using the honesty rule, one hasto prove that the invariants hold for all basic sequences of the protocol. The initiator role consistsof two basic sequences BS and BS [DDMR07, page 335]:BS ≡ [ new m ; send ˆ X, ˆ Y , m ; ] X BS ≡ [ receive ˆ Y , ˆ X, y, s ; verify s, ( y, m, ˆ X ) , ˆ Y ; r := sign ( y, m, ˆ Y ) , ˆ X ; send ˆ X, ˆ Y , r ; ] X In this protocol, the basic sequence BS defines m as a generated value, which determines thesemantics of m in BS . Observe that there is no way to tell if m was received or generated fromjust investigating BS .In order to show how this makes certain proofs impossible in basic PCL, consider a protocol Q ′ , that contains a role ρ consisting of the basic sequences BS ′ followed by BS , where BS ′ isdefined as:BS ′ ≡ [ receive ENC K {| m |} ; send ˆ X, ˆ Y , m ; ] X (3)7hus the protocol Q ′ shares the basic sequence BS with Q CR , but in Q ′ , m is a received valuedas opposed to a generated value.Now, in order to prove invariant γ [DDMR07, page 334] for basic sequence BS , we mustprove that m is either generated, or received earlier as the main message, by the same thread thatsends out the signature: γ ≡ (cid:0) Send ( Y, t ) ∧ Contains ( t, SIG ˆ Y {| y, m, ˆ X |} ) (cid:1) ⊃ (cid:16) Gen ( Y, m ) ∨ (cid:0) Receive ( Y, ( ˆ X, ˆ Y , m )) < Send ( Y, ( ˆ Y , ˆ X, y,
SIG ˆ Y {| y, m, ˆ X |} )) (cid:1)(cid:17) In order to prove this invariant with respect to basic sequence BS , one needs to prove that m is generated in the thread Y . However, there is no mechanism to reason about any precedingactions, and thus it has to be dealt with in the same way for both protocols Q CR and Q ′ . Onemust therefore also consider the case m was first received , and not generated, in a previous basicsequence as part of a bigger term, as happens in Q ′ . In fact, the invariant is false for protocol Q ′ .Thus, in order to prove the invariant for Q CR , we must be able to distinguish between thedifferent semantics of BS within the context of Q CR and Q ′ . Such reasoning is not supported bybasic PCL.Without the ability to reason about preceding actions, the protocol descriptions are effectivelycut up into independent basic sequences, which can then only be dealt with as separate protocols.This is evident from the formulation of the honesty rule [DDMR07, page 329], in which thereference to the protocol Q is only used for the definition of the basic sequences. Thus one isrequired to create much stronger proofs than would be strictly necessary. Put differently, in basicPCL one has to reason with an over approximation of protocol execution, in which basic sequencesoccur in no fixed order in a thread.This phenomenon can also be observed in the following example. Let P be a protocol, and let P be the protocol defined as P extended with a role consisting of the basic sequences BS; BS ′ ; BS ′′ .Similarly, let P be defined as P extended with a role BS ′′ ; BS ′ ; BS, i.e., a role with the same basicsequences as the role in P , but composed in a different order. Then, any invariant γ that can beproven for protocol P using the honesty rule, must also hold for P . In fact, the proof is identical.Conversely, any invariant that holds for P but not for P , cannot be proven using the honestyrule. This puts a strong restriction on the type of invariants provable in basic PCL, because thestructure (and hence the properties) of both protocols can be very different.Ultimately, this problem seems to be a side effect of the weak link between the protocoldescription Q and the actions of honest agents in a run R ∈ Runs ( Q ) in the protocol logic. Inbasic PCL, the only way to make the link between a protocol description and the actions of honestagents, is by means of defining an invariant and then proving it with the honesty rule. Thiscan be seen from inspecting the protocol logic rules: the only occurrences of a protocol name(e.g. Q ) are in the honesty rule and the composition rules. As the honesty rule only reasons aboutisolated basic sequences of the protocol, the relations among the basic sequences of the protocolare inevitably lost. Based on the semantics of PCL, it should be possible to extend the logic with a “precedence”inference rule, that would allow one to infer that given the n th action of a role ρ occurs in athread X , also the ( n − It is mentioned that in PCL, “We assume enough typing to distinguish the keys K from theprincipals ˆ A , the nonces n and so on.” [DDMR07, page 316]. However, there are no constructs inPCL that allow for formal reasoning about the type of variables.As a consequence, some claimed proofs of invariants are not correct within the logic, as theyare only true under type assumptions, that cannot be expressed in PCL. Many protocols have properties in a typed model, that do not hold for an untyped model. Inparticular, some protocols are correct in a typed model, but are vulnerable to so-called type flawattacks in an untyped model. Such attacks exploit for example that an agent could mistake anencrypted session key for an encrypted nonce, and sends the key unencrypted in a next step,revealing it to the intruder. It is therefore often easier to prove properties for the typed model,but this requires that the logic supports drawing conclusions based on types. Currently, this isnot possible in PCL.As an example, we show that invariant γ from [DDMR07, page 334] (reproduced in this paperon page 8) is false when variables are untyped. The invariant γ states that if a thread (of anhonest agent) sends a message that contains a signature term S , with a subterm m , then either1. m was generated in the thread Y , or2. the thread Y executes a receive of m , and later a send of the message tuple ( y, S ).Now consider the basic sequence BS from [DDMR07, page 335]:BS ≡ [ receive ˆ X, ˆ Y , x ; new n ; r := sign ( n, x, ˆ X ) , ˆ Y ; send ˆ Y , ˆ X, n, r ; ] Y This basic sequence corresponds to the responder receiving an unknown value, supposedly a nonce,and sending back a signed version that includes a freshly generated nonce.In order to show the invariant is false, consider a thread Y ′ that is executed by agent ˆ Y . If weassume that x = SIG ˆ Y {| y, m, ˆ X |} , where m is generated by thread Y ′ , the invariant is violated:we have that x = SIG ˆ Y {| y, m, ˆ X |} ⊃ Contains ( x, m ) and by substitution in BS and the Contains predicate, we find that
Contains ( r, m ). As a result, the message sent at the end of BS of a thread Y ( Y ′ = Y ) will contain m . However, m is neither generated by this thread nor is it the exactterm that was received. Thus the invariant γ does not hold for basic sequence BS . Hence theexample authentication proof of the CR protocol in [DDMR07] is incorrect. The model can be extended with typing information for the variables, and an axiom could beintroduced that captures the fact that variables are only instantiated by their typing information.This would not introduce much new machinery, but requires additional reasoning steps in most ofthe proofs.
In this Section we discuss two additional mechanisms for PCL, in particular the extension forDiffie-Hellman exponentials as found in [DDMP05, Dat05, Der06, DDMR07] and the extension forhash functions from [He05, HSD + .1 Diffie-Hellman exponentials In basic PCL [DDMP05, Dat05, Der06, DDMR07], axioms are provided for reasoning about Diffie-Hellman (DH) exponentials. To that end, the logic is extended with four additional axioms andsome changes are made to the language and execution model.
Below we recall the three elements of the DH extension (execution model, logic, proof system)and discuss their implications.
DH extension of the language and execution model.
The programming language andexecution model are extended [DDMR07, page 354] with constructs g ( a ) and h ( a, b ), representingrespectively g a mod p and ( g a mod p ) b mod p . In the PCL papers, the mod p and brackets areusually omitted, resulting in the abbreviations g a and g ab .This extension does not reflect the actual algebraic properties of the exponential. For Diffie-Hellman, the crucial property is that g ab = g ba . This equation must be included in the executionmodel: if it is not, the following sequence of actions (denoted by their action predicates), which isperfectly valid DH-type behaviour, does not correspond to a valid execution in PCL: Send ( X, h ( a, b )) < Receive ( Y, h ( b, a )) (4)Just extending the Has predicate in the logic is not sufficient, as the equivalence still has nocounterpart in the execution model of PCL.
DH extension of the protocol logic.
In basic PCL, the predicate
Fresh ( X, x ) holds for any x generated by thread X (captured by Gen ( X, x )), as long as x is not sent as part of anotherterm. The protocol logic is extended with an additional rule for the Fresh predicate, stating that
Fresh ( X, g ( x )) is true if and only if Fresh ( X, x ) is true, and
Has is extended in [DDMR07, page354] by
Has ( X, a ) ∧ Has ( X, g ( b )) ⊃ Has ( X, h ( a, b )) ∧ Has ( X, h ( b, a ))This rule is intended to capture the Diffie-Hellman equivalence relation. It is not sufficient, evenwith the addition of further axioms, as we show below. DH extension of the proof system.
The proof system is extended in [DDMR07, page 354,Table A.1] by a definition and four new axioms. We reproduce them here:Define
Computes (DH)
Computes ( X, g ab ) ≡ (cid:16)(cid:0) Has ( X, a ) ∧ Has ( X, g b ) (cid:1) ∨ (cid:0) Has ( X, b ) ∧ Has ( X, g a ) (cid:1)(cid:17) This definition captures the intuition that a thread can compute the value of g ab if and only ifit has the required components. Note that for a thread that just has g ab but not a or b , thispredicate is false, and therefore we have that Has ( X, g ab ) does not imply Computes ( X, g ab ).Note that the definition of Computes suggests that g ab = g ba , because of the explicit listing ofboth sides of the disjunction. If the equality would hold, one could just define Computes ( X, g ab ) ≡ Has ( X, a ) ∧ Has ( X, g b ) to achieve the same result.Using the definition of Computes , the first axiom is given as:
DH1
Computes ( X, g ab ) ⊃ Has ( X, g ab )and corresponds to the extension of the Has predicate, which can be seen by unfolding the definitionof
Computes . The second axiom states
DH2
Has ( X, g ab ) ⊃ (cid:16) Computes ( X, g ab ) ∨ ∃ m. (cid:0) Receive ( X, m ) ∧ Contains ( m, g ab ) (cid:1)(cid:17) g ab by computing it fromits parts, or receiving it. Effectively this restricts any agent (including the intruder) from knowinga term of the form g ab at the start of each run, but it also excludes that g ab is used as a parameterfor a protocol.For completeness, we also give the remaining DH axioms DH3 (cid:0)
Receive ( X, m ) ∧ Contains ( m, g ab ) (cid:1) ⊃∃ Y, m ′ . (cid:0) Computes ( Y, g ab ) ∧ Send ( Y, m ′ ) ∧ Contains ( m ′ , g ab ) (cid:1) DH4
Fresh ( X, a ) ⊃ Fresh ( X, g a )which capture the assumption that g ab must have been either computed or received (but was notgiven as a parameter). The fourth axiom echoes the extension of the Fresh predicate.Summarizing, even with the extension of the
Has predicate and the additional axioms, thebehaviour of the equivalence for Diffie-Hellman is not captured in PCL, for two reasons. First,with respect to the execution model, the sequence of actions represented by Formula (4) cannot beenabled in the execution model by just changing the protocol logic. Second, we observe that given
Has ( X, h ( a, b )), the protocol logic does not allow us to conclude that Has ( X, h ( b, a )) as one wouldexpect (especially in the case where ¬ Computes ( X, h ( a, b ))). Hence, the essential equivalence forany Diffie-Hellman type protocol is currently not captured in the execution model, nor in theprotocol logic. The Diffie-Hellman extension does not correctly capture the algebraic properties of Diffie-Hellmanexponentials. As a result, certain possible behaviours of DH-like protocols are not consideredwithin the logic and its execution model. The extension is therefore not a faithful representationof DH-like protocols.
The essential feature to be captured is the equality g ab = g ba . If this is introduced at the termlevel, e.g. by having the equality h ( a, b ) = h ( b, a ) in the term system, this solves at the same timethe problem in the execution model, protocol logic and proof system. Some further modificationsto the axioms are required, and the current proofs have to be modified to take the term equalityinto account. In [He05] and [HSD +
05] basic PCL is extended and applied to a case study of protocols thatdo not rely solely on signatures. As observed previously, such an application requires additionalaxioms. In particular, to prove authentication, we need to introduce an axiom that allows us toconclude the existence of a thread.Appendix A of [HSD +
05] gives such additional axioms and definitions for keyed hash functions:one definition and four hashing axioms. We reproduce them here for convenience.Define
Computes (HASH)
Computes ( X, HASH K ( a )) ≡ Has ( X, K ) ∧ Has ( X, a )As we will see in the following, the intention of this predicate seems to be to express which threadcomputed the hashed value from its components. However, this intuition is not correctly capturedby the definition: a typical use pattern of a keyed hash would be to provide an integrity check fora message m , as in ˆ X → ˆ Y : m, HASH K ( m ) , (5)where K is a key shared between ˆ X and ˆ Y . In the typical use pattern, the HASH K ( m ) is receivedby an agent which at that point can construct the message m himself. In this use case, the messagehash is received with (or after) the message, and is then used to verify the integrity of the message.11ssume we have that m (or some subterm of it) is freshly generated by X , and we havethat Computes ( X, HASH K ( m )) holds. However, we can also prove that once a thread Y ofthe recipient ˆ Y receives the message, Y not only has K , but also m . Thus the predicate Computes ( Y, HASH K ( m )) holds as well. Put differently, we have that for a typical use case, Computes ( . . . ) holds for both the thread who creates as well as the thread who receives. In par-ticular, this is also true for the protocols under consideration in [HSD + K be a key shared between ˆ X and ˆ Y . Then, we can prove the following property (invari-ant) for the protocols in [HSD + Honest ( ˆ X ) ∧ Has ( X, HASH K ( m )) ⊃ Computes ( X, HASH K ( m )) (6)Intuitively one can see that an honest agent either creates the hash by having the components,or receives it. In this last case, where an honest agent receives the hash, the message integrity isverified using the hash, which is possible only because the recipient also has both the key K andthe message m . We will use this result in our discussion of the HASH4 axiom later on.The first axiom in [HSD +
05, Appendix A] that uses the definition of
Computes () is the following:
HASH1
Computes ( X, HASH K ( x )) ⊃ Has ( X, x ) ∧ Has ( X, K )If we unfold the definition of
Computes in this axiom, it reduces to φ ⊃ φ . The second hash axiomstates the following: HASH2
Computes ( X, HASH K ( x )) ⊃ Has ( X, HASH K ( x ))This axiom informally states that whoever computes the hash value also has it. If we again unfoldthe definition of Computes , we can see that this works as an extension of the closure properties ofthe
Has predicate (as defined in [DDMR07]). Effectively, it introduces a new term structure f x ( y )to the PCL syntax, and expresses the one-way property of the hash function.The third hash function axiom is HASH3
Receive ( X, HASH K ( x )) ⊃ ∃ Y. Computes ( Y, HASH K ( x )) ∧ Send ( Y, HASH K ( x )) .This axiom is not sound. Consider the following protocol in Alice and Bob style notation, where m is a freshly generated nonce of the initiator, and K ′ is a symmetrical key shared by the initiatorand responder: Init → Resp : ENC K ′ {| HASH K ( m ) |} Resp → Init : HASH K ( m ) (7)In a normal run of this protocol, the initiator sends the hash as part of a bigger term, but does notsend m . Thus the responder cannot compute the hash itself, but simply decrypts the message, andsends the hash back. Thus, the preconditions are fulfilled by an initiator thread of this protocol,but the postcondition does not hold: only the initiator thread can compute it, but it does not sendit out in the required form. (Observe that contrary to the protocols in [HSD + HASH4
Has ( X, HASH K ( x )) ⊃ Computes ( X, HASH K ( x )) ∨∃ Y, m.
Computes ( Y, HASH K ( x )) ∧ Send ( Y, m ) ∧ Contains ( m, HASH K ( x )) .This axiom seems to express: if someone has the hash value, she computed the hash herself, orsomebody computed it and sent it (possibly as a subterm). Note that this cannot be proven using only basic PCL, but it can be proven using PCL combined with themeta-reasoning required to capture the assumption that variables are typed, as pointed out in Section 3.3.
HASH K ( x ) initially without knowing the components) this axiom can be proven sound. However,there is a problem with the applications of the axiom in the proofs of [DDMR07]. Each time thisaxiom is applied in proofs in the paper, one assumes honesty of ˆ X and ˆ Y , and that K is the keyshared between them. Thus we can rewrite the application of axiom HASH4 using Formula (6),as in the following. First we unfold the definition of the axiom
Honest ( ˆ X ) ∧ HASH4 = Honest ( ˆ X ) ∧ (cid:0) Has ( X, HASH K ( x )) ⊃ Computes ( X, HASH K ( x )) ∨ Φ (cid:1) , (8)where Φ is used to denote the right-hand disjunct of the axiom HASH4 , starting from theexistential quantifier. Now we use Formula (6) to get
Honest ( ˆ X ) ∧ HASH4 = Honest ( ˆ X ) . (9)In other words, if ˆ X is assumed to be honest when applying axiom HASH4 , the left-hand disjunctof the conclusion is always true (rendering the right-hand disjunct inconsequential). Because theright-hand disjunct of the conclusion contains the required thread existence, but is rendered useless,the axiom cannot be used here for proving authentication properties, based on our observationsin Section 3.1.
The authentication proofs of the four-way handshake and group key handshake protocols in[HSD +
05, He05] are not correct in their current form. The reason for this is that these proto-cols do not contain signatures, and based on the observations in Section 3.1, any authenticationproofs for such protocols must rely on newly introduced axioms. In this case, the only candidatesare the axioms
HASH3 and
HASH4 . As shown above,
HASH3 is not sound, and for the pro-tocols in [HSD +
05, He05],
HASH4 cannot be used to prove the existence of a thread. Hence theauthentication proofs of the handshakes are incorrect, and therefore also the compositional proofof authentication of IEEE 802.11i is incorrect.
The properties of a keyed hash function like the ones occurring here are similar to the propertiesof symmetric-key cryptography. Thus, once sufficient reasoning infrastructure is in place forsymmetric-key cryptography, one can devise a straightforward definition of a non-keyed hashfunction. Combining these two elements should lead to a natural definition and extension of thelogic for keyed hashes.Alternatively, it might be possible to reinstate rules that were used in older works, as e.g. foundin [DDMP04a, page 15], assuming that their soundness can be proven in the current semantics.
In this paper, we have first shown that basic PCL as defined in [DDMP05,Dat05,Der06,DDMR07]cannot be used to prove authentication properties of protocols without signatures. We considerthis to be a strong limitation on the scope of basic PCL. Next, we have pointed out two reasoningtools that are missing in basic PCL: reasoning about preceding actions of a role within a thread,and the lack of a formal type system. With respect to PCL extensions, we have shown that the PCLDiffie-Hellman extension from [DDMP05, Dat05, Der06, DDMR07] does not capture the algebraicbehaviour of Diffie-Hellman protocols correctly in the execution model and protocol logic. Finally,we have shown that the extension for protocols with keyed hash functions in [HSD +
05, He05] isnot sound. 13t follows that some currently claimed PCL proofs cannot be proven within the basic logicas defined in [DDMP05, Dat05, Der06, DDMR07], or make use of unsound axioms. These proofsinclude the authentication proofs of the CR protocol from [DDMR07,DDMP05] and the SSL/TLSand IEEE 802.11i protocols from [He05, HSD + References [ABB +
05] A. Armando, D. Basin, Y. Boichut, Y. Chevalier, L. Compagna, L. Cuellar, P.H.Drielsma, P. He´am, O. Kouchnarenko, J. Mantovani, S. M¨odersheim, D. von Oheimb,M. Rusinowitch, J. Santiago, M. Turuani, L. Vigan`o, and L. Vigneron. The AVISPAtool for the automated validation of internet security protocols and applications.volume 3576 of
Lecture Notes in Computer Science , pages 281–285. Springer-Verlag,2005.[BAN90] M. Burrows, M. Abadi, and R. Needham. A logic of authentication.
ACM Transac-tions on Computer Systems , 8(1):18–36, 1990.[Bla01] B. Blanchet. An efficient cryptographic protocol verifier based on Prolog rules. In
Proc. 14th IEEE Computer Security Foundations Workshop (CSFW) , pages 82–96.IEEE Computer Society, 2001.[BMV03] D. Basin, S. M¨odersheim, and L. Vigan`o. An on-the-fly model-checker for securityprotocol analysis. In
ESORICS , volume 2808 of
Lecture Notes in Computer Science ,pages 253–270. Springer-Verlag, 2003.[BR94] M. Bellare and P. Rogaway. Entity authentication and key distribution. In
CRYPTO’93: Proceedings of the 13th annual international cryptology conference on Advancesin cryptology , pages 232–249, New York, NY, USA, 1994. Springer-Verlag.[CMdV06] C.J.F. Cremers, S. Mauw, and E.P. de Vink. Injective synchronisation: an extensionof the authentication hierarchy.
Theoretical Computer Science , 2006.[Cre06] C.J.F. Cremers.
Scyther - Semantics and Verification of Security Protocols . PhD the-sis, Computer Science Department, Eindhoven University of Technology, November2006.[Dat05] A. Datta.
Security Analysis of Network Protocols: Compositional Reasoning andComplexity-theoretic Foundations . PhD thesis, Computer Science Department, Stan-ford University, September 2005.[DDMP03a] A. Datta, A. Derek, J. C. Mitchell, and D. Pavlovic. Secure protocol composition(extended abstract). In
FMSE ’03: Proceedings of the 2003 ACM workshop on Formalmethods in security engineering , pages 11–23, New York, NY, USA, 2003. ACM.[DDMP03b] A. Datta, A. Derek, J.C. Mitchell, and D. Pavlovic. A derivation system for secu-rity protocols and its logical formalization. In
Proc. 16th IEEE Computer SecurityFoundations Workshop (CSFW) , pages 109–125. IEEE Computer Society, 2003.14DDMP04a] A. Datta, A. Derek, J.C. Mitchell, and D. Pavlovic. Abstraction and refinement inprotocol derivation. In
Proc. 17th IEEE Computer Security Foundations Workshop(CSFW) , pages 30–45, Washington, DC, USA, June 2004. IEEE Computer Society.[DDMP04b] A. Datta, A. Derek, J.C. Mitchell, and D. Pavlovic. Secure protocol composition.
Electron. Notes Theor. Comput. Sci. , 83, 2004. Proceedings of 19th Annual Confer-ence on Mathematical Foundations of Programming Semantics.[DDMP05] A. Datta, A. Derek, J.C. Mitchell, and D. Pavlovic. A derivation system and com-positional logic for security protocols.
Journal of Computer Security , 13(3):423–482,2005.[DDMR07] A. Datta, A. Derek, J.C. Mitchell, and A. Roy. Protocol Composition Logic (PCL).
Electron. Notes Theor. Comput. Sci. , 172:311–358, 2007. Computation, Meaning,and Logic: Articles dedicated to Gordon Plotkin. Editors: L. Cardelli, M. Fiore, andG. Winskel.[DDMW06] A. Datta, A. Derek, J.C. Mitchell, and B. Warinschi. Computationally sound com-positional logic for key exchange protocols.
Proc. 19th IEEE Computer SecurityFoundations Workshop (CSFW) , 0:321–334, 2006.[Der06] A. Derek.
Formal Analysis of Security Protocols: Protocol Composition Logic . PhDthesis, Computer Science Department, Stanford University, December 2006.[DMP01] N.A. Durgin, J.C. Mitchell, and D. Pavlovic. A compositional logic for protocolcorrectness. In
Proc. 14th IEEE Computer Security Foundations Workshop (CSFW) ,pages 241–272, 2001.[DMP03] N. Durgin, J.C. Mitchell, and D. Pavlovic. A compositional logic for proving securityproperties of protocols.
Journal of Computer Security , 11:667–721, 2003.[He05] C. He.
Analysis of Security Protocols for Wireless Networks . PhD thesis, Departmentof Electrical Engineering, Stanford University, December 2005.[HSD +
05] C. He, M. Sundararajan, A. Datta, A. Derek, and J.C. Mitchell. A modular cor-rectness proof of IEEE 802.11i and TLS. In
CCS ’05: Proceedings of the 12th ACMconference on Computer and communications security , pages 2–15. ACM Press, 2005.[Low97a] G. Lowe. Casper: A compiler for the analysis of security protocols. In
Proc. 10thIEEE Computer Security Foundations Workshop (CSFW) , pages 18–30. IEEE Com-puter Society, 1997.[Low97b] G. Lowe. A hierarchy of authentication specifications. In
Proc. 10th IEEE Com-puter Security Foundations Workshop (CSFW) , pages 31–44. IEEE Computer Soci-ety, 1997.[RDD +
06] A. Roy, A. Datta, A. Derek, J. C. Mitchell, and J.-P. Seifert. Secrecy analysis inprotocol composition logic. In M. Okada and I. Satoh, editors,