Noname manuscript No.(will be inserted by the editor)

Measuring Protocol Strength with Security Goals

Paul D. Rowe · Joshua D. Guttman · Moses D. Liskov

the date of receipt and acceptance should be inserted later

Abstract Flaws in published standards for securityprotocols are found regularly, often after systems imple-menting those standards have been deployed. Becauseof deployment constraints and disagreements amongstakeholders, different fixes may be proposed and de-bated. In this process, security improvements must bebalanced with issues of functionality and compatibility.

This paper provides a family of rigorous metrics forprotocol security improvements. These metrics are setsof first order formulas in a goal language GL(Π) asso-ciated with a protocol Π. The semantics of GL(Π) iscompatible with many ways to analyze protocols, andsome metrics in this family are supported by many pro-tocol analysis tools. Other metrics are supported by ourCryptographic Protocol Shapes Analyzer cpsa.

This family of metrics refines several “hierarchies” ofsecurity goals in the literature. Our metrics are applica-ble even when, to mitigate a flaw, participants must en-force policies that constrain protocol execution. We rec-ommend that protocols submitted to standards groupscharacterize their goals using formulas in GL(Π), andthat discussions comparing alternative protocol refine-ments measure their security in these terms.

1 Introduction

Security standards often contain flaws, and thereforeevolve over time as people correct them. Often, theseflaws are discovered after deployment, which puts pres-sure on the choice of mitigation. The constraints ofoperational deployments and the needs of the variousstakeholders are crucial, but so is understanding thesignificance of the attack.

The MITRE Corporation.E-mail: {prowe,guttman,mliskov}@mitre.org.

How are we to choose among the alternatives pro-posed to repair a flaw? A security flaw is a failure of theprotocol to meet a goal—often one not well understooduntil after the flaw becomes apparent—and a revisedunderstanding of the goals of the protocol is necessaryto ensure that the mitigation is secure. Obviously, sat-isfying a goal that was not previously met is essentialto any mitigation. However, two alternatives may elim-inate the same insecure scenario while differing in thesecurity they provide.

In this paper, we describe a formal language for ex-pressing protocol security goals. We use sets of formulasin this language to compare protocols. A protocol Π2

is then at least as secure as another protocol Π1 withrespect to a set of goal formulas G if, for each formulaΓ ∈ G, if Π1 achieves the goal Γ , then so does Π2. Wewill explore various sets of formulas G below. We willargue that any set G containing formulas of a reason-able syntactic form should be regarded as a “measure-ment” for the security of the protocols.

In the case of a singleton G = {Γ}, we can use a va-riety of protocol analysis tools such as Maude-NPA [18],ProVerif [8], Scyther [14], and our Cryptographic Pro-tocol Shapes Analyzer cpsa [32] to ascertain whetherΠ2 is at least as secure as Π1 with respect to G. It suf-fices to show that Π2 achieves the goal Γ , or else thatsome attack on Π1 provides a counterexample show-ing that Π1 does not achieve Γ . In the same spirit, wecan use the same tools to measure protocols relative totwo-element sets G = {Γ1, Γ2} or other finite sets. Wesimply evaluate the protocols for each goal separatelyand combine the results.

cpsa also allows protocol comparisons using largersets G, especially sets of implications Φ =⇒ Ψ that allshare the same hypothesis Φ.

Measuring security. To compare alternative fixes,we need to measure the security of the alternatives. Weview their security as their power to exclude failures.This suggests the basic tenet:

Tenet: A system S2 is at least as secure as S1, writtenS1 � S2, if and only if any attack that is successfulagainst S2 is also successful against S1.

Of course, it is difficult to instantiate this tenet in gen-eral. It requires a robust and realistic model of theadversary’s capabilities, and it requires a clear under-standing of what constitutes an attack. We will think ofattacks as possible goals that fail, rather than as mean-ing the specific bad executions that illustrate how theycan fail.

Indeed, S1 and S2 have to be sufficiently similar tomake sense of the “same” attack succeeding on each sys-tem. Nevertheless, we believe this tenet can be used toclarify why some security metrics provide more insightthan others. Let M be some measurement techniquethat yields values in a domain ordered by ≤. An idealproperty to strive for in measuring security is the fol-lowing.

M(S1) ≤M(S2) iff S1 � S2 (1)

The crux here is a general philosophy of measure-ment, according to which the outcome of measurementunder the ≤ ordering should be a perfect substitute forthe � ordering applied directly to the systems. Luceand Suppes [27] refer to this as the Axiom of Order fortheories of measurement. In practice, we may have toweaken property (1) in several ways. For instance, wemight only achieve the property if we relativize � to arestricted class A of attacks and adversaries yielding arestricted security ordering �A. But it serves to explainwhy certain metrics do not measure security well. Let’sconsider a simple example.

The number of lines of code tends to be correlatedwith the number of bugs in software, and hence to thenumber of security vulnerabilities. If we let M be amethod that counted the number of lines of code andoutput the negative of that number, then M(S1) ≤M(S2) would mean that S1 has at least as many linesof code as S2. But it certainly does not follow that S2 ismore secure than S1. In this instance M(S1) ≤ M(S2)

is only loosely correlated with S1�S2, and so the metricis not very reliable.

The lines-of-code metric also has a property that iscommon to many security metrics proposed in the liter-ature: it takes values in the real numbers. The urge tohave quantitative metrics is understandable, especiallywhen striving to achieve the rigor of measurement inthe physical sciences. Analogies to length, weight, tem-perature, etc. make quantitative metrics almost irre-

sistible. But our basic tenet shows why this approachcannot work in general. If the � security ordering natu-rally corresponds to sets of attacks ordered by inclusion,only very rarely will systems be totally ordered by �. Inmany cases S1 will admit attacks that S2 does not allowand vice versa, meaning � tends to be only a partialorder. Any metric that tries to totally order systems isvery likely not to achieve property (1).

This paper represents an instantiation of our generalphilosophy of measuring security. We recognize thateach time there is an attack on a protocol that meansthere is some (possibly unstated) security goal the pro-tocol does not achieve. Definition 3 in Section 3.3 is areformulation of our basic tenet.

By security goal, we will mean logical formula ofa particular form. Roughly speaking, a security goalis an implication Φ =⇒ Ψ where Φ is a conjunction ofatomic formulas, and Ψ is built from atomic formulas byconjunction, disjunction, and existential quantification.(See Def. 1 in Section 3.1). When G is a set of formulasof this form, we will write Π1 �

G Π2 to mean that, forevery formula Γ ∈ G, if Π1 achieves Γ , then so doesΠ2. When G is a singleton, several protocol analysistools can assist in determining whether Π1 �

G Π2.

Enrich-by-need. Enrich-by-need analysis—as in theCryptographic Protocol Shapes Analyzer (cpsa) [32]or in Scyther [14]—allows us to resolve �G for someimportant non-singleton sets G.

Each enrich-by-need analysis process starts from ascenario containing some protocol behavior, such as oneor more participant’s local runs, and also some assump-tions about freshness and uncompromised keys. Theanalysis returns a set of result scenarios that show allof the minimal, essentially different ways that the start-ing scenario could happen. When the starting scenariois undesirable (e.g. a confidentiality failure), we wouldlike this to be the empty set. When the starting scenariois the behavior of one principal, then the analysis findswhat the protocol guarantees from that participant’s“point of view.” These results indicate what authenti-cation guarantees the protocol provides to that party.

For each run of the analyzer, there is a security goalformalizing the result of the analysis. Its hypothesis Φdescribes the content of the starting scenario, and itsconclusion is a disjunction. Each disjunct describes thecontent of one minimal, essentially different executioncontaining the starting point. Thus, this is a strongestsecurity goal with hypothesis Φ.

Specifically, this goal is strongest in the implicationordering, where Γ2 =⇒ Γ1 means that Γ1 is below Γ2 inthis ordering. Enrich-by-need analysis computes maxi-mal elements for certain subclasses G of security goals.Enrich-by-need can act as our measurement technique,

2

M , satisfying property (1) relative to the security order-ing �G. In Section 6.3 we will identify key subclasses Gof goals, defined in equation (9), for which each protocolachieves a unique strongest goal (Theorem 2). The max-imal elements identified by the enrich-by-need methodallow us to measure and compare protocol security rel-ative to �G (Corollary 1).

Application to standards. A concrete formal lan-guage of security goals makes security claims explicitand verifiable. One reason flaws and weaknesses are re-peatedly discovered in published standards is that thestandards include vague statements, for example abouttwo parties achieving “authentication,” without explain-ing what that means in practice. Basin et al. [5] haveillustrated the problems that can arise when standardsdo not contain any claims about what properties theyachieve or under which adversary models. It is thus im-portant for the standardization process to create con-crete artifacts that serve as evidence of the security ofa protocol design.

Our logical language of security goals supports thegoals of [5]. We envision a process where those propos-ing a protocol are required to include explicit and for-mal claims about what security properties it achieves.These claims should be explicit enough to allow for-mal, independent verification that the protocol achievesthose security properties. The International Organiza-tion for Standardization (ISO) and International Elec-trotechnical Commission (IEC) have started to lay thetechnical groundwork for such a process by publishinga standard (ISO/IEC 29128 [19]) for certifying the de-sign of cryptographic protocols. While this is a goodstart, it still leaves room for ambiguity based on thespecific formalism chosen. Our language is designed tobe independent of both the underlying formalism usedto represent the protocol and the tool(s) used to verifythe claim. This allows a proposal to be verified rela-tive to the same claim by independent experts usingdifferent tools.

Despite such efforts to avoid protocol weaknessesearly in the standardization process, flaws will still un-doubtedly be discovered after publication and deploy-ment. Our development here of a hierarchy of securitygoals �G against which to measure security is usefulfor this purpose. By expressing the flaw as some (pre-viously unstated) goal that is not achieved, standardscommittees can more easily identify and compare re-lated goals. Having an objective measure of the rela-tive strength of security goals will allow the committeemembers to separate the security properties from otherfactors that may affect the feasibility of certain mitiga-tions. The use of enrich-by-need analysis is particularlyappropriate in this case, because the analysis can com-

pare the strength of two proposed mitigations relativeto an infinite set of goals that share some hypothesis Φ.Since the analysis results in the strongest security goalwith Φ as a hypothesis, it does not require as much in-genuity on the part of the committee members to iden-tify a particular strengthened security goal. This is anadvantage, especially since flaws are frequently alreadythe result of the failure of imagination in the humandesigners to identify useful security goals.

Our contributions. We make three main contribu-tions.

1. We introduce the metrics of security �G for crypto-graphic protocols. Each metric is parameterized bysome set of desired security goals G.

2. We identify the sets G for which the enrich-by-needanalysis method can act as a measurement tool Mto compare the security of two or more protocolsrelative to �G.

3. We ground our theory in protocols that have un-dergone standardization. We compare our sets Gwith security goals discussed in the literature. Ourmethods can guide standards bodies’ deliberationson proposed designs and protocol improvements.

Structure of this paper. In order to help the readergain intuition for when and why it is useful to measureand compare the security of protocols, we begin in Sec-tion 2 by considering the Kerberos public key extensionpkinit. The initial version contained a flaw allowing aman-in-the-middle attack. Two alternatives emerged tofix this. We build up some intuition about how to for-mally express the security goals not met by the flawedversion. Section 3 develops our logical language of se-curity goals and explains how sets of goals can serve assecurity metrics.

Having explained our central ideas, we discuss re-lated work in Section 4. We explain, in depth, the con-nection between our logical security goals related byimplication and well-studied authentication hierarchies.We show how our formalism encompasses and extendsthat previous work. In Section 5, we show that our log-ical language helps us to understand how policy con-siderations that sit outside a protocol proper can con-tribute to the protocol’s security. In Section 6 we ex-plain the enrich-by-need method with examples, andprove that it allows us to compare protocols with re-gard to some infinite sets of goals. Concluding thoughtsare in Section 7.

This paper is an extended version of our [23].

3

Cm1 //

��

KAS

��• •

m2oo

m1 = [tC , n2]sk(C), C, T, n1

m2 = {|[k, n2]sk(S)|}pk(C), C, TGT, {|AK,n1, tS , T |}k

Fig. 1 pkinit version 25, where TGT = {|AK,C, tS |}kT

2 Example: Kerberos pkinit

pkinit [39] is an extension to Kerberos [30] that allowsa client to authenticate to the Kerberos authenticationserver (KAS ) and obtain a ticket-granting ticket us-ing public-key cryptography. This is intended to avoidthe management burden of establishing and maintain-ing user passwords, which the standard Kerberos ex-change requires.

