Authentication Primitives for Protocol Specifications?Chiara Bodei1 Pierpaolo Degano1 Riccardo Focardi2 Corrado Priami31 Dipartimento di Informatica, Universita di Pisa

Via Filippo Buonarroti, 2, I-56127 Pisa, Italy –fchiara,deganog@di.unipi.it2 Dipartimento di Informatica, Universita Ca’ Foscari di Venezia,Via Torino 155, I-30173 Venezia, Italy –

focardi@dsi.unive.it3 Dipartimento di Informatica e Telecomunicazioni, Universita di TrentoVia Sommarive, 1438050 Povo (TN), Italy –priami@science.unitn.it

Abstract. We advocate here the use of two authentication primitives werecentlypropose in a calculus for distributed systems, as a further instrument for program-mers interested in authentication. These primitives offera way of abstracting fromvarious specifications of authentication and obtaining idealized protocols “secureby construction”. We can consequently prove that a cryptographic protocol is thecorrect implementation of the corresponding abstract protocol; when the prooffails, reasoning on the abstract specification may drive to the correct implemen-tation.

1 Introduction

Security in the times of Internet is something people cannotdo without. Security has todo with confidentiality, integrity and availability, but also with non-repudiation, authen-ticity and even more, depending on the application one has inmind. The technology ofdistributed and parallel systems and networks as well influences security, introducingnew problems and scenarios, and updating some of the old ones.

A big babel of different properties and measures have been defined to guarantee thata system is secure. All the above calls for formal methods andflexible tools to catch theelusive nature of security.

Mostly, problems arise because it is necessary to face up to the heterogeneity ofadministration domains and untrustability of connections, due to geographic distribu-tion: communications between nodes have to be guaranteed, both by making it possibleto identify partners during the sessions and by preserving the secrecy and integrity ofthe data exchanged. To this end specifications for message exchange, called securityprotocols, are defined on the basis of cryptographic algorithms. Even though carefullydesigned, protocols may have flaws, allowing malicious agents or intrudersto violatesecurity. An intruder gaining some control over the communication network is able tointercept or forge or invent messages. In this way the intruder may convince agents toreveal sensitive information (confidentiality’s problems) or to believe it is one of thelegitimate agents in the session (authentication’s problems).? Work partially supported by EU-project DEGAS (IST-2001-32072) and by Progetto MIUR

Metodi Formali per la Sicurezza (MEFISTO).

Authentication is one of the main issues in security and it can have different pur-poses depending on the specific application considered. Forexample,entity authenti-cation is related to the verification of an entity’s claimed identity [20], while messageauthenticationshould make it possible for the receiver of a message to ascertain its ori-gin [28]. In recent years there have been some formalizations of these different aspectsof authentication (see, e.g., [1, 8, 14, 16, 17, 21, 27]). These formalizations are crucialfor proofs of authentication properties, that sometimes have been automatized (see, e.g.[11, 18, 23, 22, 25]).

A typical approach presented in the literature is the following. First, a protocol isspecified in a certain formal model. Then the protocol is shown to enjoy the desiredproperties, regardless of its operating environment, thatcan be unreliable, and can evenharbour a hostile intruder.

We use here basic calculi for modelling concurrent and mobile agents. In particular,we model protocols as systems of processes, calledprincipalsor parties. Using a purecalculus allows us to reason on authentication and securityfrom an abstract point ofview. Too often, security objectives, like authentication, are not considered in the verydesign phase and are instead approximately recovered afterit. The ideal line underlyingour approach relies on the conviction that security should directly influence the designof programming languages, because languages for concurrent and distributed systemsdo not naturally embed security.

In particular, we here slightly extend the spi calculus [1, 2], a language for mod-elling concurrent and distributed agents, endowed with cryptographic primitives. Wegive this calculus certain kinds of semantics, exploiting the built-in mechanisms forauthentication, introduced in [4]. Our mechanisms enable us to abstract from the vari-ous implementations/specifications of authentication, and to obtain idealized protocolswhich are “secure by construction”. Our protocols, or rather their specifications canthen be seen as a reference for proving the correctness of ”real” protocols.

In particular, our first mechanism, calledpartner authentication[4], guarantees eachprincipalA to engage an entire run session with the same partnerB. Essentially, thesemantics provides a way of “localizing” a channel toA andB, so that the partnersaccept sensitive communications on this localized channel, only. In particular, a receivercan localize the principal that sent him a message. Such a localization relies on theso-calledrelative addressof A with respect toB. Intuitively, this represents the pathbetweenA andB in (an abstract view of) the network (as defined by the syntax of thecalculus). Relative addresses arenotavailable to the users of the calculus: they are usedby the abstract machine of the calculus only, defined by its semantics.

Our solutions assume that the implementation of the communication primitives hasa reliable mechanism to control and manage relative addresses. In some real cases thisis possible, e.g., if the network management system filters every access of a user to thenetwork as it happens in a LAN or in a virtual private network.This may not be the casein many other situations. However, relative addresses can be built by storing the actualaddress of processes in selected, secure parts of message headers (cf. IPsec [19]).

Also our second mechanism, calledmessage authentication[6, 4], exploits relativeaddresses: a datum belonging to a principalA is seen byB as “localized’ in the local

space ofA. So, our primitive enables the receiver of a message to ascertain its origin,i.e. the process that created it.

