ISS

N 0

249-

6399

ap por t de r ech er ch e

THÈME 1

INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE

The game of the name in cryptographic tables

Roberto M. Amadio Sanjiva Prasad

N° 3733

Juillet 1999

Unité de recherche INRIA Sophia Antipolis2004, route des Lucioles, B.P. 93, 06902 Sophia Antipolis Cedex (France)

Téléphone : 04 92 38 77 77 - International : +33 4 92 38 77 77 — Fax: 04 92 38 77 65 - International : +33 4 92 38 77 65

The game of the name in cryptographic tablesRoberto M. Amadio Sanjiva PrasadThème 1 � Réseaux et systèmesProjet MeijeRapport de recherche n° 3733 � Juillet 1999 � 17 pagesAbstract: We present a name-passing calculus that can be regarded as a simpli�ed �-calculus equipped with a cryptographic table. The latter is a data structure representingthe relationships among names. We apply the calculus to the modelling and veri�cation ofsecrecy and authenticity properties in cryptographic protocols relying on symmetric sharedkeys. Following classical approaches [8], we formulate the veri�cation task as a reachabilityproblem and prove its decidability assuming �nite principals and bounds on the sorts of themessages synthesized by the attacker.Key-words: Cryptographic protocols, �-calculus, veri�cation

The �rst author works at Université de Provence, Marseille. and he is an external collaborator of theINRIA-Ecole des Mines Project Meije. He can be contacted at the following address: CMI, 39 rue Joliot-Curie, F-13453, Marseille, France. mailto: amadio@gyptis.univ-mrs.fr. He work was partly supportedby Action Coopérative PRESYSA, IFCPAR 1502-1, LIM (CNRS ES-A6077), and WG Confer. The secondauthor works at the Indian Institute of Technology, Delhi. mailto: sanjiva@cse.iitd.ernet.in. He waspartly supported by IFCPAR 1502-1 and AICTE 1-52/CD/CA(08)/96-97 and BRICS, Centre of the DanishNational Research Foundation.

Le jeu du nom dans les tables cryptographiquesRésumé : Nous présentons un calcul avec passage de noms qui peut être consideré commeun �-calcul simpli�é equipé avec une table cryptographique. Il s'agit d'une structure de don-nées qui représente les relations entre les noms. Nous appliquons le calcul à la modelisationet véri�cation de proprietés de securité et authenticité dans les protocoles cryptographiquesà clef symétrique. Suivant des approches classiques [8], nous formulons le problème devéri�cation comme une proprieté d'accessibilité et nous prouvons sa decidabilité en suppo-sant un nombre �ni de principaux et une borne sur les sortes des messages synthétisés parl'attaquant.Mots-clés : Protocoles cryptographiques, �-calcul, véri�cation.

