A HOL Extension of GNY for Automatically Analyzing. Cryptographic Protocols. Stephen H. Brackin ESC/ENS

Transcription

1 A HOL Extension of GNY for Automatically Analyzing Cryptographic Protocols Stephen H. Brackin Arca Systems, Inc. ESC/ENS Hanscom AFB, MA Abstract This paper describes a Higher Order Logic (HOL) theory formalizing an extended version of the Gong, Needham, Yahalom (GNY) belief logic, a theory used by software that automatically proves authentication properties of cryptographic protocols. The theory's extensions to the GNY logic include being able to specify protocol properties at intermediate stages and being able to specify protocols that use multiple encryption and hash operations, message authentication codes, computed values (e.g., hash codes) as keys, and keyexchange algorithms. 1. Introduction Cryptographic protocols are short sequences of message exchanges, usually involving encryption, intended to establish secure communication over insecure networks. Whether they actually do so, or can be subverted by attacks involving modied, replayed, or mislabeled messages, is a notoriously dicult problem. There have been several examples [11, 27, 28] of published protocols, recommended by experts, that were vulnerable to attack. Moore [26] introduced the concept of \protocol failure" as opposed to encryption weakness. The basic issues are authentication (i.e., whether participants know who they are communicating with), and security (i.e., whether information is revealed to those not meant to receive it). Researchers have developed several dierent means for detecting protocol failure. Current approaches fall The author wishes to thank Shiu-Kai Chin, Grace Hammonds, Randy Lichota, and Jack Wool for their assistance. This work was supported by Air Force Materiel Command's Electronic Systems Center/Software Center (ESC/ENS), Hanscom AFB, through the Portable, Reusable, Integrated Software Modules (PRISM) contract. into two classes: attempting to construct possible attacks, using algebraic properties of the algorithms in the protocols; and attempting to construct inferences, using specialized logics based on a notion of \belief", that protocol participants can condently reach desired conclusions. Attack-construction tools, following work by Dolev and Yao [12], include Millen's Interrogator [23, 25, 24] and Meadows' NRL Protocol Analyzer [19, 20, 21]. These tools address both authentication and security, and do not depend on the validity of a specialized logic. They suer from a combinatorial explosion in the number of possibilities they must consider, though, and require that the user specify the protocols and their desired properties in unintuitive, tool-specic terms. Inference-construction approaches, following work by Burrows, Abadi, and Needham [9], include the belief logics developed by Abadi and Tuttle (AT)[1], by Gong, Needham, and Yahalom (GNY) [14, 13], and by Syverson and van Oorschot (SvO) [35]. Using these logics does not produce a combinatorial explosion, and specifying protocols and their desired properties is intuitive. These logics do not address security, though; the SvO logic does not even identify the data sent in messages, abstracting away all but the information this data is intended to convey to its intended recipients. The work presented here is a belief logic derived from the GNY logic, but extending the GNY logic in several ways: It includes explicit conjunction and pairing operations. It allows specifying desired protocol properties at intermediate protocol stages. It allows using multiple symmetric- and public-key encryption functions, and multiple hash functions. It allows using message authentication codes (i.e., key-dependent hash functions).

2 It allows using arbitrary computed values, such as hash codes, as keys. It allows using key-exchange algorithms that construct keys from a public key, a private key, and any additional information. It also is more careful about basic concepts such as \believes", \conveyed" and \recognizes", is more restrictive in some of its inferences, and corrects errors in the GNY logic. Like the GNY logic, the logic presented here addresses only authentication, but Section 6 comments on how its ability to handle intermediate stages might be used to allow it to handle security as well. Section 6 also comments on how it might be used in conjunction with attack-construction protocol analysis tools. The logic presented here is implemented as a Higher Order Logic (HOL) [15] theory named protocol. This has several important benets: In HOL, for the HOL90.7 implementation used by protocol, theorems are identied by type checking in a Standard ML (SML) compiler [31]. The correctness of theorems proved by software using the standard HOL theorem-proving tools thus does not depend on the correctness of that software; it depends only on the correctness of the HOL tools and the SML compiler, which have been used and analyzed extensively. The HOL object language is capable of expressing abstractions at any level, so it is capable of stating general rules that apply to arbitrary families of functions and relations having arbitrary types. SML is a general-purpose programming language with Lisp-level expressive power and better than Ada-level error protection; its expressive power makes it easy to write specialized proof functions, and its strong type checking makes the compiler detect most bugs immediately. The collection of standard HOL theorem-proving tools is large, powerful, and exible. HOL and SML are well documented, have a large and active user community, are available without restrictions, and are free. One could, of course, write an automatic prover for a GNY-style logic in any general-purpose programming language, such as C, but the coding would take months, the debugging would take months, the nal program would be huge, and in the end one would have no assurance that the statements the program identied as theorems were really theorems. In HOL, it is only possible to produce false \theorems" by having false axioms or by calling mk_thm, a function that forces any sequent to be regarded as a theorem. Theory protocol does not contain any axioms, and the proof software used with protocol does not make any calls to mk_thm. Rather than introduce axioms analogous to the rules in the GNY logic, protocol denes a relation BGNY that maps objects regarded as statements to truth values; the rules dening BGNY are analogous to the rules in the GNY logic. The HOL inductive denitions package [10] proves that the relation BGNY exists but what, if anything, BGNY's having value \true" on a particular statement means is open to argument, as is any other inference based on a belief logic. Using relation-dening rules rather than axioms does not resolve the basic issue of what GNY-based proofs actually show, but it does limit the damage that can be caused by incorrect rules, causing them at worst to dene a relation that does not have desired properties, not to enable the proof of arbitrary false results. Using the HOL inductive denitions package also has the practical benet of having this package perform mechanical consistency checks on all the rules, which the author found to reveal several errors. The author has incorporated the theory protocol into software that does the following: Inputs specications of protocols and their desired properties in a simple Interface Specication Language (ISL), and produces HOL theories, having protocol as their parent, of the protocols and their desired properties. Proves, if possible, by induction on protocol stage, default protocol properties that typically have user-specied properties as easy consequences. Proves, if possible, by induction on protocol stage, user-specied properties of the protocol, up to the rst failure to prove such a property. Produces output les, determined by whether a failure to prove a user-specied property occurs and by a user-set environment variable, that contain ISL descriptions of what results were proved, what default properties were not proved, and exactly what went wrong in the attempts to prove each of the failed default properties. The default properties proved include, for each message sent, that the sender is able to send the message, the receiver is able to decrypt any encrypted submessages, the receiver has adequate reason to believe each submessage originated with its true source, and the receiver has adequate reason to believe each statement

