Scholarly article on topic 'The ρ-spi Calculus at Work: Authentication Case Studies'

The ρ-spi Calculus at Work: Authentication Case Studies Academic research paper on "Computer and information sciences"

Share paper

Academic research paper on topic "The ρ-spi Calculus at Work: Authentication Case Studies"

Available online


ELSEVIER Electronic Notes in Theoretical Computer Science 99 (2004) 267-293

The p-spi Calculus at Work: Authentication Case Studies

Riccardo Focardi ^,2 Matteo Maffeia'1,3

a Dipartimento di Informatica Universita Ca'Foscari Venezia, Italia


In [10], we introduce a process calculus for describing security protocols and we propose a static and compositional analysis of entity authentication. In this paper we apply such a technique on well-known shared key authentication protocols. The analysis helps clarifying the protocol logics, suggests simplifications and reveals some attacks. Moreover we discuss how our analysis scales up to multi-protocol systems.

Keywords: Security, Process Calculi, Static Analysis

1 Introduction

Security protocols are designed to provide diverse security guarantees in possibly hostile environments: typical guarantees include the secrecy of a message exchange between two trusted entities, the freshness and authenticity of a message, the authenticity of a claimed identity,... and more.

The presence of hostile entities makes protocol design complex and often error prone, as shown by many attacks to long standing protocols reported in the literature (e.g., [12,15,20,22,25,27]). In most cases, such attacks dwell on flaws in the protocols' logic, rather than on breaches in the underlying cryptosystem.

1 Work partially supported by MIUR project 'Modelli formali per la sicurezza' and EU Contract IST-2001-32617 'Models and Types for Security in Mobile Distributed Systems' (MyThS).

2 Email:

3 Email:

1571-0661/$ - see front matter © 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.entcs.2004.02.012

Indeed, even when cryptography is assumed as a fully reliable building-block, an intruder can engage a number of potentially dangerous actions, notably, intercepting/replaying/forging messages, to break the intended protocol invariants.

Formal methods have proved very successful as tools for protocol design and validations. On the one hand, failures to model-check protocols against formal specifications has lead to the discovery of several attacks ( e.g., [22,23,24,26,27]). On the other hand, static techniques, based on type systems and control-flow analyses have proved effective in providing static guarantees on the protocols' correctness [1,3,2,6,16,17].

Overview Static analysis is also at the basis of the technique we propose in [10,9]: we formulate a set of decidable conditions on the protocols' executions that imply formal guarantees of entity authentication for a large class of protocols. The analysis is carried out in isolation on each participant: each validated principal is decreed locally correct. Our main result, then, is that protocols consisting of the composition of locally correct principals are safe, i.e., any composition of compliant and validated principals is immune to attacks mounted by any protocol intruder 4. Our technique in based on a new process calculus, named p-spi calculus , that we use to specify the authentication protocols of interest: p-spi calculus is a dialect of the spi calculus [4] and includes a set of authentication-specific constructs inspired by the process calculus for protocol narrations Lysa [6].

In this paper, we apply the above mentioned technique to some well-known protocols: Iso Symmetric Key Two Pass Unilateral Authentication Protocol [21], the nonce-based version of the Wide Mouthed Frog Protocol [4], the Woo and Lam Authentication Protocols [29] and the Amended Needham Schroeder Shared-Key Protocol [28]. Our aim is to show that the analysis is applicable to a wide set of authentication protocols. Based on our analysis, we prove the safety of correct protocols for an unbounded number of sessions and, in some cases, we propose simplifications. On the other side, our analysis fails in validating flawed protocols suggesting possible attacks. Moreover, we show that our analysis helps clarifying and formalizing the logics behind the protocols. We give also an example of a multi-protocol system, where entities run multiple sessions of different protocols. We analyze the interleavings among different sessions and discuss how our analysis guarantees their safety.

Structure of the paper. §2 gives a brief outline of p-spi calculus and its operational semantics. §3 summarizes our static analysis, and its main properties. § 4 presents some case studies. In § 5 we give an example of multi-protocol system and in § 6

4 We implicitly appeal to the standard Dolev-Yao intruder model [14]. Intruders may intercept, reply and forge new messages, but never decrypt messages without knowing the corresponding keys.

some concluding remarks.

2 The p-spi calculus

The p-spi calculus derives from the spi calculus [4], and inherits many of the features of Lysa, a version of the spi calculus proposed in [6] for the analysis of authentication protocols. The p-spi calculus differs from both calculi in several respects: (i) it incorporates the notion of tagged message exchange from [9], (ii) it provides primitives for declaring process identities and (shared) long-term keys, (iii) it provides new useful authentication-specific constructs.

Table 1 Syntax

Notation: d ranges over simple names and simple variables, I over identity labels, A,B over principal labels, T over TTP labels, C over tags: {Claim, Owner, Verif, Key, Id},

D ::= Data

simple names tagged names simple variables tagged variables

P,Q ::= Processes I > S I>!S

let k = key(Ij, I2).P

(principal) (replication) (composition) (key assignment)

S :: = Sequential processes

0 (nil)

in(D1,...,Dm).S (input)

out(D 1,..., Dm ).S (output)

new(n).S (restriction) decrypt x as {D1,... ,Dm}j.S (decryption)

encrypt {D1,... ,Dm}d as x.S (encryption)

run(I1rI2).S (run)

commit(I1,I2).S (commit)

Syntax. The syntax of the calculus is presented in Table 1. We presuppose two countable sets: N, of names and V of variables. We reserve a, b, k, m, n for names and x,y, z for variables. Both names and variables can be tagged, noted n : C and x : C, respectively. Tags are a special category of names and include roles (the three special names Claim, Owner, Verif), the identity tag Id and the session key tag Key (tags are explained in Section 3 and their use is illustrated in Section 4). Identities ID are a subset of names, ID c N, further partitioned into principals Ip and trusted third parties (TTPs) It .

Processes (or protocols), ranged over by P, Q are formed as parallel composition of, possibly replicated, sequential processes, ranged over by S. The process form I > S represents the sequential process S running on behalf of a certain entity

identified by I. A sequential process may never fork into two parallel processes. This assumption helps assigning unique identities in ID to (sequential) processes and it is justified by observing that principals, such as initiators, responders and TTPs, can be specified as sequential processes, possibly sharing some long-term keys. To allow the sharing of long-term keys among sequential processes, we provide p-spi calculus with let-bindings as in let k = key(I1;I2).P to declare (and bind) the long-term key k shared between I1 and I2 in the scope P.

The reading of the process forms is as follows. Process 0 is the null process that does nothing, as usual. Process new(n).S generates a fresh name n local to S. The constructs for input, output, new and decryption are essentially the same as in the calculus Lysa. In particular, as in Lysa, we presuppose a unique (anonymous) public channel from/to which messages are read/sent, a technique that models well the worst-case situation of an intruder with a complete control of the network. Similarly to Lysa, our input and decryption constructs may test part of the message read (decrypted), by pattern-matching. Specifically, process in(D1,.. .,Dm).S reads a message composed of m parts matching the respective Di and continues as S, where all the variables instantiated by the pattern-matching are replaced by their actual values. Process out(D1,.. .,Dm).S outputs a messages composed of m parts and then continues as S. The pattern-matching mechanism is so defined as to ensure that untagged patterns only match untagged messages, while tagged patterns only match tagged messages (provided that the tags also match). Accordingly, the pattern x matches the message n (and binds x to n) but it does not match n : Claim (as x is untagged, while n : C is tagged). Similarly, x : Claim matches n : Claim but does not match n : Verif.

Pattern matching also applies upon decryption. Process decrypt x as {D1 Dm}d S continues only if x contains a message encrypted with key d and composed of m parts that match the respective Di. As for input, all the variables instantiated by the pattern-matching are replaced in the continuation S.