Cervesato et al. [11] found a flaw in pkinit version25, which was already widely deployed. The flaw waseventually fixed in version 27. Figure 1 shows the ex-pected message flow between the client and the KAS

in v. 25. The client provides a KAS with its identity C,the identity T of the server it would like to access, anda nonce n1. It also includes a signature over a times-tamp tC and a second nonce n2 using the client’s pri-vate key sk(C). The KAS with identity S replies bycreating a fresh session key k, signing it using its keysk(S) together with the nonce n2 and encrypting thesignature using the client’s public key pk(C). It usesthe session key k to protect another session key AK tobe used between the client and the subsequent server T ,together with the nonce n1 and an expiration time tSfor the ticket. The ticket TGT is an opaque blob fromthe client’s perspective because it is an encryption us-ing a key shared between S and T . It contains AK,the client’s identity C and the expiration time tS of theticket.

The flaw. In Cervesato et al.’s attack [11] (Fig. 2),an adversary I has obtained a private key to talk withthe KAS S. I uses it to forward any client C’s ini-tial request, passing it off as a request from I. I simplyreplaces C’s identity with I’s own, re-signing the times-tamp and nonce n2. When the S responds, I re-encryptsthe response for C, this time replacing the identity I

with C. In the process, the adversary learns the sessionkey k, and thus can also learn the subsequent sessionkey AK. This allows the attacker to read any subse-quent communication between the client and the nextserver T . Moreover, the adversary may impersonate theticket granting server T to C, and vice versa, because

Cm1 //

��

Im′

1 //

��

KAS

��• •

m2oo •m′

2oo

m1 = [tC , n2]sk(C), C, T, n1

m′1 = [tC , n2]sk(I), I, T, n1

m2 = {|[k, n2]sk(S)|}pk(C), C, TGT, {|AK,n1, tS , T |}km′2 = {|[k, n2]sk(S)|}pk(I), I, TGT, {|AK,n1, tS , T |}k

Fig. 2 Attack on flawed pkinit, where TGT = {|AK, I, tS |}kT

Cm1 //

��

KAS

��• •

m2oo

m1 = [tC , n2]sk(C), C, T, n1

m2 = {|[k,F(C,n2)]sk(S)|}pk(C), C, TGT, {|AK,n1, tS , T |}k

Fig. 3 Generic fix for pkinit

the participants rely on the protocol to ensure that theyare the only entities with knowledge of AK.

The attack arises from a lack of cryptographic bind-ing between the session key k, and the client’s iden-tity C [11]. After C’s two-message exchange, she knowsthe KAS produced the keying material k recently, be-cause of its binding with n2. However, the KAS S maynot have intended k for C.

The protocol revision process. Since this absenceof C’s identity is the root cause of the attack, the natu-ral fix is to include C as an additional field in the signedportion of the second message. Indeed this is the firstsuggestion in [11].

The authors of the pkinit standard offered a differ-ent suggestion. For operational feasibility—namely, topreserve the previous message format—more than se-curity, the pkinit authors suggested replacing n2 witha message authentication code over the entirety of thefirst message, keying the MAC with k. Since the client’sidentity is contained in the first message, this proposalalso creates the necessary cryptographic binding be-tween k and C, as well as with n2.

Cervesato et al. used a manual proof method to ver-ify a generic scheme for mitigating the attack (Fig. 3),ensuring that the two proposals were instances of thescheme. This allowed them to avoid the time-consumingprocess of writing proofs for any other proposals thatmight also fit this scheme. They verified that the attackfails if n2 is replaced with any expression F (C, n2, . . .)

that is injective on C and n2; that is, F (C, n2, . . .) =

F (C ′, n′2, . . .) implies C = C ′ and n2 = n′2.

4

We obtain the first proposal by instantiating F asconcatenation: F (C, n2) = C, n2. The second proposalinstantiates F as the MAC of the client’s request:

F (C, n2, . . .) = Hk([tC , n2]sk(C), C, T, n1).

Since the MAC provides second preimage resistance,the injectivity requirement will hold, with overwhelm-ing probability, in any execution the adversary can en-gineer.

Security goals. The pkinit parable illustrates re-curring themes in developing and maintaining protocolstandards. An attack often shows us that we care aboutpreviously unstated and unrecognized security goals asobserved by Basin et al. [5]. pkinit achieves some levelof authentication, but it fails a more stringent type ofauthentication. In Lowe’s terms [26], it achieves recentaliveness both for the client and for the KAS S, be-cause each party signs time-dependent data. However,pkinit does not achieve weak agreement, since C doesnot know that S was engaged in the protocol with C.The attack helps us to express the goal that the flawedprotocol does not meet.

But an attack itself does not uniquely identify asecurity goal. We learned that it is important for theclient to be guaranteed that it agrees with S on theclient’s identity, but what about other values such asthe expiration time of the ticket? Operational difficul-ties might arise if the client is unaware of this expirationtime, but are there any security consequences? Indeeda key contribution of [11] is to state carefully what se-curity goal the repair provides.

This goal can be achieved in different ways. Differentstakeholders may prefer different mitigations becauseof issues of efficiency, ease of deployment, or robustnessto future modification. In pkinit, the researchers optedfor a change that was minimally invasive to their for-mal representation, thereby highlighting the root causeof the problem. The protocol designers had more oper-ational context to constrain the types of solutions theydeemed feasible.

While a pair of choices might both manage to sat-isfy some stated security goal, one of them may actuallysatisfy strictly stronger goals than another. We proposea goal language (Section 3) to express when a proto-col mitigation is at least as good as a competitor—orstrictly better than it—from the security point of view.

Strand spaces. We will develop our ideas using thestrand space terminology [37,20]. A strand is a sequenceof transmission and reception events, each of which wewill call a node. We use strands to represent the behav-ior of a single principal in a single local protocol ses-sion. We call these regular strands. We also use strands

to represent the basic abilities of the adversary. Forinstance, a strand representing the adversary’s abilityto encrypt contains two reception nodes, in which theplaintext t and the encryption key K are received, fol-lowed by a transmission node in which the encryptionis sent:

• +3 • +3 •��

t

OO

K

OO

{|t|}K

By convention, we draw strands with double-arrowsconnecting the successive nodes • ⇒ •, and single ar-rows indicating the message flow • → •.

In this framework an execution is a kind of directedgraph with these two kinds of edges. These graphs arebundles, meaning all finite directed acyclic graphs where(i) the nodes at the two ends of a message transmissionarrow are labeled with the same message; (ii) each re-ception node has exactly one incoming message; and(iii) when a node on a strand is included in the graph,then so are all its predecessors on that strand. How-ever, a bundle does not have to run all of the strands“to completion,” and it may therefore contain only aninitial segment of the nodes of that strand.

A protocol Π is a finite set of strands, called theroles of Π, together with possibly some auxiliary as-sumptions about fresh and non-compromised values.The messages sent and received on these strands con-tain parameters such as C, S,AK, n1, n2, . . . in pkinit.The regular strands of Π consist of all strands obtainedfrom the roles of Π by applying substitutions to theseparameters. A Π-bundle is a bundle where every strandis either an adversary strand or a regular strand of theprotocol Π.

Fig. 2 becomes a pkinit-bundle when we expand thesingle central strand labeled I into a collection of adver-sary strands. We consider Fig. 2 an informal shorthandfor the resulting bundle.

Formalizing the authentication goal. The attackof [11] undermines what the client C should know whenhe has completed a local run of pkinit. The clientknows less about what the KAS S has done than ex-pected.

The actions of the regular (non-adversary) princi-pals are message transmission nodes and message re-ception nodes. We will formulate the client’s expecta-tion about the KAS ’s behavior as a formula about thetransmission and reception nodes of the principals.

The formula applies in a situation, depicted in (2),where there is a reception node n which completes a run

5

of the client role, which we will write ClientDone(n).

sk(S) ∈ non •s1 ��

//

n oo

(2)

s1 ∈ Client[C, S,_,_,_,_,_,_,_]

This node n belongs to a run of the protocol in whichthe active principal has some identity C, and its in-tended peer is a Kerberos Authentication Server S. Wewill write this Self(n,C) ∧ Peer(n, S). Of course, ifS’s signature key sk(S) is compromised, then C learnsnothing from a run of the protocol. Thus, we will as-sume that it is uncompromised, written as Non(sk(S)).For the moment, we ignore the other parameters of theClient role, since we will not assume anything aboutthem.

We regard these formulas as forming a hypothesis,when combined by conjunction. Thus, we would liketo understand what must be true when this hypothesisholds:

ClientDone(n) ∧ Self(n,C) (3)∧ Peer(n, S) ∧ Non(sk(S))

In the attack, there is a local run of theKAS role, and infact the server has the intended identity S. The problemis that the server’s intended peer is not the client C, butsome compromised client I. Thus, the behavior in Fig. 2is a counterexample to the goal:

∀n,C, S . (3) =⇒ ∃m. KASDone(m) (4)∧ Self(m,S) ∧ Peer(m,C)

where the whole of formula (3) is the hypothesis, al-though we have contracted it to save space. Here alsowe write KASDone(m) to indicate that the transmissionnodem is the final node of the KAS ’s role. We again useSelf to refer to the identity of the participant enactingthis role, and Peer to refer to its intended partner.

Clearly this is a weak goal, since it says nothingabout other parameters such as the nonces n1, n2, thesession key k, or the server T that the ticket will beshared with. But Fig. 2 is also a counterexample to allits stronger goals.

A curious fact about this formalism is that it saysnothing about the specific messages sent. It talks aboutthe nodes, such as n,m, and asserts that they lie on aparticular role at a specific position in the sequence ofnodes in which the role engages. It talks about the pa-rameters associated with the nodes. For instance, thePeer parameter of n is the same identity S whose sig-nature key is assumed to be uncompromised. Moreover,this is the same as the Self parameter of some nodem, and that m is a KASDone node.

However, it never assumes or asserts that the mes-sages formed from the parameters have a particular lay-out or structure. This means that the same formula candescribe executions in different protocols.

For instance, it is clear how to interpret formula (4)in the two revised versions of pkinit. There is a self-explanatory convention that links protocols in pkinitv. 25 to roles in its two candidate successors, and simi-larly for their parameters. When the protocols are moreremotely related, Guttman’s formal notion of transla-tion applies [22]. Our convention allows us to use theidentity translation a large range of cases.

Formalizing a non-disclosure goal. We can repre-sent secrecy goals in a similar style, using a special aux-iliary role which we can assume belongs to all protocolsimplicitly. This is the “listener role” that consists of asingle reception node. It has a single parameter x, andthe message received on this node is x. It representsthe assumption that x is compromised, and observedunprotected. We write Lsn(n) to express that n is thereception node lying on an instance of the listener role.We write Hear(n, x) to express that the message heardon node n is x, i.e. to stipulate a value for the parame-ter of the role. Thus, consider the assumption that addsa listener to formula (3):

ClientDone(n) ∧ Self(n,C) ∧ SessKey(n, k)

∧ Peer(n, S) ∧ Non(sk(S)) (5)∧ Lsn(m) ∧ Hear(m, k)

Here we are also using the predicate SessKey(n, k) torefer to the session key parameter of the client’s finalreception node. The formula asserts that the same valuek is also heard unprotected on the listener nodem. Thisformula represents a situation visualized in (6).

sk(S) ∈ non Cs1 ��

//

n ook // m

(6)

s1 ∈ Client[C, S,_,_,_,_,_, k,_]

For the protocol to ensure secrecy for k in this sit-uation means that this situation should never be ableto arise. Here we interpret secrecy failures as meaningthe full disclosure of a secret. This is coarser than thestandard cryptographic definition, which refers to anyability of the adversary to distinguish the secret from arandom value [6]. Formalizing secrecy as full disclosure,the security goal would be:

∀n,m,C, S, k . (5) =⇒ false (7)

Unfortunately, the adversary can extract k from m′2 inthe run shown in Fig. 2. Thus, Fig. 2 illustrates whythis goal fails: The adversary has the power to transmitk so that it will be heard on a listener node.

6

Thus, both non-disclosure and authentication goalsare expressible using these ideas.

3 Protocol Goals to Measure Security

As we have just illustrated, we express protocol goals asformulas in first order logic. For each protocol Π, thereis a goal language GL(Π); however, these languages aredesigned so that for related protocols, the languages canbe similar or often identical. This helps when comparingthe goals achieved by related protocols.

3.1 The Goal Languages