3 that the protocol assumes a submessage's originator must have had adequate reason to believe or else that originator would not have released that submessage. As an example of what this software can do, it automatically proves all the goals in the following ISL specication of the SPX Credentials Initialization protocol [36], on a SPARC 1+ with 32 megs of RAM, in seconds; it is about 4 times faster on a SPARC 10 with 64 megs of RAM. In this specication, the From construct assigns a putative source to encrypted or hashed initial-conditions data, a source the proof process uses in directing its eorts. The construct binds a statement to data that the protocol assumes will not be sent unless the sender has adequate reason to believe that the statement is true. The term {x}f(k) denotes the encryption of x with encryption function f and key k. The term [x](f,h)(k) denotes x signed with a hash of x produced with hash function h and encrypted with encryption function f and key k. The other constructs in this specication are intuitive and discussed in Section 4 below; see [6] for a formal denition of ISL. DEFINITIONS: PRINCIPALS: C,Ca,Cdc,Leaf; PUBLIC KEYS: KpC,KpCa,KpLeaf; PRIVATE KEYS: KsC,KsCa,KsLeaf; SYMMETRIC KEYS: Rn; OTHER: ChannelIdC,PwdC,UidC,ValidityKpCa,Ts; ENCRYPT FUNCTIONS: Des,Rsa; HASH FUNCTIONS: H1,H2,H3; Des WITH ANYKEY HASINVERSE Des WITH ANYKEY; Rsa WITH KsC HASINVERSE Rsa WITH KpC; Rsa WITH KpLeaf HASINVERSE Rsa WITH KsLeaf; INITIALCONDITIONS: C Received Des,H1,H2,H3,Rsa,C,PwdC,Ts,KpLeaf,Rn; C Believes (Fresh PwdC; Fresh ValidityKpCa; PublicKey Leaf Rsa KpLeaf; C Recognizes C; SharedSecret C C H2(PwdC) From C; Trustworthy C); Cdc Received Rsa,UidC,KpLeaf,H1(PwdC) From C, [C,Ca,ValidityKpCa,KpCa](H3,Rsa)(KsC) (PublicKey Ca Rsa KpCa) From C, {C,KpC,KsC}Des(H2(PwdC)) (PublicKey C Rsa KpC; PrivateKey C Rsa KsC) From C; Leaf Received Des,Rsa,KsLeaf; PROTOCOL: 1. C -> Leaf: {C,Ts,Rn,H1(PwdC)}Rsa(KpLeaf); 2. Leaf -> Cdc: C; 3. Cdc -> Leaf: {UidC, H1(PwdC), {C,KpC,KsC}Des(H2(PwdC)) (PublicKey C Rsa KpC; PrivateKey C Rsa KsC)}Rsa(KpLeaf); 4. Leaf -> C: {UidC, {C,KpC,KsC}Des(H2(PwdC)) (PublicKey C Rsa KpC; PrivateKey C Rsa KsC)}Des(Rn); 5. C -> Cdc: C; 6. Cdc -> C: [C,Ca,ValidityKpCa,KpCa](H3,Rsa)(KsC) (PublicKey Ca Rsa KpCa); GOALS: 4. C Possesses KpC,KsC; C Believes (PublicKey C Rsa KpC; PrivateKey C Rsa KsC); 6. C Possesses ValidityKpCa,KpCa; C Believes PublicKey Ca Rsa KpCa; The GNY logic is unable to describe this protocol, since the protocol uses multiple hash functions (H1, H2, and H3), and uses a hash code (H2(PwdC)) as an encryption key. The GNY logic is also unable to specify that particular protocol goals become true at particular stages e.g., that C obtains its public and private keys after receiving the transmission from Leaf in stage 4. This example illustrates a further limitation in the GNY logic that is not removed by the theory protocol: its notion of \freshness" needs to be generalized. In the GNY logic, \fresh" means \created for the current run of the protocol", and only fresh messages can be believed to have the release conditions the protocol assumes they have. In the example, C's initial-condition beliefs that PwdC and ValidityKpCa are fresh are not accurate, but they serve a legitimate \freshness" purpose in the model: C's evidence that KpC and KsC are C's public and private keys is that they are encrypted with a hash of C's current password, and C's evidence that KpCa is Ca's public key is that the current time is within the ValidityKpCa interval. These points are discussed fully in [4]. The author also used protocol and its related software to show potential vulnerabilities in two SPX protocols [4], and to independently conrm, from scratch, in less than an hour, a problem in a simple example suggested by Meadows.

