Formal veri cation of cryptographic protocols using Coq

Formal veri cation of cryptographic protocols using Coq Dominique Bolignano and Valerie Menissier-Morain 

GIE Dyade, Domaine de Voluceau, BP 105, 78153 Rocquencourt Cedex, France

(Received ..... ; Accepted in nal form .....)

Abstract. We show by the means of an example, the Otway-Rees protocol, how to formally verify authentication protocols using Coq [4]. The modeling of the problem follows the approach presented in [8] and [7]. The approach is based on the use of state-based general purpose formal methods as opposed to approaches based on the use of a modal logic of authentication. It is complementary with modal logic based approaches as it allows for a description of protocol, hypothesis and authentication properties at ner level of precision and with more freedom. It is based on a clear separation between the modeling of reliable agents and that of unreliable agents or more generally of intruders. The formalization for the intruder knowledge, axioms for manipulating them, as well as the protocol description can be transposed quite directly using Coq. The formal veri cation can also be done in a quite systematic way. Key words: cryptographic protocols, authentication, Otway-Rees, formal proof, theorem proving, Coq The distribution of applications and data across computer systems is becoming more popular at the same time that business and organizational pressures are making security more important than ever before. An important aspect of security is authentication, that is the ability of principals to mutually identify themselves, and not be mislead by malicious principals. Many authentication protocols are based on the use of cryptographic functions, i.e. encryption and decryption functions. An authentication protocol usually has two phases, one in which the identity of a principal is announced and a second phase in which this identity is veri ed. Authentication must in particular guarantee that the actions of the other principal are not simulated through replay, and that they are not modi ed or even created by a malicious principal. But the use of well-designed encryption and decryption functions does not guarantee that a protocol is free of aw. In fact the design of an authentication protocol is a particularly error-prone process, and many popular and largely used protocols have been shown to have aws [9]. The use of formal methods which allow to verify such protocols in a systematic and formal way has for this reason received increasing attention. The formal veri cation of authentication protocols may be done in basically three ways. One possibility is to use a modal logic for authentication, that is a logic that has some modalities for expressing properties in a more appropriate way. One such modal logic is the Burrows, Abadi and Needham (BAN) logic [9]. The second possibility is to use general purpose formal methods. Such methods have been designed and used for various kinds of software applications: safety critical embedded systems for trains, nuclear power plants; complex distributed systems; etc. The approach of Meadows [20] is a good representative of such approaches. The third possibility is to use model-checking techniques as in [16, 14]. Model-checking based techniques have only recently been applied to the veri cation of cryptographic protocols. Veri cation is performed on a nite model that corresponds to an abstraction of the initial speci cation. The veri cation is thus automatic. But here is thus a risk that the informal abstraction step implicitly performed by the user is unsafe and compromises the result of the analysis itself (by validating 

Email: fDominique.Bolignano, [email protected]

2 Dominique Bolignano and Valerie Menissier-Morain problematic protocols). In their current form such approaches are thus mainly useful for identifying aws rapidly. The use of general purpose formal methods has the advantage of relying on well-de ned and largely used techniques. The formal veri cation is usually done using theorem provers for standard logics which may take advantage of all research in the area of automatic or assisted proving. But as these approaches are not speci c of authentication problems modeling and veri cation is usually much less concise. The main approaches are the approach of Kemmerer [13] based on the formal speci cation language Ina Jo, the approach of Meadows [17], [18], [19], [20], based on asynchronous communicating processes, the approach of Cheng and Glicor[11] also based on the Ina Jo speci cation language, but using the BAN logic [9] that will be presented later on to model belief and nally Bieber approach [6] based on the formal speci cation language B[2]. Modal logics for authentication can be classi ed into two groups, logics of knowledge and logics of belief. The main and original dierence between the two logics is theoretical (i.e. logics of knowledge belong to the class of S5 modal logics, whereas modal logics of belief belong to KD45), but a practical dierence is that for the rst group a fact cannot be true for one principal and false for another one, as for the second a fact is only a belief and does not need to be universal in time and space. The most well-known modal logic is the Burrows, Abadi et Needham (BAN) logic [9]. The BAN logic is a logic of belief. In order to verify a protocol using the BAN logic, a set of hypothesis describing the set of initial beliefs is laid down and each step of the protocol is translated into BAN facts. The BAN logic has been used successfully for the veri cation of many protocols. But the BAN logic also has limitations which have been the subject of many research activities. There is in particular no complete semantics for the logics. This may lead to modeling problems as some facts may have an unclear meaning. This limitation lead the authors to design a new logic, the AT logic [1]. The modeling of freshness is also particularly problematic. As in most modal logic it is in particular not possible to distinguish between freshness of creation and freshness of receipt [22]. More generally the very abstract level of the BAN imposes in many cases the use of hypothesis or protocol description whose relevance is far from being obvious. We will exhibit such problems in the next section. Another problem described by A. Liebl in [15] is that there is no systematic way for translating a protocol description into a BAN description. A complete bibliography of the BAN critics and related works can be found in [15]. The BAN logic, as well as its numerous extensions or alternatives [12], [5] and more generally the modal logics of authentication provide a very elegant and concise way of proving properties of authentication protocols, but the modeling approach is in some way wired and corresponds to a high level of abstraction. Thus when ner modeling hypothesis or a ner level of description is required other approaches have to be considered. In [7], [8] we present an approach which has been designed to achieve this objective. The approach is complementary to modal logic approaches and uses general purpose to exploit the speci city of the problem and to achieve easier formalization and more concise proofs. It has already been applied in industry for the design or veri cation of a few real protocols. This approach is currently being applied for the veri cation of large electronic commerce protocols 1 . The approach is based on a clear separation between the modeling of reliable principals and that of unreliable ones. We propose a speci c modeling for the knowledge of unreliable principals that allows for 1

http://www.dyade.fr/actions/VIP/vip.html

jar.tex; 20/01/1997; 15:38; no v.; p.2

Formal veri cation of cryptographic protocols using Coq

3 easy and concise proofs in the style of modal logic proofs. The speci cation of the protocol is done in a very precise manner, and the precise sequencing constraints are in particular taken into account. We express authentication properties using basic temporal features (i.e. ordering and coherence of events). The proposed approach strongly diers in most of these respects as well is in its objectives with the other uses of formal methods. In [7], [8] the veri cations of two protocols were presented as a way of illustrating the approach. The proofs were presented informally. But informal proofs are also error prone, and for the method to be useful in the industrial context where large and complex protocols have to be designed and veri ed, it is necessary to perform proofs formally and a reasonable cost. The objective of the paper is to show that it can be done quite nicely using the Coq language and the Coq prover [4]. The presentation is done by the mean of an example and is organized as follows. In the next section we present the Otway-Rees protocol that will be used to illustrate the proofs. In section 3 we recall the approach modeling strategy and in section 4 the modeling of knowledge. In section 5 we formalize the protocol and in section 6 we present the proof.

1. The Otway-Rees protocol The encryption is the operation that transforms a data into another data. The decrypting is the inverse operation which allows to compute the original encrypted data. The encryption and decryption functions are performed using cryptographic keys. The only practical way of getting the original data from the encrypted is by decryption. A cryptographic key is said to be symmetric if and only if the same key is used for encryption and decryption. If a cryptographic key is not symmetric it is said to be asymmetric. There is thus a one to one correspondence between asymmetric keys. If Ka is encryption (resp. decryption) key then, Ka 1 denotes the corresponding decryption (resp. encryption) key. The key Ka 1 is said to be the inverse key of Ka and Ka is the inverse key of Ka 1 . The inverse key of a symmetric key is the key itself. We will use Xk (or fX gk in the case of notation ambiguity) to stand for the encryption of a data X with key k. A key is said to be public if it is known by all principals (the con dentiality is in particular not guaranteed). A key is said to be private if it is only known by principals that are supposed to use it. A symmetric key is always private, as otherwise it would not be of any use. In the case of asymmetric keys, one key is private and its inverse is usually public. If the encryption key is private and only known by one principal it is possible to authenticate originator. But it is not possible to guarantee its con dentiality as all principals knowing the inverse key may have decrypted the information. It is not possible either to guarantee freshness of the message, as the message may just be a replay of a previous message. In the opposite case, that is if the encryption key is public and the decrypting key is private it is possible to guarantee con dentiality but not authentication. Most cryptographic authentication protocols use combination of these properties to obtain proper authentication. The Otway-Rees protocol allows two principals, A and B , to share a private key so as to be able to communicate between each other in a secure way. The protocol allows some kind of mutual authentication. The protocol is initiated by one of the principals. This principal is A in our case. The protocol requires the use of a certi cation authority, S , in order to distribute private keys to principals requesting them. The protocol is composed of 4 message sending between A, B and S : 1. A ! B : (M; A; B; (Na ; M; A; B )Kas )

jar.tex; 20/01/1997; 15:38; no v.; p.3

4

Dominique Bolignano and Valerie Menissier-Morain

2. B ! S : (M; A; B; (Na ; M; A; B )Kas ; (Nb ; M; A; B )Kbs ) 3. S ! B : (M; (Na ; Kab )Kas ; (Nb ; Kab )Kbs ) 4. B ! A: (M; (Na ; Kab )Kas )