The goal language is designed to have the minimumpossible expressiveness while remaining useful. It con-tains no arithmetic; it contains no inductively defineddata-types such as terms; and it has no ability to de-scribe the syntax of messages.

This is an important and useful feature of the goallanguage: goals are much easier to view as logical ob-jects that exist independent of a particular protocolwhen they do not reference the syntax or structure ofmessages. The ability to view goals independently fromindividual protocols is essential when trying to comparedifferent protocols in terms of the goals they achieve.This reduced expressiveness has proved useful in priorwork. Formulas in GL(Π) are preserved under a classof “security preserving” transformations between proto-cols [22]. Also, for an interesting restricted class of pro-tocols, Dougherty and Guttman showed the set of se-curity goals they achieve is decidable [16]. Mödersheimet al. [2] show how to adapt another analysis approachto this class of goals.

Predicates in the goal language. We will describethe goal language GL(Π) associated with a given proto-col Π. Although there is a connection between GL(Π)

and Π, our intention is to be able to describe logicalsentences that apply both to Π and to variants of Π.

For each node in a role of Π, the goal languageGL(Π) has an associated role position predicate. Thetwo predicates ClientDone(n) and KASDone(m) usedabove are examples. Each role position predicate is aone-place predicate that says what kind of node its ar-gument n,m refers to.

On each node, there are parameters. The parame-ter predicates are two place predicates. Each parameterpredicate associates a node with one of the values thathas been selected when that node occurs. For instance,Self(n, c) asserts that the self parameter of n is c. Thisallows us to assert agreement between different strands.

Functions: pk(a) sk(a) inv(k)ltk(a, b)

Relations: Preceq(m,n) Coll(m,n) =Unq(v) UnqAt(n, v) Non(v)

Table 1 Protocol-independent vocabulary of languages GL(Π)

Peer(m, c) asserts that m appears to be partnered withc, which is the same principal who is in fact the self pa-rameter of n.

The role position predicates and parameter pred-icates vary from protocol to protocol, depending onhow many nodes the protocol has, and how many pa-rameters. However, when we regard two protocols asvariants of each other, we expect a certain amount ofoverlap between the associated names. For instance, theClientDone(n) predicate in the example should have ameaning (i.e. a node that satisfies it) in any variant ofthe pkinit protocol. Furthermore, we expect that thesatisfying nodes represent informally corresponding ac-tivity in the two variants.

Beside role position predicates and parameter predi-cates, GL(Π) has the protocol-independent vocabularyin Table 1. It helps to express the structural proper-ties of bundles. Preceq(m,n) asserts that either m andn represent the same node, or else m occurs before n;Coll(m,n) says that they lie on the same strand.m = n

is satisfied when m and n are equal. Non(v) and Unq(v)

express non-compromise and freshness (unique origina-tion), and UnqAt(n, v) identifies the node at which v isassumed fresh. pk(a) and sk(a) relate a principal a toits keys, ltk(a, b) represents the long-term shared keyof two principals a, b, and inv(k) is the inverse of a key.

We have only presented here an informal idea of howto interpret formulas in this language. For a full, formaldescription of the semantics of the satisfaction relation|= see [22].

The examples of the last section illustrate how wecan use the vocabulary of GL(Π) to express a vari-ety of security goals. These include authentication goalsand—since we assume that any protocol Π contains thelistener role—non-disclosure goals as well.

Goals. The formulas that we used in our exampleshave a special form. They are implications. Their hy-potheses are conjunctions of atomic formulas of GL(Π).The conclusions took two superficially different forms.Formula (4) has an existential formula as its conclusion.It asserts that an additional event exists, satisfying aparticular role position predicate, and with some pa-rameters matching those in the hypothesis. Formula (7)has the conclusion false. A conclusion could also be adisjunction, where the protocol allows the behavior as-sumed in the hypothesis to be explained in a number

7

of different ways. For instance, the KAS server mayhave executed either the role shown in Fig. 1, or else adifferent role in which it first retrieves a public-key cer-tificate for C, and then replies with the message shownin Fig. 1. Since we may regard false as the degeneratedisjunction with zero disjuncts, and the conclusion offormula (4) as a degenerate disjunction with one dis-junct, we regard them all as having n-ary disjunctionsas conclusions. Since the goals are intended to hold in allcases, we regard any variables free in the whole formulaas implicitly universally quantified. Thus, we stipulate:

Definition 1 A security goal (or sometimes simply agoal) is a closed formula Γ ∈ GL(Π) of the form

∀x . (Φ =⇒∨

1≤j≤i

∃yj . Ψj) (8)

where Φ and Ψj are conjunctions of atomic formulas.We write

hyp(Γ ) = Φ, andconc(Γ ) =

∨1≤j≤i ∃yj . Ψj .

We assume that the existentially bound variables in yjare distinct from all variables in hyp(Γ ); this is no lossof generality, since we can rename bound variables.

Non-disclosure goals here are the special case in whichthe disjunction is empty since the upper index is 0.

We propose to express the security services that pro-tocols provide by a set of formulas of the form (8). Theseso-called geometric sequents are natural to express se-curity goals. Each enumerates some finite number offacts that serve as the hypothesis. Then, the claim inthe conclusion is that one of zero or more alternativesholds, where each of these is a finite number of factsthat should also be found to hold. Thus, the claim islocalized, and independent of the totality of behaviorin the world of users of the protocol. This is quite ap-propriate for security properties.

We do not formalize here indistinguishability prop-erties, which are properties of pairs of runs, or proba-bilistic properties, which focus on the distributions gov-erning runs.

3.2 Measuring a Protocol with Goal Formulas

Security goals admit a natural partial order based onimplication: Γ1 ≤ Γ2 iff Γ2 ⇒ Γ1. Stronger goals arehigher in the partial order. We can use this partial or-der as a measure of the security of a protocol in thefollowing way.

Definition 2 A protocol Π achieves security goal Γiff for every bundle B of Π, B |= Γ .

This provides our formal basis for deciding whethera protocol is “good enough” for a given purpose. An im-mediate consequence of this definition is that achievinggoals is downward closed in the partial order. More for-mally:

Lemma 1 If Π achieves Γ ′ and Γ ≤ Γ ′, then Π alsoachieves Γ .

Thus, if Π achieves some goal Γ , it also achieves anyother goal that is a consequence of Γ .

Def. 2 is intuitively clear. However, it quantifies overall bundles B. This makes it look like a daunting def-inition to verify in practice. Although this problem isknown to be undecidable in general [17], there is a semi-decision procedure for finding counterexamples.

Theorem 1 There is a semi-algorithm to find a bundleB of Π such that B 6|= Γ , if any exists.

Proof Let conc(Γ ) be∨

1≤j≤i ∃yj . Ψj . Since Π-bundlesare finite structures, we can enumerate them. For eachB, again because it is a finite structure, there are atmost finitely many variable assignments η such thatB |=η hyp(Γ ).

For each such η and each j such that 1 ≤ j ≤ i, thereare only finitely many ways to extend η to assign val-ues to the variables yj in B. Thus, we can determinewhether η satisfies ∃yj . Ψj . ut

Of course, the method detailed in the proof above isnaively inefficient. Numerous tools exist that implementmuch more efficient algorithms to achieve the same re-sult. Throughout this paper we use our tool cpsa toimplement this check.

We would like to apply these ideas to pkinit v. 25and the two proposed mitigations from Section 2. Letus use pkinit1 to denote the fix in which F (C, n2) =

(C, n2), and use pkinit2 to denote the other fix in whichF (C, n2) = Hk([tC , n2]sk(C), C, T, n1). In the previoussection we identified formula (4) as the security goalthat is not achieved in pkinit v. 25. Call this formulaΓ . Cervesato et al. prove by hand that both pkinit1

and pkinit2 achieve Γ , so it should be no surprise thatapplying cpsa to those versions confirms the result.Thus both of these fixes are good enough for the newlydescribed goal Γ .

3.3 Comparing Protocols

We want to use security goals not only to measure aprotocol against a given goal, but also to measure therelative strength of two or more protocols Πi againsteach other. We will be able to do this, but only when

8

the role position predicates and parameter predicateshave a well-defined semantics for each Πi. This ensuresthat if Γ is a goal then we can ask whether B |= Γ forany bundle B of any of the protocols Πi.

There is a certain amount of freedom in choosingthe names of these predicates, and the results of thecomparisons will depend on the names chosen. We mayarrive at strange conclusions if, for example, in pkinit1,ClientDone(·) is satisfied by the last node on a clientstrand, but in pkinit2 it is satisfied by the last node ofa server strand. There is a natural way to identify thenodes and parameters of one protocol with those of itsvariants when there are protocol transformations [22]between them. For example, all the variants of pkinithave corresponding nodes and parameters. The onlything that changes is the exact structure of the mes-sages. [22] formalizes what it means for the semanticsof a language to respect these identifications. For theremainder of this section we assume our security goalsare expressed in a goal language where the predicatenames are uniformly chosen for each of the protocolsΠi, respecting the natural identifications of nodes andparameters.

The partial order ≤ on goals naturally induces apartial order � on protocols in the following way.

Definition 3 A protocol Π2 is at least as strong as aprotocol Π1, written Π1 � Π2, iff for every goal Γ , ifΠ1 achieves Γ then so does Π2.

For the set of all goals that the protocol Π achieves,we write:

Ach(Π) = {Γ | Π achieves Γ}.

The position of each Π in the partial order � is de-termined by the set Ach(Π) of goals it achieves. ThenΠ1 �Π2 iff Ach(Π1) ⊆ Ach(Π2). So � mirrors the par-tial order on sets of goals ordered by inclusion. Thus,the � order justifies us in regarding Ach as a measureof protocol strength, as in our Tenet for measurement(cf. Eq. 1). By Lemma 1, the sets Ach(Π) are closedunder logical implication.

Definition 3 is a very strong condition because itaccounts for every goal. Indeed, the condition may betoo strong for practical use. For one thing, it is not clearhow one would verify that Π1�Π2. That would requirea structured way to consider every goal, or at least anefficient way of calculating Ach(Π). Also, protocols aretypically designed with a small, finite number of goalsin mind. It may be sufficient to understand the relativebehavior of Π1 and Π2 on a finite set of design goals G.This suggests relativizing the partial order � to a setG of goals of interest.

Definition 4 A protocol Π2 is at least as strong asprotocol Π1 under G, written Π1 �

G Π2, iff for everygoal Γ ∈ G, if Π1 achieves Γ then so does Π2.

When Π1�GΠ2 and Π2�

GΠ1 we write Π1 ./G Π2.

When Π1�GΠ2 and Π2 6�GΠ1 we write Π1�

GΠ2.

We want to be clever in choosing sets of goals G sothat (1) it is straightforward to verifyΠ1�

GΠ2, and (2)�G usefully distinguishes as many protocols as possible.The first condition pushes us to consider smaller sets,while the second condition pushes us to consider largersets. In fact:

Lemma 2 Π1 ./G Π2 and G′ ⊆ G implies Π1 ./

G′Π2.

3.4 Comparing Protocols by Finite Sets

The smallest useful set is a singleton G = {Γ}. Inthis case the induced partial order �{Γ} is actually atwo-point total order on protocols. Each protocol eitherachieves Γ or not. If we let Γ(4) be the pkinit authen-tication goal in formula (4), then

pkinit �{Γ(4)} pkinit1 ./{Γ(4)} pkinit2,

because pkinit does not achieve the goal but both fixesdo. Similarly, for the non-disclosure goal Γ(7) in for-mula (7),

pkinit �{Γ(7)} pkinit1 ./{Γ(7)} pkinit2.

Thus, the two fixes agree on {Γ(4), Γ(7)}, i.e.

pkinit1 ./{Γ(4),Γ(7)} pkinit2.

Larger finite sets G may induce more interestingpartial orders. When G represents the set of desiredgoals, it is the job of the protocol designer to define aprotocol that achieves all the goals in G so that G ⊆Ach(Π). As standards committees propose fixes to pro-tocols, however, cases may arise in which two proposalsΠ1 and Π2 are incomparable via �G. Such cases pro-vide an opportunity for standards committees to dis-cuss the relative importance of goals in G. It may beworthwhile to sacrifice some goals in order to achieveothers. Recognizing that two protocols are incompara-ble in the partial order defined by the goals allows thetrade-offs to be much clearer.

4 Related Work

There are several approaches to measuring the secu-rity of systems. One approach focuses on establishinga set of standardized names for common concepts, lan-guages for expressing and sharing information about

9