4 The components of the protocol-analyzing software using protocol are described elsewhere: ISL and its Yacc-based translator in [6]; and the software for automatically proving default and user-specied properties in [5]. The software can be used on its own, with user-created ISL text les, or invoked through an StP graphical user interface being developed by Lichota [8]. The rest of this paper is organized as follows: Section 2 gives a brief description of related work. Section 3 gives basic assumptions about, and terminology for, the theory's model of protocols, protocol principals, and principals' possessions and beliefs. Section 4 gives the theory's formal denitions of terms and statements, the data items interchanged during protocols and the objects assigned truth values by BGNY. Section 5 gives the theory's rules inductively dening BGNY, and compares them to the rules dening the GNY logic. Finally, Section 6 comments on possible future work, including incorporating security as well as authentication, incorporating algebraic properties of the encryption algorithms used, and combining the tools described here with attack-nding tools. 2. Related Work Odyssey Research Associates developed a partial HOL implementation of GNY [29, 30], and Hammonds, Lichota, Hird, and Wool [16] used this implementation to produce, by hand, HOL proofs that a simple Kerberos protocol [34] has some of its desired properties. This eort took months. Using the tools described here, the author was able to specify this protocol, and nd and correct errors, in less than an hour, then prove it has all of its desired properties in 157 seconds. Mathuria, Safavi-Naini, and Nickolas noted errors, omissions, and redundancies in the GNY logic [17]. They developed a variant of GNY in which nite sets of statements have only nite sets of consequences, and developed a Prolog program to automatically compute these consequences [18]. This work diers from the work described here in that the correctness of the theorems proved depends on the correctness of the Prolog program, the program uses a less ecient proof strategy, and their GNY does not incorporate extensions for handling things such as key-exchange algorithms. Schubert and Mocas [32] developed a HOL formalization of part of SvO, with additions to SvO for handling key escrow protocols, and used it to analyze and reveal deciencies in some key escrow protocols. They developed some proof-support tools, but the proof effort still required a large amount of user input. Snekkenes [33] developed a very rigorous theory of protocol security, implemented in HOL, that explicitly identies the parts of messages that protocol participants extract, the computations they perform on these parts, the tests they apply, and the actions they take in response to these tests. This makes it possible for the theory to model attacks that exploit algebraic properties of the encryption and decryption operations used. The theory also distinguishes participants from the roles they play, so it can model attacks in which an attacker leads legitimate participants to think that they are at dierent stages in the protocol than they really are. Snekkenes' also developed proof tools, but these tools require large amounts of human input. The author developed a full, partially corrected, but much less extended, HOL formalization of GNY in [3]. At the time, the author sketched a possible algorithm for automatically proving all the desired consequences of this logic. That algorithm is more general, but much less ecient, than the algorithm used by the software described in [5]. Chin and the author used the basic idea of dening a language as a HOL concrete-recursive type, then dening a HOL object-language relation assigning truth values to the elements of this type, in [7]. The author used a Yacc-based translator for translating specications in a simple language into much more complicated HOL specications in [2]. 3. Computational Model This section gives assumptions and terminology for the rest of the paper. A network, or distributed environment, consists of principals connected by communication links. Messages on these links constitute the only communications between principals. Any principal can place a message on any link and can see or modify any message on any link. A protocol is a distributed algorithm, carried out by principals acting as state machines; the protocol determines which messages the principals send as functions of their internal states. A protocol is divided into stages by message transmissions; the number of stages is always nite. A run, or session, is a particular execution of a protocol. This paper will only consider sessions that seem to end successfully, not considering possible alarm, adaptation, or retry provisions for other sessions. At each stage of a protocol session, each principal has a nite set of received data items, which the principal either had before the session began or extracted from messages sent to it before or during the current stage. Each principal also has a potentially innite set of possessions, which are pieces of information that the

