Prudent Engineering Practice for Cryptographic Protocols
Total Page：16
File Type：pdf, Size：1020Kb
6 IEEE TRANSACTIONS ON SOFM'ARE ENGINEERING, VOL. 22, NO. 1, JANUARY 1996 Prudent Engineering Practice for Cryptographic Protocols Martin Abadi and Roger Needham Abstract-We present principles for designing cryptographic protocols. The principles are neither necessary nor sufficient for correctness. They are however helpful, in that adherence to them would have prevented a number of published errors. Our principles are informal guidelines; they complement formal methods, but do not assume them. In order to demonstrate the actual applicability of these guidelines, we discuss some instructive examples from the literature. Index Terms-Cryptography, authentication, cryptographic protocols, authentication protocols, security. + 1 INTRODUCTION RYPTOGRAPHIC protocols, as used in distributed sys- traditional cryptography, and on protocols of the sort com- tems for authentication and related purposes, are mody implemented with the DES [20] and the RSA [28] prone to design errors of every kind. Over time, various algorithms. In particular, we do not consider the subtleties formalisms have been proposed for investigating and ana- of interactive schemes for signatures (e.g., [7]).Moreover, lyzing protocols to see whether they contain blunders. we do not discuss the choice of cryptographic mechanisms (Liebl's bibliography [13] includes references to protocols with adequate protection properties, the correct implemen- and formalisms.)Although sometimes useful, these formal- tation of cryptographic primitives, or their appropriate use; isms do not of themselves suggest design rules; they are not these subjects are discussed elsewhere (e.g., [32],1191). directly beneficial in preventing trouble. Throughout, we concentrate on the simple principles We present principles for the design of cryptographic with the largest potential applicability and payoff. Admit- protocols. The principles are not necessary for correctness, tedly, the literature is full of ingenious protocols and at- nor are they sufficient. They are, however, helpful, in that tacks. We do not attempt to formulate the laws that underly adherence to them would have simplified protocols, and this ingenuity, and perhaps it is not necessary to do so. We prevented a number of published confusions and mistakes. hope that our simple principles and examples will contrib- We arrived at our principles by noticing some common ute to the engineering of robust cryptographic protocols. features among protocols that are difficult to analyze. If these features are avoided, it becomes less necessary to re- 2 BASICS sort to formal tools-and also easier to do so if there is good reason to. The principles themselves are informal guide- A protocol, for present purposes, is a set of rules or conven- lines, and useful independently of any logic. tions defining an exchange of messages between a set of We illustrate the principles with examples. In order to two or more partners. These partners are users, processes, demonstrate the actual applicability of our guidelines, we or machines, which we will generically refer to as princi- draw these examples from the literature. Some of the oddities pals. In the cryptographic protocols we consider here, the and errors that we analyze have been documented previ- whole or part of some or all of the messages is encrypted. ously (in particular, in [4]). Other examples are new: protocols We interpret the term encryption fairly broadly, applying it by Denning and Sacco [6], Hickman (Netscape) [ll],[lo], Lu for example to signature operations. For present purposes, and Sundareshan [14], Varadharajan, Allen, and Black 1311, encryption and decryption are defined as key-dependent and Woo and Lam [34]. We believe they are all instructive. transformations of a message which may be inverted only Generally, we pick examples from the authentication lit- by using a definite key; the keys used for encryption and erature, but the principles are applicable elsewhere, for ex- decryption are the same or different, depending on the ample to electronic-cash protocols (e.g., [17]). We focus on cryptographic algorithm used. We find two basic, overarching principles for the design * M. Abadi is with the Systems Research Center, Digital Equipment Corpo- of secure cryptographic protocols. One principle is con- ration, 130 Lyfton Ave., Palo Alto, CA94301. cerned with the content of a message and the other with the E-mail: [email protected]. circumstances in which it will be acted upon: 0 R. Needham is with the University of Cambridge Computer Luboratoy, Pembroke Street, Cambridge CB2 3QG, UK. 1) Every message should say what it means-its inter- E-mail: [email protected]. pretation should depend only on its content. Manuscript received November 1993; revised April 1995. 2) The conditions for a message to be acted upon should A preliminary version of this paper appeared in the Proceedings of the 1994 IEEE Computer Society Symposium on Research in Securiiy and Privacy. be clearly set out so that someone reviewing a design For information on obtaining reprints of this article, please send e-mail to: may see whether they are acceptable or not. [email protected], and reference IEEECS Log Number S95062. 0098-5589/96$05.00 01996 IEEE Authorized licensed use limited to: Univ of Calif Berkeley. Downloaded on January 20,2021 at 00:21:27 UTC from IEEE Xplore. Restrictions apply. ABADI AND NEEDHAM: PRUDENT ENGINEERING PRACTICE FOR CRYPTOGRAPHIC PROTOCOLS 7 Next we explain these principles. They leald to other, more 2.3 Secrecy specific recommendations, which we discuss in the subse- The secrecy of certain pieces of information is essential to quent sections. the functioning of cryptographic protocols. Obviously, a 2.1 Explicit Communication protocol should not publicize the cryptographic keys used for communicating sensitive data. Further, it is important to In full, our first basic principle is: know how long a piece of information needs to remain se- PRINCIPLE1 cret, and to protect it accordingly. Every message should say what it means: The inter- None of our principles makes these points explicitly. pretation of the message should depend only on its Rather, all of our principles warn against mistakes that of- content. It should be possible to write down a straight- ten imply the loss of secrecy, integrity, and authenticity. forward English sentence describing ihe content- Some of the examples clarify how the principles relate to though if there is a suitable formalism available, that is the need for secrecy. good too. There may be more to say about secrecy guidelines for cryptographic protocols, but these are outside the scope of For example, an authentication server S might send a the present paper. message whose meaning may be expressed thus: “After receiving bit-pattern P, S sends to A a session key K in- 2.4 Examples and Other Principles tended to be good for conversation with B.” All elements of Below we discuss many concrete examples where errors this meaning should be explicitly represented in the mes- would have been avoided by using our two basic princi- sage, so that a recipient can recover the meaning without ples. We also introduce other principles, some of them any context. In particular, if any of P, S, A, 13, or K are left to corollaries of the basic ones. In particular, we recommend: be inferred from context, it may be possible for one message to be used deceitfully in place of another. Be clear on how encryption is used, and on the This principle is not completely original. In 141, we rec- meaning of encryption. ommend the use of a logical notation in generating and Be clear on how the timeliness of messages is proved, and describing protocols-essentially proposing a method to on the meaning of temporal information in messages. follow the principle. Establishing the correspondence be- Hopefully, the two basic principles will encourage a certain tween the logical protocol and its concrete implementation lucidity in the design of cryptographic protocols, and can be a simple matter of parsing, as for example in 1331. thereby make it easier to follow the other principles. Although a precise comparison of informal ideas is difficult, we also find an affinity with Boyd and Mao’s proposal that protocols should be robust in the sense that “authentication 3 NOTATION of any message in the protocol depends only on informa- We adopt notation common in the literature. That notation tion contained in the message itself or already in the pos- is not quite uniform and, in the examples, we make com- session of the recipient” [3]. An operational variant on this promises between uniformity of this paper and faithfulness theme appears in the work of Woo and Lam, who say that a to the original notation. protocol is a full information protocol if ”its initiator and In this paper, the symbols A and B often represent arbi- responder always include in their outgoing encrypted mes- trary principals, S represents a server, T a timestamp, N a sages all the information they have gathered” 1351. nonce (a quantity generated for the purpose of being re- cent), K a key, and K’ its inverse. In symmetric cryptosys- 2.2 Appropriate Action tems such as DES, K and K’are always equal. For asym- For a message to be acted upon, it does not suffice that the metric cryptosystems such as RSA, we assume for simplic- message be understood; a variety of other conditions have ity that the inversion operation is an involution (so K-’-’ to hold too. These conditions often consist of what may be equals K); we tend to use for the secret part and K for the regarded informally as statements of trust, though this an- K’ thropomorphic notion should be used with care. public part of a key pair (K, K’). We write (X}, to represent Statements of trust cannot be wrong though they may be X encrypted under K; anyone who knows {X), and the in- considered inappropriate.