A Search-Based Framework for Security Protocol Synthesis

Transcription

1 A Search-Based Framework for Security Protocol Synthesis Hao Chen Submitted for the degree of Doctor of Philosophy The University of York Department of Computer Science April 2007

2 For My Mum and Dad 献 给 我 的 爸 爸 妈 妈

3 Abstract Security protocol verification has been the area where the bulk of the research in cryptographic protocols has taken place and a number of successful supporting tools have been developed. However, not much research has been done in the area of applying formal methods to the design of cryptographic protocols in the first place, despite wide recognition that the design of cryptographic protocols is very difficult. Most existing protocols have been designed using informal methods and heavily rely on the verification process to pick up vulnerabilities. The research reported in this thesis shows how to automatically synthesise abstract protocols using heuristic search, explains how to add high-level efficiency concerns to the synthesis, and demonstrates how to refine the abstract protocols to executable Java Code. i

4 ii

5 Contents Abstract List of Figures List of Tables Acknowledgements Author s Declaration i vii ix xi xiii 1 Introduction Design of Security Protocols Security Protocol Synthesis Framework The Thesis Statement of the Hypothesis Brief Overview of the Thesis Chapters Design of Security Protocols Background and Building Blocks Notation and Cryptographic Primitives Types of Security Protocols Attacks on Security Protocols Freshness Attacks Parallel Session Attacks Type-flaw Attacks Implementation Dependent Attacks Other Forms of Attack Verification Techniques Techniques Based on Modal Logic Techniques Based on State Machines Computational Complexity Approach iii

6 Contents 2.4 Design Principles Automated Design Techniques Model Checking and APG Heuristic Search Simple Logic and ASPB Techniques without Tool Support Searching for Secure BAN Protocols BAN Logic Idealised Protocols Encryption and Keys Notation Inference Rules An Example of a BAN Protocol Protocol Synthesis Framework of Clark and Jacob Representing Messages and Protocols Evaluating an Abstract Protocol The Fitness Function The Move Function Results of Clark and Jacob s Work Extending The Framework to Use Full BAN Logic Extended Message Interpretation Extended Protocol Interpretation Experimental Method and Results Public Key Protocols Public Key Protocols using Timestamps Hybrid Protocols Extensive Experimentation Conclusions and Discussion Searching for Efficient and Secure SVO Protocols SVO Logic SVO Notations SVO Axioms An Example of SVO Protocol Security Protocol Requirements Correctness Requirements Efficiency Requirements Protocol Fitness with Efficiency Concerns iv

7 Contents 4.4 Experimental Method and Results Symmetric Key Protocols Public Key Protocols Key Agreement Protocols Comments Extensive Experimentation Conclusions and Discussion Refinement of Security Protocols Idealisation and Refinement From Logic Level to Concrete Level Extract Primitives Remove Duplicates Remove Redundancies From Concrete Level to Code Level Prevent Any Type-flaw Attacks Code Generation Importing Verification Tools Casper FDR Tool Athena Tool Conclusions and Discussion Evaluation and Conclusions The Hypothesis Evaluation Extensions to Full BAN logic Extensions to SVO Logic Incorporating Efficiency Concerns Refinement of Security Protocols Further Work Closing Remark A Supporting Material 133 A.1 SVO Results on SPORE Library A.1.1 AndrewSecureRPC Protocol A.1.2 BANConcreteAndrewSecureRPC Protocol A.1.3 CCITT X509.1 Protocol A.1.4 CCITT X509.3 Protocol A.1.5 Efficiency Requirements v

8 Contents A.1.6 BAN CCITT X509.3 Protocol A.1.7 DenningSaccoSharedKey Protocol A.1.8 LoweModifiedDenningSaccoSharedKey Protocol A.1.9 KaoChowAuthenticationV1 Protocol A.1.10 KaoChowAuthenticationV2 Protocol A.1.11 KaoChowAuthenticationV3 Protocol A.1.12 KerberosV5 Protocol A.1.13 NeumannStubblebine Protocol A.1.14 NeedhamSchroederPublicKey Protocol A.1.15 NeedhamSchroederSymmetricKey Protocol A.1.16 AmendedNeedhamSchroederSymmetricKey Protocol 164 A.1.17 OtwayRees Protocol A.1.18 SPLICE AS Protocol A.1.19 WideMouthedFrog Protocol A.1.20 LoweModifiedWideMouthedFrog Protocol A.1.21 WooAndLamMutualAuthentication Protocol A.1.22 WooAndLamPi Protocol A.1.23 Yahalom Protocol A.1.24 BANModifiedYahalom Protocol A.2 Examples of Protocol Synthesis Pipeline A.2.1 Synthesising a Symmetric Key Protocol A.2.2 Synthesising a Public Key Protocol A.2.3 Synthesising a Hybrid Protocol A.3 The Participant Class A.4 Simulation Test for The Symmetric Key Protocol Generated in Appendix A Bibliography 217 vi