5 principal is capable of computing from the data items it has received. At each stage of a protocol session, each principal also has a set of beliefs. Principals believe a proposition if they can be condent, even though this condence is not absolute, that this proposition is true. Belief can be based, for instance, on the near impossibility of quickly decrypting encrypted information without having the needed key. For the remainder of this paper, \believe" will be interpreted as \believe with condence". Although the consequences of false beliefs in conjunction with a protocol could be investigated, this paper will not do so. Rather, it will investigate whether the beliefs that can be (validly) attained include desired authentication conditions. Every principal starts a session with initial sets of received items and beliefs, and expands these sets by receiving messages using the inference rules in Section 5. Every principal's received-items and belief sets increase monotonically during a session, but a principal need not still have a data item or belief that this principal had in an earlier session. This paper assumes that the principals involved in a session do not send or receive messages other than the ones in the session; in particular, it assumes that the principals do not simply give away their secrets. 4. Terms and Statements This section describes the formal denitions of the types :Function, :Term and :Statement, and discusses their intended interpretations. They are all concrete recursive types: potentially innite collections of tree-structured data items [22]. Concrete recursive types include enumerated types, natural numbers, lists, and trees. For the remainder of this paper, term and statement will denote elements of types :Term and :Statement, respectively. The formal, inductive, definition of the relation BGNY assigning truth values to statements is given in Section 5. Types :Function, :Term and :Statement are mutually recursive, dened using Gunter's mutrec library in the contrib directory of Slind's HOL90.7. This paper will only describe the types' constructors, these constructors' arguments, and their intended interpretations. Types :Function, :Term and :Statement are all polymorphic in each of the following four type variables with protocol-specic instantiations: 'algorithm names of encryption, hash, key exchange, and other algorithms (e.g., RSA, MD5, DH, minus1). 'data names of arbitrary data such as nonces, time stamps, passwords, and validity intervals. 'key names of keys 'principal names of protocol principals; Objects of type :Function are abstractions for describing operations on data if some operations use a key and others don't, some operations are invertible and others aren't, and the inverse of an operation using one key might be an operation using a dierent key. There are two :Function constructors: NoF: null function; the \inverse" of non-invertible operations. Fk: Applied to an :'algorithm and a term, it denotes the operation performed by the algorithm using the term as a key. The \key" is the null term NoT if the algorithm (e.g., subtracting 1) does not use a key. Objects of type :Term are complete descriptions of pieces of data. The recipient of such a piece of data, particularly encrypted data, need not be able to identify it or distinguish it from another piece of data, even though HOL can prove that any two dierent :Term's are distinct. The following :Term constructors denote atomic objects. Those that are applied to arguments act as typeconversion functions, changing their arguments into :Term elements.: NoT: null term; the \key" used with algorithms that do not use keys. Ta: Applied to an :'algorithm. Ta is used with Possesses to state that principals know how to carry out particular algorithms. Td: Applied to a :'data element. Tf: Applied to a :Function. By the rules in Section 5, a principal possesses a :Function if and only if it possesses both the function's algorithm and key. Tk: Applied to a :'key. Tp: Applied to a :'principal. The next constructors denote the results of combining atomic objects in some way: App: Applied to a :Function, a term, and a statement, it denotes the result of computing the :Function's value on the term, then asserting that

6 the result will not be sent unless the result's originator believes the statement. The \statement" used with computations with no associated statement is NoS, the null statement. ;;: Applied to two terms, it gives the pair consisting of these terms. The App constructor is protocol's only analog of the \extension" concept in the GNY logic. Only function applications have associated statements because only they can be encryptions or hashes, only encryptions or hashes are protected against being meaningfully modied in transit, only data that cannot be meaningfully modied in transit can be identied as coming from particular principals, and only statements that are preconditions for the release of data coming from particular principals can be believed. The Fk and App constructors give protocol its exibility. The type variable 'algorithm can be instantiated by any plausible (e.g., nite) collection of algorithms. Fk then makes it possible to generalize over all algorithms, and also makes it possible to use the result of any computation as a key. App then lets any function be applied to arbitrary data, and lets the result be used to communicate any statement. (These constructors are similar to abstractions in SvO.) The statement constructors and informal descriptions of their intended meanings follow; their formal meanings are given via the inductive denition of BGNY in Section 5 assigning truth values to statements. NoS: null statement; the \statement" associated with terms that have no associated statement. Fresh: Applied to a term, it asserts that the term was created for the current session, not recorded from an earlier session. A principal believes a term is fresh if it believes it can identify the term as created for the current session whenever this term comes into its possession. Trustworthy: Applied to a :'principal, it asserts that if this principal was the originator of a data item that the protocol assumes would not have been released unless its originator believed an associated statement, then this is adequate reason for believing the associated statement. PrivateKey: This constructor is applied to a :'principal, an :'algorithm, and a :'key, and asserts that this key, for this algorithm, is one of the principal's private keys. This diers from GNY in explicitly specifying the algorithm, which is necessary if the protocol involves more than one algorithm e.g., a pair of public and private keys that are inverses of each other for RSA are not inverses of each other for Die-Hellman. PublicKey: This constructor is applied to a :'principal, an :'algorithm, and a :'key, and asserts that this key, for thise algorithm, is one of the principal's public keys. Again, specifying the algorithm is necessary. Conveyed: Applied to a ':principal and a term, it asserts that this principal was the originator of the term. A principal believes a term was conveyed by another principal if it believes it can condently identify the term as conveyed by that other principal whenever the term comes into its possession. \Originator" is somewhat narrower than the corresponding GNY notion, and these dierences are reected in several of the rules in Section 5. NeverFromSelf: Applied to a ':principal and a term, it asserts that this principal can identify the term as not being all or part of any message that this principal originated at any earlier time. This is a renamed version of the GNY \Never Originated Here" concept, with the dependence on both the principal and the term made explicit. Possesses: Applied to a ':principal and term, it asserts that this principal received the term or is capable of computing it from terms that this principal has received. If the term is an App with a non-null associated statement, the principal either received the term or has adequate reason to believe this associated statement. Received: Applied to a ':principal and a term, it asserts that this principal received the term before the current session or received it as, or as part of, some message sent earlier in the current session. Recognizes: Applied to a ':principal and a term, it asserts that this principle can identify the term as being data of an expected form. Principal p1 believes principal p2 recognizes the data if p1 believes p2 could condently identify the item as being data of an expected form if it comes into p2's possession. This diers from the GNY notion in explicitly treating recognition as a relationship between a principal and a term, not simply as an intrinsic property of the term. Sends: Applied to two `:principal values and a term, it asserts that the rst principal sends the second principal the term. As a uniform prohibition against impossible protocols, the second principal only receives the term if the rst principal

7 possesses it to send and the principals are distinct. This is protocol's implementation of Gong's \eligibility" notion [13]. SharedSecret: Applied to two `:principal values and a term, it asserts that if these principals possess the term, or come to possess it through secure means, then they are, or will be, the only ones other than principals trusted by both of them who possess it. These principals can safely use the data to identify each other or encrypt data that they interchange with each other. Believes: Applied to a :'principal and a statement, it asserts that this principal has adequate reason to act as if it knows the statement is true. &&: Applied to two statements, it gives the conjunction of these statements. There is no corresponding formal notion in the GNY logic. 5. Inference Rules This section describes the inference rules inductively dening a relation BGNY that assigns truth values to statements. In addition to a statement, BGNY takes three other arguments that give the dependence of the statement's meaning on the assumptions made about the algorithms and keys used in the protocol and on the protocol stage. Descriptions of these other arguments follow: A function environment is a tuple of functions that express the assumptions made about the algorithms and keys used in the protocol. These functions tell which algorithms give secure encryption, hash, and key-exchange functions, which functions are other functions' inverses, and which terms have the same binary values as other terms. For readability, protocol denes the functions FeCrypt, FeHash, FeKeyEx, FeInvOf, and FeEquals to extract the dierent elements of a function environment. A protocol is a statement list. The 0th element in this list, intended to be a conjunction of Received and Believes statements, gives the protocol's initial conditions. The other elements in the list are intended to be Sends statements. A protocol stage is a non-negative integer. When used as an index into a protocol, it gives either the protocol's initial conditions or the Sends statement identifying the sender, receiver, and message transferred at that stage. Relation BGNY is dened in terms of the subrelation NotFromSelf, which is itself dened in terms of the subrelations Contains and NotSendFromHere. Contains tells whether one term syntactically contains another. NotSendFromHere, intended to be applied only to Sends statements and dened to always have value \false" otherwise, tells whether a Sends statement is a particular principal sending a message containing a particular term. NotFromSelf tells whether a principal could have output a term, possibly in a list of other terms or modied in some way, at an earlier stage in a protocol. NotFromSelf imposes a more stringent \not originated here" condition than the one the GNY logic imposes by a syntactic analysis outside the formal rules of the logic. NotFromSelf treats anything in a term or subterm as having been made available to hostile principals, regardless of whether a hostile principal could actually obtain this data. Such a relation is only possible because a term is a complete description of a data item. NotFromSelf has constant value \false" for any list of statements with an element other than the 0th one that is not a Sends statement. BGNY is also dened in terms of EquivInf, a relation that hold for two lists of statements if they describe equivalent inferences, assuming principals are able to draw rational conclusions from their beliefs and know that other principals are able to do likewise. Here, a list of statements corresponds to the inference that the nal statement in the list follows from the earlier statements in the list. Two statement lists describe equivalent inferences if the lists are equal, or if, for some principal, every statement in one list is the statement that this principal believes the corresponding statement in a list equivalent to the other list. Each \inference rule" for BGNY is really an innite schema of rules, where each member of the schema is equivalent to the schema's base rule. The relation EquivInf describes the members of such a schema. For example noting that in HOL \ -" means \theorem", \!" means \for all", and \?" means \there exists" the BGNY rule GA1 -!fenv protocol stage S3. (?S1 S2 s1 s2. BGNY fenv protocol stage S1 /\ BGNY fenv protocol stage S2 /\ EquivInf [s1; s2; s1 && s2] [S1; S2; S3]) ==> BGNY fenv protocol stage S3 denes the schema whose base rule is