Unlike the spi calculus and Lysa, in p-spi calculus we introduce an explicit construct for encryption: process encrypt {D1,.. .,Dm}d as x.S binds variable x to the encrypted message {D1,.. .,Dm}d in the continuation S. This is useful for our analysis, as it eases the reasoning based on the structural inspection of the encrypted messages of a protocol. Finally, the process forms run(I1,I2).S and commit(I1 ,I2) declare that the sequential process I1 is starting, respectively committing, a protocol session with I2. These constructs are used to check the correspondence assertions as done in [16].

Example 1: We illustrate the p-spi calculus with the following simple (flawed) authentication protocol:

1) B ^ A : nB

2) A ^ B : [nß,m}kA

We assume Uab to be known only by A and B and nB to be a fresh nonce generated by B. The intention of the protocol is to give guarantee to B that the last message has been (recently) generated by A as only A should be able to encrypt the freshly generated nonce nB. This protocol can be simply formalized in our calculus as shown in Table 2. Process Initiator, generates a fresh message m € N. After receiving x, it signals the start of a new authentication run with B, encrypts x and m with the long term key &ab, and then sends out the encrypted message. Similarly, Responder generates a fresh nonce nB and sends it out. Then, it reads y from the net and decrypts it with the long term key kAB, checking the nonce nB (through the pattern-matching mechanism of decryption). If the match is successful, the variable z gets bound to a message (from A) and the principal commits through commit(B, A).

Notice that we are only modeling one protocol session. However, as we will see, multiple sessions can be easily achieved by just replicating the Initiator and Responder processes.

Table 2 An example of protocol narration in p-spi calculus

Protocol = let kAB = key (A, B)(A > Initiator(A, B) | B > Responder(B, A))

Initiator(A,B) = new(m).in(x).run(A,B).encrypt{x,m}kAB asy.out(y) Responder(B, A) = new(nB ).out(nB).in(y).decrypt y as {nB, z}kAB .commit(B, A)

Operational Semantics. The operational semantics of p-spi calculus is given in terms of traces, after [7]. The category M of Messages is defined by the following productions: M :: = x | n | {M1,... ,Mm}M | M: C, and includes variables, names, and ciphertexts, possibly tagged. A trace is either empty, noted £, or formed as s :: a where s a trace and a and action. Every prefix form generates a corresponding action. The set of all possible actions, noted Act, includes the action key(k,I1,I2) generated by key assignment, I > in(M1,... ,Mm) generated by input, I > out(M1,... ,Mm) by output, I > new(n) by restriction, I > {M1,... ,Mm}M by encryption and I > {M1,... ,Mm}M by decryption, run(A,B) and commit(A,B) by 'run' and 'commit'.

In p-spi calculus , communication is always performed from/to the environment (processes never synchronize directly). The intruder is modeled implicitly in the environment, by encoding it with rules that formalize the possible ways to manipulate intercepted messages. We denote with T (P) the set of traces of P. The transition semantics is defined formally in [10].

Example 2: Consider again process Protocol of the previous example. The following, is a possible trace of that process:

key(kAB,A,B) :: A>new(m) :: B>new(nB) :: B>out(nB) :: A>in(nB) ::run(A,B) :: A>

encrypt{«B,m}kAB ::A>out({«B,m}kAB)::B>in({«B,m}^)::B>decrypt{«B,m}kAB :: commit(B,A)

Notice that this trace represents only one of the possible interleavings of Initiator and Responder actions. In this particular trace, commit(B, A) is preceded by run(A, B). According to the Woo and Lam idea of correspondence assertions [30], this trace is safe, since B is convinced to communicate with A (action commit(B, A)) and A is indeed running the protocol with B (action run(A, B)).

This protocol is not correct when multiple sessions (with A and B running both as Initiator and as Responder) are considered, as it suffers of a reflection attack. As mentioned above, multiple sessions can be modeled by replicating processes Initiator and Responder. For example, to model multiple protocol sessions, we may consider the following process:

Protocol2 = let kAB = key (A, B). (A >.Initiator(A, B) |A > .Responder(A, B)) |

B >. Res ponder (B, A) IB > .Initiator (B, A))

Notice that A and B run both as Initiator and as Responder. Indeed, the new processes Initiator (B, A) and Responder(A, B) model B running as Initiator and A running as Responder, respectively. Consider the following trace for Protocol2:

key(kAB,A,B) :: B>new(m) :: B>new(nB) :: B>out(nB) :: B>in(nB) :: run(B, A) :: B>encrypt{nB,m}kAB :: B>out({nB,m}kAB) :: B>in({nB,m}kAB) :: B decrypts {nB,m}kAB :: commit(B,A)

It is the same as above, except that B is running as initiator instead of A (as pointed out in bold font). Indeed B, is running the protocol with himself while A is doing nothing. Notice that the attack is revealed by the absence of correspondence: commit(B, A) is not matched by any run(A,B). The trace corresponds to the following (well-known) reflection attack:

1.a) B ^ E (A) : nB

1.b) E (A) ^ B : nB

2.a) B ^ E(A) : {m,nB}kAB 2.b) E(A) ^ B : {m,nB}kAB

We conclude this section by formalizing the definition of safety based on correspondence assertions. As in [16], we say that a trace is safe if every commit(B, A) is preceded by a distinct run(A,B). A protocol guarantees entity authentication if all of its traces are safe.

Definition 2.1 [Safety] A trace s is safe if and only if whenever s = s1:: commit (B, A) :: s2, then s1 = s^ :: run(A,B) :: s", and s^ :: s'/ :: s2 is safe. A process P is safe if, Vs € T(P), s is safe.

Notice that the trace corresponding to the attack discussed in Example 2 is not safe since commit(B,A) is not matched by run(A,B).

3 A Compositional Proof Technique

Our analysis exploits a tagging mechanism for messages that makes the interpretation of certain, critical message components unambiguous. The untagged part of a message forms the message's payload, while the tagged components include entity identifiers, tagged with Id, session keys, tagged with Key, and nonces. Nonce tags are more elaborate, as they convey information on the role that nonces play in the authentication protocol: specifically, nonces may be tagged with Claim, in messages that authenticate a claimant, with Verif, in messages that specify an intended verifier, or with Owner in messages that authenticate a session key.

The proof technique applies to protocol narrations that may be represented as p-spi processes of the form

keys(k1,...,kn).(I1 > !S1 | ... | Im t> ! Sm)

where keys(k1,..., kn) represents a sequence of let binding for the long-term keys k1,..., kn. The analysis proceeds by examining each process keys(k1,..., kn) .Ii > Si, and attempts to validate Si under the key assignment determined by the prefix keys(k1,...,kn).

Given a process keys(k1;.. . ,kn).I>S, we make the following assumptions on the way that long-term and session keys are circulated among principals and trusted third parties, namely: (a) long-term keys are never circulated in clear or within encrypted packets; (b) only principals may receive session keys, without leaking them; and (c) fresh session keys are only distributed by TTP's at most to two parties, only once. When these assumptions are satisfied, we say that keys(k1,... ,kn). I>Sis {kx,. ..,kn}-safe. This is fully formalized in [10].

The proof rules (tables 3 and 4) validate each principal and trusted party of the protocol, relative to a given identity, and two environments, i.e., they derive judgments of the form I; r; n h S for the sequential process S relative to the identity I and the two environments r and n. The history environment n keeps track of each encryption, decryption, run and key assignment occurring in the sequence of actions performed by the party in question. The nonce environment r holds the nonces that the party generates5. A nonce is first included in r as unchecked, when it is introduced by a new prefix. Subsequently, the nonce may be checked by pattern matching, and marked as such, in rules (Authenticate Claim), (Authenticate Owner) and (Authenticate Verif) (in Table 3). The proof rules are so defined as to ensure that each nonce may be checked at most once, as desired. We will explain the intuition behind rules when applying them in our case studies.