9 List of Figures 1.1 Pipeline of Synthesising Protocols Needham Schroeder Symmetric Key Protocol Needham Schroeder Public Key Protocol Simplified Needham Schroeder Public Key Protocol Beller Yacobi Protocol An Attack on the Needham Schroeder Symmetric Key Protocol An Attack on the Simplified Needham Schroeder Public Key Protocol Otway Rees Protocol An Attack on the Otway Rees Protocol Another Attack on the Otway Rees Protocol Amended Needham Schroeder Symmetric Key Protocol Basic SA for Maximisation Problems Illustration of SA for Maximisation Problems An Example of a BAN Protocol Interpreting an Integer Sequence Interpreting an Integer Sequence Public Key Protocol Generated During Experimentation Public Key Protocol With Additional Assumptions Public Key Protocol Using Timestamps A hybrid encryption protocol An Example of SVO Protocol Protocol Found in The First Search Protocol Found in The Second Search Protocol Found in The Third Search Public Key Protocol Found in The First Search Public Key Protocol Found in The Second Search Key Agreement Protocol Found in The First Search vii

10 List of Figures 4.8 Key Agreement Protocol Found in The Second Search Concrete Symmetric Key Protocol at Refinement Step One Concrete Public Key Protocol at Refinement Step One Concrete Symmetric Key Protocol at Refinement Step Two Concrete Public Key Protocol at Refinement Step Two Final Concrete Symmetric Key Protocol Final Concrete Public Key Protocol Otway Rees Protocol with Tags Otway Rees Protocol with Index Otway Rees Protocol with Rearranged Messages A Symmetric Key Protocol Pipeline of Synthesising Protocols viii

11 List of Tables 3.1 Clark and Jacob s Weighting Strategies Success Fraction of Varying Numbers of Fields per Message Success Fractions for Protocols Using Timestamps Success Fractions for Example Hybrid Protocol Specification Summary of Experimental Results Experiments on the Success Fractions, Part One Experiments on the Success Fractions, Part Two Weighting Strategies for M = Fitness Weightings for the Symmetric Key Protocols Fitness Function Weightings for the Searches Summary of Experimental Results Rules for Extracting Protocol Primitives Rules for Removing Redundant Identifiers ix

12 x

13 Acknowledgements I would like to express my sincere gratitude to my supervisors Professor John Clark and Dr. Jeremy Jacob for their guidance, patience and encouragement. Without their help and support, this work would not have been possible. I would also like to thank Professor Susan Stepney, for her constructive comments and high standards. Thank you also to my external assessor, Professor Colin Boyd, for his insightful comments. Particular thanks must be extended to the many colleagues and friends at the Department of Computer Science who have helped shape my technical understanding of security and heuristic search. Indeed, my friends in the University of York have made my PhD a wonderful experience that I will never forget. The list is so long and I cannot risk leaving anybody out. Finally, a very special thank you to my parents for their unconditional love and inspiration. If it were not for them, I would never have completed this work. Thanks also go to Weiming Cao for always believing in me. xi

14 xii

15 Author s Declaration This thesis is the work of Hao Chen and was carried out at the University of York. Work appearing here has appeared in print as follows: Hao Chen, John Clark, and Jeremy Jacob. Automated design of security protocols. In Proceedings of the 2003 Congress on Evolutionary Computation, pages IEEE Press, 2003 [Chen et al., 2003]. Hao Chen, John Clark, and Jeremy Jacob. A search-based approach to the automated design of security protocols. Technical Report YCS , University of York, 2004 [Chen et al., 2004a]. Hao Chen, John Clark, and Jeremy Jacob. Automated design of security protocols. Computational Intelligence, 20(3): , 2004 [Chen et al., 2004b]. Hao Chen, John Clark, and Jeremy Jacob. Synthesising efficient and effective security protocols. In ARSPA 2004: Proceedings of the 1st Automated Reasoning for Security Protocol Analysis Workshop, 2004 [Chen et al., 2004c]. Hao Chen, John Clark, and Jeremy Jacob. Human competitive security protocols synthesis. In GECCO 2006: Proceedings of the 8th Annual Conference on Genetic and Evolutionary Computation, pages ACM Press, 2006 [Chen et al., 2006]. Except where stated, all of the work contained within this thesis represents the original contribution of the author. xiii

16 xiv

17 Chapter 1 Introduction 1.1 Design of Security Protocols Security protocols are used repeatedly by vast numbers of agents in a system and are crucial components of network security architectures. A good security protocol must guarantee information is exchanged in a manner that allows principals to be confident that identified security properties have been maintained. If such a protocol turns out to be flawed then a system using it (and there may be very many such systems) will be in deep trouble. A widely used protocol is a potential single point of failure. It is crucial that we design protocols so that we can be confident that they achieve specified security objectives. The evidence from academic literature suggests that this is a very difficult task. Great emphasis has been given to formal and tool supported analysis of such protocols, yet surprisingly little effort has been expended on the automatic design of security protocols. The design of protocols is almost invariably carried out by humans. In the long run, it would be more effective and efficient to incorporate formal methods in the design process and so save the expense of redesign. In this thesis I demonstrate an heuristic automated approach to the synthesis of efficient protocols in which we can have high confidence. A flexible framework has been created to demonstrate proof of concept. This is described below. 1