8 A1 -!fenv protocol stage s1 s2. BGNY fenv protocol stage s1 /\ BGNY fenv protocol stage s2 ==> BGNY fenv protocol stage (s1 && s2) and also contains the rule B2A1 -!fenv protocol stage s1 s2 p q. BGNY fenv protocol stage (Believes p (Believes q s1)) /\ BGNY fenv protocol stage (Believes p (Believes q s2)) ==> BGNY fenv protocol stage (Believes p (Believes q (s1 && s2))). HOL's ability to quantify over arbitrary lists of statements, in the denition of EquivInf, fully implements the GNY \rationality rule". The author has developed a proof tool that automatically proves any desired instance of any BGNY rule schema Stage-Dependent Rules Descriptions of the rules dening how statements become and remain true during a session, and how data must be possessed before it can be sent, follow. These rules are the only ones explicitly using BGNY's protocol and stage arguments. The \initial conditions" rule makes stage-0 statements true and makes new Sends statements true as the session advances. The HOL object-language function EL picks out elements of object-language lists, indexing from 0. There is no analog of this rule in the GNY logic. I1: BGNY fenv protocol stage (EL stage protocol) The \monotonicity" rule asserts that statements stay true once they become true. It is only valid because the statement constructors do not include negation. There is no analog of this rule in the GNY logic. M1: BGNY fenv protocol stage s ==> (!n. BGNY fenv protocol (stage + n) s) The rst BGNY \reception" rule says that a principal q receives a message only if there exists a principal p, dierent from q, who is capable of sending it and sends it. This rule is analogous to GNY rule T1, and implements Gong's \eligibility" notion [13]. R1: (?p. BGNY fenv protocol (stage + 1) (Sends p q t) /\ BGNY fenv protocol stage (Possesses p t) /\ ~(p = q)) ==> BGNY fenv protocol (stage + 1) (Received q t) For simplicity, the descriptions of the remaining BGNY rules, all dened in terms of EquivInf, will give only the base rule in each rule schema. Further, each of these base rules will be given without explicit mention of the relation BGNY and its protocol and stage arguments, and will be given in sequent form, with hypotheses above a line and conclusions below it. The complicated GA1 earlier will thus be replaced by: A1: s1, s2 s1 && s2 Descriptions of the remaining rules follow Conjunction and Null-Object Rules The next three rules dene the && operator. These rules have no analogs in the GNY logic. A1: s1, s2 s1 && s2 A2: s1 && s2 s1 A3: s1 && s2 s2 The next two rules give needed properties of \null" objects. The null term is always possessed, and the null statement is always believed. These rules do not have analogs in the GNY logic. N1: (Possesses p NoT)