The above sketched primitives help us to give theabstractversion of the protocolunder consideration, which has the desired authenticationproperties “by construction”.A moreconcreteversion of the protocol, possibly involves encryptions, nonces, signa-tures and the like. It gives security guarantees, whenever its behaviour turns out to besimilar to that of the abstract specification. A classical process algebraic technique tocompare the behaviour of processes is using some notion of equivalence: the intuitionis that two processes have the same behaviour if no distinction can be detected by anexternal process interacting with each of them. The concrete version of a protocol is se-cure if its behaviour cannot be distinguished from the one ofthe abstract version. Thisapproach leads to testing equivalence [10, 7] and we shall follow it hereafter.

Our notion directly derives from the Non-Interference notion called NDC that hasbeen applied to protocol analysis in [17, 16, 15]. Note also that the idea of comparingcryptographic protocol with secure-by-construction specifications is also similar to theone proposed in [1] where a protocol is compared with “its own” secure specification.We are indeed refining Abadi’s and Gordon’s approach [1]: thesecure abstract protocolhere is unique (as we will show in the following) and based on abstract authentica-tion primitives. On the contrary, in [1] for each protocol one needs to derive a securespecification (still based on cryptography) and to use it as areference for proving au-thentication.

The paper is organized as follows. The next section briefly surveys our version ofthe spi calculus. Section 3 intuitively presents our authentication primitives, Section 4introduces our notion of correct implementation. Finally,Section 5 gives some applica-tions.

2 The Spi Calculus

Syntax. In this section we intuitively recall a simplified version ofthe spi calculus [1,2]. In the full calculus, terms can also be pairs, zero and successors of terms. Extendingour proposal to the full calculus is easy. Our version of the calculus extends the�-calculus [24], with cryptographic primitives. Here, termscan be names, variables andcan also be structured as pairs(M1;M2) or encryptionsfM1; : : : ;MkgN . An encryp-tion fM1; : : : ;MkgN represents the ciphertext obtained by encryptingM1; : : : ;Mk un-der the keyN , using a shared-key cryptosystem such as DES [9]. We assume to haveperfect cryptography, i.e. the only way to decrypt an encrypted message is knowing thecorresponding key.

Most of the processes constructs should be familiar from earlier concurrent calculi:I/O constructs, parallel composition, restriction, matching, replication. We give belowthe syntax and, afterwards, we intuitively present the dynamics of processes. Terms andprocesses are defined according to the following BNF-like grammars.L;M;N ::= termsa; b; ; k;m; n namesx; y; z; w variablesfM1; : : : ;MkgN shared en ryption