those concepts, and system administrator tools to au-tomatically collect measurements of a system with re-sults expressible in those languages. Works exemplifiedby Martin [28], Sun et al. [36], and Liu et al. [25] demon-strate ways to leverage common enumerations such asCVE [12] and CWE [13] in automatically generating se-curity metrics for the analysis of operational systems.Our approach differs in several crucial aspects. By fo-cusing on the relatively narrow domain of cryptographicprotocols, we can more easily develop a general andformal language of events in which to express securityproperties. We are thus able to provide a clear seman-tics for formulas in our language that corresponds tothe effects of attacks without enumerating those attacksexplicitly.

4.1 Protocol Security Hierarchies

More closely related to our work are approaches to an-alyzing security protocols relative to specific definitionsof protocol security. There have been many attempts inthe literature to define protocol security [6,38,34,26,9,10,1] and there has been no consensus on a formal def-inition of what is meant by that term. This is for goodreason: Security comes in various forms and strengths.Some varieties may be suitable for one purpose, butinsufficient for another.

This point was clearly made by Lowe in [26] whenhe defined a hierarchy of authentication specificationsranging from aliveness to injective agreement on a setof values. Since then, Cremers and Mauw [14] haveamended and extended this hierarchy to capture syn-chronization properties (reminiscent of properties de-fined in Woo and Lam’s [38] and Roscoe’s [34]) andwhether or not some party’s peer is running the ex-pected role. In [4], Basin and Cremers identify a hi-erarchy of adversary models and derive a hierarchy ofprotocols according to the strongest adversary modelunder which the protocols are secure. Their adversarymodels come mostly from Canetti and Krawczyk’s [9,10]. Security in this case is with respect to a small, fixedset of well-defined secrecy and authentication goals.

We view the present work as a step in the direc-tion of unifying, simplifying, and extending the relatedwork on hierarchies of specifications, adversary models,and protocols. Our security goal language is designed toexpress properties in a manner that is independent ofthe underlying formalisms or tools used to verify them.The structure of goals as first order formulas makesthe relative strength of security goals clear and imme-diate. The language is expressive enough to capture thenatural notions of authentication and secrecy used byothers. Judicious use of the atomic predicates Non(v),

Unq(v), and Preceq(m,n) can also express subtle lim-its on the adversary’s ability to compromise both long-term and short-term data. These are the dimensionsalong which Basin and Cremers vary their adversarymodels in [4]. Thus we can also incorporate a varietyof adversary models into the specifications themselves,which Basin and Cremers identify as an alternative ap-proach to theirs.

Our aim in the rest of this section is to elaborate thedetailed connection with the related work on protocolsecurity hierarchies. By recreating the authenticationhierarchy as defined by Lowe [26] and extended by Cre-mers and Mauw [14], we hope the reader will gain astronger intuition for how to uniformly express a widevariety of important security goals drawn from the lit-erature.

4.2 Recreating a Hierarchy of Authentication Goals

Lowe begins his investigation by defining four types ofauthentication, weak aliveness, weak agreement, non-injective agreement, and injective agreement.1 They areall stated from the perspective of an agent A playingthe initiator role of a protocol trying to authenticateanother agent B playing the responder role. They eachassert the existence of some protocol event given thatsome behavior has occurred. There is a clear orderingof strength among them because they demand increas-ingly more agreement between A and B. Lowe notesthat the restriction to two party protocols and to au-thentication of a responder by an initiator is incidental.The definitions naturally generalize to reversing the or-der of authentication and to multi-party protocols.

We now express each of these properties in our goallanguage. Although our language is independent of theparticular protocol being considered, it does require roleposition predicates for each node and parameter pred-icates for the values at those nodes. Thus the actualformalization of these authentication goals will dependto some degree on the protocol. In order to remain asgeneral as possible, we assume a protocol which has aninitiator role and a responder role. The role positionpredicates IStart(·), RStart(·) will be satisfied by thefirst nodes of the initiator and responder roles respec-tively. Similarly IDone(·) and RDone(·) will be satisfiedby their final nodes. We assume that, at the start ofeach role, parameters for its own identity and that of itspeer are well defined. We use the parameter predicatesSelf(·, ·) and Peer(·, ·) to represent these parameters.

1 We use the terminology of Cremers and Mauw’s [14] insteadof [26] because it makes finer distinctions that are useful for ourpurposes.

10

All other parameters p are represented by predicatesParamp(·, ·).

Most protocol goals are trivially broken when theparticipants use compromised long-term keys or creden-tials. Exactly which keys must be kept secure to achievecertain goals will depend on the protocol. These as-sumptions about uncompromised keys can be expressedin our logic by naming the keys with Paramk(n, vk) andasserting they are unavailable to the adversary withNon(vk). We may use the Self(n,A) or Peer(n,A) pa-rameter predicate with sk in Non(sk(A)). We use thenotation GoodKeys(n, k) to represent a conjunction ofsuch formulas, expressing that the relevant keys (repre-sented by the parameters k) are not compromised. Ourgoals are thus somewhat parametric in which keys arecovered in this formula.

The stronger authentication goals can naturally beexpressed by modifying the weaker ones. To avoid type-setting large formulas that are difficult to read, we willdefine new formulas in terms of the parts of previousones. Each goal has the form shown in Definition 1. Weuse the convention that for goal Γi the conjunction onthe left of the implication is denoted by Φi. Each of thedisjuncts on the right of the implication is denoted byΨ ji for j between 1 and the number of disjuncts. Ψ ji in-cludes the existential quantifier. Thus, authenticationgoal Γi is expressible as Φi ⇒

∨1≤j≤n Ψ

ji where any re-

maining free variables are implicitly universally quan-tified at the start of the formula. We build up largerformulas by adding conjuncts to these parts and cap-turing new variables under new existential quantifierswhen needed.

Expressing the goals. We start by expressing thegoals in Lowe’s hierarchy in our formalism. For the fol-lowing discussion, we direct the reader to Table 2 whichsummarizes the results. Weak aliveness, Γ1, is the per-haps the weakest meaningful form of entity authentica-tion. A protocol that satisfies weak aliveness guaranteesthat the intended peer started the protocol at some timein the past. It does not guarantee that the peer agreeson the initiator’s identity, nor does it guarantee that thethe peer is acting in the right role. The next propertyΓ2, weak agreement, specifies that the peer must alsoagree on the initiator’s identity. This is done by addingthe relevant parameter predicates to the hypothesis Φ1

and to each of the disjuncts Ψ i1.Non-injective agreement requires the peer to be act-

ing in the correct role (i.e. as a responder) and it re-quires that the two parties agree on some subset V ofparameters used in their roles. We express non-injectiveagreement as Γ3 which we obtain from Γ2 in two steps.First we remove the disjunct Ψ2

2 from the conclusionthat allows the peer to act as an initiator. Then, for

each p ∈ V , we conjoin the corresponding parameterpredicate Paramp(·, ·) to both the hypothesis and con-clusion, ensuring the variables in the second argumentare the same in both places.

The injective-agreement property is designed to en-sure that a protocol is resistant to replay attacks inwhich an adversary may record messages from a previ-ous successful session and use them at a later time. Thiscan be avoided if the protocol ensures that each set ofvalues the initiator commits to is unique to the currentsession. This injective session property is formalized asΓ∗. Injective agreement, Γ4, is then the conjunction ofΓ3 with Γ∗. It is possible to express injective agreementas a single goal, Γ ′4, but we believe it is more informativeto demonstrate the logical independence of agreementand injectivity.

Lowe points out in [26] that properties Γ1 throughΓ4 do not capture the notion of recentness. In manyprotocols the mechanisms to ensure the peer has beenrecently active are similar to those used to ensure theinjective session property. Namely, random challengenonces are used to ensure both that each session hassome unique input and that the peer’s activities haveoccurred after the creation of the nonce. However, re-centness and injectivity are logically independent. Oneis about the relative ordering of events, while the otheris about the uniqueness of sessions. For each of the prop-erties defined so far, Lowe defines another version thatensures recentness.

Recentness requires the existence of an event that isknown to have occurred not too long ago. This could bea previous event performed by the initiator, or it couldbe an external event such as a clock tick. We remainagnostic about which event is used as a time reference.We simply assume we know what event in the proto-col is sufficient for this purpose and we say that sucha node satisfies the role position predicate TimeRef(·).For each Γi we obtain a version that requires recent-ness by modifying each of its disjuncts Ψ ji , adding thetwo conjuncts TimeRef(m′)∧Preceq(m′,m). For exam-ple, we modify Γ1, weak aliveness, into Γ5, recent weakaliveness. Modifying Γ2, Γ3 and Γ4 analogously, yieldsrespectively

Γ6, recent weak agreement;Γ7, recent non-injective agreement; andΓ8, recent injective agreement.

We omit these from Table 2 since they are completelyanalogous to Γ5.

In [14], Cremers and Mauw augment this hierarchyin two ways, which we formalize in Table 3. First, theychoose to modify Γ1 not by ensuring agreement on bothidentities, but by first ensuring that the peer is acting

11

Weak aliveness.(IDone(n) ∧ Peer(n, r)∧

)=⇒

((∃m. RStart(m) ∧ Self(m, r))∨

)GoodKeys(n, k) (∃m. IStart(m) ∧ Self(m, r))

(Γ1)

Weak agreement.

Φ1 ∧ Self(n, i) =⇒ (Ψ11 ∧ Peer(m, i)) ∨ (Ψ2

1 ∧ Peer(m, i)) (Γ2)

Weak agreement: Variant.

Φ1 =⇒(

(∃i . Ψ11 ∧ Self(n, i) ∧ Peer(m, i))∨

)(∃i . Ψ2

1 ∧ Self(n, i) ∧ Peer(m, i))(Γ ′2)

Non-injective agreement.

Φ2 ∧∧

p∈V Paramp(n, vp) =⇒ Ψ12 ∧

∧p∈V Paramp(m, vp) (Γ3)

Injective session.(IDone(n1) ∧

∧p∈P (init) Paramp(n1, vp)∧

)=⇒ n1 = n2

IDone(n2) ∧∧

p∈P (init) Paramp(n2, vp)(Γ∗)

Injective agreement.

Γ3 ∧ Γ∗ (Γ4)

Injective agreement: Variant.(Φ3 ∧ IDone(n′)∧

)=⇒ Ψ1

3 ∧ n = n′∧p∈P (init) Paramp(n

′, vp)(Γ ′4)

Recent weak aliveness.

Φ1 =⇒(

(∃m′ . Ψ11 ∧ TimeRef(m′) ∧ Preceq(m′,m))∨

)(∃m′ . Ψ2

1 ∧ TimeRef(m′) ∧ Preceq(m′,m))(Γ5)

Table 2 Authentication formulas in Lowe’s hierarchy

Weak aliveness in role

Φ1 =⇒ Ψ11 (Γ9)

Non-injective synchronization.

Φ3 =⇒ ∃m. Ψ3 ∧ NodeOrder(m,n) (Γ11)

Injective synchronization.

Γ11 ∧ Γ∗ (Γ12)

Table 3 Additional Cremers and Mauw authentication formulas

in the right role regardless of whether or not the peercorrectly knows the initiator’s identity. The result isweak aliveness in a role, Γ9, obtained by omitting Ψ2

1

from Γ1. They also modify Γ9 to obtain

Γ10, yielding recent weak aliveness in a role, by addingTimeRef(m′) ∧ Preceq(m′,m) to the conclusion.

Cremers and Mauw also introduce the notion of syn-chronization which has both a non-injective and in-jective variety. Non-injective synchronization is to besimilar to the Bellare-Rogaway notion of matching con-versations [6] and Roscoe’s intensional security [34]. It

completely describes the intended protocol executiongiven completed run of the initiator. It requires thatevery transmission by the initiator precedes a match-ing reception by the peer and vice versa, where eachcorresponding pair of events agrees on the value of themessage.GL(Π) does not talk directly about this full mes-

sage value. Instead, it talks about the parameters one-by-one. This limited expressiveness is actually a designtarget of our language: a security goal that dependstoo heavily on the exact structure of messages cannotbe preserved under small syntactic changes. Since ourlanguage is designed for cross-protocol comparisons wehave traded off expressibility for simultaneous appli-cability of goals to several protocols. In many cases,equalities between protocol messages can be enforcedby stating that corresponding parameters of sender andreceiver are equal. However, when they destructure themessages in different ways, this may not suffice. In aprotocol such as pkinit in which one party transmitsa ciphertext it has encrypted, which another receivesas an opaque blob, we cannot explicitly state that thiscomponent is unchanged.