9 N2: (Believes p NoS) 5.3. Self-Belief Rules The next rule asserts that principals can believe that they believe something if they can believe this something. This rule has no analog in the GNY logic. BB1: Believes p s Believes p (Believes p s) Principals know they can compute what they can compute; this does not mean that they know what it is. This rule has no analog in the GNY logic. BP1: Possesses p t Believes p (Possesses p t) 5.4. Possession Rules Received terms are possessed, pieces of possessed pairs are possessed, and possessed keys can be used with possessed algorithms. Rules P1 and P2 are analogous to GNY rules P1 and P2, but GNY rule P2 also includes a special case of function application that is covered under rule P4. Rule P3 has no analog in the GNY logic. P1: Received p t Possesses p t P2: Possesses p t1, Possesses p t2 Possesses p (t1 ;; t2) P3: Possesses p (Ta a), Possesses p t Possesses p (Tf (Fk a t)) If a principal can do a computation, and believes a statement, the principal can make the computation and send the result even if the protocol assumes that the result's originator will only send the result if it believes the statement. This rule covers GNY rules P4, P6, P7, P8, and part of P2, and captures Gong's \eligibility" notion [13]. GNY rule P5 covers functions of two arguments that are reversible in either argument. There is no corresponding notion in protocol, though this case could be covered using FeEquals. P4: Possesses p (Tf f), Possesses p t, Believes p s Possesses p (App f t s) The next three rules are not strictly necessary, since they allow principals to take apart things that they have put together; the terms they obtain must be terms that they already have. Still, these rules make it possible to prove convenient rewrite theorems such as one asserting that a principal possesses a pair if and only if the principal possesses both elements of this pair. Note that the nal conditions in rule P7 just say that f2 is invertible and f1 is its inverse. Rule P5 is a completed analog of GNY rule P3; rules P6 and P7 have no analog in the GNY logic. P5: Possesses p (t1 ;; t2) Possesses p t1, Possesses p t2 P6: Possesses p (Tf (Fk a t)) Possesses p (Ta a), Possesses p t P7: Possesses p (App f1 (App f2 t s2) s1), FeInvOf fenv f2 = f1, ~(f1 = NoF) Possesses p t Terms equal to terms that are possessed are possessed. This rule is crucial for handling data encrypted with keys produced by key-exchange algorithms. This rule has no analog in the GNY logic. P8: Possesses p t1, FeEquals fenv t2 = t1 Possesses p t Reception Rules Received terms can be taken apart, and if the receiving principal can compute the necessary inverse functions then this principal can obtain encrypted or otherwise modied information. Rule R2 is a completed

10 analog of GNY rule T2. Rule R3 covers GNY rules T3, T4, and T6, and the single-argument case of GNY rule T5. R2: Received p (t1 ;; t2) Received p t1, Received p t2 R3: Possesses p (Tf f1), Received p (App f2 t s), FeInvOf fenv f2 = f1, ~(f1 = NoF) Received p t 5.6. Belief Acquisition Rules The next rule is the only BGNY rule allowing a principal to acquire a belief from another principal. The acquiring principal must trust this other principal, must believe that the data whose release communicates the acquired belief originated with this trusted principal, and must believe that the data was created for the current session. This rule allows the acquiring principal to believe that the originator of the data conveying a belief also has this belief; this is typically all that is needed to show desired beliefs about other principals' beliefs. This rule is analogous to GNY \jurisdiction" rule J2, but also covers the only part of GNY rule J3 that does not follow from the \Rationality Rule". This rule differs from GNY rule J2 in having the freshness requirement apply to the full term conveyed, not a particular part of it. There is no BGNY rule analogous to GNY rule J1, since that rule allows principals to acquire beliefs from other principals that they trust without saying how they acquire these beliefs, which is not realistic. T1: Believes p (Conveyed q (App f t s)), Believes p (Fresh (App f t s)), Believes p (Trustworthy q) Believes p s, Believes p (Believes q s) Principals can assume that other principals who originated something during the current session still possess it. This rule is analogous to GNY rule I6. BP2: Believes p (Conveyed q t), Believes p (Fresh t) Believes p (Possesses q t) The next rule allows a principal to acquire very limited beliefs from a message originated by a principal that the rst principal does not trust. If a principal receives something it can believe is fresh, whose associated statement asserts only that its originator is capable of originating it, then the principal can believe this statement even if it does not trust the originator of the thing it receives. This rule, giving a very weak version of having dierent levels of trust, is covered in part by conclusions of GNY rules I1, I2, and I5. BP3: Believes p (Conveyed q (App f t (Possesses q (Tf f) && Possesses q t))), Believes p (Fresh (App f t (Possesses q (Tf f) && Possesses q t))) Believes p (Possesses q (Tf f) && Possesses q t) 5.7. Believes Conveyed Rules The BGNY conveyance rules do not include analogs of GNY rule I7, which allows principals to conclude that other principals conveyed elements of pairs, or the parts of GNY rules I1, I2, I3, or I4 that allow principals to conclude that other principals conveyed plaintext. By the strict interpretation of conveyance used here, these rules are not true. The principal who rst put together and relased a pair need not have originated either of the elements of that pair. As far as conveying plaintext goes, the principal who rst creates and releases cryptotext need not be the one who created the plaintext. Also, it is never necessary to know who conveyed plaintext. Any statement to be communicated by plaintext can be associated with the cryptotext or a hash code corresponding to that plaintext; the plaintext just makes it feasible for the recipient to determine what this associated statement is. If a principal possesses another principal's public key, can believe that it is this other principal's public key, receives data encrypted with this other principal's private key, and decrypts the data with this other principal's public key to obtain something it recognizes as of an expected form, then it can believe that the data came from this other principal. This is the only BGNY conveyance rule that does not have a Fresh and NotFromSelf, or NeverFromSelf, requirement. This rule is analogous to GNY rule I4.