P;Q;R ::= pro esses0 nilMhNi:P outputM(x):P input(�m)P restri tionP jP parallel omposition[M = N ℄P mat hing!P repli ation ase L of fx1; : : : ; xkgk in P shared�key de ryption– The null process0 does nothing.– The processMhNi:P sends the termN on the channel denoted byM (a name, or

a variable to be bound to), provided that there is another process waiting to receiveon the same channel. Then behaves likeP .

– The processM(x):P is ready to receive an inputN on the channel denoted byMand to behave likePfN=xg, where the termN is bound to the variablex.

– The operator(�m)P acts as a static declaration (i.e. a binder for) the namem in theprocessP that it prefixes. The agent(�m)P behaves asP except that I/O actionsonm are prohibited.

– The operatorj describes parallel composition of processes. The components ofP jQmay act independently; also, an output action ofP (resp.Q) at any output portMmay synchronize with an input action ofQ (resp.P ) at M . In this case, a silentaction� results.

– Matching [M = N ℄P is anif-then operator: processP is activated only ifM = N .– The process!P behaves as infinitely many copies ofP running in parallel, i.e. it

behaves likeP j !P .– The process ase L of fx1; : : : ; xkgN in P attempts to decryptL with the keyN . If L has the formfM1; : : : ;MkgN , then the process behaves as the processP ,

where eachxi has been replaced byMi, i.e.as the processPfM1=x1; : : : ;Mk=xkg.Otherwise the process is stuck.

The operational semantics of the calculus is a labelled transition system, defined inthe SOS, logical style. The transitions are represented asP ��! P 0, where the labelcorresponds to a silent or internal action action� that leads the processP in the processP 0. To give the flavour of the semantics, we illustrate the dynamic evolution of a simpleprocessS. For more details, see [4].

Example 1.In this example, the systemS is given by the parallel composition of thereplication (of processP ) !P and of the processQ.S = !P j QP = ahfMgki:0Q = a(x): ase x of fygk in Q0Q0 = (�h)(bhfyghi:0 j R)

!P represents a source of infinitely many outputs ona of the messageM encryptedunderk. Therefore it can be rewritten asP j !P = ahfMgki:0 j !P . So, we have thefollowing part of computation:S ��! 0 j !P j ase fMgk of fygk in Q0 ��! 0 j !P j (�h)(bhfMghi:0 j R)In the first transition,Q receives on channela the messagefMgk sent byP andfMgkreplacesx in the residual ofQ. In the second transition,fMgk can be successfullydecrypted by the residual ofQ, with the correct keyk andM replacesy in Q0. Theeffect is to encryptM with the keyh, private toQ0. The resulting outputbhfMghi canoccur to be matched by some input inR.

3 Authentication Primitives

Before presenting our authentication mechanisms [4], it isconvenient to briefly recallthe central notion ofrelative addressof a processP with respect to another processQwithin a network of processes, described in our calculus. A relative address representsthe path betweenP andQ in (an abstract view of) the network (as defined by the syntaxof the calculus). More precisely, consider the abstract syntax trees of processes, builtusing the binary parallel composition as the main operator.Given a processR, the nodesof its tree (see e.g. Fig. 1) correspond to the occurrences ofthe parallel operator inR,and its leaves are the sequential components ofR (roughly, those processes whose top-level operator is a prefix or a summation or a replication). Assuming that the left (resp.�� �P0 P1 P2 �P3 P4

jj0 jj1jj0 jj1 jj0 jj1jj0 jj1Fig. 1.The tree of (sequential) processes of(P0jP1)j(P2j(P3jP4)):

right) branches of a tree of sequential processes denote theleft (resp. right) componentof parallel compositions, then label their arcs with tagjj0 (resp.jj1).

Tecnically, relative addresses can be inductively built while deducing transitions,when a proved semantics is used [13, 12], in which labels of transitions encode (a por-tion of) their deduction tree.

We recall the formal definition of relative addresses [5].

Definition 1 (relative addresses).Let #i; #0i 2 fjj0; jj1g�, let � be the empty string. Then, the set ofrelative addresses,ranged over byl, isA = f#0�#1 : #0 = jji#00 ) #1 = jj1�i#01; i = 0; 1g:

For instance, in Fig. 1, the address ofP3 relative toP1 is l = jj0jj1�jj1jj1jj0 (readthe path upwards fromP1 to the minimal common predecessor and reverse, then down-wards toP3). So to speak, the relative address points back fromP1 toP3.

Note that the relative address ofP3 with respect toP1 is jj1jj1jj0�jj0jj1 that we writealso asl�1. When two relative addressesl; l0 both refer to the same path, exchanging itssource and target, we call them compatible. Formally, we have the following definition.

Definition 2. A relative addressl0 = #0�# is compatiblewith l, written l0 = l�1, if andonly if l = #�#0.

We are now ready to introduce our primitives that induce a fewmodifications to thecalculus surveyed above. Note that we separately present below the two primitives, butthey can be easily combined, in order to enforce both kinds ofauthentication.

3.1 Partner Authentication

We can now intuitively present our first semantic mechanism,originally presented in[4]. Essentially, we bind sensitive inputs and outputs to a relative address, i.e. a processP can accept communications on a certain channel, say , only if the relative address ofits partner is equal to ana priori fixed addressl. More precisely, channels may have arelative address as index, and assume the form l. Now, our semantics will ensure thatP communicates withQ on l if and only if the relative address ofP with respect toQ is indeedl (and that ofQ with respect toP is l�1). Notably, even if another processR 6= Q possesses the channel l, R cannot use it to communicate withP , becauserelative addresses are not available to the users. Consequently, the hostile processRcan never interfere withP andQ while they communicate, as the relative address ofRwith respect toQ (and toP ) is notl (or l�1).

Processes do not always knowa priori which are the partners’ relative addresses. So,we shall also index a channel with a variable�, to be instantiated by a relative address,only. Whenever a processP , playing for instance the role of sender, has to communicatefor the first time with another processS in the role, e.g. of server, it uses a channel �.Our semantic rules will take care of instantiating� with the address ofP relative toSduring the communication. From that point on,P andS will keep communicating forthe entire session, using their relative addresses.

Suppose, for instance, that in Fig. 1 the processP3 sendsb alongal and becomesP 03, i.e. isalhbi:P 03 and thatP1 reads ona not yet localized channela� a value, e.g.a�(x):P 01; recall also that the relative address ofP3 with respect to the processP1is l = jj1jj1jj0�jj0jj1. HereP3 knows the partner address, whileP1 does not. Moreprecisely, forP3 the output can only match an input executed by the process reachablefrom P3 through the relative addressl, while the variable� will be instantiated, duringthe communication, to the addressl�1 of the senderP3, with respect to the receiverP1.

From this point on and for the rest of the protocol,P1 can use the channelajj0jj1�jj1jj1jj0(and others that may have the form �) to communicate withP3, only.

3.2 Message Authentication

Our second mechanism, calledmessage authentication, originally presented in [6, 4],enables the receiver of a message to ascertain its origin, i.e. the process that created it.Again it is based on relative addresses.

We illustrate this further extension originally modelled in [6] through a simple ex-ample. Suppose thatP3 in Fig. 1 is now(�n)ahni:P 03. It sends its private namen toP1 = a(x):P 01. The processP1 receives it asjj1jj0�jj1jj1jj0n = l�1n. In fact, the namen is enriched with the relative address ofP3, its sender and creator, with respect to itsreceiverP1 and the addressl�1 acts as a reference toP3. Now suppose thatP 01 forwardsto P2 the name just received, i.e.l�1n. We wish to maintain the identity of names, i.e.,in this case, the reference toP3. So, the addressl�1 will be substituted by a new relativeaddress, that ofP3 with respect toP2, i.e. jj1jj0�jj0. Thus, the namen of P3 is correctlyreferred to asjj1jj0�jj0n in P2. This updating of relative addresses is done through asuitable address composition operation (see [4] for its definition).

We can now briefly recall our second authentication primitive, [lM �= l0N ℄, akinto the matching operator. This “address matching” is passedonly if the relative ad-dresses of the two localized terms under check coincide, i.e. l = l0. For instance, ifP3 = (�d)ahdi:P 03, P0 = (�b)ahbi andP1 = a(x):[x = jj0jj1�jj1jj1jj0d℄P 01, thenP 01 will be executed only ifx will be replaced with a name coming fromP3, such asjj0jj1�jj1jj1jj0n. In fact, if P1 communicates withP0, then it will receiveb, with theaddressjj0jj0�jj1jj1jj0 and the matching cannot be passed.

4 Implementing Authentication

We model protocols as systems of principals, each playing a particular role (e.g. senderor receiver of a message). We observe the behaviour of a system P plugged in any en-vironmentE, assuming thatP andE can communicate each other on the channels theyshare. More precisely,E can listen and can send on these channels, possibly interferingwith the behaviour ofP .

A (specification of a certain) protocol, represented byP , gives security guarantees,whenever its behaviour it is not compromised by the presenceof E, in a sense madeclear later on.

For each protocolP , we present anabstractversion ofP , written using the abovesketched primitives. We will show that this version has the desired authentication prop-erties “by construction”, even in parallel withE. Then, we check the abstract protocolagainst a different, moreconcreteversion, possibly involving standard cryptographicoperations (e.g. encryptions, nonces). In other words, we compare their behaviour. Theconcrete version is secure, whenever it presents the same behaviour of the abstract ver-sion. We adopt here the notion of testing equivalence [10, 7], where the behaviour ofprocesses is observed by an external process, called tester. Testers are able to observeall the actions of systems, apart from the internal ones.

As a matter of fact, here we push a bit further Abadi and Gordon’s [1] idea of con-sidering correct a protocol if the environment cannot have any influence on its contin-uation. More precisely, letPs = AsjBs be an abstract secure-by-construction protocolandP = AjB be a (bit more) concrete (cryptographic) protocol. Supposealso that bothB andBs, after the execution of the protocol, continue with some activity, sayB0. Then,we require that an external observer should not detect any difference on the behaviourof B0 if an intruderE attacks the protocols. In other words, for all intrudersE, werequire thatAjBjE is equivalent toAsjBsjE. When this holds we say thatP securelyimplementsPs. In doing this, we propose to clearly separate the observer,or testerT ,from the intruderE. In particular, we let the testerT interact with the continuationB0,only. Conversely, we assume that the intruder attacks the protocol, only, and we do notconsider how the intruder exploits the attacks for interfering on what happens later on.This allows us to completely abstract from the specific message exchange (i.e., fromthe communication) and focus only on the “effects” of the protocol execution.

This allows us to compare protocols which may heavily differin the messages ex-changed. In fact, as our authentication primitives providesecure-by-construction (ab-stract) protocols, the idea is to try to implement them by using, e.g., cryptography. Wetherefore adopt testing equivalence to formally prove thata certain protocolP imple-ments an abstract protocolP 0 regardless of the particular message exchange.

We can keep message exchange apart from the rest of the protocol. In our model,protocol specifications are then seen as composed of two sequential parts: a messageexchange part and a continuation part, kept separate by using different channels. As saidabove, the comparison we use focuses on the effects of the protocol execution on thecontinuation, i.e., on what happens after the protocol has been executed. In other words,the comparison is performed by making invisible the protocol message exchanges andthe attacker activity. This is crucial as abstract protocols are never equivalent to theirimplementation if message exchanges were observed. Moreover, since authenticationviolations are easily revealed by observing the address of the received message, wecan exploit our operator of address matching to this aim. In particular, in our notionof testing equivalence, testers have the ability of directly comparing message addresses(through address matching), thus detecting the origin of messages.

Our notion is such that ifP 0 is a correct-by-construction protocol, specified throughour authentication primitives, andP securely implementsP 0, then also the behaviourof P in every hostile environment, i.e. plugged in parallel withany other process, willbe correct.

4.1 A Notion of Secure Implementation

We give here the formal definition of testing equivalence4 directly on the spi calculus.

We writeP m�! (P m�!, resp.), whenever the processP performs an output (aninput, resp.) on the channelm. When the kind of action is immaterial, we shall writeP ��! and call� abarb.

A test is a pair(T; �), whereT is a closed process called tester and� is a barb.

Then, a processP exhibits� (denoted byP # �) if and only if we haveP ��!, i.e. if P4 Technically it is amay-testing equivalence.

can do a transition on�. MoreoverP converges on� (denoted byP + �) if and only ifP ��!� P 0 andP 0 # �. Now, we say that a processP immediately passes a test(T; �)if and only if (P j T ) # �. We also say that a processP passes a test(T; �) if and onlyif (P j T ) + �.

Our testers are processes that can directly refer to addresses in the address match-ing operator. As an example, a tester may be the following processT = observe(z):[z �= jj1jj0�jj1℄�(x). A tester has therefore a global view of the network, becauseit hasfull knowledge of addresses, i.e., of the locations of processes. More importantly, thisfeature of the testers gives them the ability to directly observe authentication attacks.Indeed a tester may check if a certain message has been originated by the expected lo-cation. As an example,T receives a message on channelobserve and checks if it hasbeen originated atjj1jj0�jj1. Only in this case, the test(T; �) is passed, as the globalprocess (T composed with the protocol) exhibits the barb�. We callT the set of testerprocesses.

Now we define the testing preorder�: a processP is in this relation with a processQ, when each time P passes a test(T; �), thenQ passes the test as well.

Definition 3. P � Q iff 8T 2 T ;8� : (P j T ) + � implies (Q j T ) + �.

As seen above, in our model, protocol specifications are composed of two parts: a mes-sage exchange part and a continuation part. Moreover, we assume that the attackerknows the channels that convey messages during the protocol. These channels arenotused in continuations and can be extracted from the specification of the protocol itself.Note that the continuations may often use channels, that canalso be transmitted duringtheir execution, but never used to transmit messages.

We can now give our notion of implementation, whereC = f 1; : : : ; ng is the setof all the channels used by the protocolsP andP 0.Definition 4. LetP andP 0 be two protocols that communicate overC. We say thatPsecurely implementsP 0 if and only if8X 2 EC : (� 1); : : : ; (� n)(P j X) � (� 1); : : : ; (� n)(P 0 j X)whereEC is the set of processes that can only communicate over channels inC.

Note that the names of channels inC are restricted. Moreover, we require thatX mayonly communicate through them. These assumptions represent some mild and reason-able constraints that are useful for the application of the testing equivalence.

These assumptions have both the effect of isolating all the attacker’s activity insidethe scope of the restriction(� 1); : : : ; (� n) and of making all the message exchangesthat may be performed byP andP 0 not observable. As a consequence, we only observewhat is done after the protocol execution: the only possiblebarbs come from the con-tinuations. As we have already remarked, observing the communications part woulddistinguish protocols based on different message exchanges even if they provide thesame security guarantees. Instead, we want to verify whether P implementsP 0, regard-less of the particular underlying message exchange and of the possible hostile executionenvironment.

The definition above requires that whenP andP 0 are executed in a hostile envi-ronmentX , all the behaviour ofP are also a possible behaviour forP 0. So if P 0 isa correct-by-construction protocol, specified through some authentication primitives,andP securely implementsP 0, then alsoP is correct, being also a behaviour for thecorrect-by-construction protocolP 0.

As anticipated in the Introduction, this definition directly derives from the NDCnotion. In particular it borrows from NDC the crucial idea ofnot observing both thecommunication and the attacker’s activity.

5 Some Applications

We show how our approach can be applied to study authentication and freshness. Toexemplify our proposal we consider some toy protocols. Nevertheless, we feel that theideas and the techniques presented could easily scale up to more complicate protocols.

5.1 A Single Session

Consider a simple single-session protocol whereA sends a freshly generated messageM to B and suppose thatB requires authentication of the message, i.e., thatM isindeed sent byA. We abstractly denote this as follows, according to the standard andinformal protocol narration:

(A freshly generatesM )

Message1 A auth! B : MNote that, ifB wants to be guaranteed that he is communicating withA, he needs as areference some trusted information regardingA. In real protocols this is achieved, e.g.,through a password or a key known byA only. We use instead the location of the entitythat we want to authenticate. In order to do this, we specify this abstract protocol byexploiting our partner authentication primitive. The generation of a fresh message issimply modelled through the restriction operator�M of our calculus.

In order to allow the protocol parties to securely obtain thelocation of the entity toauthenticate, we define a startup primitive that exchanges the respective locations in atrusted way. This primitive is indeed just a macro, defined asfollows:startup(tA; A; tB ; B) �= (�s)( stAhsi:A j stB (x):B )wherex does not occur inB and s does not occur inA andB. The restriction ons syntactically guarantees that communications on that channel cannot be altered byanyone else, except forA andB. This holds also when the process is executed in parallelwith any possibly hostile environmentE. Now, in processstartup(�A; A; �B ; B), afterthe communication over the fresh channels, variables�A and�B are securely boundto the addresses ofB andA, respectively. More precisely, for each channel �A in A,�A is instantiated to the address ofB w.r.t. A, while for each channel �B in B, �Bis instantiated to the address ofA w.r.t. B. So, on these channels,A andB can onlycommunicate each other.

In particular, the following holds:

Proposition 1. Consider the processstartup(�A; A; �B ; B). Then, for all possibleprocessesE, in any possible execution ofstartup(�A; A; �B ; B) jE, the location vari-able�A (�B , resp.) can be only assigned to the relative addressjj0�jj1, ofB with respecttoA (to the relative addressjj1�jj0 ofA with respect toB, resp.).

Proof. By case analysis.

Now, we show an abstract specification of the simple protocolpresented above:P = startup(���; A; �B ; B)A = (�M) hMiB = �B (z):B0(z)Technically, using��� in the place oftA corresponds to having no localization for thechannel with indextA, e.g. ��� = .

After the startup phase,B waits for a messagez from the location ofA: any othermessage coming from a different location cannot be received. In this way we modelauthentication.

Note that locating the output ofM in A (as inA0 = (�M) jj0�jj1hMi) would givea secrecy guarantee on the message, because the processA would be sure thatB is theonly possible receiver ofM .

Due to the partner authentication, this protocol is secure-by-construction. To seewhy, consider its execution in a possibly hostile environment, i.e. considerP j E. ByProposition 1, we directly obtain that�B is always assigned to the relative address ofA w.r.t. B, i.e., jj1�jj0. Thus, the sematic rules ensure thatB can only receive a valuez sent byA, on the located channel jj1�jj0 . SinceA only sends one freshly generatedmessage, we conclude thatz will always contain a located name with addressjj1�jj0.This means thatB always receives a message which is authentic fromA.

As intuitively described in Section 3, the location of the channel in processBguarantees a form ofentity authentication: by construction,B communicates with thecorrect partyA. Then, sinceA is following the protocol (i.e., is not cheating), we alsoobtain a form ofmessage authenticationon the received message, i.e.,B is ensured thatthe received message has been originated byA.

To further clarify this we show the two possible execution sequences of the protocol:P j E = startup(���; A; �B ; B) j E= (�s)( shsi:A j s�B (x):B ) j E��! (�s)( (�M) hMi j jj1�jj0(z):B0(z) ) j EThere are now two possible moves.E may intercept the message sent byA (and

then continue asE0):(�s)( (�M) hMi j jj1�jj0(z):B0(z) ) j E ��!(��jj0jj0M)( (�s)( 0 j jj1�jj0(z):B0(z) ) j E0)

The way addresses are handled makesM to be received byE0 as jj1�jj0jj0M , that iswith address ofA w.r.t.E. For the same reason, the restriction onM in the target of thetransition become(��jj0jj0M).

The other possible interaction is the one betweenA andB:(�s)( (�M) hMi j jj1�jj0(z):B0(z) ) j E ��!(�s)(��jj0M)( 0 j B0(jj1�jj0M) ) j EIt is important to observe that there is no possibility forE to makeB accept a fakedmessage, asB will never accept a communication from a location which is differentfrom jj1�jj0.

We now show how the abstract protocol above can be used as a reference for moreconcrete ones, by exploiting the notion of protocol implementation introduced in theprevious section.

First, consider a clearly insecure protocol in whichA sendsM as plaintext toB,without any localized channel. P1 = A1 j B1A1 = (�M) hMiB1 = (z):B0(z)We can prove thatP1 does not implementP , by using testing equivalence. Considera continuation that exhibits the received valuez. So, letB0(z) = observehzi, andconsider the processes(� )(P j E) and(� )(P1 j E), whereE = (�ME) hMEi isan attacker which sends a fresh message toB, pretending to beA. Let the testerTbe the processobserve(z):[z �= jj1jj0�jj1℄�(y) which detects ifz has been originatedby E. Note that the only possible barb of the two processes we are considering is theoutput channelobserve. It is clear that(� )(P1 j E) may pass the test(T; �) while(� )(P j E) cannot pass it, thus(� )(P j E) 6� (� )(P1 j E). In fact,P1 can receivethe valueME onz with the address ofB1 w.r.t.E, that it is different from the expectedjj1jj0�jj1. This counter-example corresponds to the following attack:

Message1 E(A) ! B : ME E pretending to be A

We show now that the following protocol, that uses cryptography is able to provideauthentication of the exchanged message (in a single protocol session):

Message1 A! B : fMgKABKAB is an encryption key shared betweenA andB. We specify this protocol as follows:P2 = (�KAB)(A2 j B2)A2 = (�M) hfMgKABiB2 = (z):casez of fwgKAB in B0(w)Here,A2 encryptsM to protect it. Indeed, the goal is to prevent other principals fromsubstituting forM a different message, as it may happen inP1. This is a correct way

of implementing our abstract authentication primitive in asingle protocol session. Inorder to prove thatP2 securely implementsP , one has to show that every computationof (� )(P2jX) is simulated by(� )(P jX), for all X 2 E . This is indeed the case andP2 gives entity authentication guarantees:B2 can be sure that it isA the sender of themessage. On the other hand, we can also have a form of message authentication, asfar as the delivered messagew is concerned, since our testers are able to observe theoriginator of a message through the address matching operator.

Proposition 2. P2 securely implementsPProof. We give a sketch of the proof. We have to show that every computation of(� )(P2jX) is simulated by(� )(P jX), for all X 2 E . To this purpose, we definea relationS which can be proved to be a barbed weak simulation. Barbed bisimulation[26] provides very efficient proof techniques for verifyingmay-testing preorder, and isdefined as follows. A relationS is a barbed weak simulation if for(P;Q) 2 S :

– P # � implies thatQ + �,– if P ��! P 0 then there existsQ0 s.t.Q( ��!)�Q0 and(P 0; Q0) 2 S.

The union of all barbed simulation is represented byC= . Moreover, we say that a relationS is a barbed weak pre-order (denoted with/) if for (P;Q) 2 S and for allR 2 T wehaveP j RC=Q j R. It is easy to prove that/��may.

We now define a relationS as follows:(� )(�jj0KAB)(�jj0jj0M) ( ( ~A j B2) j X ) S (� )(P j X)where either~A = A2 or ~A = 0. Moreover the keyKAB may appear inX only in aterm jj0jj0�jj1fMgKAB , possibly as a subterm of some other composed term.

The most interesting moves are the following:

– ~A = A2, and (� )(�jj0KAB)(�jj0jj0M) ( (A2 j B2) j X )��! (� )(�jj0KAB)(�jj0jj0M) ( (0 j B0(jj0�jj1M)) j X ) = FThis is simulated as(� )(P j Y ) ��! ��! (� )(�jj0M)( ( 0 j B0(jj0�jj1M)) j X ) = G. It is easy tosee thatF � G, sinceKAB is not free inB0(w).

– ~A = A2, and (� )(�jj0KAB)(�jj0jj0M) ( ( A2 j B2) j X )��! (� )(�jj0KAB)(�jj0jj0M)( ( 0 j B2 ) j X 0 )HereX 0 intercepts the message which is exactlyjj0jj0�jj1fMgKAB . This is simu-lated by just idling. We indeed obtain that(� )(�jj0KAB)(�jj0jj0M)( ( 0 j B2 ) j X 0 ) S (� )(P j X).

– ~A = 0 and (� )(�jj0KAB)(�jj0jj0M) ( ( 0 j B2 ) j X )��! (� )(�jj0KAB)(�jj0jj0M)( ( 0 j case���0fNgKAB of fwgKAB in B0(w) ) j X 0 ) = F 0By the hypothesis onX it must beN = M and���0 = jj0jj0�jj1. ThusF 0 � (� )(�jj0KAB)(�jj0jj0M) ( ( 0 j B0(jj0�jj1M) ) j X 0 )This is simulated as for the first case above.

Since(� )(P2jX) S(� )(P jY ), we obtain the thesis.

5.2 Multiple Sessions

The version of the protocolP2 is secure if we consider just one single session, but it isno longer such, when considering more than one session. We will see this, and we willalso see how to repair the above specification in order to obtain the same guarantees.Our first step is extending thestartup macro to the multisession case:m startup(tA; A; tB ; B) �= (�s)( !stAhsi:A j !stB (x):B )Two processes that initiate the startup by a communication overs are replicated throughthe “!” operator; so there are many pairs of instances of the sub-processesA andBcommunicating each other. Each pair plays a single session.

The following result extends Proposition 1 to the multisession case (note that hereany replication originates a new instance of the two location variables). Intuitively, theproposition below states that, when many sessions are considered, our startup mech-anism is able to establish different independent runs between instances ofP andQ,where no messages of one run may be received in a different run. This is a crucial pointthat provides freshness, thus avoiding replay of messages from a different run.

Proposition 3. Consider the processstartup(�A; A; �B ; B). Then, for all possibleprocessesE, in any possible execution of the location variable�A (�B , resp.) canbe only assigned to the relative address of a single instanceof B with respect to oneinstance ofA (of a single instance ofA with respect to one instance ofB, resp.).

Proof. By case analysis.

Actually, different instances of the same process are always identified by differ-ent instances of location variables. Therefore, two location variables, arising from twodifferent sessions, never point to the same process.

We now define the extension ofP to multisession as follows:Pm = m startup(���; A; �B ; B)

Consider now the following execution:Pm = (�s)( !shsi:A j !s�B (x):B ) j E��! (�s)( ( A j !shsi:A ) j ( jj0jj0�jj1jj0(z):B0(z) j !s�B (x):B ) ) j E��! (�s)( ( A j ( A j !shsi:A ) ) j ( jj0jj0�jj1jj0(z):B0(z)jj ( jj0jj1jj0�jj1jj1jj0(z):B0(z) j !s�A(x):B ) ) ) j EHere, the first and second instances ofB are uniquely hooked to the first and sec-ond instances ofA, respectively. This implies that all the future located communica-tions of such processes will be performed only with the corresponding hooked partner,even if they are performed on the same communication channel. Generally, due to non-determinism, instances ofA and instances ofB may hook in different order.

It is now straightforward proving a couple of properties about authentication andfreshness, exploiting Proposition 3. They hold for protocol Pm and for all similar pro-tocols, where multiple sessions arise from the replicationof the same processes, playingthe same roles. In the following, we useB0(#�#0N) to mean the continuationB0, wherethe variablez has been bound to the value#�#0N , i.e. to a messageN that has the rel-ative address#�#0 of its sender w.r.t. to its receiver.

Authentication: When the continuation of an instance ofB0(#�#0N) is activated,#�#0must be the relative address of an instance ofA with respect to the actual instanceof B.

Freshness:For every pair of activated instances of continuationsB0(#�#0N) andB0(~#� ~#0N 0) it must be# 6= ~#, i.e., the two messages have been originated by twodifferent instances of the processA.

We are now able to show thatP2 is not a good implementation when many sessions areconsidered, i.e. thatPm2 does not implementPm. Consider:Pm2 = (�KAB)(!A2 j !B2)

Let B0(z) = observehzi, and considerE = (x): hxi: hxi. E may intercept theencrypted message and replay it twice. If we consider the tester T = observe(x):observe(y):[x �= y℄�(x), we obtain that(� )(Pm2 j E) may pass the test(T; �) while(� )(Pm j E) never passes it. Indeed, inPm2 the replay attack successfully performed,andB is accepting twice the same message:

Message1:a A! E(B) : fMgKAB E intercepts the message intended forBMessage2:a E(A) ! B : fMgKAB E pretending to be AMessage2:b E(A) ! B : fMgKAB E pretending to be A

Thus, we obtain that(� )(Pm2 j E) 6� (� )(Pm j E).We end this section by giving a correct implementation of themultisession authen-

tication protocolPm, which exploits a typical challenge-response mechanism toguar-antee authentication:

Message1 B ! A : NMessage2 A! B : fM;NgKAB

whereN is a freshly generated nonce that constitutes the challenge. It can be formallyspecified as follows:Pm3 = (�KAB)(!A3 j !B3)A3 = (�M) (ns): hfM;nsgKABiB3 = (�N) hNi: (x):casex of fz; wgKAB in [w = N ℄B0(z)The following holds.

Proposition 4. Pm3 securely implementsPmProof. The proof can be carried out in the same style of the one for Proposition 2.

Note that we are only considering protocols in which the roles of the initiator (orsender) and responder (or receiver) are clearly separated.If A and B could play boththe two roles in parallel sessions, then the protocol above would suffer of a well-knownreflection attack. Extending our technique to such a more general analysis is the objectof future research.

References

1. M. Abadi and A. D. Gordon. “A Calculus for Cryptographic Protocols: The Spi Calculus”.Information and Computation, 148(1):1–70, January 1999.

2. M. Abadi. ‘Secrecy by Typing In Security protocols”.Journal of the ACM, 5(46):18–36,sept 1999.

3. M. Abadi, C. Fournet, G. Gonthier. Authentication Primitives and their compilation. InProceedings of Principles of Programming Languages (POPL’00), pp. 302–315. ACM Press,2000.

4. C. Bodei, P. Degano, R. Focardi, and C. Priami. “Primitives for Authentication in ProcessAlgebras”.Theoretical Computer Science283(2): 271-304, June 2002.

5. C. Bodei, P. Degano, and C. Priami. “Names of the�-Calculus Agents Handled Locally”.Theoretical Computer Science, 253(2):155–184, 2001.

6. C. Bodei, P. Degano, R. Focardi, and C. Priami. “Authentication via Localized Names”. InProceedings of the 12th Computer Security Foundation Workshop (CSFW12), pp. 98–110.IEEE press, 1999.

7. M. Boreale and R. De Nicola. Testing equivalence for mobile processes.Information andComputation, 120(2):279–303, August 1995.

8. M. Burrows, M. Abadi, and R. Needham. “A Logic of Authentication”. ACM Transactionson Computer Systems, pp. 18–36, February 1990.

9. National Bureau of Standards. “Data Encryption Standard(DES)”. FIPS Publication 46,1977.

10. R. De Nicola and M.C.B. Hennessy. Testing equivalence for processes.Theoretical Com-puter Science, 34:83–133, 1984.

11. A. Durante, R. Focardi, and R. Gorrieri. “A Compiler for Analysing Cryptographic ProtocolsUsing Non-Interference”.ACM Transactions on Software Engineering and Methodology,vol. 9(4), pp. 488-528, October 2000.

12. P. Degano and C. Priami. “Enhanced Operational Semantics: A Tool for Describing andAnalysing Concurrent Systems”. To appear in ACM Computing Surveys.

13. P. Degano and C. Priami. “Non Interleaving Semantics forMobile Processes”.TheoreticalComputer Science, 216:237–270, 1999.

14. F. J. T. Fabrega, J. C. Herzog, and J. D. Guttman. “Strandspaces: Why is a security protocolcorrect?” InProceedings of the 1998 IEEE Symposium on Security and Privacy, pp. 160–171, 1998. IEEE Press.

15. R. Focardi, R. Gorrieri, and F. Martinelli. “Message authentication through non-interference”. InProceedings of International Conference in Algebraic Methodology andSoftware Technology, LNCS 1816, pp.258-272, 2000.

16. R. Focardi, R. Gorrieri, and F. Martinelli. “Non Interference for the Analysis of Crypto-graphic Protocols”. InProceedings of the International Colloquium on Automata, Languagesand Programming (ICALP’00), LNCS 1853, Springer, 2000.

17. R. Focardi and F. Martinelli. “A Uniform Approach for theDefinition of Security Properties”.In Proceedings of World Congress on Formal Methods in the Development of ComputingSystems, LNCS 1708, pp. 794–813, Springer-Verlag, 1999.

18. R. Focardi, A. Ghelli, and R. Gorrieri. “Using Non Interference for the Analysis of SecurityProtocols ”. InProceedings of the DIMACS Workshop on Design and Formal Verification ofSecurity Protocols, DIMACS Center, Rutgers University, 1997.

19. R. Thayer, N. Doraswamy, and R. Glenn. RFC 2411: IP security document roadmap, Novem-ber 1998.

20. International Organization for Standardization. Information technology - Security techniques- Entity authentication mechanism; Part 1: General model. ISO/IEC 9798-1, Second Edition,September 1991.

21. G. Lowe. “A Hierarchy of Authentication Specification”.In Proceedings of the 10th Com-puter Security Foundation Workshop (CSFW10). IEEE press, 1997.

22. G. Lowe. “Breaking and Fixing the Needham-Schroeder Public-key Protocol using FDR”.In Proceedings of Tools and Algorithms for the Construction and Analysis of Systems(TACAS’96), LNCS 1055, pp. 146–166, Springer-Verlag, 1996.

23. R. Kemmerer, C. Meadows, and J. Millen. “Three systems for cryptographic protocol anal-ysis”. J. Cryptology, 7(2):79–130, 1994.

24. R. Milner, J. Parrow, and D. Walker. “A Calculus of MobileProcesses (I and II)”.Informationand Computation, 100(1):1–77, 1992.

25. J. C. Mitchell, M. Mitchell, and U. Stern. “Automated Analysis of Cryptographic ProtocolsUsing Mur�”. In Proceedings of the 1997 IEEE Symposium on Research in Security andPrivacy, pp. 141–153. IEEE Computer Society Press, 1997.

26. Sangiorgi, D. “Expressing Mobility in Process Algebras: First-Order and Higher-OrderParadigms.”. PhD Thesis. University of Edinburgh, 1992.

27. S. Schneider. “Verifying authentication protocols in CSP”. IEEE Transactions on SoftwareEngineering, 24(9), Sept. 1998.

28. B. Schneier.Applied Cryptography. John Wiley & Sons, Inc., 1996. Second edition.