12

Nonetheless, in many cases the specification of allthe parameters will uniquely determine the messagestructure, and hence agreement on all parameters willentail agreement on the messages. In such cases we canformalize non-injective synchronization by modifyingΓ3 in the following way. We express the existence ofeach node we expect by the corresponding role posi-tion predicate. We express the desired ordering of theseevents using the Preceq(·, ·) and Coll(·, ·) predicates.This conjunction of predicates may be abbreviated byNodeOrder(m,n), where n is the only node variable inthe hypothesis of Γ3. We then conjoin this to the con-clusion Ψ3, existentially quantifying over all new nodevariables m, resulting in non-injective synchronization,Γ11. We do not add any more role parameter predicatesor equalities because we assume the set V of parametersto agree on for Γ3 is already the entire set of parame-ters P (init) and is enough to enforce agreement on thevalue of each message of the protocol.

To express injective synchronization we simply con-join the injective session property to non-injective syn-chronization resulting in Γ12.

Ordering the goals by strength. Having expressedthe various goals in these hierarchies in our logical goallanguage, we now demonstrate their relative strengthby implication. As we saw above, many goals are ob-tained from others by a handful of reusable modifica-tions. Most of these modifications involve either addingconjuncts to the conclusion of an implication or remov-ing disjuncts. Such modifications strengthen the im-plication by strengthening its conclusion. The rest ofthis section discusses this set of reusable modificationsto goals and demonstrates that the resulting goals arestronger. The results are summarized in Fig. 4 wherethe implications on opposite sides of each of the paral-lelograms hold for analogous reasons.

We first work our way up the diagram vertically. Inorder to see that Γ2 is stronger than Γ1 we first notethat we have obtained Γ2, in part, by adding conjunctsto the conclusion. If this were the only modification,it would immediately follow that Γ2 was stronger thanΓ1. However, we have also seemingly strengthened thehypothesis by adding the conjunct Self(n, i), therebypotentially weakening the implication. In fact, however,it does not actually weaken the goal. We know thatΦ1 ⇔ Φ1 ∧ ∃i . Self(n, i) because we have assumedthat the self parameter is always well defined at thefirst (and hence also last) node of the roles. Any skele-ton satisfying IDone(n) has a well-defined value for theself parameter at that node, and hence also satisfiesSelf(n, i). Because of this we could have expressed Γ2

as the alternate form Γ ′2 in Table 2, making it syntacti-

Γ12

y� ��Γ8

z� ��

Γ11

y�Γ4

��

Γ7

z� ��

��

Γ3

��

��

Γ6

z� ��Γ2

��

Γ5

z�

Γ10ks

y�Γ1 Γ9ks

Γ1 : Weak Aliveness Γ7 : Rec. non-inj. Agrmt.Γ2 : Weak Agrmt. Γ8 : Rec. inj. Agrmt.Γ3 : Non-inj. Agreement Γ9 : Weak Aliveness in RoleΓ4 : Inj. Agreement Γ10 : Rec. Aliveness in RoleΓ5 : Rec. Weak Aliveness Γ11 : Non-inj. SynchΓ6 : Rec. Weak Agrmt. Γ12 : Inj. Synch

Fig. 4 Combined hierarchy

cally evident that it is stronger than Γ1. Γ6 is strongerthan Γ5 for the same reasons.

To see that Γ3 is a stronger requirement than Γ2

we argue similarly. The consequent is strengthened byremoving one of the disjuncts and adding a conjunct tothe remainder. Again, although it looks like a strength-ening of the antecedent, the set V is chosen to ensurethat for any p ∈ V , IDone(n) ⇒ ∃vp . Paramp(n, vp).In order for non-injective agreement to be satisfiable,it may be necessary to replace RStart(m) with a laternode such as RDone(m). The issue is that the respon-der may not have learned or committed to all the rele-vant values in V at its first node. Such a modificationonly serves to further strengthen the goal because laternodes always imply the existence of earlier nodes of thesame strand. Similarly, we conclude that Γ7 is strongerthan Γ6.

Injective agreement Γ4 is clearly stronger than non-injective agreement Γ3 since Γ4 simply requires an ad-ditional goal to be met. For the same reason, we canconclude that Γ8 ⇒ Γ7 and that Γ12 ⇒ Γ11.

Γ9 strengthens Γ1 since it results from omitting oneof the disjuncts of Γ1’s conclusion. For the same reasonΓ10 ⇒ Γ5.

Γ5 is obtained from Γ1 by adding the requirementfor recency. This is done by adding conjuncts to the con-clusion, thereby strengthening the goal. The same rea-

13

soning justifies all the parallel implications that simplyadd recency to a goal.

To see that Γ3 ⇒ Γ9, we recognize that both goalsrequire the peer to be in the expected role, but Γ3 re-quires more agreement among the parameters. That is,Γ3 can be obtained from Γ9 by adding parameter predi-cates to both the hypothesis and the conclusion. As weargued above, the addition of these predicates to thehypothesis does not strictly strengthen the hypothesis.Thus the additional parameter predicates conjoined tothe conclusion can only strengthen the goal. Γ10 simi-larly strengthens Γ5.

Finally, we argue that Γ11 is stronger than Γ7. Theconjunction NodeOrder(m,n) is typically stronger thanthe conjunction TimeRef(m′)∧Preceq(m′,m), becauseTimeRef(m′) is usually one of the role position predi-cates included in NodeOrder(m,n), and Preceq(m′,m)

is one of the required orderings. Thus NodeOrder(m,n)

asserts the existence of more nodes and more order-ings among them. This means that synchronization isa stronger requirement than recency. Thus we see thatΓ11 ⇒ Γ7, and similarly, Γ12 ⇒ Γ8.

5 Protocols and Policies

One common source of resistance to the use of formalverification tools is their inability to capture the widevariety of realistic assumptions about the environmentin which a protocol operates. When a potential attackis presented to a standards committee, it is common forthe committee to argue that the attack violates someassumption guaranteed externally by some policy. InSection 5.1 we use an example protocol from an ISOstandard [24] to show how we can use our goal languageto capture not only properties that a protocol must en-force, but also limitations on the adversary that areenforceable through policy decisions. In Section 5.2 wediscuss how a well-known flaw in the Transport LayerSecurity (TLS) protocol, discovered in 2009 [33], illumi-nates the tension that may arise when applications relyon a protocol to provide enough information to makelocal policy decisions. We show how our goal languagemight help structure standards bodies’ understandingof the root cause of such a flaw and appropriate waysto mitigate it.

5.1 Policy-Based Constraints

The hierarchy is rather extensive, and yet it is still in-sufficient to express many goals or properties that arisefor protocols developed as standards. In [3], Basin et al.use Scyther to analyze the ISO/IEC 9798 standard for

P as TTP

��

A as InitnA,A,Boo

��•

TokenPA // •

��•

��

TokenAB // B as Resp

��• •

TokenBAoo

TokenPA={|nA, kAB , B|}kAP, {|nP , kAB , A|}kBP

TokenAB={|nP , kAB , A|}kBP, {|mA, B|}kAB

TokenBA={|nB , A|}kAB

Fig. 5 ISO/IEC 9798-2, Mechanism 5

authentication protocols. They measure the protocolsagainst goals in the above hierarchy and discover nu-merous cases in which the protocols do not achieve thegoals. They then propose repairs to the protocols anddemonstrate that the repaired protocols each achieve atleast recent non-injective agreement. Interestingly, theiralterations to the protocol messages were not sufficientto repair all the protocols. The repairs to two mech-anisms from Part 2 of the standard [24] only achievesthe goal under the extra external assumption that somepolicy is enforced. We dedicate the remainder of thissection to demonstrating how we can apply our goallanguage to one of these protocols to express the ade-quacy of the protocol repairs under such policy-basedconstraints.

Figure 5 depicts the expected execution the proto-col identified as Mechanism 5 in [24]. Two parties, Aand B, want to authenticate each other using an on-line trusted third party (TTP) P . We assume that Pshares symmetric keys kAP and kBP with A and B re-spectively. A, acting as initiator, begins by sending anonce nA together with B’s identity to P . P , acting inthe role of TTP, creates a fresh, symmetric session keykAB to be used between A and B. The key is encryptedseparately for A and B together with the random val-ues nA and nP and the identities of the intended peers.A passes along P ’s encryption for B together with an-other encryption using the session key kAB of a randomvalue mA and B’s identity. The responder B completesthe protocol by using kAB to encrypt a random valuenB and A’s identity.

The protocol as described does not achieve non-injective agreement because many of the encryptionshave similar structure. This allows an adversary to com-bine messages from two sessions in which A and B areboth acting as initiator to convince A that B is acting

14

P as TTP

��

P as InitnA,P/A,Boo

��•

TokenPA // •

��•

TokenAB // B as Resp

TokenPA={|nA, kAB , B|}kAP, {|nP , kAB , A|}kBP

TokenAB={|nP , kAB , A|}kBP, {|mA, B|}kAB

TokenBA={|nB , A|}kAB

Fig. 6 Attack on ISO/IEC 9798-2, Mechanism 5

as responder. Basin et al. suggest including unique tagsin each of the encryptions so that such role confusionsare no longer possible. Although this change eliminatesthe role-mixup attacks, the resulting protocol still doesnot achieve non-injective agreement (in fact, it does noteven achieve weak aliveness).

Figure 6 displays a remaining attack on the proto-col. In this instance P is executing both the initiatorand the TTP roles simultaneously. As initiator, P sendsthe nonce and the two identities P and B. The adver-sary swaps P ’s identity with A’s identity before deliv-ering the message to P in the TTP role (representedwith P/A over the dotted line). As TTP, P believes therequest to be coming from A wanting to talk with B,so he prepares encryptions for both A and B using thelong-term shared symmetric keys kAP and kBP . Theadversary can redirect this message back to P in theinitiator role. P is willing to accept this message be-cause it believes it to be coming from A acting as TTPand it is encrypted with the key kAP that he shares withA. When P acting as initiator sends the final messageto B, B believes that A was active at some point whichis not true. This violates weak aliveness of A from theresponder’s point of view.

The root cause of this problem is that the secondmessage does not contain enough information aboutwho the TTP thinks is playing which role, assumingthat a principal can play both the TTP role and theinitiator role. This suggests two natural ways to addressthe attack. The first is to alter the message structure toadd more detailed information about which principalsappear to be playing which roles. The second is to elim-inate the ambiguity by forbidding any principals thatacts as TTP to also act as either initiator or respon-der. While the first option may be desirable because itallows for more flexible deployment scenarios, it maybe difficult for a standards committee to accept such adrastic change to the message structure when numer-ous implementations exist. Furthermore, the first op-

tion requires the protocol implementors to create anddistribute a patch, while the second option empowersany enterprise that is an end user of the protocol toprotect themselves with a policy change.

Our goal language makes it straightforward to eval-uate whether a particular proposal to amend the pro-tocol will achieve the desired authentication goal as wedemonstrated for the case of PKINIT. But how can weuse our techniques to evaluate whether a change in lo-cal policy will allow the protocol to achieve its goal? Ananalysis of the protocol will always tell us that it doesnot even achieve weak aliveness. We must capture whatthe protocol does achieve and ensure that it entails agoal that says either the protocol violates some externalpolicy or else it achieves non-injective agreement.

The external policy can be viewed as an extra as-sumption we would like to make on our analysis. Whilegoals typically represent assumptions as conjuncts inthe antecedent, our language restricts us to using pos-itive statements such as the fact that some event hasoccurred, or some value is freshly chosen. This policyis really a negative statement: A principal will not playboth the TTP role and another role. We can expresssuch requirements by negating the policy to make apositive statement and place that in the disjunctions ofthe conclusion. So if we let Φ′3 ⇒ Ψ ′3 represent the goalof non-injective agreement with the initiator from theresponder’s point of view, then we can use the followinggoal:

Φ′3 =⇒ Ψ ′3 ∨ Ψa ∨ Ψb (Γ13)

in which we let

Ψa = ∃n1, n2, v . TTPStart(n1) ∧ Self(n1, v) ∧InitStart(n2) ∧ Self(n2, v)

Ψb = ∃n1, n2, v . TTPStart(n1) ∧ Self(n1, v) ∧RespStart(n2) ∧ Self(n2, v).

The disjunction Ψa ∨ Ψb captures a violation of thepolicy that restricts any principal that plays the TTProle from playing either the initiator role (Ψa) or theresponder role (Ψb). Using cpsa we have verified thatthe protocol achieves goal Γ13 thereby demonstratingthat such a policy, if properly enforced, can ensure theprotocol achieves non-injective agreement.