18 Chapter 1 Introduction 1.2 Security Protocol Synthesis Framework The security protocol synthesis framework, or toolkit, makes use of a widely studied approach, namely the use of belief logics to specify desired security properties. We search over the space of candidate abstract protocols, simulating them to evaluate what they actually achieve. A measure of how well the actual achievements match the required goals provides guidance to this search. A highly unusual feature of the approach is that the simulation (execution) of the abstract protocol corresponds to a proof that the abstract protocol actually achieves what it does. When we finally find a abstract protocol whose achievements match those required, the execution of that protocol is a proof that the protocol achieves those results. Thus we have evolved a provably correct abstract protocol. The correctness of a security protocol is a crucial design goal, but other, non-security criteria (most typically efficiency criteria) are also of considerable importance. The definition of efficiency will vary according to circumstance. Furthermore, designers often wish to find an efficient way of implementing a specification and they may also want to explore the consequences of making different initial assumptions. Our aim is to show that a wide range of security protocols, whose specification includes efficiency concerns, as well as correctness concerns, can be synthesised automatically. The search operates over a space of abstract protocols (described in SVO logic). I have developed further procedures to compile concrete implementation level protocols from those abstractions, and also to remove redundancies. I incorporate checking of the protocols by analysis with other techniques to ensure that the refinement process has not introduced flaws. After this, a Java implementation of the synthesised protocol can be generated. Figure 1.1 shows the framework to synthesise secure cryptographic protocols. I have experimented extensively with the toolkit. I have examined the protocols in the Secure Protocols Open Repository (SPORE) online library. The toolkit has been able to generate automatically all of those humandesigned protocols, whose specification can be expressed in the notion of the toolkit. These are the products of human endeavour over almost 30 2

19 1.2 Security Protocol Synthesis Framework Figure 1.1: Pipeline of Synthesising Protocols 3

20 Chapter 1 Introduction years. Protocol synthesis in the framework typically takes no more than a few minutes. 1.3 The Thesis Statement of the Hypothesis My hypothesis is: Realistic security protocols, whose specification includes both correctness concerns and efficiency concerns, can be generated automatically. The hypothesis is supported by the pipeline of the security protocol synthesis framework (see Figure 1.1). The whole process of synthesising security protocols is fully automated Brief Overview of the Thesis Chapters The subsequent chapters contain: Chapter 2 Design of Security Protocols provides an overview of security protocols. It introduces basic security protocol terminology and some fundamental topics in this area: attacks on security protocols, verification techniques and design principles and techniques. It provides a summary of each topic and explains how these areas are related. The existing methodologies for security protocol design are briefly discussed. Chapter 3 Searching for Secure BAN Protocols extends Clark and Jacob s work [Clark and Jacob, 2000, 2001] to the synthesis of public key based protocols and hybrid protocols. This chapter shows that the heuristic search approach for synthesising abstract security protocols is highly flexible and reliable, and therefore merits further investigation. 4

21 1.3 The Thesis Chapter 4 Searching for Efficient and Secure SVO Protocols extends the heuristic search approach to the use of SVO logic, a more sophisticated and realistic logic than BAN logic, as well as to the incorporation of various efficiency concerns. This extension increases design choice and allows a wider range of protocols to be evolved, and also gives greater confidence in the practical security of evolved protocols. Chapter 5 Refinement of Security Protocols presents a rule-based refinement approach to generate concrete level protocols from abstract level SVO protocols. This chapter shows that implementation of realistic security protocols can be generated automatically from the synthesised SVO protocols, and completes the pipeline of synthesising security protocols. Chapter 6 Evaluation and Conclusions examines the achievements of the research reported in this thesis and evaluates the degree to which the hypothesis has been justified. Appendix A Supporting Material demonstrates how the security protocol synthesis framework works and presents some example results. 5

22 6

23 Chapter 2 Design of Security Protocols This chapter reviews the literature of the design techniques that have been developed for security protocols. This review includes both informal and formal techniques, such as: prudent engineering principles, logics for security protocol design and others. Because some of these design methods have been developed based on protocol verification techniques, this chapter also reviews some well known formal verification techniques. 2.1 Background and Building Blocks Over the past two decades, security protocol verification has been the area where the bulk of the research in security protocols has taken place, and a number of successful supporting tools have been developed. However, little research has been done in the area of applying formal methods to the design of security protocols in the first place, despite the wide recognition that the design of security protocols is very difficult. Most existing protocols have been designed using informal methods and heavily rely on the verification process to pick up vulnerabilities in designs. In the long run, it would be more effective and efficient to incorporate formal methods in the design process and so save the expense of redesign. This situation has an analogy in the verification process of general purpose computer programs, where reliable testing techniques allow many bugs to be found, but will not provide a basis for complete proof of correctness. To begin with, I will 7