It is assumed here that the principal A (resp. B ) knows the key Kas (resp. Kbs ), and that S knows both keys Kas and Kbs . The protocol description can be read as follows: 1. A sends a message to B to tell that he is the principal A and wants to start an authentication procedure with B ; the message is a quadruple where the rst component is a nonce (i.e. a new number) M that A generates for the purpose; the second component is the identi er A of the originator of the authentication request and the third component is the identi er B of the expected target of the request; none of the three rst component is crypted; the fourth component is a quadruple encrypted with Kas and contains a nonce Na newly generated by A, the nonce M , and the identi ers A and B ; 2. B reemits the message to S but adding a new component encrypted using Kbs and similar to the crypted component sent by A but for the presence of a nonce Nb newly generated by B ; 3. S replies to B by sending a triple whose rst component is M , whose second component is a pair encrypted with Kas composed of the nonce Na , and of the private key Kab that A and B will have to use for their session; the third component is a pair similar to the previous one, but it is encrypted with Kbs and the nonce Nb is used instead of Nas ; 4. B reemits to A the part of the previous message that was encrypted with Kas and dedicated A.

2. Modeling Strategy In this section we present the basic modelling strategy underlying the approach. First the dierent principals involved in the protocol, apart from A, B and S that are obvious principals, have to be identi ed. Communications media can be considered as principals that receive messages on one end and emit other messages at another end. Some principals will be considered to be trustable (or reliable) and some not. Communication media are usually considered to be non trustable as messages can usually be spied, replayed, removed or created by intruders. We will consider that this is the case in the following although this is not central in anyway to the approach. The same protocol can be studied against many dierent hypothesis. In the case of the protocol at hand we will take A, B and S to be the only trustable principals. All trustable principals are always be assumed to play their role as stated by the protocol. For non trustable principals the situation is very dierent as we do not know how many they are, how they work, how they cooperate and we have to imagine the worst case. So instead of modeling each non trustable principal separately, and instead of describing how they work, we will model the set of all such principals and call it the \external world" or more concisely the intruder. Of course, since we model all non trustable principals as a single principal which communicates directly with trustable principals, here with A, B , and S , and since the communication media are part of the

jar.tex; 20/01/1997; 15:38; no v.; p.4

Formal veri cation of cryptographic protocols using Coq

5

intruder, it is not possible to distinguish between the situation where a message is sent from A to B

without being spied, from the situation where it is spied and even from the situation where it is for example removed and immediately remitted without being modi ed. But such situations are all the same with respect to authentication properties: the question for B is for example to know if the message was originally sent by A and if yes when. The question is also to know if a data is known or not by the intruder. In any of the three previously mentionned situations the whole message will be supposed to be known by the intruder as he had the possibility to spy and store it, but this does not mean of course that all data composing this message will be known as such components may be present in encrypted form. We will in fact model the intruder as a principal that may know some data initially and that will store and decrypt all data passed to the malicious principals and thus all information circulating on the communication media. The intruder will also be able to encrypt data to create new messages he will send to mislead trustable principals. But he will only be able to decrypt and encrypt data with keys he knows. This modeling will in particular allow us to tell at any time which data is potentially known by the intruder under the chosen \trustability" hypothesis.

3. Modeling of Intruder Knowledge Data that can be communicated between principals can be: basic data, which may be (1) cryptographic keys which take their values in domain K , (2) other basic data which will take their values in D and which cannot be used as cryptographic keys; data obtained by composition (1) using the pair operator which takes some data c1 and some c2 and returns the pair (c1 ; c2 ), (2) or by encryption of some data c using key k (corresponding encrypted data will be noted ck ). The domain of symmetric keys is noted KS , while that of asymmetric keys is noted KA. K is thus the union of KA and KS . The pair operator is used to represent reversible constructors. Taking into account other reversible constructors such as the sequence, set, or aggregate constructors would be done in a straightforward manner. In [7] the domain C of data components is de ned inductively starting from the in nite and disjoint sets KS; KA and D: C = CK j(C; C )jB B = K jD K = KAjKS jK 1 modulo (i.e. quotiented by) the two axioms 8k:k 2 KS ) k 1 = k, and 8k:k 2 KA ) (k 1 ) 1 = k. The j operator stands for disjoint type union: for example, some data (i.e. element) of B is either in K or in D. Thus if k and d are respectively elements of KA and D, then d; (d; k); k 1 ; (d; k)k ; dk , etc., are elements of C . The set of data components that can be collected by the intruder (or by any other principal as well) is described as the set S de ned in the following manner:

S = C [S j;

jar.tex; 20/01/1997; 15:38; no v.; p.5

6 Dominique Bolignano and Valerie Menissier-Morain where [ is an ACUI operator with neutral ; (i.e. associative, commutative, unitary and idempotent): if k and d are respective elements of K and D, then d; (d; k) and dk are all three elements of C and d[ (d; k) [ dk is an element of S which formalizes the knowledge of all three elements.The domain of symmetric keys will be noted KS , while that of asymmetric keys will be noted KA (i.e. K = KA [ KS ). In the sequel, we will adopt the following conventions: variables s; s0 ; s00 ; :::; s1 ; s2 ; ::: take their values in S by default; variables k; k0 ; k00 ; :::; k1 ; k2 ; ::: take their values in K ; variables d; d0 ; d00 ; :::; d1 ; d2 ; ::: take their values in D, etc. The formalization of C and S in Coq is done as follows. First we de ne the domain K as the disjoint union of the two domains KA and KS . This is obtained as the following simple inductive de nition where N is an underspeci ed set (we expect this set to be in nite). Inductive K: Set := ka: N -> K | ks: N -> K.

Then we de ne the function inv : K ! K such that 8k:k 2 KS ) inv(k) = k, 8k:k 2 KA ) inv(inv(k)) = k and 8k:k 2 KA ) inv(k) 6= k. The function inv will be used to associate each key with its inverse (i.e. k 1 ). The Coq description is as follows2 : Parameter inv: K -> K. Axiom inv_ka: (n: N) (inv (inv (ka n)))=(ka n). Axiom inv_ks: (n: N) (inv (ks n))=(ks n).

Then we de ne the domain C by directly transposing the previous inductive de nition into Coq. Inductive C : Set := encrypt : C -> K -> C | pair : C -> C -> C | B2C : B -> C.

Thus the Coq domain for C directly conforms to its de nition in [7]. Now for the formalization of S , we proceed dierently by using a concrete domain in the Coq formalization: sets of data components are modelled using lists in Coq and the properties of the ACUI operator [ used in [7] are used to de ne equivalence classes over the more concrete lists3: thus instead of having d [ k = k [ d as in [7] we will have in Coq equivS (cons(C d cons(C k empty))) = equivS (cons(C k cons(C d empty))) where cons and nil are constructors for polymorphic lists as de ned in the PolyList contribution of the Coq library. Using an abstract version of S would be a feasible alternative and would just require using a function, let us say consa : C ! S ! S , to associate the abstract set obtained by adding a data component to a given abstract state4 . Here the use of concrete sets facilitates mechanization in the proof process through the use of inductive proofs. The complete Coq de nitions for C , D, B , KA, KS and K are presented in Appendix B. The knowledge of the intruder at any given time will be modeled by the set of data components he will have collected or deduced previously. The ve basic operations that an intruder may use in order to exploit data were de ned in [7] and referred to as , 0 , , 0 and  operations: for the encryption of a known data component using a known key, 0 for the decryption of a known data component using a known key,  for the pairing of two known data components, 0 for the decomposition of a pair (i.e. 2 For more more conciseness in the presentation we omit in this paper the Coq formalization of unused axioms whose formalization is straightforward: the Coq formalization of 8k:k 2 KA ) inv(k) 6= k is for example omitted here. 3 The equivalence relation for concrete lists is de ned as equivS in the Coq formalization. 4 We used inv to play this role in the de nition of C .

jar.tex; 20/01/1997; 15:38; no v.; p.6

Formal veri cation of cryptographic protocols using Coq

7 obtaining the rst or second projection); and  for data extraction. Each action was formalized as a state transformation relation: s = ) s0 def = f(s; s0 )j(9c; k : k [ c  s ^ s0 = s [ (c)k g 0 s = ) s0 def = f(s; s0 )j(9c; k : k 1 [ (c)k  s ^ s0 = s [ cg = f(s; s0 )j(9c1 ; c2 : c1 [ c2  s ^ s0 = s [ (c1 ; c2 ))g s =) s0 def 0 def  s =) s0 = f(s; s0 )j(9c1 ; c2 : (c1 ; c2 )  s ^ s0 = s [ c1 [ c2 )g s =) s0 def = f(s; s0 )js0  sg where  is de ned on S  S as: s0  s def = 9s00 :s0 [ s00 = s. The exploitation of a given knowledge (i.e. a given set of data components) to deduce new information (i.e. new data) consists in the application of zero or more of the above operations in any order and any number of times. A set of data components s0 (or a single data components) is thus said to be deducible from a set of data component s if and only if there exists a sequence of applications of the ve basic operations which allows us to obtain s0 from s. Given any subset5 E = fx1 ; ::; xn g of f ; 0 ; ; 0 ;  g, E! is de ned as the re exive-transitive closure n . The predicate known in is de ned as follows: c known in s if and only 1 of the relation =x) [ : : : [ =x) 0 0 if s f ; ;; ! ;g c: c known in s if and only if c is deducible from s. In [7] an axiomatization is derived for known in. This axiomatization uses another relation, i.e. comp of , which allows for more direct and precise proofs. Intuitively comp of is similar to known in but based on a restricted set of potential operations:0 operations of decryption and operations of decomposition. More precisely s comp of c if and f ;0 ;g only if s ! c. The use of comp of is not strictly required but signi cantly reduces the veri cation process. The axiomatization proposed in [7] is recalled in Appendix A. An example of such rule is ck known in s ^ k 1 known in s ) c known in s which states that if a principal knows (i.e. can deduce) both the encrypted component ck and the inverse key k using the set of data s then he knows (i.e. can deduce) the component c. The consistency of these axioms and some completness properties have been proved in [7]. Here we are only concerned with the formalization of the axioms in Coq. The axioms are directly translated into the Coq formalism. The axiom (A4), i.e. ck known in s ^ k 1 known in s ) c known in s, for example becomes: Axiom A4: (c1:C) (k1:K) (s:S) (known_in (encrypt c1 k1) s) -> (known_in (B2C (K2B (inv k1))) s) -> (known_in c1 s).

To this set of axioms we add the four following axioms6 : Axiom (c: Axiom (c: Axiom (c: Axiom (c:

EquivKnown: C) (s1, s2: SD) EquivNKnown: C) (s1, s2: SD) EquivComp: C) (s1, s2: SD) EquivNComp: C) (s1, s2: SD)

(equivS s1 s2) -> (known in c s1) -> (known in c s2). (equivS s1 s2) -> ~(known in c s1) -> ~(known in c s2). (equivS s1 s2) -> (decomp_of c s1) -> (decomp_of c s2). (equivS s1 s2) -> ~(decomp_of c s1) -> ~(decomp_of c s2).

Only non empty subsets are useful in practice. not known in and not comp of predicates are used in practice to stant for the negation of known inand comp of. Il faut aussi expliquer que l'on a remplacer certains des axiomes par des de nitions inductives pour faciliter les preuves. 5 6

jar.tex; 20/01/1997; 15:38; no v.; p.7

8 Dominique Bolignano and Valerie Menissier-Morain In order to justify this translation we proceed as follows. The relation known in (resp. comp of ) used in Coq will be noted known inc (resp. comp ofc). The signature of known inc (resp. comp ofc ) is C ! Sc ! Sc ! Bool where Sc refers to the domain for concrete sets of data components. Similarly the relation known in (resp. comp of ) used in [7] will be noted known ina (resp. comp ofa ). The signature of known ina (resp. comp ofa ) is C ! Sa ! Sa ! Bool where Sa refers to the domain for abstract sets of data components de ned in [7]. The function h : Sc ! Sa which associates to any concrete concrete set s of Sc its abstract counterpart h(s) of Sa (e.g. h(cons(C d cons(C k empty))) = h(cons(C k cons(C d empty))) = d [ k) is such that h(s1) = h(s2) if and only if equivS (s1; s2). By de nition we state that c known inc s (resp. c comp ofc s) is equivalent to c known ina h(s) (resp. c comp ofa h(s)). Thus by associating to each axiom of [7] the same axiom in Coq where Sa is replaced by Sc , known ina by known inc , comp ofa by comp ofc, the set membership operator 2: C  Sa ! Bool by the list membership predicate In : C  Sc ! Bool and setofkeysa : Sa ! Bool by its trivial counterpart7 setofkeysc : Sc ! Bool on lists, we trivially preserve consistency of axioms (any proof done using the concrete axioms can easily be transformed into a valid proof by replacing the concrete predicates by their abstract counterparts). Completeness properties are also preserved because of the addition of the four equivalence axioms above. Indeed any \abstract" proof is translated into a coherent \concrete" one, by associating to each step in the abstract proof a coherent step in the concrete one as illustrated below. But this may require the use (the insertion) of new proof steps which are based on the equivalence axioms above. The transformation is illustrated below: .. .

d1 6= d3 :(d1 comp of k) d1 6= d2 (C 3) :(d1 comp of (d2 [ k)) (C 3) :(d1 comp of (d2 [ k [ d3 )) .. .

.. .

:(d1 comp of k) d1 6= d2 (C 3) equivS(d2[k; k [ d2) :(d1 comp of (k [ d2)) (EquivNComp) :(d1 comp of (d2[k)) :(d1 comp of (d2 [ k [ d3 ))

d1 6= d3

(C 3)

The rst abstract proof tree is transformed into the second concrete tree (we use the same notation in the two cases to simplify presentation). This involves inserting an (EquivNComp) step to \change the order" in the concrete set so as to allow for a coherent application of step (C3). The added step appears in bold. setofkeys is a predicate that tells if a set of data components only contains keys (i.e. is only a set of keys). It is always used as a positive subgoal. 7

jar.tex; 20/01/1997; 15:38; no v.; p.8

Formal veri cation of cryptographic protocols using Coq 4. Formalization of the Protocol

9

The formalization is done using a very basic notation inspired from the so-called chemical abstract machine paradigm (e.g. Unity [10], Gamma [3],: : : ): a system is described as a set of atomic actions which may be applied repeatedly and in any order and whenever there pre-condition holds. If S stands for the domain of possible states, every action can be described as a relation of S  S binding the state before application to the state after application.

The sending and reception of a message are not synchronous. Consequently the transmission of a message cannot be considered as an atomic action but as the combination of two events or actions, one for the sending and one for the reception.

Our modeling of the protocol will thus distinguish 8 dierent kinds of atomic actions, two for each message type. Instead of using one relation of S  S for each action we will use a single subset S AS where A = f1a; 1b; 2b; 2s; 3s; 3b; 4b; 4ag for describing the whole system. Each of the 8 labels nx of A stands for one action: the sending or reception by principal X of message n. The set S will quite naturally be de ned as a subset of SA  SB  SS  SI where each component describes the domain of local states for each principal A; B , S and I .

The domain SI will be S where S is the domain for sets of data as de ned in the previous section. Intuitively the state of the intruder is the set of data that have been listen to on the communication line and that unreliable principals may know or may have known since the beginning of the protocol. The states of the three trustable principals are de ned as the following aggregates:

jar.tex; 20/01/1997; 15:38; no v.; p.9

10

Dominique Bolignano and Valerie Menissier-Morain

SA =

SS =

SB =

M B Na KAB at

: Nonce : Principal : Nonce :K : ProgramAddress

M A B Na Nb KeyAB KeyX at

: Nonce : Principal : Principal : Nonce : Nonce : Principal ! Principal ! K : Principal ! K : ProgramAddress

M A Nb KAB Ca Cb at SI = S

: Nonce : Principal : Nonce :K :C :C : ProgramAddress

Fields at is used in each state to hold the value of the abstract program counter for the algorithm executed by the corresponding principal. We assume here that keys are never changed. The eld B is used by the master to store the identi er of the supposed slave. The eld A is used in the same way to store the identi er of the supposed master. Fields NA ; NB ; KA ; KB contain the current values of NA ; NB ; KA ; KB previously used or received according to the protocol description. Field KeyAB models the directory of session keys held by the server: it maps a pair of principals to the corresponding session key (e.g. KeyAB (A; B ) should be Kab according to our notations). Field KeyX models the directory of keys that the server associates to each principal in order to exchange con dential data with this principal (e.g. KeyX (A) should be Kas ). The value of these two directories is a constant in the present modelization. At some points some of these elds may be irrelevant. In the sequel we will use variables names starting with upper cases to stand for constant values. The key Kas is for example the private key between A and

jar.tex; 20/01/1997; 15:38; no v.; p.10

Formal veri cation of cryptographic protocols using Coq

11

S . It is a constant. The protocol is then modeled using the 8 following basic actions. action(sa :at; 1a; s0a :at) ^ s0i = si [ (s0a :M; A; s0a :B; (s0a :Na ; s0a :M; A; s0a :B )Kas )^ new(s0a :Na ; si ) ^ new(s0a :M; si ) action(sb :at; 1b; s0b :at) ^ (s0b :M; s0b :A; s0b :B; s0b:C1 ) known in si action(sb :at; 2b; s0b :at) ^ s0b = sb [ (sb :M; sb :A; sb :B; sb :C1; (s0b :Nb ; sb :M; sb :A; sb :B )Kbs ) new(s0b :Nb ; si ) action(sa :at; 2s; s0a :at) ^ (s0s:M; s0s :A; s0s:B; (s0s:Na ; s0s:M; s0s :A; s0s:B )key(s0s:A); (s0s :Nb ; s0s :M; s0s :A; s0s :B )key(s0s :B) ) known in si ^ new(s0s :Nb ; si ) action(sa :at; 3s; s0a :at) ^ s0i = si [ (ss :M; (ss:Na ; K (ss:A; ss :B ))key(ss :A); (ss :Nb ; K (ss :A; ss :B ))key(ss :B) ) ^ p(s0s :Kab ; si ) action(sb :at; 3b; s0b :at) ^ (sb :M; s0b :C2 ; (sb :Nb ; s0b:Kab )Kbs ) known in(si) action(sb :at; 4b; s0b :at) ^ s0i = si [ (sb :M; sb :C2 ) action(sa :at; 4a; s0a :at) ^ (sa :M; (sa :Nb ; s0a :Kab )Kas ) known in si

(1) (2) (3) (4) (5) (6) (7) (8)

where primed variables are used for representing values of state variables after the application of the operation and where by convention state variables that are not explicitly changed are supposed to be unchanged: the rst action which only mentions new values for sa :at and si thus assumes by default that all other elds are left unchanged, i.e. sa :M = s0a :M , : : : , ss = s0s , and sb = s0b . These equalities are all made explicit in the Coq formalization. Each of the 8 actions models a communication between one of the trusted principals and the intruder and thus may aect at the same time state variables of the two principals. The description of each action uses the action predicate. This predicate speci es the management of the control eld at which identi es the position of a principal in the \program" it is executing. We will return on this at the end of this section. The Coq description of this protocol is presented in Appendix B: the eight actions are described respectively as eight relations (rel1, : : : , rel8) that relate the global state before activation of the action to the global state after. We then need to de ne initial conditions: the initial state of the intruder will be speci ed by the predicate initial hypothesis1 (si ); other initial conditions (e.g. privacy of some keys) will be made explicit when required in the course of the proof so as to get a minimal set of hypothesis. The predicate action has not yet been speci ed. It can be de ned explicitly by describing the eect of each action on the eld at or it can be de ned implicitly: 8sa ; s0a ; s00a ; act : action(sa :at; 1a; sa :at) ^ action(sa :at; act; sa :at) ) act = 4a expresses for example that the only action that A can perform after action 1a is action 4a. Once the possible transitions have been identi ed, the formalization of action is thus straightforward and will not be detailed here. The possible transitions are such that both A and B are required to repeat a loop in which one of the two sequences 1a, 4a, and 1b, 2b, 3b, 4b appears; no transition constraint is placed on actions of S . But many other possibilities could as well be considered. The fact that principal A (resp. B ) can play two roles implies that the state of principal A (resp. principal B ) needs to be of type SA when it acts as a master and of type SB when it acts as a slave. This can be done in many ways (e.g. keeping the two kinds of information in each state, superimposing the two, banalising some elds,: : : ) but does not aect in practice the veri cation since there is no data carried from one session to the other besides the name of the principal and its private key which are two constant and which have been \wired" for this purpose.

jar.tex; 20/01/1997; 15:38; no v.; p.11

12

Dominique Bolignano and Valerie Menissier-Morain

5. Security Properties

We have now to express the authentication properties that we want the protocol to satisfy. A rst aspect of authentication is authentication of keys: A (resp. B ) wants to be sure on completion of action 4a (resp. 4b) that the key Kab that he just received (1) is still private, and (2) really is the key assumed (and proposed) by the key server S , and not another one. The rst property must be true at any given time. It can be formalized as :(Kab known in si ), which means that the key is not known by the intruder. This property needs to be true initially and has to remain true all the time: it is an invariant property. The second property can be expressed as: Kab = KeyAB (A; B ) where KeyAB is the function used by the server S to associate a private key to each pair of principals. An other aspect of authentication is the principal authentication. Each principal may want to be sure that he is really talking with the principal he wants to talk to and not another one. For this we adopt the view of a global observer which has a correct and complete view of the system: this observer will select any two trustable principals and wants the protocol to guarantee that he will not see one principal believe that he has performed a correct authentication session with the other principal while this other principal was doing something else or was doing a session not completly coherent. The rst principal will be called A or B depending on his role in the current session, and the second one will use the remaining name. Some protocols provide mutual authentication as was the case for the two protocols used to present the approach in [8], and [7]. The Otway-Rees protocols only provides partial authentication: B cannot be sure, after completing the session that he has really been talking to A, as the message 1 may well be a replay of a previous session. But the protocol for example provides principal authentication to A. As suggested by the approach such properties are de ned on partial views: the observer abstracts away (i.e. not considers) actions 1b; 2a; 3s; 3b; 4b and only considers among the remaining actions 1a; 2b; 4a those that are (supposed to be) parts of communications between A and B . The authentication property expresses that each time where A performs a complete cycle (i.e. a session) 1a; 3a, than B has necessarily performed 2b with respective values coherent with values of 1a; 3a. Furthermore the ordering of involved actions must have been the following : 1a; 2b; 3a8 . The ordering relation for the actions of one session can be represented in the general case using a partial order relation. The informal proof of such properties were shown in [8], and [7] for two dierent protocols and all ended up proving some very similar invariant properties.

6. Veri cation In the following we will just present the formal proof of the rst property, i.e. :(Kab known in si ), which expresses the privacy of Kab . In fact, si can contain fKabgk encrypted with a session key k known by the key server and not present in si so Kab can be known by the intruder even if :(Kab known in si ). Thus we need to reinforce this invariant by addition of all the session keys known by the key server S rngDDKKeyAB except Kab , that is to say rngDDKKeyABminusKab, to si and we obtain the 8 It is important to keep this de nition in mind when reading the property formulation: if for example B answers correctly to A but believes while doing this that he is talking to a third agent C (i.e. eld A of sB is equal to C ) than the corresponding actions are abstracted away and the authentication property is not satis ed. In the same way it should be kept in mind that only correct actions are considered: if an unexpected message or value is sent to A, B or S the principal \handles" the error by refusing to perform the operation (i.e. pre-condition not satis ed).

jar.tex; 20/01/1997; 15:38; no v.; p.12

Formal veri cation of cryptographic protocols using Coq 13 following invariant: :(Kab known in (si [ rngDDKKeyABminusKab)). This invariant property will be called invP in the sequel. The transposition to Coq is quite straigthforward and can be written: Definition invP := [st: GlobalState] Cases st of (ABSI _ _ _ si) => ~(known_in (B2C (K2B Kab)) (app C si rngDDKKeyABminusKab)) end.

rngDDKKeyAB

and rngDDKKeyABminusKab satisfy the three following properties:

Axiom rngDDKKeyAB1: (d1, d2: D) (In C (B2C (K2B (KeyAB d1 d2))) rngDDKKeyAB). Axiom rngDDKKeyABminusKab1: (d1, d2: D) ~(KeyAB d1 d2)=Kab -> (In C (B2C (K2B (KeyAB d1 d2))) rngDDKKeyABminusKab). Axiom rngDDKKeyABminusKab2: (equivS rngDDKKeyAB (cons C (B2C (K2B Kab)) rngDDKKeyABminusKab)).

Cases introduces a pattern matching construction on the gloabl state st where

si is the last component

and the preceding component sa , sb and ss are not useful thus they are represented by _ and not named. The objective here is to prove formally using Coq that invP is an invariant property. In order to do that we use two intermediate steps which both can be written as invariants. When trying to prove that invP is preserved by all actions we indeed face two problems. First, actions 2b and 4b both send complex data stored in the two elds Ca and Cb of B and we have to prove that the sending of this data does not violate the invariant by providing some useful information for the intruder. In fact this is certainly not the case as the information stored in the two elds Ca and Cb is updated using information that has previous circulated on the communication media due to steps 1 and 3 of the protocol. The rst intermediate invariant exactly expresses this fact. The second problem that we face when trying to prove that invP is preserved on actions 3s and 4b as this is only true if the two keys Kas and Kbs are private. We will thus use the properties as second intermediate invariant. 6.1. First preliminary invariant: The rst invariant will be noted inv0 and is formalized using the following property:

sB :Ca known in si ^ sB :Cb known in si The transposition to Coq is straightforward: Definition inv0 := [st: GlobalState] Cases st of (ABSI _ (MANbKabCaCb _ _ _ _ ca cb) _ si) => (known_in ca si) /\ (known_in cb si) end.

and the preservation of the invariant takes the form: Theorem POinv0: (st1, t2: GlobalState) (inv0 st1) -> (rel st1 st2) -> (inv0 st2).

jar.tex; 20/01/1997; 15:38; no v.; p.13

14 Dominique Bolignano and Valerie Menissier-Morain The proof of the preservation is presented in Appendix C, and ends up quite naturally into one goal for each action. It imposes a requirements on initial conditions: inv0 needs to be veri ed initially by the user of the protocol, which means that the two elds Ca and Cb are initialized with values that satisfy the property. If for example Ca was set to Kas or Kab , the invP property would indeed not hold in a quite obvious manner. 6.2. Second preliminary invariant: The second invariant will be noted inv1 and is formalized using the following property:

:(Kas known in si) ^ :(Kbs known in si) We need, as for the rst preliminary invariant, to reinforce this invariant by adding the set of the keys known by the server rngDDKKeyAB to si . The transposition to Coq is straightforward: Definition inv1 := [st: GlobalState] Cases st of (ABSI _ _ _ s) => ~(known_in (B2C (K2B Kas)) (app C s rngDDKKeyAB)) /\ ~(known_in (B2C (K2B Kbs)) (app C s rngDDKKeyAB)) end.

and the preservation of the invariant takes the form: Theorem POinv1: (st1, st2: GlobalState) (inv0 st1) -> (inv1 st1) -> (rel st1 st2) -> (inv1 st2).

The proof is presented in Appendix D and is similar to the previous one. The auxiliary goals are large enough to be described with auxiliary lemmas to improve clarity. As an example, for the rst action the auxiliary lemma is as follows: Lemma POinv1rel1: (l, l0: SD) (k, k0, k1, k2: K) (c, c0, c1, c2: C) (d, d0, d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, d11, d12, d13, d14, d15, d16, d17, d18, d19, d20: D) (inv0 (ABSI (MBNaKab d7 d8 d9 k0) (MANbKabCaCb d4 d5 d6 k c c0) (MABNaNbKeyK d d0 d1 d2 d3) l)) -> (inv1 (ABSI (MBNaKab d7 d8 d9 k0) (MANbKabCaCb d4 d5 d6 k c c0) (MABNaNbKeyK d d0 d1 d2 d3) l)) -> (rel1 (ABSI (MBNaKab d7 d8 d9 k0) (MANbKabCaCb d4 d5 d6 k c c0) (MABNaNbKeyK d d0 d1 d2 d3) l) (ABSI (MBNaKab d18 d19 d20 k2) (MANbKabCaCb d15 d16 d17 k1 c1 c2) (MABNaNbKeyK d10 d11 d12 d13 d14) l0)) -> (inv1 (ABSI (MBNaKab d18 d19 d20 k2) (MANbKabCaCb d15 d16 d17 k1 c1 c2) (MABNaNbKeyK d10 d11 d12 d13 d14) l0)).

The expansion of any variable of the initial and nal global states (SA ; SB ; SS ; SI ) and of rel produces a large sentence but these lemmas are natural in this proof.

jar.tex; 20/01/1997; 15:38; no v.; p.14

Formal veri cation of cryptographic protocols using Coq

15

The proof of this precise lemma is presented in Appendix E. The proof of all these lemmas has almost the same structure: we rst introduce all the simple variables, then we perform some unfolding on de nitions and elimination on conjunctions, then we possibly clean the useless hypothesis (unfolded conjunctions or hypothesis useful for only some lemmas), we rewrite an equality deduced from rel and then the real work can start. For even relations (rel2, rel4, rel6 and rel8 that corresponds to the reception of messages) this part consists to note that the goal is an hypothesis and the proof is nished. For odd relations, as for rel1, the goal is a cunjunction so we split it into two very similar goals. In the sequel of the proof we avoid to name arguments of lemmas that is it useless to name for their application and thus we can propose the same proof for the two goals. Furthermore the proof of each goal is organised so that it is composed of only one tactical such that we can bene t of the semantic property of ;: t1; t2 applies t2 to each subgoal of t1. Thus we can link Split with a single instance of the proof without any repetition. This proof consists rst to apply the D2 axiom, then unfold the tuple construction and do some simpli cation on the goal. After this, we apply as long as it is possible axioms C 2, C 3 or C 4. The resulting subgoals can have three forms: a negation of an equality of C elements with dierent constructors of inductive types, this subgoal is proved by the Discriminate tactic; a property like not_comp_of c l with known_in c l in the hypothesis, this subgoal is proved by application of axiom D1; a property like not_comp_of c l with known_in c l not in the hypothesis, this subgoal is proved by successive applications of axiom equivncomp de ned as follows: Axiom equivncomp: (c: C) (s1, s2: SD) (equivS s1 s2) -> ((not_comp_of c s1) -> (not_comp_of c s2)).

and prove some equivalence properties. We may need to perform another sequence of application of axioms C 2, C 3 or C 4 and do the same treatment of the subgoals to obtain subgoals only of the rst two types. To conciliate subgoals of dierent types, we use the Orelse combinator of tactics. The scripts of these proofs are very short, sometimes the script of the proof is shorter than the lemma itself! 6.3. Final invariant: The preservation of the invariant takes the form: Theorem POinvP: (st1, st2: GlobalState) (inv0 st1) -> (inv1 st1) -> (invP st1) -> (rel st1 st2) -> (invP st2).

jar.tex; 20/01/1997; 15:38; no v.; p.15

16 Dominique Bolignano and Valerie Menissier-Morain The proof of POinvP is then very similar to the previous proofs and just requires some further constraints on the initial conditions: (x; y) 6= (A; B ) ^ (x; y) 6= (B; A) ) KeyAB (x; y) 6= Kab where KeyAB is the directory of session keys held by the server. The coq proof is as for POinv1 derived from one lemma for each action.

7. Conclusion We have shown how to formally verify authentication protocols based on the approach described in [8] and [7]. The presentation was done using the Otway-Rees protocol. Most of the formalization is not speci c to the particular protocol that was used. This is in particular the case for the modeling of the intruder knowledge, for the way authentication properties, states and operations are expressed. The transposition to another protocol can thus be done in a quite systematic way. For this protocol the proof counts 1100 lines, more precisely the description takes 9 parameters and 35 de nitions precised with 13 axioms and the proof takes 28 lemmas. The Coq formalization of the protocol and the Coq formalization of the authentication properties appeared to be a quite direct applications of the modelization proposed in [7]. Formal proofs, although more tedious than unformal ones could be done in a quite cost-eective way. The formal proof of a new invariant is about a few days work, as it usually requires a few backtracking (e.g. initial invariant too loose or two strong, misprints in invariant expression, or in protocol expression, detection of a real bug,: : : ) in the proof. Paulson has recently been developping in [21] an approach for proving security properties of cryptographic protocols. Although developped independtly Paulson's approach and the approach de ned in [7] which we rely on here use similar ways for the analysis messages that are passed to the intruder. The formalization and veri cation in the case of Paulson's approach is done using the Isabelle/HOL proof tool, and the approach is illustrated using the same protocol but using dierent security properties. Thus Paulson veri cation points out Mao and Boyd's attack which is out of scope in the present illustration (the attack does not violate the con dentiality properties used here). The approach is currently being applied successfully for the veri cation of the C-SET protocol, the smartcard based payment protocol proposed by GIE CB, an organization sponsored and owned by major french banks9 . The formal veri cation has been partially completed, and has allowed to identify signi cant improvements to the protocol in terms of security. More recently the same kind of veri cation has been started for the veri cation of the SET (Secure Electronic Transaction) protocol, proposed recently by Visa and MasterCard. The veri cation activity happens to reuse much from one veri cation to the other and from on protocol to the other. As a result many variants of a given protocol or sets of hypotheses can be analyzed with few additional eort.

Appendix A We now describe a set of properties that allows to derive positive uses of known in. 9

http://www.dyade.fr/actions/VIP/vip.html

jar.tex; 20/01/1997; 15:38; no v.; p.16

Formal veri cation of cryptographic protocols using Coq A1 c known in s ^ c0 known in s ) (c; c0 ) known in s A2 (c; c0 ) known in s ) c known in s ^ c0 known in s A3 c known in s ^ k known in s ) ck known in s A4 ck known in s ^ k 1 known in s ) c known in s A5 s0 known in s ^ s00 known in s ) (s0 [ s00) known in s A6 (s0 [ s00) known in s ) s0 known in s ^ s00known in s A7 s known in s A8 ; known in s B1 (c; c0 ) comp of s ) c comp of s ^ c0comp of s B2 ck comp of s ^ k 1 comp of s ) c comp of s B3 s0 comp of s ^ s00 comp of s ) (s0 [ s00) comp of s B4 (s0 [ s00) comp of s ) s0 comp of s ^ s00comp of s B5 s comp of s B6 ; comp of s C1 :(c comp of s) ^ :(k 1 comp of s) ^ c =6 c0k ) :(c comp of s [ c0k ) C2 :(c comp of s [ c0 ) ^ c =6 c0k ) :(c comp of s [ c0k ) C3 :(c comp of s) ^ c =6 d ) :(c comp of s [ d) C4 :(c comp of s [ c1 [ c2 ) ^ c =6 (c1 ; c2 ) ) :(c comp of s [ (c1 ; c2 )) C5 :(c comp of ;) C6 :(s0 comp of s) _ :(s00 comp of s) ) :(s0 [ s00 comp of s) C7 c 2= s ^ setofkeys(s) ) :(c comp of s) C8 setofkeys(s) ) setofkeys(s [ k) C9 setofkeys(;) D1 :(s0 known in s) ) :(s0 comp of s) D2 :(b comp of s) ) :(b known in s) D3 :(ck comp of s) ^ :(k comp of s) ) :(ck known in s) D4 :(ck comp of s) ^ :(c known in s) ) :(ck known in s) D5 :((c; c0 ) comp of s) ^ (:(c known in s) _ :(c known in s)) ) :((c; c0 ) known in s)

17

jar.tex; 20/01/1997; 15:38; no v.; p.17

18

Dominique Bolignano and Valerie Menissier-Morain

D6 :(s known in s00) _ :(s0 known in s00) ) :(s [ s0 known in s00) E1 s known in s0 ) s known in s0 [ s00 Appendix B Require PolyList. (* De nition of types *)

Parameter N: Set. Inductive K: Set := ka: N > K j ks: N > K. Parameter inv: K > K. Axiom inv ka: (n: N) (inv (inv (ka n)))=(ka n). Axiom inv ks: (n: N) (inv (ks n))=(ks n). Parameter D: Set. Parameters Aid, Bid: D. Axiom D dec: (d1, d2: D) f(d1=Aid=nd2=Bid)g+f~(d1=Aid=nd2=Bid)g. Inductive B: Set := K2B: K > B j D2B: D > B. Inductive C: Set := Encrypt: C > K > C j Pair: C > C > C j B2C: B > C. Syntactic De nition SD := (list C). Syntax constr SPP 4 "SD".

10

20

(* known in and not comp of predicates, equivS equivalence, setofkeys *)

Inductive known in: C > SD > Prop := E0: (c1, c2: C) (s: SD) (known in c1 s) > (known in c1 (cons C c2 s)) j EP0: (c: C) (s1, s2: SD) (known in c s1) > (known in c (app C s1 s2)) j A2A: (c1, c2: C) (s: SD) (known in (Pair c1 c2) s) > (known in c1 s) j A2B: (c1, c2: C) (s: SD) (known in (Pair c1 c2) s) > (known in c2 s). Inductive equivS: SD > SD > Prop := equivS1a: (equivS (nil C) (nil C)) j equivS1b: (s1, s2: SD) (c: C) (equivS s1 s2) > (equivS (cons C c s1) (cons C c s2)) j equivS2: (s: SD) (c1, c2: C) (equivS (cons C c1 (cons C c2 s)) (cons C c2 (cons C c1 s))) j equivS4: (s1, s2, s3: SD) (equivS s1 s2) > (equivS s2 s3) > (equivS s1 s3) j AlreadyIn1: (c1: C) (s: SD) (In C c1 s) > (equivS s (cons C c1 s)) j AlreadyIn1b: (c1: C) (s: SD) (In C c1 s) > (equivS (cons C c1 s) s) j AlreadyIn: (c1: C) (s: SD) (known in c1 s) > (equivS s (cons C c1 s)) j AlreadyInb: (c1: C) (s: SD) (known in c1 s) > (equivS (cons C c1 s) s). Hint equivS1a equivS1b equivS2 equivS4

30

40

jar.tex; 20/01/1997; 15:38; no v.; p.18

Formal veri cation of cryptographic protocols using Coq

19

AlreadyIn1 AlreadyIn1b AlreadyIn AlreadyInb.

Lemma equivS1: (s: SD) (equivS s s). Proof. Induction s; Auto. Qed. Lemma equivS3: (s1, s2: SD) (equivS s1 s2) > (equivS s2 s1). Proof. Intros s1 s2 equiv; Elim equiv; EAuto. Qed. Lemma equivS5: (c: C) (s1, s2, s3: SD) (In C c s2) > (equivS s2 (cons C c s3)) >

50

60

(equivS (cons C c (app C s1 s2)) (cons C c (app C s1 s3))).

Proof. Intros. Elim s1; Simpl. Apply equivS4 with s2:= s2. Apply AlreadyIn1b; Auto. Auto. Intros. Apply equivS4 with s2:=(cons C a (cons C c (app C l s2))). Apply equivS2. Apply equivS4 with s2:=(cons C a (cons C c (app C l s3))). Apply equivS1b; Auto. Apply equivS2. Qed. Lemma equivS6: (c: C) (s1, s2: SD) (equivS (cons C c (app C s1 s2)) (app C s1 (cons C c s2))). Proof. Induction s1; Simpl; Intros. Apply equivS1. Apply equivS4 with (cons C a (cons C c (app C l s2))). Apply equivS4 with (cons C c (cons C a (app C l s2))). Apply equivS1. Apply equivS2. Apply equivS1b. Apply (H s2). Qed. Lemma equivS7: (s, s1, s2: SD) (equivS s1 s2) > (equivS (app C s1 s) (app C s2 s)). Proof. Induction s. Intros. Elim app nil end. Elim app nil end. Assumption. Intros.

70

80

90

jar.tex; 20/01/1997; 15:38; no v.; p.19

20

Dominique Bolignano and Valerie Menissier-Morain

Apply equivS4 with (cons C a (app C s1 l)). Apply equivS3. Apply equivS6. Apply equivS4 with (cons C a (app C s2 l)). Apply equivS1b. Apply (H s1 s2 H0). Apply equivS6. Qed. Lemma equivS8: (s1, s2: SD) (equivS (app C s1 s2) (app C s2 s1)). Proof. Induction s1; Induction s2; Simpl. Auto. Intros. Apply equivS1b. Assumption. Apply equivS1b. Elim app nil end. Apply equivS1. Intros. Apply equivS4 with (cons C a (cons C a0 (app C l l0))). Apply equivS1b. Apply equivS3. Apply equivS6. Apply equivS4 with (cons C a0 (cons C a (app C l l0))). Apply equivS2. Apply equivS1b. Assumption. Qed. Lemma equivS9: (s: SD) (equivS s (app C s s)). Proof. Induction s; Simpl. Auto. Intros. Apply equivS4 with (cons C a (cons C a (app C l l))). Apply equivS4 with (cons C a (app C l l)). Apply equivS1b; Auto. Apply AlreadyIn1. Apply in eq. Apply equivS1b. Apply equivS6. Qed. Fixpoint setofkeys [s: SD]: Prop := Cases s of nil => True j (cons (B2C (K2B )) s1) => (setofkeys s1) j => False end. Inductive not comp of: C > SD > Prop:=

100

110

120

130

140

150

jar.tex; 20/01/1997; 15:38; no v.; p.20

Formal veri cation of cryptographic protocols using Coq C1: (c1, c2: C) (k: K) (s: SD) (not comp of c1 s) > (not comp of (B2C (K2B (inv k))) s) > ~(c1=(Encrypt c2 k)) > (not comp of c1 (cons C (Encrypt c2 k) s)) j C2: (c1, c2: C) (k: K) (s: SD) (not comp of c1 (cons C c2 s)) > ~(c1=(Encrypt c2 k)) > (not comp of c1 (cons C (Encrypt c2 k) s)) j C3: (c1: C) (d: D) (s: SD) (not comp of c1 s) > ~(c1=(B2C (D2B d))) > (not comp of c1 (cons C (B2C (D2B d)) s)) j C4: (c1, c2, c3: C) (s: SD) (not comp of c1 (cons C c2 (cons C c3 s))) > ~(c1=(Pair c2 c3)) > (not comp of c1 (cons C (Pair c2 c3) s)) j D1: (c1: C) (s: SD) ~(known in c1 s) > (not comp of c1 s).

Axiom D2: (b: B) (s: SD) (not comp of (B2C b) s) > ~(known in (B2C b) s). Axiom EP1: (c: C) (s1, s2: SD) ~(known in c (app C s1 s2)) > ~(known in c s1). Axiom equivknown: (c: C) (s1, s2: SD) (equivS s1 s2) > ((known in c s1) > (known in c s2)). Axiom equivncomp: (c: C) (s1, s2: SD) (equivS s1 s2) > ((not comp of c s1) > (not comp of c s2)). Lemma equivnknown1: (c: C) (s1, s2: SD) (equivS s1 s2) > (~(known in c s1) > ~(known in c s2)). Proof. Intros; Unfold not; Intros. Apply H0. Apply (equivknown c s2 s1). Elim H; Simpl; EAuto. Exact H1. Qed. (* Keys *)

Parameters KeyAB: D > D > K. Parameters KeyX: D > K. Parameter rngDDKKeyAB: SD. Parameter rngDDKKeyABminusKab: SD. Syntactic De nition Kab := (KeyAB Aid Bid). Syntax constr KabPP 4 "Kab". Syntactic De nition Kas := (KeyX Aid). Syntax constr KasPP 4 "Kas". Axiom Kas symmetric: (inv Kas)=Kas. Syntactic De nition Kbs := (KeyX Bid). Syntax constr KbsPP 4 "Kbs". Axiom Kbs symmetric: (inv Kbs)=Kbs. Axiom KeyAB1: (d1, d2: D) ~(d1=Aid=nd2=Bid) > ~(KeyAB d1 d2)=Kab.

21

160

170

180

190

200

jar.tex; 20/01/1997; 15:38; no v.; p.21

22

Dominique Bolignano and Valerie Menissier-Morain

Axiom rngDDKKeyAB1: (d1, d2: D) (In C (B2C (K2B (KeyAB d1 d2))) rngDDKKeyAB). Axiom rngDDKKeyABminusKab1: 210 (d1, d2: D) ~(KeyAB d1 d2)=Kab > (In C (B2C (K2B (KeyAB d1 d2))) rngDDKKeyABminusKab). Axiom rngDDKKeyABminusKab2: (equivS rngDDKKeyAB (cons C (B2C (K2B Kab)) rngDDKKeyABminusKab)). Lemma rngs: (equivS rngDDKKeyAB (app C rngDDKKeyABminusKab rngDDKKeyAB)). Proof. Apply equivS4 with (cons C (B2C (K2B Kab)) rngDDKKeyABminusKab). Exact rngDDKKeyABminusKab2. Apply equivS4 with (app C rngDDKKeyAB rngDDKKeyABminusKab). 220 Apply equivS4 with (app C (cons C (B2C (K2B Kab)) rngDDKKeyABminusKab) rngDDKKeyABminusKab). Elim app comm cons. Apply equivS1b. Apply equivS9. Apply equivS7. Apply equivS3. Exact rngDDKKeyABminusKab2. Apply equivS8. Qed. (* De nition of GlobalState *) De nition triple := [c1, c2, c3: C] (Pair c1 (Pair c2 c3)). De nition quad := [c1, c2, c3, c4: C] (Pair c1 (Pair c2 (Pair c3 c4))). De nition quint := [c1, c2, c3, c4, c5: C] (Pair c1 (Pair c2 (Pair c3 (Pair c4 c5)))).

De nition new := [n: D] [s: SD] (s2: SD) (setofkeys s2) > ~(known in (B2C (D2B n)) (app C s s2)). Inductive AState: Set := MBNaKab: D > D > D > K > AState. Inductive BState: Set := MANbKabCaCb: D > D > D > K > C > C > BState. Inductive SState: Set := MABNaNbKeyK: D > D > D > D > D > SState. Inductive GlobalState: Set := ABSI: AState > BState > SState > SD > GlobalState.

230

240

250

(* De nition of the invariant properties *)

De nition inv0 := [st: GlobalState] Cases st of ca cb) s) => (ABSI (MANbKabCaCb (known in ca s) =n (known in cb s) end. De nition inv1 := [st: GlobalState] Cases st of

260

jar.tex; 20/01/1997; 15:38; no v.; p.22

Formal veri cation of cryptographic protocols using Coq

23

(ABSI s) => ~(known in (B2C (K2B Kas)) (app C s rngDDKKeyAB)) =n ~(known in (B2C (K2B Kbs)) (app C s rngDDKKeyAB)) end.

De nition invP := [st: GlobalState] Cases st of (ABSI s) => ~(known in (B2C (K2B Kab)) (app C s rngDDKKeyABminusKab)) end.

270

(* De nition of rel *)

De nition rel1 := [st1, st2: GlobalState] Cases st1 st2 of (ABSI sta1 stb1 sts1 s1) (ABSI sta2 stb2 sts2 s2) => Cases sta1 sta2 of (MBNaKab na1 kab1) (MBNaKab m2 b2 na2 kab2) => s2=(cons C (quad (B2C (D2B m2)) (B2C (D2B Aid)) (B2C (D2B b2)) (Encrypt (quad (B2C (D2B na2)) (B2C (D2B m2)) (B2C (D2B Aid)) (B2C (D2B b2))) Kas)) s1) =n (new na2 s1) =n (new m2 s1) =n stb1 = stb2 =n sts1 = sts2 =n na1 = na2 =n kab1 = kab2

end end. De nition rel2 := [st1, st2: GlobalState] Cases st1 st2 of (ABSI sta1 stb1 sts1 s1) (ABSI sta2 stb2 sts2 s2) => Cases stb1 stb2 of (MANbKabCaCb nb1 kab1 cb1) (MANbKabCaCb m2 a2 nb2 kab2 ca2 cb2) => (known in (quad (B2C (D2B m2)) (B2C (D2B a2)) (B2C (D2B Bid)) ca2) s1) =n sta1 = sta2 =n sts1 = sts2 =n s1=s2 =n nb1 = nb2 =n kab1 = kab2 =n cb1 = cb2 end end. De nition rel3 := [st1, st2: GlobalState] Cases st1 st2 of (ABSI sta1 stb1 sts1 s1) (ABSI sta2 stb2 sts2 s2) => Cases stb1 stb2 of (MANbKabCaCb m1 a1 nb1 kab1 ca1 cb1) (MANbKabCaCb m2 a2 nb2 kab2 ca2 cb2) => s2=(cons C (quint (B2C (D2B m1)) (B2C (D2B a1)) (B2C (D2B Bid)) ca1 (Encrypt (quad (B2C (D2B nb2)) (B2C (D2B m1)) (B2C (D2B a2)) (B2C (D2B Bid))) Kbs)) s1) =n (new nb2 s1) =n sta1 = sta2 =n sts1 = sts2 =n m1 = m2 =n a1 = a2 =n kab1 = kab2 =n ca1 = ca2 =n cb1 = cb2

end end. De nition rel4 := [st1, st2: GlobalState] Cases st1 st2 of (ABSI sta1 stb1 s1) (ABSI sta2 stb2 sts2 s2) => Cases sts2 of (MABNaNbKeyK m2 a2 b2 na2 nb2) =>

280

290

300

310

(known in (quint (B2C (D2B m2)) (B2C (D2B a2)) (B2C (D2B b2)) (Encrypt (quad (B2C (D2B na2)) (B2C (D2B m2)) (B2C (D2B a2)) (B2C (D2B b2)))

jar.tex; 20/01/1997; 15:38; no v.; p.23

24

Dominique Bolignano and Valerie Menissier-Morain

(KeyX a2)) (Encrypt (quad (B2C (D2B nb2)) (B2C (D2B m2)) (B2C (D2B a2)) (B2C (D2B b2))) (KeyX b2)))

s1) =n sta1 = sta2 =n stb1 = stb2 =n s1 = s2

320

end end. De nition rel5 := [st1, st2: GlobalState] Cases st1 st2 of (ABSI sta1 stb1 sts1 s1) (ABSI sta2 stb2 sts2 s2) => Cases sts1 of (MABNaNbKeyK m1 a1 b1 na1 nb1) => s2=(cons C (triple (B2C (D2B m1)) (Encrypt (Pair (B2C (D2B na1)) (B2C (K2B (KeyAB a1 b1)))) (KeyX a1)) (Encrypt (Pair (B2C (D2B nb1)) (B2C (K2B (KeyAB a1 b1)))) (KeyX b1))) s1) =n sta1 = sta2 =n stb1 = stb2 =n sts1 = sts2

330

end end. De nition rel6 := [st1, st2: GlobalState] Cases st1 st2 of (ABSI sta1 stb1 sts1 s1) (ABSI sta2 stb2 sts2 s2) => Cases stb1 stb2 of (MANbKabCaCb m1 a1 nb1 ca1 ) (MANbKabCaCb m2 a2 nb2 kab2 ca2 cb2) =>

340

(known in (triple (B2C (D2B m1)) cb2 (Encrypt (Pair (B2C (D2B nb1)) (B2C (K2B kab2))) Kbs)) s1) =n sta1 = sta2 =n sts1 = sts2 =n s1=s2 =n m1 = m2 =n a1 = a2 =n nb1 = nb2 =n ca1 = ca2

end end. De nition rel7 := [st1, st2: GlobalState] Cases st1 st2 of (ABSI sta1 stb1 sts1 s1) (ABSI sta2 stb2 sts2 s2) => Cases stb1 of (MANbKabCaCb m1 cb1) => s2 = (cons C (Pair (B2C (D2B m1)) cb1) s1) =n sta1 = sta2 =n stb1 = stb2 =n sts1 = sts2 end end. De nition rel8 := [st1, st2: GlobalState] Cases st1 st2 of (ABSI sta1 stb1 sts1 s1) (ABSI sta2 stb2 sts2 s2) => Cases sta1 sta2 of (MBNaKab m1 b1 na1 ) (MBNaKab m2 b2 na2 kab2) =>

350

360

(known in (Pair (B2C (D2B m1)) (Encrypt (Pair (B2C (D2B na1)) (B2C (K2B kab2))) Kas)) s1) =n stb1 = stb2 =n sts1 = sts2 =n s1 = s2 =n m1 = m2 =n b1 = b2 =n na1 = na2

end end.

jar.tex; 20/01/1997; 15:38; no v.; p.24

Formal veri cation of cryptographic protocols using Coq

25 370

De nition rel := [st1, st2: GlobalState] (rel1 st1 st2) n= (rel2 st1 st2) n= (rel3 st1 st2) n= (rel4 st1 st2) n= (rel5 st1 st2) n= (rel6 st1 st2) n= (rel7 st1 st2) n= (rel8 st1 st2).

Appendix C Require securite. Theorem POinv0: (st1, st2: GlobalState) (inv0 st1) > (rel st1 st2) > (inv0 st2). Proof. Induction st1; Intros a b s l; Elim a; Elim b; Elim s. Induction st2; Intros a0 b0 s0 l0; Elim a0; Elim b0; Elim s0. Do 15 Intro. Unfold inv0; Unfold rel; Intros know c c0 l rel1 8.

10

(* rel1 *)

Elim rel1 8. Intros r1. Elim r1; Intros eq l0 and1; Elim and1; Intros t1 and2; Elim and2; Intros t2 and3; Elim and3; Intros i c1 c2 t3. Clear rel1 8 r1 and1 and2 and3 t1 t2 t3. Inversion i c1 c2; Elim H4; Elim H5; Rewrite eq l0. Split; Apply E0; Elim know c c0 l; Intros; Assumption. (* rel2 *)

20 Intro rel2 8; Elim rel2 8. Intros r2. Elim r2; Unfold quad; Intros know c1 l and1; Elim and1; Intros t1 and2; Elim and2; Intros t2 and3; Elim and3; Intros eq l0 and4; Elim and4; Intros t3 and5; Elim and5; Intros t4 eq c2. Clear rel1 8 rel2 8 r2 and1 and2 and3 and4 and5 t1 t2 t3 t4. Elim eq l0; Elim eq c2. Split. Apply (A2B (B2C (D2B Bid)) c1 l (A2B (B2C (D2B d16)) (Pair (B2C (D2B Bid)) c1) l (A2B (B2C (D2B d15)) (Pair (B2C (D2B d16)) (Pair (B2C (D2B Bid)) c1)) l know c1 l))). Elim know c c0 l; Intros; Assumption. 30

(* rel3 *) Intros rel3 8; Elim rel3 8. Intros r3. Elim r3; Intros eq l0 and1; Elim and1; Intros t1 and2; Elim and2; Intros t2 and3; Elim and3; Intros t3 and4; Elim and4; Intros t4 and5; Elim and5; Intros t5 and6; Elim and6; Intros t6 and7; Elim and7; Intros eq c1 eq c2. Clear rel1 8 rel2 8 rel3 8 r3 and1 and2 and3 and4 and5 and6 and7 t1 t2 t3 t4 t5 t6. Elim eq c1; Elim eq c2; Rewrite eq l0. Split; Apply E0; Elim know c c0 l; Intros; Assumption. (* rel4 *)

Intros rel4 8; Elim rel4 8. Intros r4. Elim r4; Intros t1 and1; Elim and1; Intros t2 and2; Elim and2; Intros i c1 c2 eq l0. Clear rel1 8 rel2 8 rel3 8 rel4 8 r4 and1 and2 t1 t2. Inversion i c1 c2; Elim H4; Elim H5; Elim eq l0; Assumption.

40

(* rel5 *)

jar.tex; 20/01/1997; 15:38; no v.; p.25

26

Dominique Bolignano and Valerie Menissier-Morain

Intros rel5 8; Elim rel5 8. Intros r5. Elim r5; Intros eq l0 and1; Elim and1; Intros t1 and2; Elim and2; Intros i c1 c2 t2. Clear rel1 8 rel2 8 rel3 8 rel4 8 rel5 8 r5 and1 and2 t1 t2. Inversion i c1 c2; Elim H4; Elim H5; Rewrite eq l0. Split; Apply E0; Elim know c c0 l; Intros; Assumption.

50

(* rel6 *)

Intros rel6 8; Elim rel6 8. Intros r6. Elim r6; Unfold triple; Intros know c2 l and1; Elim and1; Intros t1 and2; Elim and2; Intros t2 and3; Elim and3; Intros eq l0 and4; Elim and4; Intros t3 and5; Elim and5; Intros t4 and6; Elim and6; Intros t5 eq c1. Clear rel1 8 rel2 8 rel3 8 rel4 8 rel5 8 rel6 8 r6 and1 and2 and3 and4 and5 and6 t1 t2 t3 t4 t5. Elim eq c1; Elim eq l0. Split. Elim know c c0 l; Intros; Assumption. Apply (A2A c2 (Encrypt (Pair (B2C (D2B d6)) (B2C (K2B k1))) Kbs) l (A2B (B2C (D2B d4)) 60 (Pair c2 (Encrypt (Pair (B2C (D2B d6)) (B2C (K2B k1))) Kbs)) l know c2 l)).

(* rel7 *)

Intros rel7 8; Elim rel7 8. Intros r7. Elim r7; Intros eq l0 and1; Elim and1; Intros t1 and2; Elim and2; Intros i c1 c2 t2. Clear rel1 8 rel2 8 rel3 8 rel4 8 rel5 8 rel6 8 rel7 8 r7 and1 and2 t1 t2. Inversion i c1 c2; Elim H4; Elim H5; Rewrite eq l0. Split; Apply E0; Elim know c c0 l; Intros; Assumption. (* rel8 *)

70

Intros r8. Elim r8; Intros t1 and1; Elim and1; Intros i c1 c2 and2; Elim and2; Intros t2 and3; Elim and3; Intros eq l0 t3. Clear rel1 8 rel2 8 rel3 8 rel4 8 rel5 8 rel6 8 rel7 8 r8 and1 and2 and3 t1 t2 t3. Inversion i c1 c2; Elim H4; Elim H5; Elim eq l0; Assumption. Qed.

Appendix D

Require inv1rel1. Require inv1rel2. Require inv1rel3. Require inv1rel4. Require inv1rel5. Require inv1rel6. Require inv1rel7. Require inv1rel8. Theorem POinv1: (st1:GlobalState)(st2:GlobalState) (inv0 st1) > (inv1 st1) > (rel st1 st2) > (inv1 st2). Proof. Induction st1; Intros a b s l; Elim a; Elim b; Elim s. Induction st2; Intros a0 b0 s0 l0; Elim a0; Elim b0; Elim s0. Do 15 Intro. Unfold rel; Intros Inv0 Inv1. Intros Rel1 8. Elim Rel1 8; Clear Rel1 8. Exact (POinv1rel1 l l0 k k0 k1 k2 c c0 c1 c2

10

d d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d17 d18 d19 d20 Inv0 Inv1).

20

jar.tex; 20/01/1997; 15:38; no v.; p.26

Formal veri cation of cryptographic protocols using Coq

27

Intros Rel2 8. Elim Rel2 8; Clear Rel2 8. Exact (POinv1rel2 l l0 k k0 k1 k2 c c0 c1 c2

d d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d17 d18 d19 d20 Inv0 Inv1).

Intros Rel3 8. Elim Rel3 8; Clear Rel3 8. Exact (POinv1rel3 l l0 k k0 k1 k2 c c0 c1 c2

d d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d17 d18 d19 d20 Inv0 Inv1).

Intros Rel4 8. Elim Rel4 8; Clear Rel4 8. Exact (POinv1rel4 l l0 k k0 k1 k2 c c0 c1 c2

30

d d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d17 d18 d19 d20 Inv0 Inv1).

Intros Rel5 8. Elim Rel5 8; Clear Rel5 8. Exact (POinv1rel5 l l0 k k0 k1 k2 c c0 c1 c2

d d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d17 d18 d19 d20 Inv0 Inv1).

Intros Rel6 8. Elim Rel6 8; Clear Rel6 8. Exact (POinv1rel6 l l0 k k0 k1 k2 c c0 c1 c2

d d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d17 d18 d19 d20 Inv0 Inv1).

40

Intros Rel7 8. Elim Rel7 8; Clear Rel7 8. Exact (POinv1rel7 l l0 k k0 k1 k2 c c0 c1 c2

d d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d17 d18 d19 d20 Inv0 Inv1).

Exact (POinv1rel8 l l0 k k0 k1 k2 c c0 c1 c2

d d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d17 d18 d19 d20 Inv0 Inv1).

Qed.

50

Appendix E

Require securite. Lemma POinv1rel1: (l, l0: SD) (k, k0, k1, k2: K) (c, c0, c1, c2: C)

(d, d0, d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, d11, d12, d13, d14, d15, d16, d17, d18, d19, d20: D) (inv0 (ABSI (MBNaKab d7 d8 d9 k0) (MANbKabCaCb d4 d5 d6 k c c0) (MABNaNbKeyK d d0 d1 d2 d3) l)) > (inv1 (ABSI (MBNaKab d7 d8 d9 k0) (MANbKabCaCb d4 d5 d6 k c c0) (MABNaNbKeyK d d0 d1 d2 d3) l)) > (rel1 (ABSI (MBNaKab d7 d8 d9 k0) (MANbKabCaCb d4 d5 d6 k c c0) (MABNaNbKeyK d d0 d1 d2 d3) l) (ABSI (MBNaKab d18 d19 d20 k2) (MANbKabCaCb d15 d16 d17 k1 c1 c2) (MABNaNbKeyK d10 d11 d12 d13 d14) l0)) > (inv1 (ABSI (MBNaKab d18 d19 d20 k2) (MANbKabCaCb d15 d16 d17 k1 c1 c2) (MABNaNbKeyK d10 d11 d12 d13 d14) l0)).

10

20

Proof. Do 32 Intro; Intros Inv0;

jar.tex; 20/01/1997; 15:38; no v.; p.27

28

Dominique Bolignano and Valerie Menissier-Morain

Unfold inv1; Unfold rel1; Intro known Kas Kbs; Elim known Kas Kbs; Intros known Kas known Kbs; Intros and1; Elim and1; Intros eq l0 t1; Clear Inv0 known Kas Kbs and1 t1; Split; Apply D2; Rewrite eq l0; Unfold quad; Simpl; Repeat Apply C2 Orelse Apply C3 Orelse Apply C4; Repeat (Apply D1; Assumption) Orelse Discriminate. Qed.

30

References

1. M. Abadi and M. Tuttle. A semantic for a logic of authentication. In Proceedings of the 10th ACM Symposium on Principles of Distributed Computing, 1991. 2. J.R. Abrial. The B-method for large software speci cation, design and coding. In VDM'91. Springer Verlag, 1991. 3. J.P. Ban^atre and D. LeMetayer. Programming by multiset transformation. Technical Report 117, IRISA Rennes, March 1990. 4. Bruno Barras, Samuel Boutin, Cristina Cornes, Judicael Courant, Jean-Christophe Filli^atre, Eduardo Gimenez, Hugo Herbelin, Gerard Huet, Pascal Manoury, Cesar Mu~noz, Chetan Murthy, Catherine Parent, Christine Paulin-Mohring, Amokrane Sabi, and Benjamin Werner. The Coq Proof Assistant Reference Manual, version 6.1. Projet Coq, INRIARocquencourt and CNRS-Ens Lyon, December 1996.  emiques des Protocoles Cryptographiques. PhD thesis, Universite Paul Sabatier de Toulouse, 5. P. Bieber. Aspects Epist 1990. 6. P. Bieber and N. Boulahia-Cuppens. Formal development of authentication protocols. In BCS-FACS sixth Re nement Workshop, 1994. 7. D. Bolignano. Formal veri cation of cryptographic protocols. In Proceedings of the third ACM Conference on Computer and Communication Security, 1996. 8. D. Bolignano. Un approche a la veri cation formelle des protocoles cryptographiques. Technique et science informatique, 1996. 9. M. Burrows, M. Abadi, and R. Needham. A logic of authentication. ACM Transactions on Computer Systems, 8, 1990. 10. K.M. Chandy and J. Misra. Parallel Program Design: A Foundation. Addison Wesley, Reading, M.A., 1988. 11. P.C. Chen and V.D. Gligor. On the formal speci cation and veri cation of a multiparty session protocol. In Proceedings of the IEEE Symposium on Research in Security and Privacy, 1990. 12. R.C. Hauser and E.S. Lee. Veri cation and modelling of authenti cation protocols. In Proceedings of the Computer Security ESORICS'92, 1992. 13. R.A. Kemmerer. Analyzing encryption protocols using formal veri cation techniques. In IEEE Journal on Selected Areas in Communications, volume 7(4), 1989. 14. G. Leduc, O. Bonaventure, E. Koerner, L. Leonard, C. Pecheur, and D. Zanetti. Speci cation and veri cation of a TTP protocol for the conditional access to services. In Proceedings of the 12th Workshop on the Application of Formal Methods to System Development (Univ Montreal), 1996. 15. A. Liebl. Authenti cation in distributed systems: A bibliography. In Operating System Review, ACM, vol. 27, 1993. 16. G. Lowe. An attack on the Needham-Schroeder public-key protocol. In Information Processing Letters, 1995. 17. C. Meadows. Using narrowing in the analysis of key management. In Proceedings of the IEEE Symposium on Research in Security and Privacy, 1989. 18. C. Meadows. Representing partial knowledge in an algebraic security model. In Proceedings of the Computer Security Foundations Workshop, IEEE, 1990. 19. C. Meadows. A system for the analysis of a key management protocol. In Proceedings of the IEEE Symposium on Research in Security and Privacy, 1991. 20. C. Meadows. Applying formal methods to the analysis of a key management protocol. In Journal of Computer Security, 1992. 21. Lawrence C. Paulson. Proving properties of security protocols by induction. Technical report, University of Cambridge, november 1996. 22. E. Snekkenes. Roles in cryptographic protocols. In Proceedings of the IEEE Symposium on Research in Security and Privacy, pages 105{119. IEEE, 1992.

jar.tex; 20/01/1997; 15:38; no v.; p.28