Notice that Γ13 fits only tangentially into the hier-archy of Fig. 4. It is weaker than non-injective agree-ment because we achieved it by weakening the conclu-sion, adding extra disjuncts. However, it is not strongerthan any of the other goals in the hierarchy. This ex-ample demonstrates the inadequacy of such hierarchiesin addressing the real goals and constraints that arise

15

Client Attacker Server------ -------- ------

<--------- Handshake --------><===== Initial Traffic ======>

<----------------- Handshake ========================><=============== Client Traffic ======================>

Fig. 7 TLS renegotiation attack

in the standardization of security protocols. We believethat combining our goal language with formal verifica-tion tools goes a long way to offering the flexibility andextensibility necessary to naturally express and verifygoals and policy-based constraints that arise during thedevelopment and maintenance of protocol standards.

5.2 TLS Renegotiation

The policy in Section 5.1 is encoded in our security goalΓ13. One aspect of that example that made it particu-larly clean is that the policy is a global one that can beenforced during the registration of participants. Thatis not always the case. Some policy decisions may dy-namically rely on information provided by the protocolitself, for example when an application is relying on theunderlying protocol for certain guarantees. When a sur-prising behavior—potentially a flaw—is discovered, wemay need to change what information is available at theinterface between the protocol and the application. Theapplication can then use this information to correctlyenforce a policy. We start with an example.

Transport Layer Security (TLS) [15] is a globallydeployed protocol designed to add confidentiality, au-thentication and data integrity between communicatingapplications. It is secure, scalable, and robust enough toprotect e-commerce transactions over HTTP. Despiteits success, it has been forced to evolve over time, inpart due to the discovery of various flaws in the designlogic.

One such flaw, discovered in 2009 by Marsh Ray(see [33]), concerns renegotiating TLS parameters. Itworks on the boundary between the TLS layer and theapplication layer it supports. Fig. 7 is a high-level pic-ture of the attack borrowed from [33]. The attackerfirst creates a unilaterally authenticated session withthe server in the first handshake. Thus, the server au-thenticates itself to the attacker, but not vice versa.The attacker and server then exchange initial trafficprotected by this TLS session. Later, a renegotiationoccurs, possibly when the application at the server re-quires mutual authentication for some action. The at-tacker then allows the client to complete a handshakewith the server, adding and removing TLS protections.The client’s handshake occurs in the clear (depicted by

<---> in Fig. 7), while the server’s handshake is pro-tected by the current TLS session. The attacker has noaccess to this newly negotiated session, but the servermay retroactively attribute data sent in the previoussession to the authenticated client. The server may thenperform a sensitive action in response to a request sentby the attacker, but based on the credentials subse-quently provided by the client.

In a typical illustration, the server is a pizza shop.The attacker orders a pizza for delivery to his address;then the client authenticates and orders a pizza for hisown address. Because this is (now) a bilaterally authen-ticated connection, the server charges the orders madein this process to the client’s account.

Which level is to blame for this attack?

– Does TLS fail to achieve a security goal that itshould achieve?

– Or should the application take responsibility? It ac-cepts some data out of a stream that is not bilat-erally authenticated, and lumps it with the futuredata which will be bilaterally authenticated.

– Or is there shared responsibility? Perhaps TLS hasthe responsibility of providing clearer indications tothe application when a change in the TLS propertiestakes place, and the application has the responsibil-ity of heeding these indications.

TLS was subsequently updated with a renegotiation ex-tension [33]. Renegotiation now creates a cryptographicbinding between the new session and the existing ses-sion. If a server completes a mutually authenticatedrenegotiation with a client, then the earlier session wasalso negotiated with the same client. However, the au-thors of [33] also note:

While this extension mitigates the man-in-the-middle attack described in the overview, it doesnot resolve all possible problems an applicationmay face if it is unaware of renegotiation.

As Bhargavan et al. [7]’s recent attacks showed, thepractically important issue was not in fact resolved bythis. Perhaps future versions of TLS will simplify thesituation by eliminating renegotiation.

However, the main point stands: for applications touse a security protocol such as TLS effectively, and takepartial responsibility for achieving reasonable policies,some signals and commands must be shared betweenTLS and the application. Formal verification—coupledwith our goal language—fits naturally here. With a lit-tle effort the goal language can be updated to addressthe multilayer nature of flaws such as this.

16

5.3 Enforcing Policies at Protocol Interfaces

The job of TLS, acting in either direction, is to take astream of data from an application, delivering as muchas possible of this stream to the peer application. Whenthe sender is authenticated to the receiver, TLS guar-antees that the portion delivered is an initial segment ofwhat the authenticated sender transmitted. When themode offers confidentiality, no other principal shouldlearn about the content (beyond its length).

Naturally, these goals are subject to the usual as-sumptions, such as that the certificate authorities aretrustworthy, that the private keys are uncompromised,and that randomness was freshly chosen.

When renegotiation occurs, this affects what the ap-plication should rely on. If a handshake authenticatesa client identity C, then that guarantee should applyto the data starting when the cipher spec changes. Itcontinues to apply until another cipher spec change orthe end of the connection. Authentication guaranteesfor the “client traffic” should definitely not apply to the“initial traffic” of Fig. 7, which lies on the other side ofa cipher spec change.

We may regard the TLS record layer as engaging intwo types of events, namely the network-facing eventsand the application-facing events. Consider the out-bound stream of data from the application to its peer.The network-facing events are transmission events formessages on the network to the peer. The application-facing events accept a stretch of data from the appli-cation, to be transmitted to the peer via the network.These stretches of data may be of various lengths, sothat the record layer has to break them into many TLSrecords before network transmission.

For the inbound stream of data from the peer, thenetwork-facing events are reception events for messageson the network from the peer. The application-facingevents deliver a stretch of data to the application. Asthe record layer assembles these stretches of data frommany TLS records on the network, they may be of var-ious lengths.

Thus, in representing the TLS record layer, we usefour kinds of node:

NetReceive(n): n is a network-facing event receiving arecord;

NetSend(n): n is a network-facing event transmitting arecord;

AppAccept(n): n is an application-facing event accept-ing data from the application to go to the peer;

AppDeliver(n): n is an application-facing event deliv-ering data from the peer to the application.

Several parameter predicates may apply to these nodes.If NetReceive(n) or NetSend(n), then n certainly has

a MAC key and an encryption key, as well as sequencenumber and payload data. We will not pause to formal-ize these, nor to define the roles that these events lieon. They are most easily formalized as protocol rolesthat interact with mutable state [21,31].

When AppAccept(n) or AppDeliver(n), then threeparameter predicates that apply to n are:AppData(n, d): n is accepting or delivering the applica-

tion data d;AppPeer(n, p): the authenticated peer at the time n oc-

curs is p;AppSelf(n, p): the authenticated identity of the active

principal at the time n occurs is p.The predicates AppPeer(n, p) and AppSelf(n, p) maynot hold of any value p if the endpoint is unauthenti-cated when n occurs.

Using these notions about the protocol behavior,the application can express its requirements about thesecurity services that the protocol provides. We are in-terested in a situation where two segments of data aredelivered to the pizza server, and it replies with a seg-ment completing the transaction. We assume that theapplication defines a method to concatenate data seg-ments d1, d2, which we write d1ˆd2; and that it has away to assert that data d expresses a well-formed trans-action Transact(d). Then the application is interestedin the situation when:

AppAccept(n1) ∧ AppAccept(n2)

∧ AppDeliver(n3) ∧∧1≤i≤3

AppData(ni, di) ∧ Transact(d1ˆd2ˆd3).

In this situation, we certainly want it to be the casethat there is a single client c which is the peer of allthree events:∃c . AppPeer(n1, c) ∧ AppPeer(n2, c)

∧ AppPeer(n3, c).

The authentication properties of the protocol itself mayalso imply further conclusions, such as c actually havingtransmitted d1ˆd2.

Thus, the goal language we have provided can beenriched to express events at the interface between theprotocol and its application. This notation—augmentedwith some application level vocabulary—allow the ap-plication author to express the meaningful conclusionsthat should hold whenever the application obtains itssecurity services from the protocol.

6 Comparing Protocols by Hypotheses

Up to now, we have limited ourselves to consideringonly finite sets of goals G for the comparison of pro-

17

tocols. Using finite sets is helpful because Ach(Π) ∩ Gcan be enumerated. The limitation of considering onlyfinite sets of goals is that the distinguishing power ofthe induced partial order �G is limited by the size of G(cf. Lemma 2). We may lack the imagination to ensureG includes goals that would help distinguish protocolsin a useful way. A more flexible approach might be tofix a set of assumptions and try to compare protocolsaccording to the strength of the conclusions they allow.For example, Π2 should be considered stronger than Π1

if Π2 allows an initiator to conclude more informationabout their peer’s session than Π1 allows. This insightleads us to consider the following set of goals that allshare a common hypothesis:

H(Φ) = {Γ | hyp(Γ ) = Φ}. (9)

Thus, for Γ, Γ ′ ∈ H(Φ), Γ ≤ Γ ′ iff conc(Γ ′)⇒ conc(Γ ).H(Φ) is typically not a finite set, so we can no longercalculate Ach(Π) ∩H(Φ) by enumeration.

However, using our tool cpsa [32], we can find—for a large, natural class of assumptions Φ—a singlestrongest formula in Ach(Π) ∩H(Φ). We will call thisformula the shape analysis sentence SASΦ(Π). It servesto summarize the whole set Ach(Π) ∩ H(Φ). The keyidea here is enrich-by-need protocol analysis. As we willsee, enrich-by-need analysis outputs such a maximallystrong formula.

Thus the sets H(Φ) are a natural companion toenrich-by-need protocol analysis. This raises the ques-tion of whether the analysis methods used by othertools have similar connections to other classes of goals.

6.1 Enrich-by-Need Protocol Analysis

Our approach to protocol analysis is based on what wecall the “point-of-view principle.” Most of the securitygoals we care about in protocol design and analysis con-cern the point of view of a particular participant C. Cknows that it has sent and received certain messagesin a particular order. C may be willing to assume thatcertain keys are uncompromised, which for us meansthat they will be used only in accordance with the pro-tocol in question. And C may also be willing to assumethat certain randomly chosen values will not also beindependently chosen by another participant, whethera regular (compliant) participant including C itself onanother occasion, or an adversary.

These facts and assumptions may be formalized in ahypothesis. The hypothesis in Eqn. 3 is an example. Itsummarizes the situation in which a client has executeda full local run; it declares the variables C, S to standfor two of the parameters of the client run, and it adds

the assumption that the signature key sk(S) of the peeris uncompromised.

The protocol analysis question is, given these factsand assumptions, what follows about what may hap-pen on the network? The answers to this question areof two main kinds. Positive conclusions assert that someregular participant Q has taken protocol actions. Theseare authentication goals. They assert, subject to the as-sumptions, that C’s message transmissions and recep-tions authenticate Q as having taken corresponding ac-tions. Negative conclusions are generally non-disclosureassertions. They say that a value cannot be found avail-able on the network in a particular form; often, that akey k cannot be observed unprotected by encryption onthe network.

Skeletons and cohorts. The enrich-by-need processstarts with a representation of the hypothesis. We willrefer to these representations of behavior and assump-tions as skeletons A. A skeleton consists of some behav-ior of Π, i.e. some regular strands in the strand spaceterminology, together with the stated assumptions.

A skeleton A for Π is a structure that provides par-tial information about a set of Π-bundles. It consists ofa finite set of regular strands of Π, or initial segmentsof them; some assumptions about which keys shouldbe assumed uncompromised and which should be as-sumed to have been freshly chosen; and a partial order-ing on the nodes of Π. A bundle B is an instance of askeleton A if there is a structure-preserving map (“ho-momorphism”) from the strands of A into the regularstrands of B such that B satisfies the freshness and non-compromise assumptions of A, and its arrows enrich thepartial ordering of A (see [20] for copious detail).

cpsa [32] is a software tool that carries out protocolanalysis in strand spaces. Given any skeleton A0 as astarting point, cpsa provides information about the setof all bundles B such that there is a homomorphismfrom A0 into B. cpsa does this by computing a setof skeletons {Bi}i∈I with two properties. First, eachof the skeletons Bi is a realized skeleton. By this wemean that there is a bundle Bi such that Bi resultsfrom Bi when we “forget” the specific adversary strandsin Bi. Second, every bundle B containing an image of A0