24 Chapter 2 Design of Security Protocols review some background of security protocols as well as cryptographic primitives of security protocols in this section Notation and Cryptographic Primitives A security protocol is a protocol that uses cryptographic primitives to let principals communicate securely over an insecure network. Security requirements normally include goals such as principal authenticity, data confidentiality, message non-repudiation and others. With the help of security protocols, principals that do not share any secret key, and may not even have any knowledge of each other beyond possibly an identifier, can establish a key for a secure communication session. To specify security protocols, I will use the standard notation. 1 The sequence of messages 1. A B : M 1 2. B S : M 2 3. S A : M 3 specifies a protocol in which principal A sends M 1 to principal B, B then sends M 2 to server S who then sends M 3 to principal A. A message may have some or all of the following components: Principal Identifiers Identifiers represent the participants of a protocol run. Legitimate principals in a protocol run are typically denoted by capital letters. It is common to see ordinary principals in a protocol denoted by the letters A, B, C,..., with the letter S typically denoting a trusted server of some sort, for example, a key server. An intruder, Z, acting in the role of A, is typically denoted by Z A. Plaintext In cryptography, plaintext is the form of a message or a message component which is transferred or stored without cryptographic protection. 1 Some protocol researchers call it Alice Bob notation. It is informal but is widely used in the literature to describe the steps in a security protocol. 8

25 2.1 Background and Building Blocks Ciphertext The original information is known as plaintext, and the encrypted form as ciphertext. The ciphertext message contains all the information of the plaintext message, but is not in a format readable by a human or computer without the proper mechanism to decrypt it. In this thesis the notation {X} K represents a message or a message component X encrypted with key K. Key Many of the work on the analysis of security protocols is based on the Dolev-Yao [Dolev and Yao, 1983] model or some variant, which treats encryption algorithms as black boxes. Protocol researchers are usually only interested in whether symmetric or asymmetric encryption is used. For this reason, encryption keys are classified as follows: Symmetric Key Symmetric cryptography uses the same key for both encryption and decryption. Classic examples include DES (Data Encryption Standard) [DES, 1999], and its successor AES (Advanced Encryption Standard) [AES, 2001]. A symmetric key which is shared between principals A and B is denoted by K ab. Asymmetric Key Asymmetric cryptography uses a pair of keys for encryption and decryption. These are called a public private key pair. The most well-known example is RSA (Rivest-Shamir- Adleman) cipher [Rivest et al., 1978]. A public key is so-called because it is generally available to anyone. Corresponding to the public key is a private key, which is known only to one principal. A message encrypted with the public key can be decrypted only by the corresponding private key. In some cases, the role of these keys can be swapped. Thus, a message encrypted with the private key can be decrypted only by the corresponding public key. Furthermore, if an encrypted message decrypts to an intelligible message using the public key, that encrypted message must have been created using the corresponding private key. A private key can therefore be used to put a digital signature on a message, because it is uniquely bound to an individual. Typically, different keys and different algorithms are used for decryption and digital signatures. For digital signatures, the public key is used to verify that the signature is that of the principal bound to the public key. A public and private key pair owned by principal A is denoted by K a and Ka 1 respectively. Nonce All messages in the current run of a protocol are stable for the 9

26 Chapter 2 Design of Security Protocols entirety of the protocol; however, messages in the past are not necessary carried forward into the present. Therefore, it is important for principals involved in a protocol to determine that messages they receive really have been created as part of the current run of the protocol. This is typically achieved by the inclusion in messages of data to bind messages to the current run. This data takes the form of numbers generated to be used only once (for bindings to the current run). These numbers used only once are commonly called nonces. If a principal generates a nonce for the current protocol run and receives messages that contain it, this principal may deduce that these messages have been created after the nonce was generated. A nonce is denoted by N a, where A is the principal who created the nonce. 2 Timestamp A timestamp is a value which is taken from the system clock. It is an alternative to a nonce, which provides evidence that a message has been generated recently. The sender of the message adds the current time to the message when it is sent. This is checked by the receiver when the message is received by comparing with the local time. If the received timestamp is within an acceptable window of the current time, then the message is regarded as fresh. The difficulty of using timestamps is that synchronised system clocks are required and must be maintained securely. A timestamp is denoted by T a, where A is the principal who issued the timestamp. Hash A hash value is the result of applying a hash function to a message, denoted by H(X). Hash functions are usually used to determine if a message has been corrupted. Similar to encryption algorithms, hash functions are treated as black boxes in most work on security protocols Types of Security Protocols This section provides an overview of various forms of security protocol in use today. At the highest level, security protocols are categorised according 2 Where necessary subscripts can be used. For example, if principal A generates two nonces, these could be denoted by N a1 and N a2. 10