11 BC1: Received p (App f t s), Possesses p (Tf (Fk a (Tk k))), Believes p (PublicKey q a k), Believes p (Recognizes p t), FeCrypt fenv f, FeInvOf fenv f = Fk a (Tk k) Believes p (Conveyed q (App f t s)) If a principal receives data encrypted with a symmetric key that it can believe it shares with only one other principal, decrypts the data to obtain information it recognizes as of an expected form, and the data is fresh but not a possible replay of something the principal sent earlier in the session, then the principal can believe that the encrypted data came from this other principal. This rule is analogous to GNY rule I1. BC2: Received p (App (Fk a2 tk) t s), Possesses p (Tf (Fk a1 tk)), Believes p (SharedSecret p q tk), Believes p (Recognizes p t), Believes p (Fresh (App (Fk a2 tk) t s)), FeCrypt fenv (Fk a2 tk), FeInvOf fenv (Fk a2 tk) = Fk a1 tk, NotFromSelf protocol stage p (App (Fk a2 tk) t s) Believes p (Conveyed q (App (Fk a2 tk) t s)) If a principal receives a hash of data that it can believe it shares with only one other principal, or receives a message authentication code computed with a symmetric key that it can believe it shares with only this principal, or both, the principal has the data used to produce the hash or message authentication code, and the hash or message authentication code is fresh but not a possible replay of something the principal sent out earlier in the session, then the principal can believe that the hash or message authentication code came from this other principal. This rule extends GNY rule I3 to message authentication codes, and removes the restriction that the shared secret be at the end of the hashed data. BC3: Received p (App (Fk a tk) t s), Possesses p (Tf (Fk a tk) ;; t), Believes p (SharedSecret p q (tk ;; t)), Believes p (Fresh (App (Fk a tk) t s)), FeHash fenv (Fk a tk), NotFromSelf protocol stage p (App (Fk a tk) t s) Believes p (Conveyed q (App (Fk a tk) t s)) If a principal receives data encrypted with its own public key, and decrypts this data to obtain something it recognizes as information of an expected form that it shares with only one other principal, and the encrypted data is fresh but not a replay of something the principal sent out itself earlier in the session, then the principal can believe that the encrypted data came from this other principal. This rule is analogous to GNY rule I2, but removes the restriction that the shared secret is at the end of the message. BC4: Received p (App f x s), Possesses p (Tf (Fk a (Tk k))), Believes p (PrivateKey p a k), Believes p (SharedSecret p q x), Believes p (Recognizes p x), Believes p (Fresh (App f x s)), FeCrypt fenv f, FeInvOf fenv f = Fk a (Tk k), NotFromSelf protocol stage p (App f x s) Believes p (Conveyed q (App f x s)) If a principal receives data encrypted with a symmetric key that it can believe it shares with only one other principal, and can decrypt the data with this key to obtain information it recognizes as meaningful, and the data is not a possible replay of something the principal sent at any earlier time, then the principal can believe that the encrypted data came from this other principal. This rule is analogous to GNY rule I1'. BC5: Received p (App (Fk a2 tk) t s), Possesses p (Tf (Fk a1 tk)), Believes p (SharedSecret p q tk), Believes p (Recognizes p t), Believes p (NeverFromSelf p (App (Fk a2 tk) t s)), FeCrypt fenv (Fk a2 tk), FeInvOf fenv (Fk a2 tk) = Fk a1 tk Believes p (Conveyed q (App (Fk a2 tk) t s)) If a principal receives a hash of data that it can believe it shares with only one other principal, or receives a message authentication code computed with a symmetric key that it can believe it shares with only one other principal, or both, and the principal has the data used to produce the hash or message authentication code, and the hash or message authentication code is not a possible replay of something the principal sent at any earlier time, then the principal can believe that