also contains an image of one of the Bi. We summarizethese properties by saying that {Bi}i∈I characterizesthe skeletons compatible with the starting point A0.

We start the enrich-by-need analysis with a skeletonA0. At any point in the enrich-by-need process, we havea set S of skeletons to work with. Initially, S = {A0}.

At each step, we select one of these skeletons A ∈ S,and ask if the behavior of the participants recorded in itis possible. When a participant receives a message, thenthe adversary should be able to generate that message,

18

using messages that have been sent earlier, without vi-olating the assumptions. In this case, we regard thatreception as “explained,” since we know how the ad-versary can arrange to deliver the expected message.We say that that particular reception is realized. Whenevery reception in a skeleton A is realized, we call A it-self realized. It then represents—together with behaviorthat the adversary can supply—a possible complete ex-ecution, i.e. a bundle.

We collect the realized skeletons in a set R.If the skeleton A ∈ S we select is not realized, then

we use a small number of rules to generate an enrich-ment step. An enrichment step takes one unrealized re-ception and considers how to add some or all of theinformation that the adversary would need to generateits message. It returns a cohort of skeletons: This is afinite set {A1, . . . ,Ai} of skeletons forming a disjunctiverepresentation of all the ways the regular participantscan supply the necessary information to the adversary.We update S by removing A and adding the cohortmembers: S ′ = (S \ {A}) ∪ {A1, . . . ,Ai}.

As a special case, a cohort may be the empty set,i.e. i = 0, and in this case A is discarded and nothingreplaces it. This occurs when there are no possible be-haviors of the regular participants that would explainthe required reception. Then the skeleton A cannot con-tribute any executions (realized skeletons).

This process may not terminate, and in fact the un-derlying class of problems is undecidable [17]. However,when it does terminate, it yields a finite set R of re-alized skeletons with a crucial property: For a class ofsecurity goals, if they have no counterexample in theset R, then the protocol really achieves that goal [22].Moreover, we can inspect the members of R and deter-mine whether any of them is a counterexample.

We call the members ofR shapes, and they representthe minimal, essentially different executions consistentwith the starting point.

Enrich-by-need analysis originates with Meadows’sNPA [29]. Dawn Song’s Athena [35] applied the idea tostrand spaces [37]. Two systems in use currently thatuse the enrich-by-need idea in a form close to whatwe describe here are Scyther [14] and our cpsa [32].See [20,22] for a comprehensive discussion, and for moreinformation about our terminology here.

Example: Initiator’s authentication guarantee inpkinit. Suppose that the client C has executed astrand of the client role in the fixed pkinit1, i.e., wherewe instantiate F (C, n2) = (C, n2). Suppose also thatwe are willing to assume that the authentication serverS has an uncompromised signature key sk(S). We an-notate this assumption as sk(S) ∈ non, meaning thatsk(S) is non-compromised.

sk(S) ∈ non •s1 ��

//

• oo

(10)

s1 ∈ Client[C, S, T, n1, n2, tC , tS , k, AK]

This is our starting point A0, depicted in (10), whichcorresponds to the information expressed in formula (3)from Section 2. C receives a message that contains thedigital signature [k, (C, n2)]sk(S), and we know that theadversary cannot produce this because sk(S) is uncom-promised. Thus, this second node of the local run isunrealized.

To explain this reception, we look at the protocol tosee what ways a regular participant might create a mes-sage of the form [k, (C, n2)]sk(S). In fact, there is onlyone. Namely, the second step of the KAS role doesso. Knowing the KAS sends this signature means itwill agree on the parameters used: S, k, C, n2. However,we do not yet know anything about the other param-eters used in S’s strand. They could be different val-ues t′C , T

′, n′1, TGT′, AK ′, t′S . Thus, we obtain a cohort

containing a single skeleton A1, depicted in (11), thatincludes an additional KAS strand with the specifiedparameters.

sk(S) ∈ non •s1 ��

// // •s2��

• oo •oo

(11)

s1 ∈ Client[C, S, T, n1, n2, tC , tS , k, AK]

s2 ∈ KAS[C, S, T ′, n′1, n2, t′C , t′S , k, AK

′]

This skeleton is now already realized, because, with thisweak assumption, the adversary may be able to use C’sprivate decryption key to obtain k and modify the au-thenticator {|AK,n1, tS , T |}k as desired. The adversarymight also be able to guess k, e.g. if S uses a badlyskewed random number generator. Similarly, the com-ponents that are not cryptographically protected areunder the power of the adversary.

We can we now re-start the analysis with two addi-tional assumptions to eliminate these objections. First,we add sk(C) to non. Second, we assume that S ran-domly generates k, and we write k ∈ unique, meaningthat k is chosen at a unique position. We are uninter-ested in the negligible probability of a collision betweenk and a value chosen by another principal, even one cho-sen by the adversary. This situation is depicted in (12).

sk(S), sk(C) ∈ non •s1 ��

// // •s2��

k ∈ unique • oo •oo

(12)

s1 ∈ Client[C, S, T, n1, n2, tC , tS , k, AK]

s2 ∈ KAS[C, S, T ′, n′1, n2, t′C , t′S , k, AK

′]

19

This skeleton is not realized, because with the assump-tion on sk(C), the adversary cannot create the signedunit [t′C , n2]sk(C); it must come from a compliant prin-cipal. Examining the protocol, this can only be thefirst node of a client strand with matching parametersC, n2, t

′C , i.e. a local run s0:

sk(S), sk(C) ∈ non •s0 ��

•s1 ��

// // •s2��

k ∈ unique ◦ • oo •oo

(13)

s0 ∈ Client[C, S′′, T ′′, n′′1 , n2, t′C , t′′S , k′′, AK′′]

s1 ∈ Client[C, S, T, n1, n2, tC , tS , k, AK]

s2 ∈ KAS[C, S, T ′, n′1, n2, t′C , t′S , k, AK

′]

Curiously, two possibilities now remain. The strands0 could be identical with s1, in which case the doubly-primed parameters equal the unprimed ones. Or alter-natively, s0 might be another client strand that hasby chance selected the same n2; we have not assumedn2 ∈ unique. In this case, the doubly-primed variablesare not constrained. If we further add the assumptionthat n2 ∈ unique, then s1 = s0 follows.

In all of these cases, C and S do not have to agreeon TGT , since this item is encrypted with a key sharedbetween S and T , and C cannot decrypt it or check anyproperties about what he receives.

We have illustrated several points about enrich-by-need protocol analysis. Authentication follows by suc-cessive inferences about regular behavior, based on themessage components the adversary cannot build. Whentwo inferences are possible, the method branches, po-tentially resulting in several outputs. Various levels ofauthentication may be achieved; they depend on whichparameters principals agree on, and which parametersmay vary. Secrecy properties hold when no execution iscompatible with the secret’s disclosure.

More formally, there is a notion of homomorphismbetween skeletons [20]. Suppose that we start with the“point of view” expressed in the skeleton A0, and cpsaterminates, providing us with the shapes C1, . . . ,Ci,which are the minimal, essentially different executionscompatible with A0. Then for each Cj , there is a homo-morphism Hj from A0 to Cj . Moreover, every homo-morphism K : A0 → D from A0 to a realized skeleton Dagrees with at least one of the Hj . Specifically, we canregard K as the result of adding more information afterone of the Hj . We mean that we can always find someJ : Cj → D where K is the composition K = J ◦Hj .

6.2 Shape Analysis Formulas

Given a skeleton, we can summarize all of the informa-tion in it in the form of a conjunction of atomic formu-las. We call this formula the characteristic formula for

the skeleton, and write cf(A). Thus, a cpsa run withstarting point A0 is essentially exploring the securityconsequences of cf(A0).

When cpsa reports that A0 leads to the shapesC1, . . . ,Ci, it is telling us that any formula that is truein all of these skeletons, and is preserved by homomor-phisms, is true in all realized skeletons D accessible fromA0. The set of formulas preserved by homomorphismare called positive existential, and are those formulasbuilt from atomic formulas, ∧,∨, and ∃. By contrast,formulas using negation ¬φ, implication φ =⇒ ψ, oruniversal quantification ∀y . φ are not always preservedby homomorphisms.

Thus, the disjunction of the characteristic formulasof the shapes C1, . . . ,Ci tell us just what security goalsA0 leads to. However, we can be somewhat more pre-cise. The skeleton Cj may have nodes that are not in theimage of A0, and it may involve parameters that werenot relevant in A0. Thus, A0 will not determine exactlywhich values these new items take in Cj , e.g. which ses-sion key is chosen on some local run not present in A0.Thus, these new values should be existentially quanti-fied. Effectively, these are all the variables that do notappear in cf(A0). Thus, for each Cj , let yj list all thevariables in cf(Cj) that are not in cf(A0). Let x list allthe variables in cf(A0). Then this run of cpsa has vali-dated the following formula that has the required formof a security goal (Definition 1):

∀x . (cf(A0) =⇒∨

1≤j≤i

∃yj . cf(Cj)) (14)

The conclusion∨

1≤j≤i ∃yj . cf(Cj) is the strongest for-mula that is true in all of the Cj .

We call the formula (14) the shape analysis sentencefor this run of cpsa. Since the empty disjunction isthe constantly false sentence, in the special case wherei = 0, (14) is ∀x . cf(A0) =⇒ false. That is to say, it is∀x . ¬cf(A0).

We will frequently have need to reference particu-lar shape analysis sentences and their various parts. Weintroduce here a notation for ease of presentation. Sup-pose the characteristic formula cf(A0) in protocol Π isrepresented by the conjunction of atomic formulas Φ,and each resulting shape is formalized by ∃yj . cf(Cj).The shape analysis sentence (14) is called SASΦ(Π).For the conclusion of SASΦ(Π), i.e. the conclusion ofthe implication, we write SASConcΦ(Π).

20

6.3 Enrich-by-Need Compares Protocols byHypotheses

Fortunately, the shape analysis sentences SASΦ(Π) arealways in H(Φ), and the induced partial order �H(Φ)

has a nice property relative to SASΦ(Π).

Theorem 2 Π achieves Γ iff SASConchyp(Γ )(Π) ⇒conc(Γ ).

Proof For the forward implication, we rely on the factthat SASConchyp(Γ )(Π) is the strongest conclusion al-lowed from hyp(Γ ) inΠ. That is, whenever hyp(Γ )⇒ χ

then SASConchyp(Γ )(Π)⇒ χ. So let χ = conc(Γ ).For the reverse implication, the assumption means

that Γ ≤ SAShyp(Γ )(Π) in the strength ordering. Also,Π achieves SAShyp(Γ )(Π) by definition, so by Lemma 1,Π achieves Γ . ut

This theorem says that we can completely charac-terize Ach(Π)∩H(Φ) because it has a single maximumelement, namely SASΦ(Π). Thus, we get the followingcorollary.

Corollary 1 Π1 �H(Φ) Π2 iff Π2 satisfies SASΦ(Π1).

This means we can use cpsa to compare protocolsaccording to �H(Φ). We simply run the tool once togenerate SASΦ(Π1) and then check whether Π2 satisfiesSASΦ(Π1) using any semi-decision procedure for findingcounterexamples.

We can also define larger sets by considering a set Pof hypotheses and taking the union G =

⋃Φ∈P H(Φ).

When P is finite we can run the tool once for each mem-ber of P . We thus verify that Π1 �

G Π2, by checkingthat Π2 satisfies SASΦ(Π1) for each Φ ∈ P .

We can again use the example of the variants ofpkinit to demonstrate the induced ordering. We canlet Γ be the desired security goal and run cpsa onboth fixes pkinit1 and pkinit2 starting from inputsrepresenting hyp(Γ ). The result is that

SASConchyp(Γ )(pkinit1) = SASConchyp(Γ )(pkinit2).

Thus we find that

pkinit �H(Φ) pkinit1 ./H(Φ) pkinit2.

This is the same ordering as for �{Γ}. In this case, in-creasing the size of the set of goals we consider does nothelp us further distinguish the protocols under consid-eration. It does, however, tell us that the two fixes areequally good for a larger class of goals. This assurancewould be useful for standards committees. It would al-low to them to know that both fixes will behave thesame under adjustments to the strength of the conclu-sion of Γ .

6.4 Comparing Protocols by Conclusions