The game of the name in cryptographic tables 31 IntroductionCryptographic protocols are commonly used to establish secure communication channelsbetween distributed principals. Cryptographic protocols seem good candidates for formalveri�cation and several frameworks have been proposed for making possible formal andautomatable analyses. We do not attempt to survey here all the various approaches, butcon�ne our remarks to some which assume `perfect encryption' and model a protocol as acollection of interacting processes competing against a hostile environment.One class of approaches involves state exploration using model-checking techniques [11,6, 13]. Lowe [11], Schneider [15] and several others have used CSP to specify authentica-tion protocols, analysing them with the FDR model-checking tool. Other state explorationapproaches are based on logic programming techniques [12]. The main bene�t of these ap-proaches is their automation and e�cacy in uncovering subtle bugs in protocols (e.g., Lowe's`man-in-the-middle' attack on the Needham-Schroeder symmetric key protocol). However,their applicability is limited by the quickly growing size of the state space to be examined;simplifying hypotheses on the behaviour of the environment necessary to bound the statespace may drastically curtail the ability to �nd errors.A second class of approaches relies on general-purpose proof assistant tools. Paulson [14]uses induction on traces to formally prove protocol correctness using Isabelle. Bolignano [4]uses a state-based analysis of the protocols, proving invariant properties, with the proofssubsequently mechanized in Coq. Although these approaches are not automatic, recentwork [10, 16] suggests that certain authentication protocols can be modelled in decidablefragments of �rst-order logic.In all the approaches mentioned above the attacker must be explicitly modelled. A morerecent trend has been the use of name-passing process calculi for studying cryptographicauthentication protocols. Abadi and Gordon have presented the spi-calculus [1], an exten-sion of the �-calculus with cryptographic primitives (see [7] for a related approach using a`second-order' calculus). Principals of a protocol are expressed in a �-calculus-like notation,whereas the attacker is represented implicitly by the process calculus notion of `environ-ment'. Security properties are modelled in terms of contextual equivalences, in contrast tothe previous approaches. The spi-calculus provides a precise notation with a formal opera-tional semantics, particularly for expressing the generation of fresh names, for the scope ofnames, and for identifying the di�erent threads in a protocol and the order of events in eachthread. These features are important: in the various notations found in the literature, theissues of name generation, scoping, data sorts, and synthesis capabilities of the adversarywere often treated in an ad hoc and/or approximate manner.Unfortunately, the addition of the cryptographic primitives to the �-calculus considerablycomplicates reasoning about the behaviour of processes. Although there have been someattempts to simplify this reasoning (see [2, 9, 5]), the developed theory has not yet led toautomatic or semi-automatic veri�cation methods.In this paper, we describe an approach that combines the analyses found in the model-checking and theorem-proving approaches with the bene�ts of using a process notation. Fo-cussing on symmetric shared-key cryptosystems, we propose a name-passing calculus basedRR n° 3733

4 Roberto M. Amadio Sanjiva Prasadon a variety of �-calculus and use it for modelling and verifying secrecy and authenticityproperties in cryptographic protocols. Our approach departs from that of Abadi and Gordonin three major ways.First, we insist on considering every transmissible value as a name, thus eliminating com-plications to the theory arising from structured values. We keep track of the relationshipsamongst names (what name is a ciphertext of what plaintext) by means of a cryptographictable. Secondly, we model secrecy and authenticity properties as reachability properties thatare largely insensitive to the ordering of the actions and to their branching structure. Intu-itively, we designate con�gurations reached after a successful attack as erroneous. Protocolveri�cation then involves showing invariance of the property that such error con�gurationsare not reachable. Thirdly, we eliminate named communication channels and, as in e.g., [4],let all communications between principals and the environment transit on a public medium.This paper is organized as follows. In section 2, we de�ne a simple name-passing cal-culus equipped with a cryptographic table, present some derived operators, and relate ourformalism to the �-calculus. In section 3, we apply the calculus for modelling a concreteexample: the Yahalom protocol. Finally, in section 4 relying on simple rewriting techniqueswe show that the reachability problem is decidable assuming �nite principals and boundson the sorts of the messages synthesized by the attacker.2 The calculusWe de�ne a process calculus enriched with a `cryptographic table' to model and analysesymmetric key cryptographic protocols. We use a; b; : : : for names and a;b; : : : for vectorsof names. N denotes the set of names. The principals' behaviour as well as secrecy andauthenticity properties are represented as processes.De�nition 2.1 (processes) A process (typically p; q) is de�ned by the following grammar:p ::= 0 jj err jj!a:p jj?a:p jj (�a) p jj [a = b]p; q jj p j q jj A(a)jj let a = fbgc in p jj case fbgc = a in p :As usual, 0 is the terminated process; err is a distinguished `error' process; !a:p sends a tothe environment and becomes p; ?a:p receives a name from the environment, binds it to aand becomes p; (�a) p creates a new restricted name a and becomes p; [a = b]p; q tests theequality of a and b and accordingly executes p or q; p j q is the parallel composition of pand q; A(a) is a recursively de�ned process; let a = fbgc in p de�nes a to be the encryptionof b with key c in p; �nally case fbgc = a in p de�nes b to be the decryption of a with keyc in p. The input and restriction operators act as name binders. Moreover, a is bound inlet a = fbgc in p and the names b are bound in case fbgc = a in p. We denote with fn(p)the set of names free in p. We assume that for every process identi�er A(a) there is a uniquerecursive equation A(a) = p such that fn(p) � fag.Let T be a relation in (Sk�1Nk)�N �N . We write a 2 n(T ) if the name a occurs in atuple of the relation T . We write (b; c; a) 2 T as fbgc = a 2 T . This notation is supposedINRIA

The game of the name in cryptographic tables 5to suggest that c is a key, b is a tuple of plaintext, and a is the corresponding ciphertext.The relation T induces an order <T on n(T ) which we de�ne as the least transitive relationsuch that: fb1; : : : ; bngc = a 2 T ) b1; : : : ; bn; c <T a.De�nition 2.2 (cryptographic table) A cryptographic table T is a relation in (Sk�1Nk)�N �N which satis�es the following properties:T is �nite.<T is acyclic.fbgc = a 2 T and fbgc = a0 2 T ) a = a0 (single valued)fbgc = a 2 T and fb0gc0 = a 2 T ) b = b0 and c = c0 (injectivity) .We introduce a notion of sort for the names in a cryptographic table.De�nition 2.3 (sorts) The collection of sorts Srt is the least set that contains the groundsort 0 and such that (s1; : : : ; sn) 2 Srt if si 2 Srt for i = 1; : : : ; n with n � 2.Every name occurring in a cryptographic table can be assigned a unique sort as follows.De�nition 2.4 (sorting) Let T be a cryptographic table. We de�ne a function srtT :n(T )! Srt as follows:srtT (a) = � 0 if a is minimal in <T(s1; : : : ; sn) if fb1; : : : ; bn�1gbn = a 2 T and srtT (bi) = si; i = 1; : : : ; n :De�nition 2.5 (con�guration) A con�guration r is a triple (�fag) (p j T ) where fag isa set of restricted names, p is a process, and T is a cryptographic table.We write r � r0 if r and r0 are identical con�gurations up to �-renaming of bound namesand associativity-commutativity of parallel composition.In �gure 1, we de�ne a reduction relation on con�gurations. The �rst �ve rules describethe computation performed by the principals or by `observer processes' needed in the ver-i�cation of secrecy or authenticity properties.Rules (out) and (in) concern the sending ofa name to the environment and the reception of a name from the environment. Rules (�),(m), and (rec) describe internal computation performed by the principals: generation of newnames, conditional, and unfolding of recursive de�nitions. The cryptographic table plays arole in the next three rules. In particular, it allows sharing of information between prin-cipals and environments. The rules (let1) and (let2) compute the ciphertext a0 associatedwith fbgc in T while adding fbgc = a0 to T if it is not already there. The rule (case) triesto decode the ciphertext a with key c. In the rule (case), a deadlock occurs (speci�ed bythe absence of a transition) if either the vectors b and b0 do not have the same length or anincorrect key is used for decoding.Finally, the last three rules (let1e), (let2e), and (casee) describe the encoding/synthesis anddecoding/analysis performed by the environment: in the rule (let1e) the environment learnsRR n° 3733