5 We write n(x) = enc{. ..}d to say that x ^ enc{. ..}d G n, and similarly for the other entries. We write n(^) = enc{. ..}d to mean that there exists x such that n(x) = enc{.. .}d.

The local correctness, for a sequential process, can be established provided that the process complies with the key safety assumption stated above.

Definition 3.1 [Local Correctness] Let P be the process keys(k ,...,kn).I > S, with ki shared between Ii and Ji. P is locally correct if the judgment I; 0; n^,...,^ h S is

Table 3 Local correctness: Principal and TTP rules Claimant and Verifier Rules

Authenticate Claim

A;r,77: checked;IIhS II(•) = dec{B : ld,n : Claim...}* II(A-) t {key(A,T),key(A,B)} A;r,n : unchecked;n h commit(A,B).S

Authenticate Owner

A; r, n : checked; n h S n(») = dec{B : Id, n : Owner, y : Key ...}kjT n(kAT ) = key(A, T) n(») = dec{D1,... ,Dm}y (n(») = enc{D[,... ,D'm}y implies 3i s.t. Di does not match D¡) A; r,n : unchecked;n h commit(A,B).S

Authenticate Verif

A]T,n : checked; II h S Yl(»)=dec{A : ld,n : Verif... }klB n(i:4jj) = kev(A,B) A;r,n : unchecked;n h commit(A,B).S


A\T\Ily ^ enc{A : ld,.v : Claim}* h S Il(i^) = key(A,B) Il = Ii.B^nm A; r; n h encrypt {A : Id, x : Claim... }kAB as y.S

A;r;n.y m enc{Du... ,Dm}x h S n(») = dec{B : Id,n : Owner,x : Key...}kAT n(kAT) = key(A,T) n = n'.B m run A;T; n h encrypt {D1,... ,Dm}x as y.S

Verifier Run

A\T\Il.y ^ enc{B : ld,.v : Verif }* h S n(A-) t {key(A,T),key(A,B)} Il = lt.B^nm A\Y\YIB nm\-S h encrypt{B : ld,.v : Verif.. .}* as y.S h run(.4,B).5

TTP Rules

Ttp Forward & Check

T;r, n : checked;n.y m enc{A : Id,x : Claim}kBT h S n(*)=dec{B : Id,n : Verif.. .}tlJ n(kBT) =key(B,T) n(kAT) =key(A,T) T; r, n : unchecked; n h encrypt {A : Id, x : Claim . ..}kBT as y.S

Ttp Forward

T;r;n.y m enc{A : Id,x : Claim}kBT h S n(»)= dec{B : Id, x : Verif ...}kAJ n(kBT ) = key(B,T) n(kAT ) = key(A, T) r;r;IIh encrypt {A : ld,.v : Claim... }tBT as y.S

Ttp Distribute

T; r; n.y m enc{A : Id,x : Owner, ks : Key}kBT h S T; r; n h encrypt {A : Id, x : Owner, ks : Key ■■■}kBT as y.S

Table 4 Local Correctness: Generic Principal Rules Generic Principal Rules

Nil New

I; r, n : unchecked; n h S n fresh in r

/;T;II h 0 /;r;IIhnew(;j).S

Input Output

/;r;nhS /;r;nhS

/;r;nhin(...).S /;T;n h out(.. ,).S


I;r;n.y ^ enc{d1.. ,dm}d h S n(^) = dec{... ,d : Key, ...}k implies n = n'.B ^ run.x ^ enc{. ..}d.n"

I; r; n h encrypt{d1,..., dm }d as y.S


/; T; n,v i—' dec{Di ,...,£>„, }d h S

/;T; n h decrypt v as {Di,... ,D„,}d.S

derivable,for n^,...,^ = k1 ^key(I1,J1),...,kn ^key(In,Jn), andSis {k1,...,kn}-safe.

Finally, a process is correct if all of its sequential components are locally correct.

Definition 3.2 [Process Correctness] LetP = keys(k1,...,kn).(I1 > !S1 | ••• |Im > !Sm). P is correct if the process keys(k1;.. .,kn).Ii > Si is locally correct, for all i G {1,...,m}

Our main result states that correctness, in the sense of Definition 3.2, is a sufficient condition for safety (Definition 2.1) and, consequently, is a sufficient condition to guarantee entity authentication. Formally:

Theorem 3.3 (Global Safety) Let P = keys(k1,..., kn). (I1 > ! S1 | ••• | Im > ! Sm). IfP is correct, then it is safe [10].

4 Case Studies

In this section we analyze some well-known authentication protocols. We give the p-spi calculus code of the protocol and either we prove its safety or, in the case the protocol is flawed, we show how it can be fixed in order to be proved correct. In 4.1, we analyze the ISO Symmetric Key Two-Pass Unilateral Authentication Protocol [21], in 4.2 the nonce-based version of the Wide Mouthed Frog Protocol [4], in 4.3 the Woo and Lam Authentication Protocols [29] and in 4.4 the Amended Needham Schroeder Shared-Key Protocol [28].?? the Carlsen's Secret Key Initiator Protocol [11].

4.1 ISO Symmetric Key Two-Pass Unilateral Authentication Protocol

In this section, we apply our analysis to the ISO Symmetric Key Two-Pass Unilateral Authentication Protocol [21]. The aim of this direct authentication protocol is to authenticate A with B.

(1) B ^ A : nB

(2) A ^ B : {B,nB,m}kAB

In the first message, B sends to A a challenge. A receives the nonce and encrypts it together with the identity label of B. B receives the ciphertext, checks the freshness of the message by checking the equality between the nonce sent just before and the nonce inside the ciphertext, and, in the case the operation is successful, accepts the authentication request from A. The identity label B inside the ciphertext avoids reflection attacks (see Section 2). The first step for analyzing this protocol by our technique, is to suitably tag it: nB is used for checking the freshness of a message where the identity label B specifies the intended verifier. Thus B is tagged as Id and nB by Verif. Notice that tags makes clearer the role of message components.

(1) B ^ A : nB

(2) A ^ B : {B : Id,nB : Verif,m}kAB

The code of the protocol is in Table 5. The rule names, on the right side of every construct, summarize the steps of the analysis.

Table 5 ISO Symmetric Key Two-Pass Unilateral Authentication Protocol

Protocoliso = let kjs = key(A,B).(A > Initiatoriso(kAB,A,B) |B >Responderiso(kas,B,A))

Initiatoriso(kAB,A,B) -new(m). in(4 run(A, B).

encrypt{B : Id,x : Verif,m}kAB asy. VERIFIER out(y) Output

Responderiso(kAB,B,A) -new(nB). out(nB). ¡n(y).


decrypty as {B : Id,nB : Verif,z}kAB. Decryption commit(B,A) AuTHENTIOATE VERIF

The local correctness of let kjs = key (A, B).A > Initiator iso(kjB, A, B) can be proved as in Table 6.

The hypotheses of rules (New), (Input), (Run) and (Output) are trivially verified; the only interesting case is (VERIFIER), which is applied for proving

A; {m : unchecked};kjB ^ key(A,B).B ^ run h encrypt{B : Id,x : Verif,m}kAB asy.out(y)

Rules (Claimant), (Verifier) and (Owner) formalize the ways in which A may declare her willingness to authenticate with B. This is why they require that run(A,B)

Table 6 Initiatoriso(kjB, A, B): proof of safety

A;0;kAB ——' key(A,B) h new(m).in(x).run(A,B).encrypt{B : Id,x : Verif,m}kAB asy.out(y)

4 (new)

A; {m : unchecked};kAB — key(A,B) h in(x).run(A,B).encrypt{B : Id,x : Verif, m}kAB asy.out(y)

4 (Input)

A; {m : unchecked};kAB — key(A,B) h run(A,B).encrypt{B : Id,x : Verif,m}kAB asy.out(y)

4 (Run)

A; {m : unchecked};kAB — key(A,B).B — run h encrypt{B : Id,x : Verif,m}kAB asy.out(y)

4 (Verifier)

A; {m : unchecked};kAB — key(A,B).B — run.

y — enc{B : Id,x : Verif,m}kAB h out(y)

4 (Output)

A; {m : unchecked};kAB — key(A,B).B — run.

y — enc{B : Id,x : Verif,m}kAB h 0


Table 7 Responderiso(kAB, B, A): proof of safety

B; 0;kAB — key(A,B) h new(ns).in(y).decrypty as {B : Id, nB : Verif,z}kAB .commit(B,A)

4 (new)

B; {nB : unchecked};kAB — key(A,B) h in(y).decrypty as {B : Id,nB : Verif,z}kAB .commit(B,A)

4 (Input)

B; {nB : unchecked}; kAB — key(A,B) h decrypt y as {B : Id, nB : Verif,z}kAB .commit(B,A)

4 (Decryption)

B; {nB : unchecked};kAB — key(A,B).

y — dec{B : Id,nB : Verif,z}kAB h commit(B^^)

4 (Authenticate Verif)

B; {nB : checked};kAB — key(A,B). y — dec{B : Id, nB : Verif, z}kjB h 0


has been previously executed. In particular, in (Verifier), A may request B to authenticate herself, by sending a message {B : Id,x : Verif. ..}kAB to B using a long-term key kjB shared with B. The role Verif is used, as expected, to inform B that he is the intended verifier of the current authentication session. Rule (Verifier) can be also used by A to inform a TTP T that B is the intended verifier. In that case the ciphertext is encrypted with a long-term key shared between A and T (see Sections 4.2 and 4.3).

(Verifier) requires that B — run is the last element in the history environment and that kjB — key(A,B) belongs to the history environment, which are both true. As far as let kjB = key(A,B). Responderiso(kAB,B,A) is concerned, local correctness can be proved as in Table 7.

Proving the local correctness of let kAB = key(A,B).B > Responderiso(kAB,B,A) is straightforward. The only interesting case is (Authenticate Verif), which is applied for proving

B; {«b : unchecked};kAB ^ key(A,B).y ^ dec{B : Id,«b : Verif,z}kAB h commit(B,A)

Rules (Authenticate Claim), (Authenticate Owner) and (Authenticate Verif) formalize the three possible ways for a principal A to authenticate another principal B. Specifically, (Authenticate Verif) states that A may legally commit (hence authenticate) B only if A has previously generated a nonce n and decrypted a message {A : Id,n : Verif...}kAB (with the same nonce) with k shared with B.

(Authenticate Verif) hypotheses hold since y ^ dec{B : Id,nb : Verif,z}kAB belongs to the history environment and «^unchecked to the nonce environment. Notice that this rule checks the nonce: this is why the binding of nB moves to checked. Moreover, as required by (Authenticate Verif), the history environment contains also kAB ^ key(A,B). Since (New), (Output), (Input) and (Decryption) are trivially satisfied, B; 0;kAB ^ key(A,B) h Responderiso (kAB,B,A).

Finally, the protocol uses no session keys and long term keys are neither sent on the net nor encrypted. Thus both the initiator and responder code are key safe and, hence, can be judged correct. By Theorem 3.3, we directly obtain that every trace of Protocoliso is safe, thus no authentication attack is possible. This example clarifies how direct authentication protocols are analyzed by our proof system: the idea is that a commit(B, A) can be proved only if a ciphertext of a particular form has been previously decrypted. That ciphertext must have been encrypted by following one of the principles, in this case (Verifier). This guarantees that a run(A, B) has been previously asserted. Since nonces can be checked only once, in every trace generated by the protocol, every commit(B,A) is preceded by a distinct run(A,B).

Notice that Protocoliso models only one protocol session, thus one may argue that attacks could arise on multiple sessions. However this is not true as our technique is fully compositional and guarantees that Protocoliso is safe even when sequential processes Initiatoriso and Responderiso are arbitrarily replicated.

The specification can be generalized to an arbitrary number m of entities, acting both as initiator and responder, arbitrarily replicated.

Protocoliso -m = letm^j,= key(4Ij).

(\m,j=li=jIi > !Initiatoriso(kij,Ii,Ij)|Ii > !Responderiso(kij,I,-,Ij)))

kij represents a long term key shared between entities i, and Ij. We assume that kij = kji (and correspondingly define the key assignment only for keys kij with i < j). Initiatoriso and Responderiso are arbitrarily replicated for every pair of entities i,, Ij, using the appropriate long-term key. The proofs of correctness of

processes letJm/=11<Jkij = key(I,Ij).Ii > Initiatoriso(Kij,It,Ij) and letmj=1 i<jkij = key(I,Ij).Ii > Responderiso(Kij,Ii,Ij) are the same as those for the process let k^B = key(kAB,A,B). A > Initiatoriso(kAB,A,B) and for let kAB = key (kAB,A,B). B > Responderiso(kAB,B,A), up to a renaming of identities and keys. As specified by Definition 3.2, replicated identical processes do not need to be re-proved correct.

A variant of the ISO Symmetric Key Two-Pass Unilateral Authentication Protocol

A slight variant of the Iso Symmetric Key Unilateral Authentication Protocol is the following:

(1) B m a : nB

(2) A m B : {A,nB,m}^

The only difference is the identity label in (2): A instead of B, namely the claimant label instead of the intended verifier one. The tagged version of the protocol is:

(1) B m a : nb

(2) A m B : {A : Id,nB : Claim,m}KAB

The protocol can be analyzed similarly to the protocol of Table 5. The only difference is that the encryptions with a nonce tagged by Claim are checked by rule (Claimant) instead of rule (Verifier). Moreover the commit generated by the decryption of such ciphertexts are proved by (Authenticate Claim) instead of (Authenticate Verif). (Authenticate Claim) states that A may legally commit (hence authenticate) B only if A has previously generated a nonce n and decrypted a message {B : Id, n : Claim ...}k (with the same nonce) with k shared either with B, in the case of direct authentication protocols, or with a TTP T, if a TTP is used for achieving authentication (see Sections 4.2 and 4.3).

A flawed protocol

Let us consider again the protocol in Table 2. As discussed in Example 2, the protocol is subject to attacks when running in multiple sessions. Indeed, the flaw in the protocol's logics is revealed by failure to validate one of its components. The problem is with the responder, as we illustrate showing that the process let &AB=key(&AB,A,B).B > Responder(B,A) is not locally correct. Notice that in order for I; r;n h commit(B, A) to be derivable, one needs I = B. However, we easily see that $n such that B; r;n h commit(B,A). In fact, for B;r;n h commit(B,A) to be derivable, by rules (Authenticate Claim), (Authenticate Owner), (Authenticate Verif), it has to exists y such that n(y) = dec{A : Id, nb : R.. •}kAB , with R € {Claim, Owner, Verif}, but the only decrypt construct in S is decrypt y as {nB, z}kAB. Thus, B; r; n h commit(B, A).

Notice that local correctness does not fail only because a role is not specified. Indeed, even adding a role R € {Claim, Owner} to the nonce, the hypotheses of the two authentication rules would not hold, since the ciphertext is missing the identity label A. The attack presented in Section 2 exploits precisely this flaw.

4.2 The nonce-based version of the Wide Mouthed Frog Protocol

In this section, we apply our technique for proving the correctness of the nonce-based version of the Wide Mouthed Frog Protocol (WMF) [4], as presented in [16]. The protocol is composed of the following six messages:

Table 8 Wide Mouthed Frog Protocol in p-spi calculus

ProtOColwMF = let kt = key" ¡(I,-,/(,).

(|" /¡>UnitiatorwMF(ki, /,,/j) | i j =1

/i> !R esponderwMF (k,, /j, /,) | /0 >! Server WMF (k,, /,, kj, /j))

ServerwMF (ki, Ii, kj, Ij) =

new(nT) New

in(Ii). Input

out(nT). Output

in(I/, xi). Input

decrypt xi as {Ij : Id,x^, nT : Verif }kl. Decryption

in(x^). Input

encrypt{I,- : Id,xij,xB : Claim}kj asx. TTP FORW. & CHECK

out(x) Output

/nitiatorwMF(ki, /,, /j) = ResponderwMF(kj, /j, /,) =

new(kjj) New new(nB ) New

out(/i). Output out(nj). Output

in(xr). Input in(x). Input

run(/i, /j ). Run decrypt x as {//: Id,xab, nB : Claim}jj Decryption

encrypt{/j : Id, kjj,xT : Verif as x. VERIF commit(/j, /i) Auth Claim

out(/i, x) Output

(1) (2)

A ^ T T ^ A A ^ T T ^ B B ^ T T ^ B

A, {B, kAB, nT }kAT *

{A, kAB , nB}kBT

The aim of the protocol is to establish a session key kAB between A and B, using a TTP T. Long-term keys kAT and kBT are shared between A and T and between B and T, respectively. The protocol works as follows: in the first message A sends

to T her own identity label and, in the second message, T replies to A by sending a fresh nonce nT. In the third message, A generates a fresh session key kAB and sends the encrypted message {B,kAB,nT}kAT to T, meaning that she is asking T to transport the session-key kAB to B. By checking nT, T is ensured about the freshness of the received ciphertext. Identity label A (sent as plaintext) is a hint for choosing the correct decryption key. The (void) fourth message is just a request from T of starting the protocol with B. In the fifth message B sends to T a fresh nonce nB and, in the last message, T sends to B a ciphertext containing the identity label A, the key kAB and the nonce nB, used again for ensuring freshness. With the last message, T communicates to B that A is willing to share the key kAB with him.

We give a specification of the WMF protocol in p-spi calculus in Table 8 . ProtocolwMF is divided into two parts: in the former, m long term keys ki are associated to the principal Ii and to the TTP T through the construct let ki=key(Ii, I0) iterated for all i = 1m. We assume I0 € It and Ii € Ip for all i = 1m. The latter part consists of the parallel composition of principals and trusted servers. Every principal is parameterized by a specific session partner. Also, every trusted server is parameterized by a specific pair composed of a claimant and a verifier (with the respective keys).

The rule names, on the right side of every construct, show how to verify the local correctness of every sequential component. We briefly discuss the most interesting cases:

InitiatorWMF(ki,Ii,Ij) The only interesting case is (Verifier) which is applied for proving I;T-;n h encrypt{Ij : Id,kij,xT : Verifas x.out^-,x). All the hypotheses are satisfied since n = n'.Ij m run and ni(ki) = key(Ii,I0).

ResponderwMF(kj,Ij,Ii) The only interesting case is (Authenticate Claim) which is applied for proving Ij;r,;nj h commit(Ij,Ii). All the hypotheses hold since n,-(x) =dec{Ii: Id,xab,nB : Claim}kj, andnj(kj) =key(Ij,I0). Moreover r,(nB) = unchecked, since nB has not been checked before..

ServerwMF(ki,Ii,k-,Ij) The only interesting case is (Ttp Forward & Check) which is applied for proving I0;r0;n0 h encrypt{I;- : Id,xij,xB : Claim}kJ as x. out(x). Rules (Ttp Forward & Check), (Ttp Forward) and (Ttp Distribute) govern the behavior of TTPs. The first two rules regulate the generation of messages of the form {...,A : Id,...,x : Claim,.. .}k, the third the generation of session keys. Specifically, in rule (Ttp Forward & Check), T generates a message {...,A : Id,...,x: Claim,... }kBT if it has previously decrypted (and checked the nonce n of) a message of the form {...,B : Id,...,n : Verif,...}kAT, and kAT and kBT are shared with A and B respectively. All the hypotheses hold since n0(x;) = dec{Ij : Id,xij,nT : Verif}k. and r0(nT) = unchecked. Moreover no (ki) = key(Ii, Io) and no (k-) = key(Ij, Io).

Key Safety is trivially satisfied, as long term keys are never extruded and no session key is tagged by Key: this means no session key is used for authentication. Thus, ProtocolWMF is correct.

Type Flaws and Tagging

Actually the protocol discussed above is affected by the following type flaw attack:

(1.b) A ^ E (T) : A

(4.a) E (T) ^ A : *

(5.a) A ^ E (T) : nA

(2.b) E (T) ^ A : пл

(3.b) A ^ E (T) : A, {B, kAB, nA }Kat

(6.a) E (T) ^ A : {B, kAB, nA }kbt

The sessions a and b are interleaved. The enemy waits for an authentication request from A, (1.b). Then the enemy impersonates T and starts a new session with A, (4.a), who generates a new nonce па, (5.a). The enemy, by impersonating the TTP T, sends back to A the nonce па, (2.b). A generates the ciphertext where the verifier of the authentication session is specified, (3.b). The enemy intercepts the ciphertext. Notice that the form of the ciphertext in (3) is the same as the ciphertext in (6). Thus the enemy can reply to A the ciphertext generated by A herself, (6.a). A believes that the identity label B represents the claimant of the authentication session and accepts the (false) authentication request from B.

Notice that the attack is possible only on the untagged version of the protocol: when messages are tagged, the ciphertext sent in (3.b) differs from the one that B expects to receive in (6.b) because of the different tag. This shows how tagging solves message ambiguities. Indeed, we assume that protocol messages are effectively tagged when implemented. Notice that the same protocol, with tagged ciphertexts, is type-checked and considered safe also in [16]. The tagging used there adds a different label to each encrypted protocol message, so that ciphertexts cannot be confused. That tagging is very reasonable and can be easily incorporated in protocol implementations. Our tagging is strictly less demanding: we do not require that every message is unambiguously tagged since we tag only certain components: two ciphertexts of two different protocol messages could be confused if they have the same tags. As a consequence, if the protocol is implemented with the reasonable tagging technique used in [16], our tags can be safely removed without compromising the protocol safety.

4.3 The Woo and Lam Authentication Protocols

The following protocols are proposed by Woo and Lam in [29]. They start by protocol nf and, step by step, simplify it to n. The final simplification results in a flawed protocol. Protocol nf:

^ B : ^ A :

(3) A ^ B :

(4) B ^ T :

(5) T ^ B :

{A, B, UB}kAT

{A, B, ub, {A, B, UB }kAT }kBT {A, B, Uß}kßT

The aim of this protocol is to authenticate A with B. A starts the protocol by sending her own identity label to B, (1). B responds with a challenge nonce nB, (2). That nonce is encrypted by A, with the long term key shared with the TTP T, together with her own identity label and the identity label of B, (3). A represents the claimant of the authentication session, while B the intended verifier. B receives the ciphertext and encrypts it, with the long term key shared with T, together with the two identity labels A and B and the nonce nB. By that ciphertext, B asks T for confirming the authentication request from A. T receives the ciphertext, and encrypts the two identity labels and the nonce nB with the long term key shared with B, (5). B receives the ciphertext, checks its freshness and accepts the authentication request ofA.

Protocol ni, obtained from nf by removing the first occurrence of nB from (4):

(1) A ^B : A

(2) B ^ A : nB

(3) A ^ B : {A,B,nB}kAT

(4) b ^ T : {A,B, {A,B,nB}kAT}kBT

(5) T ^ B : {A,B,nB}kBT

Protocol n2, obtained from ni by removing every occurrence of B:

(1) A ^B : A

(2) B ^ A : nB

(3) A ^ B : {A,nB}kAT

(4) B ^ T : {A, {A,nB}kAT K

(5) T ^ B : {A,nB}kBT

Protocol n3, obtained from n2 by removing the identity label A from (3) and the second occurrence of A from (4):

(1) A mB : A

(2) B M A : He

(3) A M E : {nB}kAT

(4) E M T : {A, {nB}kAT }kET

(5) T M E : {A,nB}kET

Protocol n, obtained from n3 by removing the identity label A from (5):

(1) A ME : A

(2) E M A : HE

(3) A ME : {nB}kAT

(4) E M T : {A, {nB}kAT }kET

(5) T ME : {nB}kET

An attack on n is reported in [29]. A list of attacks on n, n1; n2, n3 and nf can be found in [12]. We report from [5] an attack on n2 (and consequently on n3 and

(1.a) A M I(C) : A

(1.b) I (A) m E : A

(2.b) E m I (A) : he

(2.a) I(C) m A : nE

(3.a) A m I(C) : {A,nB}kAT

(3.b) I(A) ^B : {A,nB}kAT

(4.b) B ^ T : {A, {A,UB}kAT}km

(5.b) T mE : {A,nB}kET

The attack presupposes an authentication request from A to C (1.a), an arbitrary principal different from B. The enemy begins another authentication session with B, (1.b),by impersonating A. B sends to A the nonce nB, (2.b), actually intercepted by the attacker and replicated back to A, (2.a). A encrypts in the ciphertext, (3.a), the nonce received with her own identity (here is the problem: A wants to authenticate herself with B, but in the ciphertext there is no information regarding B) and sends the ciphertext to C. The ciphertext is captured by the attacker and routed to B, (3.b). B sends the ciphertext to T, (4.b), and the server completes the protocol with the last message exchange, (5.b). B accepts the authentication request from A but A wanted to authenticate herself with C. The tagged version of the protocol follows:

(1) A-

(2) B-

(3) A ^B :

(4) B ^ T :

(5) T ^ B :

{A : Id,nB : Claim}kAT

{A : Id, {A : Id,nB : Claim}kAT}kBT

{A : Id,nB : Claim}kBT

Table 9 Simplified Woo and Lam Protocol in p-spi calculus

Pr0t0C0lwL =

let ki = key°=1(/,-, lo).

(|m /p\/mtiatorwL(ki, /i, /j )| i, j = 1

/i>\KesponderwL (ki, /j, /') | /o>\ServerwL(ki, /i, kj, /j))

Initiatorwiiki: Ii, Ij) =

out(I,). Output

ln(xB). Input

run(I,, Ij). Run encrypt{Ij : Id,xB : Verif }k as x. VERIFIER

out(x) Output

Serverwi(ki, I/, kj, Ij) =

ln(Ij, z). Input

decrypt z as {Ij : Id,x,: Verif }k/. Decryption encrypt{I, : Id,xt: Claim}kj asy. TTP FORWARD out(y) Output

ResponderwL(Kj, Ij, I/) =

new(nB) New

out(nB). Output

in(x). Input

out(Ij, x). Output

in(y). Input decrypty as {I;: Id,nB : ClaimU Decryption

commlt(/j, /,)

Auth Claim

We cannot check this protocol since A specifies her own identity in the ciphertext encrypted with the long term key owned by A and T (Message 3). No rule allows this kind of encryption, since the verifier identity is missing and the ciphertext is useless for completing a safe authentication session. Moreover the server encrypts a ciphertext, with the long term key owned by B and T, where a nonce tagged by Claim and A by Id appear. There is no rule for this kind of encryption, since the server has no evidence about the willingness of A to authenticate with B.

The attacks on Пf and П1 are based on type flaws and can be prevented by tagging. Indeed, we are able to check in p-spi calculus only Пf and П1. The tagged version of П1 is the following:

^ B : ^ A :

(3) A ^ B

(4) B ^ T

(5) T ^ B

{A,B : Id,nB : Verif}kAT {A,B,{A,B : Id,nB : Verif}клт {A : Id,B,nB : Claim}kBT

For checking the protocol, the identity label B in (3) is required together with the nonce tagged by Verif. This confirms that the attack to n2 arises because A does not specify the intended verifier in the ciphertext (3) and the server has no way to derive which principal the authentication session is directed to.

Our rules suggest a simplification of the protocol: since the identity label A in (3) is not tagged, it can be safely removed as well as the outside ciphertext in (4). The resulting protocol is :

{B : Id,nB : Verif}kAT A, {B : Id,nB : Verif}kAT B : {A : Id,nB : Claim}kBT

This simplification is also suggested in [16]. The p-spi calculus specification of the protocol is given in Table 9. In order to check the correctness of the server, Ttp Forward is applied. Such a rule states that T may generate a message {A : Id, x : Claim,.. .}kBT if it has previously decrypted (without checking the nonce) a message of the form {B : Id, x : Verif,...}kAT (kAT and kBT are shared with A and B respectively); notice that x is forwarded to B so that B can check the freshness of the first message.

4.4 The Amended Needham Schroeder Shared-Key Protocol

The original version of this protocol was proposed in [28] and was affected by different attacks. Some of them rely on cryptographic assumptions [8], other on the protocol's logics [13]. A correct version of the protocol is the Amended Needham-Schroeder Protocol, suggested by Needham and Schroeder in [25]:

(1) A — B : A

(2) B — A : {A, uB}kBT

(3) A — T : A,B,UA, {A,u%}kBT

(4) T — A : {ua, B, kAB, {kAB, uB, A }kBT }kAT

(5) A — B : {kAB, uB, A}kBT

(6) B — A : {uB}kab

(7) A — B : {ub - 1}kab

The tagged version of the protocol may help understanding how our system works with authentication through session keys, and clarifying the protocol's logics:

(1) A ^ B

(2) B ^ A

(3) A ^ T

(4) T ^ A

(5) A ^ B

(6) B ^ A

(7) A ^ B

A starts the protocol sending her own identity label to B as cleartext, (1). In (2), B encrypts, with the long term key shared with T, a fresh nonce nQB together with the identity label A. By this ciphertext, B communicates to T he is willing to authenticate himself with A. In (3), A sends to T the ciphertext received by B and, as cleartext, also a fresh nonce nA and the two identity labels A and B. The server distributes, by means of two ciphertexts, a session key kAB to A and B, (4). The identity label B is inserted in the ciphertext encrypted by kAT for communicating to A that B is the owner of the session key kAB. Similarly the identity label A, in the ciphertext encrypted by kBT, informs B that A is the owner of kAB. Thus nA and nB are tagged by Owner and kAB by Key. In (6), A receives a ciphertext encrypted with kAB. By the nonce-check performed on the ciphertext received in (4), A knows that kAB is fresh. Since A has not generated any ciphertext encrypted with kAB before, that ciphertext has been originated by B. Thus B is alive and A can authenticate him. Similarly, in (7), B receives a ciphertext encrypted with kAB, different from the one encrypted in (6). Thus that ciphertext has been originated by A and B is allowed to authenticate her. Let us suppose to provide p-spi calculus with integer numbers as spi calculus [4], and specifically to add prev(d) and succ(d) to data. The specification of the protocol is in Table 10. The protocol passes our analysis and, hence, is safe. We briefly discuss the interesting rules of every sequential component:

(Ttp Distribute) is used for checking the safety of the server. The rule allows a TTP T to declare new session keys through messages of the form {I: Id,x : Owner, ks : Key.. .}¿. (Ttp Distribute) is trivially satisfied since it has no side conditions.

(Owner) is used for checking the safety of both the initiator and the responder. The rule allows A to send a message {D1,... ,Dm}y for confirming to have received the fresh session key y, provided that she has previously decrypted a message {B : Id,n : Owner,y : Key.. •} kAT, declaring that y is a fresh key shared with B, and she has previously performed a run with B. Both the conditions are satisfied inInitiatorNs(ki,Ii,Ij) andResponder^s(kj,Ij,I). (Authenticate Owner) states that A may commit B if she has decrypted (i) a mes-

{A, n''B}kBT

A, B, nA, {A, n(B}kBT

{nA : Owner,B : Id,kAB : Key,{kAB : Key,n°B : Owner,A : Id}kBT}kAT {kAB : Key,n°B : Owner,A : Id}kBT

{ nB } kAB

{nB - 1}kAB

Table 10 Amended Needham Schroeder Shared-Key Protocol in p-spi calculus


let hi = key" ¡(I,-,Io).

Ii>\InitiatorNs (kt, Ii, Ij )|

Ii>\ResponderNs(k,,Ij,Ii) \ Io > \ ServerNs (ki, Ii, kj, Ij ))

ServerNs(ki, It, kj ,Ij). =

in(/,-, Ij, xt, x). Input

decrypt x as {Ii,xj }kj. Decryption

new(ktj). New

encrypt {xj : Owner,Ij : Id,ktj : Key}kj asyj. TTP DISTRIBUTE

encrypt {xt : Owner,Ij : Id,ktj : Key,yj}kt asy. TTP DISTRIBUTE

out(y). Output

Initiator's (k,, //, Ij ) = out(/,- ).

in(4 new(nA). out(I,, Ij, nA, x).

in (xt).

decrypt xt as {na : Owner,

Ij : Id,x,j : Key,x_b }j, . out(xß). in(yB ).

decrypt yB as {y}x:j commit(I,,Ij ). run(I,, Ij ).

encrypt {prec(y)}x,j asx. out(x)





Decryption Auth Owner


ResponderNs(kj, Ij, It) =

in(It). Input

new(nB). New

encrypt {Ij,nB}kj asx. Encryption

out(x). Output

in(xT). Input decrypt xT as {nB : Owner;It: Id,xtj : Key}kj. Decryption

new(a). New

encrypt {a}xtj as y. OWNER

out(y). Output

in(yA). Input

decryptyA as {prec(a)}xjj. Decryption

commit(Ij,It) AUTH OWNER

sage {B : Id,n : Owner,y : Key.. .}kAT, encrypted by a TTP, including a fresh session key y owned by B and a nonce n that A previously generated; and (it) at least one message ..,Dm}y that she did not generate 6 . (Authenticate Owner) is satisfied in Initiators',h,Ij) as well as in ResponderNs(kj,Ij,I).

Notice that also key safety is satisfied, since long term keys and received session keys are never extruded, and the TTP distributes correctly the session key k,j to I and Ij. An interesting point is that the identity label and the nonce in the ciphertext

(2) sent by B are not tagged. This means that such an encryption is useless for the

safety of ProtocolNs. Moreover, the nested encryption (4) produced by the server is useless too: the ciphertexts could be safely split up. The resulting protocol is known

as Carlsen's Secret Key Initiator Protocol [11] which, similarly to the Amended Needham Schroeder Shared-Key Protocol, passes our analysis.

6 in this case the principal sends an encrypted nonce {nA }K and expects to receive back the en-

crypted nonce decremented by one, i.e., {nA — 1 }K.

5 An example of multi-protocol system

In this section we present an example of multi-protocol system. Particularly, we consider the interaction among principals running both the Wide Mouthed Frog Protocol (Section 4.2) and a slight variant of the Woo and Lam Authentication Protocol (Section 4.3):

(1) A ^B : A

(2) B ^ A : hb

(3) A ^B : {B,M,m}K

(4) b ^ T : A, {B,M,nB}kAT

(5) T ^B : {A,M,nB}kBT

This protocol differs from the simplified version of Section 4.3 only because of the presence of a payload M sent by A and transmitted by T to B.

5.1 An untagged interleaving

Let us consider what may happen when principals run untagged versions of the protocols: the multi-protocol system is flawed. In Section 4.2 an attack on the untagged Wide Mouthed Frog Protocol has been presented: a similar attack can be performed also in a multi-protocol system. In this case A acts both as initiator, following the Wide Mouthed Frog Protocol, and Responder, following the Woo and Lam Authentication Protocol:

(i. WMF) A ^ E(T) : A

(1.WL) E (B) ^ A : B

(2.WL) A ^ E(B) : ub

(2. WMF) E (T) ^ A : ub

(3.WMF) A ^E(T) : {B, M, Uß}kAT

(3.WL) E (B) ^ A : M'

(4.WL) A ^E(T) : A, M'

(5.WL) E (T) ^ A : {B, M, Uß}kAT

At the end, A believes that B is willing to authenticate himself: A accepts the authentication request from B even if B is not present in the authentication session.

5.2 A tagged interleaving

Let us now consider the tagged versions of the protocols. The previous attack is impossible, since B is tagged by Verif in (3.WMF) while is tagged by Claim in (5.WL). As a direct consequence of Theorem 3.3, given the safety of ProtocolWL and ProtocolWMF, the parallel composition (Table 11) of principals running the two

Table 11 An example of multi-protocol system

Multiprotocol =

let ki = key™!®, Io).

( |m I¡>\InitiatorwMF (k¡, Ii, Ij )\Ij>\InitiatorwL (ki, Ii, Ij ) | j = 1

Ii>IResponderwMF(ki,Ij,Ii)\Ii>!ResponderwL(ki,Ij,Ii) | Io>!ServerwMF(ki, Ii, kj, Ij )|Io>IServerwL(ki, I/-, kj, Ij ))

protocols is safe. An interesting point is the possible interleaving of authentication sessions. For instance let us consider the following scenario:

(i.WMF) A ^B(T) (2.WL) B(T) ^A (3.WMF) A ^B(T)

{B : Id,M,üb : Verif}¿A:

(4.WL) B ^ 7 : A, {B : Id,M,nB : Verif}kAT

(5.WL) T ^B : {A : Id,M,nB : Claim}¿BT

A is running as initiator in the Wide Mouthed Frog Protocol, while B as responder in the Woo and Lam. B intercepts the message sent by A to T and exploits it for completing the authentication session. The interleaving arises since the second message of the two protocols has the same structure: an identity label, a payload and a nonce. Also the tags are the same. The corresponding trace is

A > out (A)::

B>in(A):: B>new(nB) :: B>out(nB) ::

A>in(nB) :: run(A,B) :: A >encrypt{B: Id,M,nB : Verif}¿AT :: A >out({B : Id,M,nB : Verif}kAT) :: B>in({B : Id,M,nB : Verif}kAT) :: B>out(A, {B : Id,M,nB : Verif}kAT) :: T>in(A, {B : Id,M,nB : Verif}kAT):: T >decrypt{B : Id,M,nB : Verif}kAT :: T>encrypt{A : Id,M,nB : Claim}¿BT :: T>out(^^ : Id,M,nB : Claim}¿BT) :: B>: Id,M,nB : Claim}¿BT) :: B>decrypt{A : Id,M,nB : Claim}¿BT :: commit(B,A)

which is safe. Our tagging is fair general and can be applied uniformly over authentication protocols. The main result ensures that if every sequential component is locally correct, then all their possible interleavings in a multi-protocol tagged systems are safe. This result is justified by our tagging approach: it conveys and formalizes authentication informations and if two messages can be confused, then they provide the same authentication information (in the example case, {B : Id,M,nB : Verif}¿AT conveys the following information: A has started an authentication session with B).


Table 12 Summary of the proof rules

(Authenticate Claim) After receiving {B : Id,n : Claim ...}k and checking the nonce n, A authenticates B as the claimant of the authentication session. See Sections 4.1,4.2 and 4.3.

(Authenticate Owner) After receiving {B : Id,n : Owner,y : Key■■■}kAT and checking the nonce n, A authenticates y as a fresh session key owned by B. The reception of {D1,...,Dm}y authenticates B. See section 4.4.

(Authenticate Verif) After receiving {A : Id,n : Verif...}kAB and checking the nonce n, A authenticates B, since the verifier requested by B is A. See Section 4.1.

(Claimant) By encrypting {A : Id, x : Claim,.. .}kAB, A specifies herself as claimant and starts an authentication session with B. See Section 4.1.

(Verifier) By encrypting {B : Id,x : Verif,.. .}k, A specifies B as verifier and starts an authentication session with B. See Sections 4.1,4.2 and 4.3.

(Owner) By encrypting {D1,... ,Dm}y, A confirms to have received the fresh session key y in {B : Id,n : Owner,y : Key,.. .}k and starts an authentication session with B. See Section 4.4.

(Ttp Forward & Check) By encrypting {A : Id,x: Claim,.. .}kBT, T informsB that A is recently willing to authenticate herself with him. See Section 4.2

(Ttp Forward) By encrypting {A : Id, x: Claim,.. .}kBT, T informs B that A is willing to authenticate herself with him. checking the freshness of the request is demanded to B. See Section 4.3.

(Ttp Distribute) By encrypting {A : Id,x : Owner,ks : Key,...}kBT, T distributes the fresh session key ks to B, declaring that it is shared with A. See Section 4.4.

In this paper we have applied our framework of [9,10] to the analysis of various authentication protocols taken from literature. The rules applied for verifying each protocol are summarized in Table 12. Our technique seems to be promising especially for the simplicity of the analysis. On the other hand, it is fair to observe that the analysis cannot validate every possible (correct) authentication protocol, since it could be the case that entity authentication is achieved without necessarily combining together the principles we have considered here. However, the present principles appear general enough to validate many existing protocols and help understanding the underlying authentication mechanisms. Furthermore, the framework is scalable as new conditions may be added, if needed, to validate new protocols. we are currently extending our approach to deal with a wider range of authenti-

cation protocols, e.g., protocols based on public-key encryption and other kinds of nonce-challenges [18,19]. We are basing such an extension on a type and effect system. This should allow us to formally compare our approach with the type and effect systems proposed by Gordon and Jeffrey in [16,17].

Acknoledgements We thank the anonymous referees for their very helpful comments and suggestions.


[1] M. Abadi. Secrecy by typing in security protocols. Journal of the ACM, 46(5):749-786, 1999.

[2] M. Abadi and B. Blanchet. Analyzing Security Protocols with Secrecy Types and Logic Programs. In

29th Annual ACM SIGPLAN - SIGACT Symposium on Principles of Programming Languages (POPL 2002), pages 33-44, Portland, Oregon, January 2002. ACM Press.

[3] M. Abadi and B. Blanchet. Secrecy types for asymmetric communication. Theor. Comput. Sci., 298(3):387-415, 2003.

[4] M. Abadi and A. D. Gordon. A calculus for cryptographic protocols: The spi calculus. Information and Computation, 148(1):1-70, 1999.

[5] R. Anderson and R. Needham. Programming satan's computer. In Jan van Leeuwen, editor, Computer Science Today — Recent Trends and Developments, volume 1000 of LNCS, pages 426-440, 1995.

[6] C. Bodei, M. Buchholtz, P. Degano, F. Nielson, and H. Riis Nielson. Automatic validation of protocol narration. In In proceedings of 16th IEEE Computer Security Foundations Workshop (CSFW 16), pages 126-140, June 2003.

[7] M. Boreale. Symbolic trace analysis of cryptographic protocols. In Proceedings ofICALP 01, volume 2076, pages 667-681. LNCS 2076, Springer Verlag, 2001.

[8] C. Boyd. Hidden assumptions in cryptographic protocols. IEEE Proceedings, Part E, pages 433-436, November 1990.

[9] M. Bugliesi, R. Focardi, and M. Maffei. Principles for entity authentication. In Proceedings of 5th International Conference Perspectives of System Informatics (PSI 2003), volume 2890, pages 294-307, July 2003.

[10] M. Bugliesi, R. Focardi, and M. Maffei. Compositional analysis of entity authentication protocols. In

Proceedings of European Symposium on Programming (ESOP 2004), March 2004.

[11] U. Carlsen. Optimal privacy and authentication on a portable communications system. Operating Systems Review, 28(3):16-23, July 1994.

[12] J. Clark and J. Jacob. A survey of authentication protocol literature: Version 1.0., November 1997.

[13] D. Denning and G. Sacco. Timestamps in key distributed protocols. Communication of the ACM, 24(8):533-535, 1981.

[14] D. Dolev and A. Yao. On the security of public key protocols. IEEE Transactions on Information Theory, 29(2): 198-208, 1983.

[15] R. Focardi, R. Gorrieri, and F. Martinelli. Non interference for the analysis of cryptographic protocols. In

Proceedings ofICALP'00, pages 354-372. Springer LNCS 1853, July 2000.

[16] A. Gordon and A. Jeffrey. Authenticity by typing for security protocols. In 14th IEEE Computer Security Foundations Workshop (CSFW-14),pages 145-159, June 2001.

[17] A. Gordon and A. Jeffrey. Types and effects for asymmetric cryptographic protocols. In 15th IEEE Computer Security Foundations Workshop — CSFW'01, pages 77-91. IEEE Computer Society Press, 24-26 June 2002.

[18] J. Guttman. Security protocol design via authentication tests. In 15th IEEE Computer Security Foundations Workshop — CSFW'01, pages 92-103, Cape Breton, Canada, 24-26 June 2002. IEEE Computer Society Press.

[19] Joshua D. Guttman and F. Javier Thayer. Authentication tests and the structure of bundles. Theoretical Computer Science, 283(2):333-380, 2002.

[20] J. Heather, G. Lowe, and S. Schneider. How to prevent type flaw attacks on security protocols. In 13th IEEE Computer Security Foundations Workshop — CSFW'00, pages 255-268, Cambridge, UK, 3-5 July 2000. IEEE Computer Society Press.

[21] ISO/IEC. Information Technology-Security Tecniques-Entity Authentication Mechanisms, Part 2:Entity Authentication using Simmetric Tecniques. 1993.

[22] G. Lowe. Breaking and fixing the Needham-Schroeder public-key protocol using FDR. In Tools and Algorithms for the Construction and Analysis of Systems (TACAS), volume 1055, pages 147-166. Springer-Verlag, Berlin Germany, 1996.

[23] G. Lowe and B. Roscoe. Using CSP to detect errors in the TMN protocol. IEEE Transaction on Software Engineering, 23(10):659-669, October 1997.

[24] J. C. Mitchell, M. Mitchell, and U. Stern. Automated analysis of cryptographic protocols using mur^. In

Proceedings of the 1997 IEEE Symposium on Research in Security and Privacy, pages 141-153. IEEE Computer Society Press, 1997.

[25] R M Needham and M D Schroeder. Authentication revisited. ACMSIGOPS Operating Systems Review, 21(1):7-7, 1987.

[26] L. C. Paulson. The inductive approach to verifying cryptographic protocols. Journal of Computer Security, 6:85-128, 1998.

[27] L. C. Paulson. Relations between secrets: Two formal analyses of the yahalom protocol. Journal of Computer Security, 9(3):197-216, 2001.

[28] M.D. Schroeder R.M. Needham. Using encryption for authentication in large networks of computers.

ACM Communication, 21(12):993-999, 1978.

[29] Thomas Y. C. Woo and Simon S. Lam. A lesson on authentication protocol design. Operating Systems Review, 28(3):24-37, 1994.

[30] T.Y.C. Woo and S.S. Lam. Authentication for distributed systems. IEEE Computer, 25(3):39-51, 1992.