Using the set H(Φ) uses the idea that fixing a hypothe-sis, we can compare goals based on the strength of theirconclusions. We can also reverse that idea by fixing aconclusion and comparing goals based on the strengthof their hypotheses. The intuition is that for two pro-tocols that both achieve a given conclusion, we mightprefer the one that requires fewer assumptions. For ex-ample, in order for an initiator to authenticate a respon-der, one protocol may require that the private keys ofboth parties be kept secret, while another protocol mayonly require that the responder’s private key be keptsecret. This motivates the use of the following set ofgoals that share a common conclusion.

C(χ) = {Γ | conc(Γ ) = χ}

Thus, for Γ, Γ ′ ∈ C(χ), Γ ≤ Γ ′ if and only ifhyp(Γ ) ⇒ hyp(Γ ′). In order to determine an orderingΠ1�

C(χ)Π2, we are again faced with the task of tryingto compute Ach(Πi)∩C(χ). Unfortunately, there is nosimple analog to Theorem 2. Ach(Π) ∩ C(χ) may nothave a single maximal element.

Discovering maximal elements of Ach(Π)∩H(Φ) re-lies on a sort of deductive inference in which conclu-sions are inferred from the hypothesis Φ. The enrich-by-need analysis method naturally supports this typeof “forward” inference systematically determining thestrongest conclusions allowed from the hypothesis.

Discovering maximal elements of Ach(Π) ∩ C(χ)

is a type of abductive reasoning in which hypothesesare inferred from the conclusion χ. The enrich-by-needmethod is not as well suited to support this type of“backward” inference. A better method would be onethat systematically determines weaker hypotheses thatare still sufficient to imply χ. This would be a sort of“impoverish-as-possible” analysis method. We are un-aware of any tools that are specifically designed to sup-port this type of reasoning. Such a tool might enable ananalog to Theorem 2 and thus provide a simple way toverify whether Π1 �

C(χ) Π2. This suggests a potentialarea for future research.

In the absence of an impoverish-as-possible analy-sis tool, we believe that �C(χ) is still a useful notionthat can help clarify relationships among protocol vari-ants. For one thing, if one finds a sufficiently strongassumption Φ to ensure χ, one can run cpsa repeat-edly, omitting conjuncts of Φ until χ is no longer satis-fied. Tool support apart, �C(χ) also serves to organizethe concepts in a way that enables clearer discussionsamong standards committee members regarding rela-tive trade-offs. Also, if we are able to use other meansto come up with a goal Γ ∈ C(χ) that Π1 achieves but

21

Π2 does not, then we can use Theorem 1 to demonstrateΠ1 6�C(χ)Π2.

7 Conclusion

In this paper we have presented a family of securitymetrics �G for cryptographic protocols, parameterizedby sets of goals G expressed in a logical language. Thenatural partial ordering on formulas induced by logicalimplication yields a partial order on protocols that re-flects which attacks are possible for a Dolev-Yao styleadversary to achieve. This ensures that protocol Π1 isat least as strong as Π2 exactly when Π1 achieves anysecurity goal achieved by Π2. We showed how thesesecurity metrics can capture and expand well-studiedsecurity hierarchies from the literature [26,14].

The language is designed to be tool-independent, sothat any of the wide variety of protocol analysis toolsavailable might be used to verify that a protocol meetsa given goal. Although we rely on a well-understoodsemantics of our language in the strand space formal-ism, there should be no fundamental barriers to usingother formalisms as a semantic base. We believe this isa step toward enabling a diverse set of analysis toolsto “speak the same language,” allowing analysts to usedifferent tools based on their relative strengths. This vi-sion is mostly limited by the types of properties we havechosen to consider and the adversary model we use toverify them. We currently only consider trace proper-ties. Thus, our language is not well-suited for indistin-guishability properties (useful for privacy goals, amongothers) or probabilistic properties relying on the morecomplex details of a computational adversary model.Expanding our ideas to accommodate such goals (andthe tools that verify them) is an area of future work.

We also identified the strengths of a particular styleof protocol analysis called enrich-by-need. This analysisstyle is embodied by such tools as our own cpsa as wellas Scyther. With such tools we can identify the uniquestrongest goal achieved by a protocol Π in a particu-lar class of goals denoted H(Φ) that all share a com-mon hypothesis Φ. We suspect other styles of protocolanalysis might be similarly characterized. An interest-ing area for future investigation would be to develop an“impoverish-as-possible” style of analysis which wouldidentify maximal elements achieved by Π in the setC(χ) of goals that share a conclusion χ.

We believe this logical formulation of security goalssupported by formal verification can help the process ofstandardizing cryptographic protocols. Standards bod-ies could adopt the practice of requiring submissions toinclude explicit claims of goals they achieve—written in

a formal goal language such as ours—together with evi-dence that those goals have been formally verified withan analysis tool. Our motivating example of pkinitsuggests that the process of explicitly including formalsecurity claims (even without evidence) would go a longway toward improving the quality of published stan-dards as suggested by Basin et al. [5]. It would force thestandards bodies to specifically delineate what proper-ties a protocol is designed to achieve, for instance for-mulas (4) and (7) in the case of pkinit. The resultwould be standards that contain concrete artifacts thatcould be independently verified by others, thereby in-creasing the public’s confidence in the claims.

Our logical goal language could be useful even in theabsence of a formal process for its use. The precision ofthe language makes it easier to understand the securityconsequences of subtle changes to a protocol’s design.This can help guide committee members by providingexplicit statements and evidence for the positive andnegative consequences of design changes, thereby mak-ing it easier to make a case for or against a particulardesign choice. We expect that, used in this way, ourgoal language could make the standardization processmore transparent, with results that are more robust tofuture attacks.

References

1. Martín Abadi and Cédric Fournet. Mobile values, new names,and secure communication. In 28th ACM Symposium onPrinciples of Programming Languages (POPL ’01), pages104–115, January 2001.

2. Omar Almousa, Sebastian A. Mödersheim, Paolo Modesti,and Luca Viganò. Typing and compositionality for securityprotocols: A generalization to the geometric fragment. InESORICS, LNCS. Springer, September 2015.

3. David A. Basin, Cas Cremers, and Simon Meier. Provablyrepairing the ISO/IEC 9798 standard for entity authentica-tion. Journal of Computer Security, 21(6):817–846, 2013.

4. David A. Basin and Cas J. F. Cremers. Modeling and ana-lyzing security in the presence of compromising adversaries.In ESORICS, pages 340–356, 2010.

5. David A. Basin, Cas J. F. Cremers, Kunihiko Miyazaki, SasaRadomirovic, and Dai Watanabe. Improving the security ofcryptographic protocol standards. IEEE Security & Privacy,13(3):24–31, 2015.

6. Mihir Bellare and Phillip Rogaway. Entity authenticationand key distribution. In Crypto, pages 232–249, 1993.

7. Karthikeyan Bhargavan, Antoine Delignat-Lavaud, CédricFournet, Alfredo Pironti, and Pierre-Yves Strub. Triple hand-shakes and cookie cutters: Breaking and fixing authenticationover TLS. In IEEE Symposium on Security and Privacy,2014.

8. Bruno Blanchet. An efficient protocol verifier based on Pro-log rules. In 14th Computer Security Foundations Workshop,pages 82–96. IEEE CS Press, June 2001.

9. R. Canetti and H. Krawczyk. Analysis of key-exchange proto-cols and their use for building secure channels. In Eurocrypt,LNCS, pages 453–474. Springer, 2001.

22

10. Ran Canetti and Hugo Krawczyk. Universally composablenotions of key exchange and secure channels. In Eurocrypt,LNCS, pages 337–351. Springer Verlag, 2002.

11. Iliano Cervesato, Aaron D. Jaggard, Andre Scedrov, Joe-KaiTsay, and Christopher Walstad. Breaking and fixing public-key Kerberos. Inf. Comput., 206(2-4):402–424, 2008.

12. The MITRE Corporation. The common vulnerabilities andexposures (CVE) initiative. http://cve.mitre.org.

13. The MITRE Corporation. The common weakness enumera-tion (CWE). http://cwe.mitre.org.

14. Cas Cremers and Sjouke Mauw. Operational Semantics andVerification of Security Protocols. Springer, 2012.

15. T. Dierks and E. Rescorla. The Transport Layer Security(TLS) Protocol Version 1.2. RFC 5246 (Proposed Standard),August 2008. Updated by RFCs 5746, 5878, 6176.

16. Daniel J. Dougherty and Joshua D. Guttman. Decidabilityfor lightweight Diffie-Hellman protocols. In IEEE Symposiumon Computer Security Foundations, 2014.

17. Nancy Durgin, Patrick Lincoln, John Mitchell, and AndreScedrov. Multiset rewriting and the complexity of boundedsecurity protocols. Journal of Computer Security, 12(2):247–311, 2004. Initial version appeared in Workshop on FormalMethods and Security Protocols, 1999.

18. Santiago Escobar, Catherine Meadows, and José Meseguer.Maude-NPA: Cryptographic protocol analysis modulo equa-tional properties. Foundations of Security Analysis and De-sign V, pages 1–50, 2009.

19. International Organization for Standardization. ISO/IEC29128: Information technology—security techniques—verification of cryptographic protocols, 2011.

20. Joshua D. Guttman. Shapes: Surveying crypto protocolruns. In Veronique Cortier and Steve Kremer, editors, For-mal Models and Techniques for Analyzing Security Protocols,Cryptology and Information Security Series. IOS Press, 2011.

21. Joshua D. Guttman. State and progress in strand spaces:Proving fair exchange. Journal of Automated Reasoning,48(2):159–195, 2012.

22. Joshua D. Guttman. Establishing and preserving protocolsecurity goals. Journal of Computer Security, 22(2):201–267,2014.

23. Joshua D Guttman, Moses D Liskov, and Paul D Rowe. Se-curity goals and evolving standards. In Security Standardis-ation Research, pages 93–110. Springer, 2014.

24. ISO/IEC IS 9798-2, "Entity authentication mechanisms –Part 2: Entity authentication using symmetric enciphermentalgorithms", 1993.

25. Changwei Liu, Anoop Singhal, and Duminda Wijesekera.A model towards using evidence from security events fornetwork attack analysis. In WOSIS 2014 - Proceedings ofthe 11th International Workshop on Security in Informa-tion Systems, Lisbon, Portugal, 27 April, 2014, pages 83–95,2014.

26. Gavin Lowe. A hierarchy of authentication specification. InCSFW, pages 31–44, 1997.

27. R. D. Luce and P. Suppes. Measurement, theory of. Ency-clopedia Britannica, 15th Edition(11):739–745, 1974.

28. Robert A. Martin. Making security measurable and manage-able. In MILCOM 2008, November 2008.

29. C. Meadows. The NRL protocol analyzer: An overview. TheJournal of Logic Programming, 26(2):113–131, 1996.

30. C. Neuman, T. Yu, S. Hartman, and K. Raeburn. The Ker-beros Network Authentication Service (V5). RFC 4120 (Pro-posed Standard), July 2005. Updated by RFCs 4537, 5021,5896, 6111, 6112, 6113, 6649, 6806.

31. John D. Ramsdell, Daniel J. Dougherty, Joshua D. Guttman,and Paul D. Rowe. A hybrid analysis for security protocolswith state. In Integrated Formal Methods, pages 272–287,2014.

32. John D. Ramsdell and Joshua D. Guttman. CPSA: A cryp-tographic protocol shapes analyzer, 2009. http://hackage.haskell.org/package/cpsa.

33. E. Rescorla, M. Ray, S. Dispensa, and N. Oskov. TransportLayer Security (TLS) Renegotiation Indication Extension.RFC 5746 (Proposed Standard), February 2010.

34. A. W. Roscoe. Intensional specifications of security protocols.In IEEE Computer Security Foundations Workshop, pages28–38, 1996.

35. Dawn Xiaodong Song. Athena: A new efficient automatedchecker for security protocol analysis. In Proceedings of the12th IEEE Computer Security Foundations Workshop. IEEECS Press, June 1999.

36. Kun Sun, Sushil Jajodia, Jason Li, Yi Cheng, Wei Tang, andAnoop Singhal. Automatic security analysis using securitymetrics. In MILCOM 2011, November 2011.

37. F. Javier Thayer, Jonathan C. Herzog, and Joshua D.Guttman. Strand spaces: Proving security protocols correct.Journal of Computer Security, 7(2/3):191–230, 1999.

38. Thomas Y. C. Woo and Simon S. Lam. Verifying authen-tication protocols: Methodology and example. In Proc. Int.Conference on Network Protocols, October 1993.

39. L. Zhu and B. Tung. Public Key Cryptography for InitialAuthentication in Kerberos (PKINIT). RFC 4556 (ProposedStandard), June 2006. Updated by RFC 6112.

23