6 Roberto M. Amadio Sanjiva Prasad(out) (�fag) (!a:p j q j T )! (�fagna) (p j q j T )(in) (�fag) (?a:p j q j T )! (�fag) ([b=a]p j q j T ) if b =2 fag(�) (�fag) ((�a) p j q j T )! (�fag [ fag) (p j q j T ) a =2 fn(q) [ n(T )(m) (�fag) ([a = b]p1; p2 j q j T )! � (�fag) (p1 j q j T ) if a = b(�fag) (p2 j q j T ) if a 6= b(rec) (�fag) (A(b) j q j T )! (�fag) ([b=c]p j q j T ) if A(c) = p(let1) (�fag) (let a = fbgc in p j q j T )! (�fag) ([a0=a]p j q j T )if fbgc = a0 2 T(let2) (�fag) (let a = fbgc in p j q j T )! (�fag [ fa0g) ([a0=a]p j q j T [ ffbgc = a0g)if 6 9 a0 (fbgc = a0 2 T ) and a0 is fresh.(case) (�fag) (case fbgc = a in p j q j T )! (�fag) ([b0=b]p j q j T )if fb0gc = a 2 T(let1e) (�fa; ag) (p j T [ ffbgc = ag)! (�fag) (p j T [ ffbgc = ag)if fb; cg \ fa; ag = ; and a =2 fag(let2e) (�fag) (p j T )! (�fag) (p j T [ ffbgc = ag)if fb; cg \ fag = ;; 6 9 a (fbgc = a 2 T ); and a is fresh(casee) (�fag) (p j T [ ffbgc = ag)! (�fagnfbg) (p j T [ ffbgc = ag)if fa; cg \ fag = ; and fbg \ fag 6= ;Figure 1: Reduction rules

INRIA

The game of the name in cryptographic tables 7a private name by encoding, in the rule (let2e) the environment creates a new ciphertext,and in the rule (casee) the environment learns new names by decoding.We write r !R r0 to make explicit the reduction rule R being applied. We note thatencoding a new tuple (plaintext,key) generates a new ciphertext. It follows that the acyclicityand injective function properties of the cryptographic table are preserved by reduction.Lemma 2.6 The set of con�gurations is closed under reduction.De�nition 2.7 (error) A con�guration with error is a con�guration having the shape:(�fag) (err j p j T ).We write r # err if r is a con�guration with error (read r commits on err) and r #� errif r !� r0 and r0 # err . Note that con�gurations with errors are closed under reduction.In general, we are interested in deciding whether r #� err , that is, whether r can reach acon�guration with error.The process calculus presented di�ers from the �-calculus in two main respects: (i) Welet all communications go through a unique (unnamed) channel that connects the principalsto the environment. (ii) We add cryptographic primitives, which a�ect the contents of thecryptographic table.In principle, we can code this process calculus in a variety of �-calculus. This amountsto: (i) Decorating all input-output actions with fresh global channels � thus replacing!b:p with ab:p and likewise ?b:p with a(b):p, where a is a fresh name. (ii) Representingthe cryptographic table as a process that receives messages on a global channel, say c.The coding and decoding operations are represented as remote procedure calls from theprincipals and the environment to the cryptographic process. To make sure that messagesare not intercepted, we assume that the cryptographic process is the unique receiver on thechannel c (syntactic conditions that guarantee this property are presented in [3]).We refrain from going into this development because it seems much more e�ective, bothin the mathematical development and in the practical applications, to expose directly thestructure of the cryptographic table rather than hiding it behind a process algebraic veil.Finally, we remark that the reduction rules in �gure 1 can be easily turned into a labelledtransition system whose actions (internal reduction, input, free and bound output) areinherited from the �-calculus. We can then rely on the �-calculus notion of bisimulation toreason about the equivalence of con�gurations. Thus our approach does not preclude theexpression of security properties based on process equivalence [1].Some syntactic sugar We now describe how several concepts may be encoded in thecore calculus given above. We �rst describe several abbreviations that improve readability.We then describe annotations with which we decorate the protocols when analyzing theirsecrecy and integrity properties. We sometimes use multiple abbreviations if the order ofexpanding them out is apparent from the context.RR n° 3733

8 Roberto M. Amadio Sanjiva PrasadSending or receiving a tuple of names can be encoded in the calculus with monadiccommunication by considering tuples as ciphertexts encoded with a distinguished globally-known key g: !(~b):p � let a = f~bgg in !a:p ?(~b):p �?a:case f~bgg = a in p :A ciphertext f~bgc may appear as a component of the output tuple, or as a value in a match,in an encoding or as a parameter. In all these cases it is intended that f~bgc stands for thename a resulting from the encoding let a = f~bgc in : : : For instance:!(~b0; f~bgc; : : :):p � let b = f~bgc in !(~b0; b; : : :):p[a = f~bgc]p; q � let b = f~bgc in [a = b]p; qlet b = f~b0; f~bgc; : : :gc0 in p � let a = f~bgc in let b = f~b0; a; : : :gc0 in pA(~a0; f~bgc; : : :) � let a = f~bgc in A(~a0; a; : : :) :In a �ltered input, we check that the input has a component that is equal to a certain value(marked as b) or that has a certain shape, e.g. f~bgc, and we stop otherwise.?(~b0; b; : : :):p �?(~b0; c; : : :):[c = b]p;0?(~b0; f~bgc; : : :):p �?(~b0; b; : : :):case f~bgc = b in p :As in the �ltered input, we check that the decryption of the ciphertext yields a certaincomponent.case f~b0; b; : : :gc = a in p � case f~b0; x; : : :gc = a in [x = b]p;0case f~b0; f~cgd; : : :gc0 = a0 in p � case f~b0; a; : : :gc0 = a0 in case f~cgd = a in p :We mark the generation of a name a intended to remain secret in a protocol con�gurationwith the annotation (�a)sec p. We can easily program an observer W (a) such that if theenvironment ever discovers the name a, then an error con�guration is reachable:W (a) �?a0[a = a0]err ;0 (secrecy observer). (1)Secrecy annotations are then translated as follows:(�a)sec p � (�a) (p j W (a)) (secrecy annotation): (2)In order to program an observer for authenticity properties we need a limited form of privatechannel. Fortunately, a private key a already allows the encoding of a private use-at-most-once channel a as follows: a~b:p �!f~bga:p a(~b):p �?f~bga:p :We note that this encoding does not work for arbitrary (multiple-use) channels, since theenvironment may replay messages, and without mechanisms like time-stamping, it wouldINRIA

The game of the name in cryptographic tables 9not be possible to di�erentiate replayed messages from genuine fresh messages. However,the encoding can be generalized to a bounded use channel, if each message instance containsdistinguished components that uniquely index each distinct use of the channel.To specify authenticity properties we mark certain send and receive actions in the princi-pals with authenticity annotations. The idea is as follows: let us assume that after executingits part of the protocol, principal y receives a message (f 0; t0;m0), where f 0; t0 name the pur-ported sender and receiver of the message. Suppose y believes that this message is authentic,i.e., has been sent to it (thus, t0 = y) by the principal x whom it has presumably authen-ticated. An all-knowing `session' judge can detect an authenticity �aw if this particularmessage had not actually been sent by x. The judge only rules on messages purportedlysent by x � if y presumes to have authenticated another principal, the judge reports no er-ror. Following this intuition, we introduce authenticity annotations auth_o(_); auth_i(_)which represent, respectively, x registering a message with a judge process prior to sendinga message to y, and y claiming authenticity of the message received.auth_o((x; y;m)):p � (�n) j(o; (x; y;m); n):j0(n):pauth_i((x; y;m)):p � j(i; (x; y;m);_):pJx ;y � j(d; (x; t;m); n)[d = o](j0n:J 0x ;y(m)); ([d = i](err ;0))J 0x ;y(m) � j(d; (x; t0;m0);_):[d = i]([m0 = m]0; err); J 0x ;y(m) :Here we assume two distinguished names o and i, which indicate whether the authenticity ofa message is being registered or claimed. Communication with the judge is over restrictedchannels j; j0 to disallow the environment from making bogus assertions of authenticity. Wewill require the channel j appears in the principals to which x; y are instanced, and j0 onlyin the principal corresponding to x. Note that although j is used twice, the di�erent usesare distinguishable by the names o and i, and so replays can be recognized.Relying on these encodings we translate authenticity annotations as follows:!(~b)auth :p � auth_o(~b):!(~b):p ?(~b)auth :p �?(~b):auth_i(~b):p :We observe that in an authenticated output, the principal receives an acknowledgement fromthe judge process on channel j0 before actually outputting the message.3 Modelling cryptographic protocolsWe now illustrate how a protocol speci�ed informally in a notation common in the securitycommunity can be transformed into an annotated process in the enriched notation of �2.We consider a symmetric key protocol due to Yahalom. This protocol concerns principalsa, b, and a trusted server c running in a possibly hostile environment that can interceptall communications. Initially, principal a and principal b each share a symmetric secret keywith c. At the end of the protocol, principals a, b (and c) share a third symmetric secretkey, a `session key', which can be used by principals a and b to exchange information. ARR n° 3733

10 Roberto M. Amadio Sanjiva Prasadparticular run of the protocol is informally described by the following list of events:event 1 a! b : a; b; naevent 2 b! c : b; fa; na; nbgkbcevent 3 c! a : a; fb; kab ; na; nbgkac ; fa; kabgkbcevent 4 a! b : b; fa; kabgkbc ; fnbgkabevent 5 a! b : a; b; fdgkab post � protocolevent 50 b! a : b; a; fdgkab alt � post � protocol :Principal a sends a clear-text message containing a nonce challenge to b. Instead of respond-ing directly to a, b generates a new nonce nb, its response to a's challenge, which, added tocomponents of the original message, is sent encrypted to c. Server c creates a secret key kab ,which is placed in two separately encrypted message pieces that are sent to a: the �rst part,readable by a, contains a's original challenge, b's retort nb and the shared secret kab . Theother part, not readable by a but by b, contains the same shared secret and a's identity; itis forwarded by a in event 4 to b, together with b's challenge encrypted with this new sharedsecret. For parametricity in the modelling, we have explicitly added redundant informationin some of the messages � b in event 1, a in event 3, and b in event 4. We have also shown(two possibilities of) the �rst post-protocol message in which datum d is sent encryptedusing the new session key kab .The secrecy property we would like to verify is that the keys kac , kbc, and kab remainsecret. The authenticity property that we would like to verify is that the message successfullyreceived by b at the second part of event 5 (alternatively 50) of the protocol is `authentic',i.e., it is equal to the message emitted by a in the �rst part of the same event. Followingevent 3, principal a will believe it is interacting with principal b if the third element of themessage component encrypted with kac is the same as the nonce na that it had generatedin event 1. Following event 4, principal b will believe it has authenticated and established asecure channel with principal a, provided the nonce nb encrypted with the received key kabis equal to the nonce generated at event 2.We will model a system q(a,b,c) consisting of principals a, b and c, which are assumedto follow the protocol honestly. Our goal is to verify that a session between a and b cannotbe attacked by showing that the system q(a,b,c) can never evolve into a con�guration witherror.From the message sequence chart above we can extract the sequence of events where aprincipal acts as a sender or a receiver, as well as the name generation, cryptographic andmatching operations that it performs.Let pa, pb, and pc be the processes corresponding to instances of principals a,b,c involvedin one protocol session. The process pa, for the �rst alternative of the �rst post-protocolINRIA

The game of the name in cryptographic tables 11event, is then speci�ed as follows:event 1 (�na) (!(a; b; na):event 3 ?(a; fb; k; na; ngkac ; y):event 4 !(b; y; fngk):event 5 !(a; b; fdgk)auth :0) :The behaviours associated with principals b and c are de�ned in a similar way.pb = ?(a0; b; n0):(�nb) (!(b; fa0; n0; nbgkbc):?(b; fa0; k0gkbc ; x0):case fnbgk0 = x0 in?(a0; b; fzgk0)auth :0) : pc =?(b; fa; n1; n2gkbc):(�kab)sec !(a; fb; kab ; n1; n2gkac ; fa; kabgkbc):0 :The process we consider for analysis is:q(a; b; c) � (�kac)sec (�kbc)sec (�j) (�j0) (pa j pb j pc j Ja;b j ;)where ; is the empty cryptographic table. Keys kac and kbc being long-term secrets, werestrict these names at the top-level. To indicate that the authenticity judge is observing asession involving a and b, we place a judge process Ja;b in parallel with the principals andrestrict the names j; j0. What we have presented is only illustrative: we also have to considera similar process with event 50 instead of event 5, and with the judge Jb;a . In general, toconsider the protocol operating in more complicated scenarios, we can emend q by enrichingthe contexts in which the principals are placed.4 ReachabilityIn the previous sections, we expressed secrecy and authenticity properties as reachabilityproperties. We now present some results on the problem of determining whether a con�gu-ration can reach one with error.De�nition 4.1 (substitution) A name substitution � is a function on names that is theidentity almost everywhere.De�nition 4.2 (injective renaming) Let r and r0 be con�gurations. We write r �= r0 ifthere is an injective substitution � such that �r � r0.We study reachability modulo injective renaming.Lemma 4.3 (1) The relation �= is re�exive, symmetric, and transitive.(2) If r �= r0 then r # err i� r0 # err .(3) If r �= r0 and r !R r1 then 9 r01 r0 !R r01 and r1 �= r01.RR n° 3733

12 Roberto M. Amadio Sanjiva PrasadWe consider rewriting modulo injective renaming.Lemma 4.4 Let r be a con�guration. Then the set fr0 j r !R r0g where R is not (let2e) is�nite modulo injective renaming.Lemma 4.5 Let r � (�fag) (p j T ) be a con�guration. Given a sort s, the set of con�gura-tions to which r may reduce by (let2e), while introducing a name of sort s in the cryptographictable, is �nite modulo injective renaming.Therefore, if we can bound the sorts in the cryptographic table then the reduction relationde�ned in �gure 1 is �nitely branching modulo injective renaming.A second important result is that all reduction rules except input are strongly con�uentmodulo injective renaming.Lemma 4.6 Let r be a con�guration and suppose r !R1 r1 and r !R2 r2 where R1 is notthe input rule. Then 9 r01; r02 (r1 !0;1R01 r01; r2 !0;1R02 r02; and r01 �= r02)where R02 in not the input rule and !0;1R indicates reduction in 0 or 1 steps.The rule (let2e) can be postponed except in certain particular cases.Lemma 4.7 Suppose r is a con�guration andr � (�a) (p j T )!let2e r0 � (�a) (p j T [ ffbgc = a0g)!R r00where fbgc = a0 is the tuple introduced by the �rst reduction. Then in the following casesthe �rst reduction (let2e) can be postponed or eliminated:(1) If R = (in) and the name taken in input is not a0 then9 r1; r2 (r !in r1 !let2e r2) and r00 �= r2 :(2) If R = (let2e) and r00 � (�a) (p j T [ ffbgc = a0; fb1gc1 = a01g) where fb1gc1 = a01is the tuple introduced by the second reduction and this tuple does not depend on a0, i.e.,a0 =2 fb1; c1g. Then the two (let2e) reductions can be permuted:r ! (�a) (p j T [ ffb1gc1 = a01g)! r00 :(3) If R = (let1) and we haver0 � (�a) (p00 j let a = fbgc in p0 j T [ ffbgc = a0g)!let1r00 � (�a) (p00 j [a0=a]p0 j T [ ffbgc = a0g) :Then the (let2e) reduction can be eliminated as follows:r !let2 (�a; a0) ([a0=a]p0 j p00 j T [ ffbgc = a0g)!let1e r00(4) In all other cases: 9 r1; r2 (r !R r1 !let2e r2) and r00 �= r2. INRIA

The game of the name in cryptographic tables 13Next we introduce a measure d(s) of a sort s which will provide an upper bound on thenumber of (let2e) reductions that might be needed for the synthesis of a name.De�nition 4.8 (sort measure) We de�ne a measure d on sorts as follows:d(0) = 0 d(s1; : : : ; sn) = 1 + d(s1) + : : :+ d(sn) :Lemma 4.9 Suppose r1 !let2e � � � !let2e rn+1 !in rn+2 where the name received in inputin the last reduction has sort s and n � d(s). Then at least n � d(s) (let2e) reductions canbe postponed modulo injective renaming, i.e.r1 � r01 !let2e � � � !let2e r0d(s)+1 !in r0d(s)+2 !let2e � � � !let2e r0n+2and r0n+2 �= rn+2.Proofhint. We apply lemma 4.7(1) to shift the input reduction to the left till the pointwhere the (let2e) reduction introduces a tuple fbgc = a and a is the name of sort s taken ininput. The construction of the name a needs at most d(s) (let2e) reductions. All the other(let2e) reductions can be moved to the right of the input by iterated application of the lemma4.7(1-2). qedTo summarize, (let2e) reductions can be postponed except when they are needed in theconstruction of a name to be input. In this case, the number of needed (let2e) reductions isbounded by d(s) if s is the sort of the input name.Next, let us concentrate on the reachability problem in the case where all principals are�nite processes (in practical applications this is often the case). We note that the secrecyand authenticity annotations compile to �nite processes.De�nition 4.10 (con�guration measure) We de�ne the measure of a con�guration r �(�fag) (p j T ) as the pair (jpj; jaj) where jpj is the size of the process and jaj is the cardinalityof fag.Lemma 4.11 (1) Rules (out), (in), (�), (m), (let1), (let2), and (case) decrease the size ofthe process jpj.(2) Rules (let1e) and (casee) decrease the size of the restricted names jaj while leavingunchanged the size of the processes.(3) Rule (let2e) leaves the measure (jpj; jaj) unchanged.(4) If r !let2e r0 and r0 # err then r # err .In the following, we concentrate on the issue of deciding reachability of a con�guration witherror assuming that for every input we can compute a �nite and complete set of sorts whichis de�ned as follows.RR n° 3733

14 Roberto M. Amadio Sanjiva Prasad1. Perform in an arbitrary order the reductions di�erent from (let2e) and (in).2. Analyse the current con�guration:(a) err has been reached: stop and report that err is reachable.(b) err has not been reached and no (in) reductions are possible: backtrack if possible, otherwisereport that err is not reachable and stop.(c) Otherwise:i. Non-deterministically select an input action and compute a �nite complete set of sorts forit, say fs1; : : : ; sng.ii. Non-deterministically perform a sequence of (let2e) reductions of length at mostmaxfd(s1); : : : ; d(sn)g.iii. Non-deterministically select an input for the input action. Goto step 1.Figure 2: Complete strategy for checking error reachabilityDe�nition 4.12 (complete set of sorts) Given a con�guration r � (�a) (?a:p j q j T )we say that a set of sorts S is complete for the input ?a:p if whenever there is a reductionsequence starting from r leading to err and whose �rst reduction is performed by ?a:p, thereis a reduction sequence leading to err where the name taken in input has a sort in S.Example 4.13 The problem of determining tight bounds on a complete set of sorts is nottrivial. Consider p � (�k) (?a:!fagk j?ffcgk0gkerr). It is easily checked that the set f0g isnot complete for the input ?a:!fagk, but the set f(0; 0)g is.If a �nite complete set of sorts can be computed then the strategy in �gure 2 decidesif r can reach err . We remark that sort constraints are usually assumed in the veri�cationmethods described, e.g., in [11, 14].Theorem 4.14 Starting from a con�guration r the strategy in �gure 2 terminates and itwill report an error i� r #� err .Proofhint. Concerning termination, we note that we can perform the loop from step 1 tostep 2(c)(iii ) a �nite number of times since at every iteration we perform at least one inputaction and this decreases the well-founded measure of de�nition 4.10. We will argue nextthat the non-deterministic choices in steps (i), (ii), and (iii) are �nitely branching (moduloinjective renaming). This entails the termination of the strategy.()) The strategy examines a subset of the reachable con�gurations and therefore it isobviously sound.(() Let r be the initial con�guration. The rewriting in step 1 terminates in a con�gurationr0 by lemma 4.11. By iterated application of lemma 4.6 and lemma 4.3, if r #� err thenr0 #� err .In step 2(b), if we have not reached err then we can safely claim by lemma 4.11(4) thaterr is not reachable. INRIA

The game of the name in cryptographic tables 15In step 2(c)(ii ), we know, by lemma 4.9, that if there is a sequence that leads to errorthen there is a sequence that leads to error whose initial sequence of (let2e) is bounded bythe sorts' measure. By lemma 4.5, there is a �nite number of sequences of (let2e) reductionsof a given length (modulo injective renaming). Thus there are a �nite number of cases toconsider.In step 2(c)(iii ), we apply again lemma 4.4 to conclude that there are a �nite number ofcases to consider modulo injective renaming. qedIt is not di�cult to generate e�ectively a positive boolean combination of equationalconstraints on sorts which determines the general shape of the input variables. As above, weconsider con�gurations r � (�a) (p j T ) such that p does not contain recursive de�nitions.Let p1; : : : ; pn be the list of all sequential threads resulting from the interleaving of theactions in p. We remark that to determine whether r #� err it is su�cient to check whether9 i (�a) (pi j T ) #� err . Therefore, without loss of generality, we consider processes thatdo not contain parallel composition. We also assume that all bound names in r are distinctand di�erent from the free names. To every name a we associate a distinct sort variable saranging over Srt . We de�ne a function E from con�gurations to constraints as follows:E(r) = Vfsa = srtT (a) j a 2 n(T )g^Vfsa = 0 j a 2 (fn(r) [ fag)nn(T )g^E(p)where E(p) is inductively de�ned on the structure of the sequential thread p as follows:E(0) = false E([a = b]p; q) = ((sa = sb) ^ E(p)) _ E(q)E(err) = true E((�a) p) = (sa = 0) ^ E(p)E(!a:p) = E(p) E(let a = fbgc in p) = (sa = (sb; sc)) ^ E(p)E(?a:p) = E(p) E(case fbgc = a in p) = (sa = (sb; sc)) ^E(p)With every run which reaches err , say r !� r0 # err we associate an assignment � �(sc1 = s1) ^ � � � ^ (scn = sn) where c1; : : : ; cn are the input variables which are actuallyinstantiated in the run and s1; : : : ; sn are the corresponding sorts of the names provided bythe environment. The assignment � satis�es the constraints E(r).Proposition 4.15 If r !� r0 # err and � is the corresponding assignment of input variablesthen E(r) ^ � is consistent.Proofhint. By induction on the length of the reduction r !� r0. qedFor instance, in example 4.13, we can deduce that the sort of the input on the right handside must have the shape ((s; 0); 0). Of course, there are in�nitely many sorts of this shapeand therefore proposition 4.15 does not provide a �nite complete set of sorts. It remains tobe seen whether symbolic representations of the con�gurations can yield stronger decidabilityresults.RR n° 3733

16 Roberto M. Amadio Sanjiva PrasadAcknowledgements. We would like to thank Kevin Compton, Mads Dam, Andrew Gor-don, and Joachim Parrow for helpful discussions.References[1] M. Abadi and A. Gordon. A calculus for cryptographic protocols: the spi calculus. InProc. ACM Computer and Comm. Security, 1997.[2] M. Abadi and A. Gordon. A bisimulation method for cryptographic protocols. In Proc.ESOP 98, Springer Lect. Notes in Comp. Sci. 1382, 1998.[3] R. Amadio. On modeling mobility. Journal of Theoretical Computer Science, to appear,1999.[4] D. Bolignano. Formal veri�cation of cryptographic protocols. In Proc. ACM Conferenceon Computer Communication and Security, 1996.[5] M. Boreale, R. De Nicola, and R. Pugliese. Proof techniques for cryptographic processes.In Proc. IEEE Logic in Comp. Sci., 1999.[6] E. Clarke, S. Jha, and W. Marrero. Using state space exploration and a natural deduc-tion style message derivation engine to verify security protocols. In Proc. IFIP WorkingConference on Programming Concepts and Methods (PROCOMET), 1998.[7] M. Dam. Proving trust in systems of second-order processes: preliminary results. InProc. HICSS 98, 1998.[8] D. Dolev and A. Yao. On the security of public key protocols. IEEE Trans. on Infor-mation Theory, 29(2):198�208, 1983.[9] M. Elkjaer, M. Höle, H. Hüttel, and K. Nielsen. Towards automatic bisimilarity checkingin the Spi calculus. In Proc. of DMTCS 99 and CATS 99, 1999.[10] A. Huima. E�cient in�nite-state analysis of security protocols. In Proc. Formal methodsand security protocols, FLOC Workshop, Trento, 1999.[11] G. Lowe. Breaking and �xing the Needham-Schroeder public-key protocol using fdr. InProc. TACAS, Springer Lect. Notes in Comp. Sci. 1996, 1996.[12] C. Meadows. A model of computation for the nrl protocol analyzer. In Proc. IEEEComputer Security Foundations Workshop, 1994.[13] J. Mitchell, M. Mitchell, and U. Stern. Automated analysis of cryptographic protocolsusing mur�. In Proc. IEEE Symposium on Security and Privacy, 1997.[14] L. Paulson. Proving properties of security protocols by induction. In Proc. IEEEComputer Security Foundations Workshop, 1997. INRIA

The game of the name in cryptographic tables 17[15] S. Schneider. Security properties and CSP. In Proc. IEEE Symp. Security and Privacy,1996.[16] C. Weidenbach. Towards an automatic analysis of security protocols in �rst-order logic.In Proc. CADE 99. Springer Lect. Notes in Comp. Sci. (LNAI) 1632, 1999.

RR n° 3733

Unité de recherche INRIA Sophia Antipolis2004, route des Lucioles - B.P. 93 - 06902 Sophia Antipolis Cedex (France)

Unité de recherche INRIA Lorraine : Technopôle de Nancy-Brabois - Campus scientifique615, rue du Jardin Botanique - B.P. 101 - 54602 Villers lès Nancy Cedex (France)

Unité de recherche INRIA Rennes : IRISA, Campus universitaire de Beaulieu - 35042 Rennes Cedex (France)Unité de recherche INRIA Rhône-Alpes : 655, avenue de l’Europe - 38330 Montbonnot St Martin (France)

Unité de recherche INRIA Rocquencourt : Domaine de Voluceau- Rocquencourt - B.P. 105 - 78153 Le Chesnay Cedex (France)

ÉditeurINRIA - Domaine de Voluceau - Rocquencourt, B.P. 105 - 78153 Le Chesnay Cedex (France)http://www.inria.fr

ISSN 0249-6399