12 the hash or message authentication code came from this other principal. This rule extends GNY rule I3' to message authentication codes, and removes the restriction that the shared secret be at the end of the hashed data. BC6: Received p (App (Fk a tk) t s), Possesses p (Tf (Fk a tk) ;; t), Believes p (SharedSecret p q (tk ;; t)), Believes p (NeverFromSelf p (App (Fk a tk) t s)), FeHash fenv (Fk a tk) Believes p (Conveyed q (App (Fk a tk) t s)) If a principal receives data encrypted with its own public key, and decrypts this data to obtain something it recognizes as information it shares with only one other principal, and the encrypted data is not a replay of something the principal sent out itself at any earlier time, then the principal can believe that the encrypted data came from this other principal. This rule is analogous to GNY rule I2', but removes the restriction that the shared secret is at the end of the message. BC7: Received p (App f x s), Possesses p (Tf (Fk a (Tk k))), Believes p (PrivateKey p a k), Believes p (SharedSecret p q x), Believes p (Recognizes p x), Believes p (NeverFromSelf p (App f x s)), FeCrypt fenv f, FeInvOf fenv f = Fk a (Tk k) Believes p (Conveyed q (App f x s)) 5.8. Believes Fresh Rules If a principal can believe that something contains or was computed from something the principal has adequate reason to believe is fresh, the principal has adequate reason to believe that the containing or computed thing is fresh. Rule BF1 is a completed analog of part of GNY rule F1; the rest of GNY rule F1 is covered by rule BF2. Rule BF2 also covers GNY rules F2, F3, F4, and F10, and extends F10 to message authentication codes. BF1: Believes p (Fresh t) Believes p (Fresh (t ;; t2)), Believes p (Fresh (t1 ;; t)) BF2: Believes p (Fresh (t ;; tk)), Possesses p t, Possesses p (Tf (Fk a tk)) Believes p (Fresh (App (Fk a tk) t s)) If a principal can invert a computation to obtain something it recognizes as fresh, or can invert the computation with a key it believes is fresh and get something it recognizes as meaningful, then it can believe that the original computed item is fresh. This rule effectively covers GNY rules F5 and F6, plus corrected versions of GNY rules F7, F8, and F9, and extends them to invertible non-encryption functions. BF3: Believes p (Recognizes p t), Believes p (Fresh (t ;; tk1)), Possesses p (Tf (Fk a1 tk1)), FeInvOf fenv (Fk a2 tk2) = Fk a1 tk1 Believes p (Fresh (App (Fk a2 tk2) t s)) If a principal can believe a hash code is fresh, and the hash does not use a key, then the principal can believe that the thing hashed is fresh. This rule is analogous to GNY rule F11. BF4: Believes p (Fresh (App (Fk a NoT) t s)), Possesses p (App (Fk a NoT) t s) Believes p (Fresh t) Things equal to things believed fresh can be believed fresh. This is needed for believing freshness of keyexchange keys. There is no analog of this rule in the GNY logic. BF5: Believes p (Fresh t1), FeEquals fenv t2 = t1 Believes p (Fresh t2) 5.9. Believes Recognizes Rules A principal can recognize as of an expected form anything that the principal can determine contains, or is computed from, something the principal recognizes as of an expected form. Rule BR1 is a completed analog of part of GNY rule R1; the rest of GNY rule R1 is covered by rule BR2. Rule BR2 covers GNY rules R2, R3, R4, and R5, imposing the additional restriction that the principal possess the data operated on.

13 BR1: Believes p (Recognizes p t) Believes p (Recognizes p (t ;; t2)), Believes p (Recognizes p (t1 ;; t)) BR2: Believes p (Recognizes p t), Possesses p (Tf f), Possesses p t Believes p (Recognizes p (App f t s)) A principal can recognize as meaningful anything that the principal can decrypt or otherwise invert to obtain something the principal recognizes as meaningful. This rule covers the apparent intent of GNY rules R2, R3, and R4, and also covers non-encryption invertible operations. BR3: Believes p (Recognizes p t), Possesses p (Tf f1)), FeInvOf fenv f2 = f1, ~(f1 = NoF) Believes p (Recognizes p (App f2 t s)) A principal can recognize as meaningful anything the principal can determine is used to compute something the principal recognizes as meaningful. This rule covers a corrected and extended form of GNY rule R6; as stated, GNY rule R6 allows any principal possessing a hash function to identify as of an expected form any piece of data that this principal possesses. BR4: Believes p (Recognizes p (App f t s)), Possesses p (Tf f) Believes p (Recognizes p t) Believes Shared Secret Rules The SharedSecret relation is symmetrical. There is no analog of this rule in the GNY logic. BS1: Believes p (SharedSecret q r x) Believes p (SharedSecret r q x) Anything containing a shared secret can be regarded as a shared secret. This rule has no analog in the GNY logic; it removes unnatural GNY restrictions that require that shared secrets occur in particular places in messages in order to be recognized as shared secrets. BS2: Believes p (SharedSecret q r x) Believes p (SharedSecret q r (x ;; y)), Believes p (SharedSecret q r (y ;; x)) A key computed using a valid key-exchange algorithm, from one principal's private key and another principal's public key, can be believed to be a secret shared between these two principals. There is no analog of this rule in the GNY logic. BS3: Believes p (PrivateKey p a k1), Believes p (PublicKey q a k2), FeKeyEx fenv (Fk a (Tk k1)) Believes p (SharedSecret p q (App (Fk a (Tk k1)) (Tk k2 ;; tx) NoS)) Something equal to something believed to be a shared secret can be believed to be a shared secret. This rule is essential in believing that keys computed by key-exchange algorithms are shared secrets. There is no analog of this rule in the GNY logic. BS4: Believes p (SharedSecret p q t1), FeEquals fenv t2 = t1 Believes p (SharedSecret p q t2) 6. Future Work This section briey describes possible future work. The theory described here might be extended to address security as well as authentication as follows: introduce a new KnownOnlyTo predicate taking a term and a list of principals as arguments, and asserting that only these principals possess the term. Dene rules for making new KnownOnlyTo inferences by induction on protocol stage. Eliminate the general monotonicity rule M1 above, and replace it with more limited monotonicity rules for received, possessed, believed fresh, and recognized data. Afterwards, make deductions as before. A KnownOnlyTo predicate is probably a more rigorous analog of the BAN/GNY/SvO concept of \shared secret". A protocol principal never really has adequate reason to believe that a data item is a secret shared by two other principals, but this principal might have adequate reason to believe that it is currently the only principal that has this data.