27 2.1 Background and Building Blocks to the principal cryptographic approach taken 3, that is, symmetric key or public key. There are further distinctions that can be made: the number of messages involved in the protocols (for example, one-pass, two-pass, three-pass and others) and whether one principal wishes to convince the second of some matter (one-way or unilateral authentication) or whether both parties wish to convince each other of something (two-way or mutual authentication). These distinctions are also made by the ISO entity authentication standards [ISO, 1997]. Below I give examples of various types of protocol. They appear to be fairly straightforward and I give a flavour of the intended arguments for their secure operation. However, within apparently simple protocols, many problems may lurk. Symmetric Key Protocols Perhaps the most celebrated symmetric key protocol is the Needham Schroeder Symmetric Key Protocol [Needham and Schroeder, 1978]. The protocol, as shown in Figure 2.1, is intended to distribute the secret key K ab, which is newly generated by the server S, to the two principals, A and B, and assure each principal that the other principal has the key and is operational. The protocol assumes that key K as is already shared between A and S, andkey K bs is shared between B and S. Principal A requests from the server S a key to communicate with B. She includes a random nonce N a generated specially for this run of the protocol. This nonce will be used by A to ensure that the second message is timely. S creates a new key K ab and the second message. Only A can decrypt this message successfully since she possesses the key K as. By decrypting the second message, she obtains the key K ab and checks that the message contains the nonce N a. A also checks for the inclusion of identifier B. A passes on to B the encrypted component {K ab, A} Kbs as the third message. Principal B decrypts this message and gets the key K ab for communication with A. He then generates a nonce N b, encrypts it 3 Security protocols can also be categorised by their purposes rather than cryptographic mechanisms. For example, there are authentication protocols, key Establishment protocols, non-repudiation protocols etc. 11

28 Chapter 2 Design of Security Protocols 1. A S : A, B, N a } 2. S A : {N a, B, K ab, {K ab, A} Kbs 3. A B : {K ab, A} Kbs 4. B A : {N b } Kab 5. A B : {N b 1} Kab K as Figure 2.1: Needham Schroeder Symmetric Key Protocol using the newly obtained key K ab, and sends the result to A as the fourth message. Principal A decrypts it, forms N b 1, encrypts it and sends the result back to B as the last message. B decrypts this and checks the result is correct. Only A could have formed N b 1 and then have encrypted it. The above description reflects the intended security arguments for the Needham Schroeder Symmetric Key Protocol. The protocol is, however, flawed. Section 2.2 will demonstrate an attack on the protocol. Public Key Protocols Protocols using public key cryptography have numerous applications in authentication. Figure 2.2 is one of the most famous public key protocols, the Needham Schroeder Public Key Protocol [Needham and Schroeder, 1978]. In the protocol, the trusted server S (called the certification authority) stores the public keys of various principals and distributes them on request, sealed under its private key Ks 1. The server s public key is assumed known to the principals. Messages indexed 1, 2 and 4, 5 are used by A and B to obtain each other s public keys. Message 3 is encrypted under B s public key and so can be decrypted only by B. It contains a nonce N a together with A s identifier. B decrypts this message and gets the nonce, forms a nonce of his own N b and encrypts both nonces under A s public key and sends the result as Message 6. A then decrypts Message 6. Since 12

29 2.1 Background and Building Blocks 1. A S : A, B 2. S A : {K b, B} K 1 s 3. A B : {N a, A} Kb 4. B S : B, A 5. S B : {K a, A} K 1 s 6. B A : {N a, N b } Ka 7. A B : {N b } Kb Figure 2.2: Needham Schroeder Public Key Protocol 1. A B : {N a, A} Kb 2. B A : {N a, N b } Ka 3. A B : {N b } Kb Figure 2.3: Simplified Needham Schroeder Public Key Protocol only B could have obtained the N a, A knows that B is operational and has just responded to his recent nonce. A then encrypts B s nonce N b under B s public key K b and sends Message 7. B then decrypts and checks that it contains his nonce and concludes that A is operational and indeed initiated the protocol. Of course, it may be that A and B already possess each other s public key, in which case the protocol reduces to three messages. The simplified version of Needham Schroeder Public Key Protocol is shown in Figure 2.3. In 1995, 17 years after the Needham Schroeder Public Key Protocol was published, Lowe [1995] demonstrated an attack on the protocol; however there is some controversy over Lowe s attack. Further details of the attack and the controversy are discussed in Section

30 Chapter 2 Design of Security Protocols 1. A B : A, K a B A : {K ab } Ka A B : {N a } Kab { 4. B A : B, K b, Cert(B), {N a } K 1 b } K ab Figure 2.4: Beller Yacobi Protocol Hybrid Protocols The speed of encryption and decryption using public key algorithms has prevented their widespread use for general communication. People have proposed the use of public key cryptography to exchange symmetric encryption keys and then symmetric cryptography to secure following communication. This is an excellent use of the public key technology and several such hybrid protocols have been proposed. An example of such a protocol is the Beller Yacobi protocol [Beller and Yacobi, 1993]. The protocol is designed to satisfy the requirements of mobile communications environments. It is intended to provide security between a mobile station and a base station. The protocol is shown in Figure 2.4. Upon receiving the base A s public key K a, the mobile B generates session key K ab and uses K a to encrypt it, then sends the encrypted message to A. Only A could decrypt the second message and get the K ab. In the third message, A sends a nonce N a encrypted using K ab. B then returns N a signed using his private key together with his identifier, public key and certificate Cert(B), all encrypted by K ab. The certificate is known as the secret certificate of the mobile station, which is issued by a trusted central authority. The certificate can be checked by anyone using the public key of the central authority in order to verify the mobile s identity. The certificate must be kept secret from all other mobile users and eavesdroppers, because it is all that is required to masquerade as the owner of the certificate. Finally, A decrypts this message and verifies the signature on N a. The Beller Yacobi protocol is unfortunately flawed. Beller and Yacobi [1993] presented a parallel session attack on the protocol. 14

31 2.2 Attacks on Security Protocols Other Forms of Protocols In the literature, there are many other types of security protocol. For example, protocols that deal with non-repudiation, in which principals exchange messages whilst ensuring that each of the principals can prove to a third party that a message has been sent and/or received, and secret voting, in which an observer can receive votes and ensure that double voting does not occur but is not able to determine which vote comes from which voter. Schneier [1996] provides a detailed review of the wide variety of security protocols which have been developed. 2.2 Attacks on Security Protocols Research on attacking security protocols is important. It has revealed that various styles of attack may happen on almost every level when people design and implement security protocols, which is the reason why security protocols are so difficult to get right. Flawed protocols are often used to test new analysis and verification methods, to see if certain flaws can be discovered by that technique. The purpose of this section is to summarise and illustrate various styles of attacks on security protocols. These attacks will be referred to in later chapters when discussing methods that are used to design and verify security protocols Freshness Attacks These are also known as replay attacks [Syverson, 1994]. A freshness attack occurs when a message (or message component) from a previous run of a protocol is recorded by an intruder and replayed as a message component in the current run of the protocol. If a protocol does not have any mechanism to distinguish different runs of the protocol, it is quite possible to fool an honest principal into running the protocol with an intruder. A classic example of such an attack occurs in the Needham Schroeder Symmetric Key Protocol, which is described in Figure

32 Chapter 2 Design of Security Protocols 1.1 A S : A, B, N a } 1.2 S A : {N a, B, K ab, {K ab, A} Kbs 1.3 A B : {K ab, A} Kbs 2.3 Z A B : {K ab, A} Kbs 2.4 B Z A : {N b } Kab 2.5 Z A B : {N b 1} Kab K as Figure 2.5: An Attack on the Needham Schroeder Symmetric Key Protocol The desired goal of the Needham Schroeder Symmetric Key Protocol is that, at the end of a run of the protocol, each principal should be in possession of the secret key K ab recently generated by the server S and believe that the other has the key. In 1981, Denning and Sacco demonstrated that the protocol was flawed [Denning and Sacco, 1981]. The attack is shown in Figure 2.5. Consider the third message, Although B decrypts this message and assumes legitimately that it was created by the server S, there is nothing in the message to indicate that it was actually created by S as part of the current protocol run. Suppose that A had earlier invoked the protocol and had been provided with a session key K ab to talk to B. After that, A and B will have discarded the key. However, an intruder Z may have monitored the network when the corresponding protocol run was executed and recorded messages including the third one {K ab, A} Kbs. Z can cryptanalyse ciphers offline and eventually break the key K ab. By the time Z breaks the key, he can now fool B into accepting the compromised key as new by intercepting Message 1.3 and then following Messages 2.3, 2.4 and 2.5 in Figure 2.5. B believes he is following the correct protocol. Z is able to form the correct response in Message 2.5 because he knows the compromised key K ab. He can now engage in communication with B using the compromised key and masquerade as A. 16

33 2.2 Attacks on Security Protocols 1.1 A Z : {N a, A} Kz 2.1 Z A B : {N a, A} Kb 2.2 B Z A : {N a, N b } Ka 1.2 Z A : {N a, N b } Ka 1.3 A Z : {N b } Kz 2.3 Z A B : {N b } Kb Figure 2.6: An Attack on the Simplified Needham Schroeder Public Key Protocol Parallel Session Attacks A common assumption of the ability of an intruder is that the intruder may start any number of parallel protocol runs between any principals including different runs involving the same principals and with principals taking the same or different protocol roles. A parallel session attack occurs when two or more protocol runs are executed concurrently and messages from one are used to form messages in another. Lowe [1995] demonstrated a parallel session attack on the Needham Schroeder Public Key protocol in 1995, 17 years after the protocol was published. The attack is illustrated in Figure 2.6. In this attack, the intruder Z is actually a recognized principal, that is, he is known to the other principals and has a certified public key which is also known to other principals. Suppose that principal A starts a protocol run with Z, thinking of Z as an honest principal. Z, however, impersonates A to establish a false protocol run with B. In Message 2.1, Z uses A s nonce N a and inserts A s identifier instead of his own. Principal B replies with his nonce N b, but he will of course encrypt the Message 2.2 with A s public key as he thinks that this run was started by A. The Message 2.2, which is then forwarded to A by Z as Message 1.2, is exactly what A is expecting from Z. Thus, A dutifully proceeds to the next step, in which A sends Message 1.3 that contains nonce N b and encrypted with Z s public key. Z can decrypt this message and get N b. By the time Z gets N b, he can 17

34 Chapter 2 Design of Security Protocols construct the Message 2.3, the final message of the run Z started with B, by encrypting N b with B s public key. Note that there is some controversy over Lowe s attack. Lowe s attack violates the following protocol goal, which is named weak agreement for B by Lowe. A has previously been running the protocol, apparently with B [Lowe, 1996]. It is clear that Lowe s attack proves the protocol does not satisfy the the requirement of weak agreement for B. However, a careful reading of Needham and Schroeder s original paper indicates that Lowe s weak agreement for B was not among the goals of the protocol. No matter whether Lowe s attack is legitimate or not, the attack and the controversy do highlight a fact that security protocols, although fairly small in terms of number of messages, are notoriously difficult to get right. Lowe s attack has been widely used to motivate new research proposals in the area of security protocols Type-flaw Attacks A message consists of a sequence of components each with some value (for example, the identifier of a principal, the value of a nonce, or the value of a key). When the message is written on paper, its components are clearly distinct. But the message is represented at the implementation level as a sequence of bits. That is, a principal receiving a message, no matter whether the message is encrypted or not, the principal simply reads a sequence of bits that need to be interpreted. A type-flaw attack occurs when the receiver of a message accepts that message as valid but imposes a different interpretation on the bit sequence than the principal who created it intended (for example, a message component was intended as a principal s identifier, but the receiver accepts it as a key). The well known protocol of Otway and Rees provides an example of a 18

35 2.2 Attacks on Security Protocols 1. A B : M, A, B, {N a, M, A, B} Kas 2. B S : M, A, B, {N a, M, A, B} Kas, {N b, M, A, B} Kbs 3. S B : M, {N a, K ab } Kas, {N b, K ab } Kbs 4. B A : M, {N a, K ab } Kas Figure 2.7: Otway Rees Protocol 1. A Z B : M, A, B, {N a, M, A, B} Kas 4. Z B A : M, {N a, M, A, B} Kas Figure 2.8: An Attack on the Otway Rees Protocol protocol which is subject to a type-flaw attack. The protocol is shown in Figure 2.7 and two type-flaw attacks by Clark and Jacob [1997] are demonstrated in Figure 2.8 and Figure 2.9. The Otway Rees Protocol aims to distribute a new session key K ab, which is created by the trusted server S, to principals A and B. M is a protocol run identifier. K as and K bs are long term symmetric keys that A and B share with server S respectively. N a and N b are nonces chosen by A and B respectively. After initiating the protocol, principal A expects to receive a message back in Message 4 that contains her nonce N a used in Message 1 together with a new session key K ab created by server S. Due to the similarity in the encrypted parts of Messages 1 and 4 (that is, the two messages start with the same component and are encrypted by the same key) an intruder can construct Message 4 (as shown in Figure 2.8, the intruder does it by simply replaying M together with the encrypted components) and send to A. The attack depends on the length of the composite components M, A, B being the same as the session key K ab. Assume that M is (say) 64 bits long, A and B are both 32 bits long and K ab is 128 bits, then A decrypts {N a, M, A, B} Kas checks for the presence of the nonce N a and accepts M, A, B as the new key K ab, because they both have 128 bits in length. M, A and B are all 19

36 Chapter 2 Design of Security Protocols 1. A B : M, A, B, {N a, M, A, B} Kas 2. B Z S : M, A, B, {N a, M, A, B} Kas, {N b, M, A, B} Kbs 3. Z S B : M, {N a, M, A, B} Kas, {N b, M, A, B} Kbs 4. B A : M, {N a, M, A, B} Kas Figure 2.9: Another Attack on the Otway Rees Protocol publicly known (since they were broadcasted in plain text). Similarly, as demonstrated in Figure 2.9, it is clear that an intruder can play the role of S in messages 3 and 4 simply by replaying the encrypted components of Message 2 back to B. The intruder can now listen into conversation between A and B using the now publicly available key M, A, B Implementation Dependent Attacks Some protocol specifications allow both secure and insecure implementations. An imprudent implementation approach may introduce vulnerabilities into protocols. For example, an implementation would be vulnerable if the nonce generation function, which is used by the implementation, makes nonces predictable, although the protocol definition is secure. A subtle area where implementation dependent attacks may arise is the interaction between a specific protocol and the actual cryptographic algorithm used. This section shows that the imprudent use of a bit stream cipher in context of the Amended Needham Schroeder Symmetric Key Protocol, which is shown in Figure 2.10, may produce vulnerable results. The Amended Needham Schroeder Symmetric Key Protocol was proposed in 1987 to resist the freshness attack described in Figure 2.5. The protocol was thought to be secure but Boyd [1990] demonstrated an implementation dependent attack on it in The vulnerability lies in the last two messages of the protocol. 20

37 2.2 Attacks on Security Protocols 1. A B : A 2. B A : {A, N b } Kbs 3. A S : A, B, N a, {A, N b } Kbs } 4. S A : {N a, B, K ab, {K ab, N b, A} Kbs 5. A B : {K ab, N b, A} Kbs 6. B A : {N b } Kab 7. A B : {N b 1} Kab K as Figure 2.10: Amended Needham Schroeder Symmetric Key Protocol Suppose the implementation use a bit stream cipher 4 to encrypt data. Now if N b is odd then the final bit will be 1 and N b 1 will differ only in the final bit. On a bit by bit encryption basis, the cipher stream for Message 7 can be formed simply by flipping the value of the final bit of the cipher stream for Message 6. As long as nonce N b is chosen randomly, it will be odd half of the time and so this form of attack has a half chance of succeeding Other Forms of Attack There are some other attacks which can be applied to security protocols. For example, in Binding Attacks, an adversary may choose or modify certificate information to attack one or more protocol runs 5 ; in Denial of Service Attacks, an adversary may prevent legitimate users from completing the protocol by exhausting the computational resources of the server; in Known-plaintext Attacks, an attacker has samples of both the plaintext and its encrypted version (ciphertext) and is at liberty to make use of them to reveal further secret information (typically this is the secret key). The list of attacks in this section may be regarded as the most common 4 A bit stream cipher encrypts a plain text bit stream on a bit by bit basis. 5 In public key protocols, the certificate of a principal acts as an assurance from a trusted authority that the principal s public key does belong to that principal. 21

38 Chapter 2 Design of Security Protocols threats that are considered in designing security protocols. It is, however, not exhaustive. The ways in which an adversary may interact with one or more protocol runs are infinite; attacks on security protocols are only limited by the genius of the adversary. Indeed, there is no need to worry about whether the list of attacks is exhaustive; what is really required is confidence that a security protocol meets its security objectives given a known list of assumptions (and the assumptions should be as weak as possible). In conclusion, protocol design might seem a simple task; protocols often comprise only a few messages. This is, however, clearly deceptive and the examples we have shown in this section indicate that the design of secure protocols is a remarkably subtle affair. It also indicates that a systematic (and automated) approach to analysis is essential. The next section reviews some of the methods and tools that have been used to date. 2.3 Verification Techniques There is a rich history of research on formal verification and on reasoning about security protocols. This section reviews some well known (and relevant to this thesis) formal verification techniques which have been developed to prove that a protocol specification satisfies certain security goals. The techniques can be divided into three major categories: techniques based on modal logic, techniques based on state machines and computational complexity approach. To begin with, I will review the Dolev-Yao model because the first two categories both incorporate at least some aspects of the work of Dolev and Yao [1983], followed by detailed reviews of each of the three categories. In the Dolev-Yao model, the network is assumed to be under the control of an adversary, all messages sent from any honest principal to any other must pass through the adversary. The adversary can read, alter, redirect and delete any or all messages, and may have control of one or more network principals. However, it is assumed, cryptographic operations are 22

39 2.3 Verification Techniques used in a black box fashion, ignoring various cryptographic properties. The adversary can only decrypt a message if it has the right keys. The adversary can only compose new messages from keys and messages that it already possesses Techniques Based on Modal Logic One of the most commonly followed approaches is to use logics of belief and knowledge to reason about security protocols. Such logics consist of various statements of beliefs in or knowledge about messages in a security protocol and inference rules for deriving new beliefs or knowledge from existing beliefs or knowledge. The greatest amount of effort has been expended in the use of belief logics and it is to this that we turn our attention first. The seminal work of this approach, and perhaps the best known and most influential, was developed by Burrows, Abadi and Needham in 1989 [Burrows et al., 1989]. BAN logic focuses on the beliefs that can be held by honest principals involved in security protocols and on the evolution of these beliefs as a consequence of communication throughout the course of a protocol. For example, one BAN belief, stated informally, would be: If I believe I have received a message encrypted with key K, and I believe that only Alice and I know the key K, then I believe that the message was originated by either Alice or me. In an analysis of a protocol, a set of initial beliefs are assumed. Each message in the protocol is represented by a set of beliefs it is meant to convey. An analyst then uses BAN inference rules to determine what beliefs can be derived from the initial beliefs and the beliefs gained from messages. BAN inference rules are simple and intuitive and are very easy to apply. Even so, as the BAN paper demonstrated, the logic can be used to identify many serious flaws in security protocols. The use of BAN logic forces the analyst to explicitly identify assumptions and provides a means of deriving what is actually achieved by the protocol. To achieve specific security goals, the analyst may be forced to adopt dubious assumptions. Thus, for example, the Needham Schroeder Symmetric 23