A Search-Based Framework for Security Protocol Synthesis

(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

(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.

(4)

(5)

List of Figures

1.1 Pipeline of Synthesising Protocols . . . 3

2.1 Needham–Schroeder Symmetric Key Protocol . . . 12

2.2 Needham Schroeder Public Key Protocol . . . 13

2.3 Simplified Needham Schroeder Public Key Protocol . . . 13

2.4 Beller–Yacobi Protocol . . . 14

2.5 An Attack on the Needham Schroeder Symmetric Key Protocol 16 2.6 An Attack on the Simplified Needham Schroeder Public Key Protocol . . . 17

2.7 Otway–Rees Protocol . . . 19

2.8 An Attack on the Otway–Rees Protocol . . . 19

2.9 Another Attack on the Otway–Rees Protocol . . . 20

2.10 Amended Needham Schroeder Symmetric Key Protocol . . 21

2.11 Basic SA for Maximisation Problems . . . 31

2.12 Illustration of SA for Maximisation Problems . . . 32

3.1 An Example of a BAN Protocol . . . 41

3.2 Interpreting an Integer Sequence . . . 44

3.3 Interpreting an Integer Sequence . . . 49

3.4 Public Key Protocol Generated During Experimentation . . 53

3.5 Public Key Protocol With Additional Assumptions . . . 54

3.6 Public Key Protocol Using Timestamps . . . 57

3.7 A hybrid encryption protocol . . . 59

4.1 An Example of SVO Protocol . . . 75

4.2 Protocol Found in The First Search . . . 86

4.3 Protocol Found in The Second Search . . . 88

4.4 Protocol Found in The Third Search . . . 89

4.5 Public Key Protocol Found in The First Search . . . 92

4.6 Public Key Protocol Found in The Second Search . . . 92

(10)

List of Figures

4.8 Key Agreement Protocol Found in The Second Search . . . 96

5.1 Concrete Symmetric Key Protocol at Refinement Step One . 107 5.2 Concrete Public Key Protocol at Refinement Step One . . . . 107

5.3 Concrete Symmetric Key Protocol at Refinement Step Two . 108 5.4 Concrete Public Key Protocol at Refinement Step Two . . . . 108

5.5 Final Concrete Symmetric Key Protocol . . . 112

5.6 Final Concrete Public Key Protocol . . . 113

5.7 Otway–Rees Protocol with Tags . . . 116

5.8 Otway–Rees Protocol with Index . . . 117

5.9 Otway–Rees Protocol with Rearranged Messages . . . 117

5.10 A Symmetric Key Protocol . . . 121

(11)

List of Tables

3.1 Clark and Jacob’s Weighting Strategies . . . 47

3.2 Success Fraction of Varying Numbers of Fields per Message 55 3.3 Success Fractions for Protocols Using Timestamps . . . 57

3.4 Success Fractions for Example Hybrid Protocol Specification 60 3.5 Summary of Experimental Results . . . 63

3.6 Experiments on the Success Fractions, Part One . . . 65

3.7 Experiments on the Success Fractions, Part Two . . . 66

4.1 Weighting Strategies for M=9 . . . 82

4.2 Fitness Weightings for the Symmetric Key Protocols . . . 85

4.3 Fitness Function Weightings for the Searches . . . 91

4.4 Summary of Experimental Results . . . 100

5.1 Rules for Extracting Protocol Primitives . . . 106

(12)

(13)

Acknowledgements

I would like to express my sincere gratitude to my supervisors Profes-sor 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.

(14)

(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 secu-rity protocols. In Proceedings of the 2003 Congress on Evolutionary Computation, pages 2181–2188. 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–2004–376, University of York, 2004 [Chen et al., 2004a].

• Hao Chen, John Clark, and Jeremy Jacob. Automated design of secu-rity protocols. Computational Intelligence, 20(3):503–516, 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 se-curity protocols synthesis. In GECCO 2006: Proceedings of the 8th Annual Conference on Genetic and Evolutionary Computation, pages 1855–1856. 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.

(16)

(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.

(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 proto-cols, 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 con-siderable 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 imple-mentation 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 crypto-graphic 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 human-designed protocols, whose specification can be expressed in the notion of the toolkit. These are the products of human endeavour over almost 30

(19)

1.2 Security Protocol Synthesis Framework

(20)

Chapter 1 Introduction

years. Protocol synthesis in the framework typically takes no more than a few minutes.

1.3 The Thesis

1.3.1 Statement of the Hypothesis

My hypothesis is:

Realistic security protocols, whose specification includes both correctness con-cerns and efficiency concon-cerns, can be generated automatically.

The hypothesis is supported by the pipeline of the security protocol synthe-sis framework (see Figure 1.1). The whole process of synthesynthe-sising security protocols is fully automated.

1.3.2 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.

(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 so-phisticated 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 refine-ment approach to generate concrete level protocols from abstract level SVO protocols. This chapter shows that implementation of realistic se-curity 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.

(22)

(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

(24)

Chapter 2 Design of Security Protocols

review some background of security protocols as well as cryptographic primitives of security protocols in this section.

2.1.1 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 : M1 2. B→S : M2 3. S→A : M3

specifies a protocol in which principal A sends M1 to principal B, B then sends M2 to server S who then sends M3 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 ZA. 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}

(25)

2.1 Background and Building Blocks

Ciphertext The original information is known as plaintext, and the en-crypted 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}_Krepresents 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 (Ad-vanced Encryption Standard) [AES, 2001]. A symmetric key which is shared between principals A and B is denoted by Kab. 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 Ka and K−_a1 respectively. Nonce All messages in the current run of a protocol are stable for the

(26)

entirety of the protocol; however, messages in the past are not nec-essary 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 Na, 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 Ta, 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.

2.1.2 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}

(27)

2.1 Background and Building Blocks

to the principal cryptographic approach taken3, 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 mu-tual 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 Kab, 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 Kasis already shared between A and S, andkey Kbs is shared between B and S.

Principal A requests from the server S a key to communicate with B. She includes a random nonce Na 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 Kab and the second message. Only A can decrypt this message successfully since she possesses the key Kas. By decrypting the second message, she obtains the key Kab and checks that the message contains the nonce Na. A also checks for the inclusion of identifier B. A passes on to B the encrypted component{Kab, A}Kbs as the

third message. Principal B decrypts this message and gets the key Kab for communication with A. He then generates a nonce Nb, 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.

(28)

1. A→S : A, B, Na

2. S→A : nNa, B, Kab,{Kab, A}_K

bs o Kas 3. A→B : {Kab, A}Kbs 4. B→A : {Nb}Kab 5. A→B : {Nb−1}K_ab

Figure 2.1: Needham–Schroeder Symmetric Key Protocol

using the newly obtained key Kab, and sends the result to A as the fourth message. Principal A decrypts it, forms Nb−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 Nb−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 K−_s 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 Na together with A’s identifier. B decrypts this message and gets the nonce, forms a nonce of his own Nb and encrypts both nonces under A’s public key and sends the result as Message 6. A then decrypts Message 6. Since

(29)

2.1 Background and Building Blocks 1. A→S : A, B 2. S→A :{Kb, B}_K−1 s 3. A→B :{Na, A}_K b 4. B→S : B, A 5. S→B :{Ka, A}_K−1 s 6. B→A :{Na, Nb}_K a 7. A→B :{Nb}Kb

Figure 2.2: Needham Schroeder Public Key Protocol

1. A→B : {Na, A}_K

b

2. B→A : {Na, Nb}Ka

3. A→B : {Nb}Kb

Figure 2.3: Simplified Needham Schroeder Public Key Protocol

only B could have obtained the Na, A knows that B is operational and has just responded to his recent nonce. A then encrypts B’s nonce Nb under B’s public key Kb 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 2.2.2.

(30)

Chapter 2 Design of Security Protocols 1. A→B : A, Ka 2. B→A : {Kab}Ka 3. A→B : {Na}_K ab 4. B→A : nB, Kb, Cert(B),{Na}_K−1 b o Kab

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 Ka, the mobile B generates session key Kaband uses Ka to encrypt it, then sends the encrypted message to A. Only A could decrypt the second message and get the Kab. In the third message, A sends a nonce Na encrypted using Kab. B then returns Na signed using his private key together with his identifier, public key and certificate Cert(B), all encrypted by Kab. 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 Na.

The Beller–Yacobi protocol is unfortunately flawed. Beller and Yacobi [1993] presented a parallel session attack on the protocol.

(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.

2.2.1 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 2.1.

(32)

1.1 A →S : A, B, Na

1.2 S →A : nNa, B, Kab,{Kab, A}_K

bs o Kas 1.3 A →B : {Kab, A}Kbs 2.3 ZA→B : {Kab, A}Kbs 2.4 B →ZA : {Nb}K_ab 2.5 ZA→B : {Nb−1}Kab

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 Kab 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 as-sumes 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 Kab to talk to B. After that, A and B will have discarded the key. However, an intruder Z may have moni-tored the network when the corresponding protocol run was executed and recorded messages including the third one{Kab, A}_K

bs. Z can cryptanalyse

ciphers offline and eventually break the key Kab. 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 Kab. He can now engage in communication with B using the compromised key and masquerade as A.

(33)

2.2 Attacks on Security Protocols 1.1 A →Z :{Na, A}_K_z 2.1 ZA→B :{Na, A}Kb 2.2 B →ZA :{Na, Nb}Ka 1.2 Z →A :{Na, Nb}Ka 1.3 A →Z :{Nb}_K_z 2.3 ZA→B :{Nb}Kb

Figure 2.6: An Attack on the Simplified Needham Schroeder Public Key Protocol

2.2.2 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 Na and inserts A’s identifier instead of his own. Principal B replies with his nonce Nb, 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 Nb and encrypted with Z’s public key. Z can decrypt this message and get Nb. By the time Z gets Nb, he can

(34)

construct the Message 2.3, the final message of the run Z started with B, by encrypting Nb 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.

2.2.3 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).

(35)

2.2 Attacks on Security Protocols 1. A→B : M, A, B,{Na, M, A, B}_K_as 2. B→S : M, A, B,{Na, M, A, B}_K as,{Nb, M, A, B}Kbs 3. S→B : M,{Na, Kab}Kas,{Nb, Kab}Kbs 4. B→A : M,{Na, Kab}Kas

Figure 2.7: Otway–Rees Protocol

1. A →ZB : M, A, B,{Na, M, A, B}_K

as

4. ZB→A : M,{Na, M, A, B}_K_as

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 Kab, which is created by the trusted server S, to principals A and B. M is a protocol run identifier. Kas and Kbs are long term symmetric keys that A and B share with server S respectively. Na and Nb 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 Na used in Message 1 together with a new session key Kab 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 Kab. Assume that M is (say) 64 bits long, A and B are both 32 bits long and Kabis 128 bits, then A decrypts{Na, M, A, B}Kas

checks for the presence of the nonce Na and accepts M, A, B as the new key Kab, because they both have 128 bits in length. M, A and B are all

(36)

Chapter 2 Design of Security Protocols 1. A →B : M, A, B,{Na, M, A, B}_K_as 2. B →ZS : M, A, B,{Na, M, A, B}Kas,{Nb, M, A, B}Kbs 3. ZS→B : M,{Na, M, A, B}Kas,{Nb, M, A, B}Kbs 4. B →A : M,{Na, M, A, B}_K as

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.

2.2.4 Implementation Dependent Attacks

Some protocol specifications allow both secure and insecure implementa-tions. An imprudent implementation approach may introduce vulnerabili-ties 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 1990. The vulnerability lies in the last two messages of the protocol.

(37)

2.2 Attacks on Security Protocols 1. A→B : A 2. B→A :{A, Nb}Kbs 3. A→S : A, B, Na,{A, Nb}Kbs 4. S→A :nNa, B, Kab,{Kab, Nb, A}Kbs o Kas 5. A→B : {Kab, Nb, A}K_bs 6. B→A :{Nb}Kab 7. A→B : {Nb−1}Kab

Figure 2.10: Amended Needham Schroeder Symmetric Key Protocol

Suppose the implementation use a bit stream cipher4to encrypt data. Now if Nb is odd then the final bit will be 1 and Nb−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 Nb is chosen randomly, it will be odd half of the time and so this form of attack has a half chance of succeeding.

2.2.5 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 runs5; 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}

(38)

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 computa-tional complexity approach. To begin with, I will review the Dolev-Yao model because the first two categories both incorporate at least some as-pects 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

(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.

2.3.1 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 dubi-ous assumptions. Thus, for example, the Needham Schroeder Symmetric

(40)

Key Protocol can be “proved” secure, but if only a dubious assumption is made about the freshness of the key Kab [Burrows et al., 1989]. It is interesting to note that the assumptions of many protocols are often not made explicitly.

However, BAN logic misses some flaws because of its various limitations. For example, it does not model the distinction between seeing a message and understanding it; all principals are assumed to behave correctly ac-cording to the rules of the protocol; it does not model knowledge and cannot be used to prove results about secrecy, and can be used only to reason about authentication. In particular, the idealisation process (map-ping from protocol specification to BAN logic specification) has been the widely acknowledged weakest link of BAN reasoning. Further details of the idealisation problem will be discussed in chapter 5.

Consequently, many variations and enhancements of the BAN logic have been developed. These new belief logics, such as AT logic [Abadi and Tuttle, 1991], GNY logic [Gong et al., 1990] and SVO logic [Syverson and van Oorschot, 1996] can be categorised as members of the “BAN family”. Besides the “BAN family”, some other logics have also been developed for the verification of security protocols. For example, Bieber’s CKT5 logic [Bieber, 1990], can be used to reason about the evolution of knowl-edge about words used in a security protocol; Moser’s non-monotonic logic [Moser, 1989], can be used to reason about the way in which beliefs developed through use of security protocols can be reversed.

BAN logic is described in more detail in chapter 3 and SVO logic in chap-ter 4.

2.3.2 Techniques Based on State Machines

More recently, research in the area of security protocol verification has focused on state exploration tools. Much of this was inspired by Lowe’s demonstration that it was possible to use a general purpose model checker, FDR, to find an attack on the Needham-Schroeder public key proto-col [Lowe, 1995], which was not identified by the BAN logic. Thus, interest

(41)

2.3 Verification Techniques

in the belief logics has reduced as state exploration tools have improved. The idea of using CSP (Communicating Sequential Processes) and FDR (Failures Divergences Refinement) to verify security protocols was first suggested by Roscoe [1995]. Principals in a protocol are specified as CSP processes operating in parallel. In addition, an attacker of the Dolev-Yao type is added that can carry out certain actions. An authentic run of the protocol is specified (the protocol terminates with success only if the message sequence is what the protocol intended). The implementation of the protocol which comprises the various principals as agents must now be shown to satisfy the specification. The FDR tool is then used to check possible traces of the implementation against the specification. Roscoe and Gardiner [1995] have created a variety of heuristics to prune down the search space to make the model checking feasible.

Lowe’s success in finding an attack on the Needham-Schroeder public key protocol using FDR tool inspired many researchers both to prove they could reproduce his results and to apply their own techniques to other protocols. Work since then has progressed in both applying general purpose model checkers, for example, Mitchell’s Mur φ [Mitchell et al., 1997], and designing special purpose model checkers, for example, Song’s Athena [Song, 1999].

The limitation in this approach is that model checkers can only search a finite number of states. Thus, there has also been some research in showing that under certain conditions checking a finite number of states might be sufficient. For example, Lowe [1999] gives a set of conditions under which checking a small number of sessions would be sufficient to prove secrecy of a key.

2.3.3 Computational Complexity Approach

The computational complexity approach was pioneered by Bellare and Rogaway [1994] when they published a mathematical proof that a simple entity authentication protocol was secure. The approach is the same as that in the cryptographic research community to prove security of

(42)

crypto-Chapter 2 Design of Security Protocols

graphic algorithms. These are complexity-theoretic reduction proofs; the security of protocol S is reduced to the security of another better understood problem P in the sense that if there is an efficient algorithm that can break S then there is an efficient algorithm to solve P.

The approach uses a mathematical model that defines a protocol in which a powerful adversary plays a central role. The adversary essentially controls all the principals and can initiate protocol runs between any principals at any time. Insider attacks are modelled by allowing the adversary to corrupt any principals, and the adversary can also obtain previously used keys. Cryptographic algorithms may be modelled either with generic properties or as specific transformations. Security of protocols is defined in terms of matching conversations (for authentication) and indistinguishability (for confidentiality of keys) [Boyd and Mathuria, 2003].

A complete mathematical proof with respect to cryptographic definitions provides a strong assurance that a security protocol is behaving as desired. But on the other side, the computational complexity approach does suffer several limitations and the significance of a proof of security is controversial. For example, it is often difficult to obtain correct proofs of security and such proofs usually entail lengthy and complicated mathematical proofs, which are difficult to understand. Furthermore, current provable security techniques do not help in protocol design. A small change in the protocol will require a new proof to be constructed.

2.4 Design Principles

Abadi and Needham take a strong practical engineering approach provid-ing eleven useful rules in their general design guide [Abadi and Needham, 1996]. These are rules of thumb for good protocol design. They are not meant to apply to every protocol in every instance, but they do provide a list of things that should be considered when designing a protocol. The principles are summarised below. Many of them will be related to discussions and examples later in chapter 5.

(43)

2.4 Design Principles

should depend only on its content.

Principle 2 The conditions for a message to be acted upon should be clearly set out so that someone reviewing a protocol design may see whether they are acceptable or not.

Principle 3 If the identity of a principal is essential to the meaning of a message, it is prudent to mention the principal’s name in the message. Principle 4 Be clear about why encryption is being done. Encryption is

not cheap, and not asking precisely why it is being done can lead to redundancy. Encryption is not synonymous with security and its improper use can lead to errors.

Principle 5 When a principal signs material that has already been en-crypted it should not be inferred that the principal knows the content of the message. On the other hand, it is proper to infer that the principal that signs a message and then encrypts it for privacy knows the content of that message.

Principle 6 Be clear what you are assuming about nonces. (Is the nonce used simply for freshness? Is it being used to bind a message to a particular principal?) What may do for avoiding temporal succession may not do for ensuring association, and perhaps association is best established by other means.

Principle 7 The use of a predictable quantity such as the value of a counter can serve in guaranteeing newness, through a challenge response exchange. But if a predictable quality is to be effective it should be protected so that an intruder cannot simulate a challenge and later replay a response.

Principle 8 If timestamps are used as freshness guarantees by reference to absolute time then the difference between local clocks at various machines must be much less than the allowable age of a message deemed to be valid. Furthermore the time maintenance mechanism everywhere becomes part of the trusted computing base.

Principle 9 A key may have been used recently, for example to encrypt a nonce, yet be quite old, and possibly compromised. Recent use does not make the key look any better than it would otherwise.

Principle 10 If an encoding is used to present the meaning of a message, then it should be possible to tell which encoding is being used. In the common case where the encoding is protocol dependent, it should

(44)

be possible to deduce that the message belongs to this protocol, and in fact to a particular run of the protocol, and to know its number in the protocol.

Principle 11 The protocol designer should know which trust relationship his protocol depends on, and why the dependence is necessary. The reason for particular trust relations being acceptable should be explicit though they will be found on judgment and policy rather than on logic.

Anderson and Needham [1995] extended the principles of Abadi and Need-ham. Their extension introduces robust principles for the use of public key cryptography in security protocols. For example, they suggested signing a message before encryption to ensure non-repudiation of the message. Syverson [1996] analysed and discussed Anderson and Needham’s exten-sion and identified some limitations and exceptions to them. He then suggested that the design principles should be used during the entire design process in order to catch simple errors that may be introduced. Abadi and Needham noted that the design principles are guidelines rather than strict rules. For example, there are examples of protocols which violate one or some of the principles and yet are believed to be secure. Nev-ertheless, people should always consider their reasons carefully whenever they have violated any of the design principles.

2.5 Automated Design Techniques

2.5.1 Model Checking and APG

Automatic Protocol Generation, APG for short, is a tool developed by Perrig and Song [2000a,b], which uses Athena [Song et al., 2001], a model checker for security protocol verification, to generate correct and efficient protocols with reference to the desired security properties and system requirements. The tool searches the protocol space and generates candidate protocols, then Athena is applied as a protocol screener to analyse the candidates and outputs protocols which satisfy security properties. Due to the huge design

(45)

2.5 Automated Design Techniques

space, a number of state reduction rules are used to limit the candidate protocols. These rules are claimed to be intuitive; but Perrig and Song give no argument for their correctness. APG has been useful for identifying highly efficient and secure protocols when searching for small protocols (that is, four-round three-party protocols). However, APG does not easily scale up for the generation of larger protocols. The reason is that even small increases in the number of principals or protocol rounds, the protocol space will grow dramatically, and so more aggressive state reduction rules will be required. For example, Perrig and Song [2000b] estimate the protocol space may have 1012 messages on average for a four-round three-principal authentication and key agreement protocol design. Their estimate is based on their protocol generation model and the average number of messages that a principal can generate in a given round of the protocol.

2.5.2 Heuristic Search

The heuristic search approach, by Clark and Jacob [2000, 2001], considers a design space consisting of the set of all feasible protocol designs. A feasible protocol design is “series of honest exchanges between two principals” and specified in the BAN logic. Given assumptions and initial beliefs of the principals as well as desired goals of the protocol, the design space is searched to find a design which achieves the protocol goals. It is clear that this space grows exponentially as the number of messages or the number of principals rise. The choices of the belief contents of messages introduce further combinatorial complexity. For a technique to be scalable it cannot be based on simple enumeration. Clark and Jacob use heuristic search techniques (in particular simulated annealing and genetic algorithms) to search the design space. This section reviews the heuristic search technique of simulated annealing, which is used in this thesis.

For many real problems, we are faced with a choice between an accurate but impractical algorithm (in terms of computational complexity) and a close–enough or an approximate but practical algorithm. Heuristic search algorithms are widely used to solve important practical combinatorial optimisation problems. They exchange guarantees of optimality for com-putational tractability and have been defined as “a technique, which seeks

(46)

good (that is, near-optimal) solutions at a reasonable computational cost without being able to guarantee either feasibility or optimality, or even in many cases to state how close to optimality a particular feasible solu-tion is” [Reeves, 1995]. Examples of heuristic search include Simulated Annealing [Kirkpatrick et al., 1983], and Genetic Algorithms [Goldberg, 1989].

An impressive feature of these modern heuristic search methods is that they are robust across a wide range of problem types. However, the principal problem with optimisation techniques remains: they may produce solutions for which no obvious improvements can be found (that is, locally optimal) but which are not necessarily globally optimal solution to the problem posed.

Simulated Annealing

Simulated annealing is inspired by the physical process of annealing, a process of cooling molten metals in a heat bath so that a minimal energy state is reached. It was suggested as a method for the solution of complex optimisation problems by Kirkpatrick et al. in 1983 [Kirkpatrick et al., 1983].

Simulated annealing can be considered as a revised version of hill-climbing (a local optimisation search). It attempts to avoid getting stuck in a local optimum by accepting a controlled amount of inferior solutions, in the hope of finding a long-term reward: a global optimum. It controls the acceptance of inferior solutions by gradually changing the value of a parameter called temperature, from high to low. Any solution better than the current one is always accepted as the new current solution. A worse solution is accepted probabilistically based on the temperature. At high temperatures virtually any solution is accepted. At low temperatures there is little chance of an inferior solution being accepted. In the end, the temperature is reduced to zero, which means that the program will not accept any inferior solutions. Thus the search is reduced to a simple hill-climbing. The basic algorithm is shown in Figure 2.11, with a detailed explanation and an illustrative example in Figure 2.12. The search starts at some initial state S0∈ State. There is a control parameter T ∈R+ known

(47)

S :=S0 T :=T0

repeat untilstopping criterion is met repeatMILtimes

Pick Y∈ N(S) with uniform probability Pick U ∈ (0, 1)with uniform probability if f(Y) > f(S) +T ln U then S :=Y T :=α×T

Figure 2.11: Basic SA for Maximisation Problems

as the temperature. This starts high at T0and is gradually lowered, typically by geometric cooling (that is, by multiplying by a cooling factor, α ∈ (0, 1) at each iteration).

At each temperature, a number MIL (Moves in Inner Loop) of moves to new states are attempted. A candidate state Y is randomly selected from the neighbourhood N(S)of the current state. The new state Y is accepted if it is better or only slightly worse than S, as measured by a fitness function f ∈ State → R. By “slightly worse” is meant “no more than |T ln U|

lower”. Here U ∈ (0, 1) is a random variable, and so T ln U ∈ (−∞, 0); the smaller T is, the more likely that this term is close to 0 and eventually only improving moves are accepted (that is, the technique reduces to hill climbing).

The algorithm terminates when some stopping criterion is met. Common stopping criteria, and the ones used for the work in this thesis, are to stop the search after a fixed number MaxIL of inner loops have been executed, or else when some maximum number MUL of consecutive unproductive inner loops have been executed (that is, without a single move having been accepted).

Figure 2.12 is an example showing how a simulated annealing search can proceed to a globally optimal solution. It shows the distribution of the function to be maximised. From the initial state S0, the search can

(48)

Chapter 2 Design of Security Protocols ( )

Figure 2.12: Illustration of SA for Maximisation Problems

accept the inferior state and move to S1. Then the search can naturally progress to S2 and S3. Because the program can still accept the worse states with a probability based on the temperature, the search moves on to S4and S5. Later on, the temperature is reduced further, which decreases the possibility of inferior states being accepted. As a result, the search proceeds successfully to the globally optimal state S7.

This example gives an ideal situation of applying the simulated annealing technique. Suppose that the starting point is S6, the simulated anneal-ing may actually move out of the global optimum S7 and subsequently be unable to find a state of similar quality, whilst a simple hill-climbing could have come up with the globally optimal solution easily. Research also shows that to guarantee convergence to a global optimum will, in general, require more iterations than an exhaustive search [Reeves, 1995]. In practice, researchers will make practical shortcuts to give good chances of getting good solutions (for example, the best solution achieved for the whole run is recorded). There have been many applications of simulated annealing to real-world problems. Acceptable (and possibly global) solu-tions have typically been found within a minute fraction of the theoretical computational cost required for convergence.

(49)

2.5.3 Simple Logic and ASPB

Buttyán et al. [1998] developed “Simple Logic”. This logic is a BAN-like logic, but differs from others since it has been developed for use in protocol design whilst others in the BAN family have been used exclusively for verification purposes. “Simple Logic” extends BAN logic with the notion of channels with various access restrictions that can be used as the abstract model at the top layer. In particular, based on the logic they construct syn-thetic rules that they use to derive high level protocol descriptions from the goals of the protocol. Zhou and Foley [2003] proposed an automated secu-rity protocol builder (ASPB). The ASPB uses synthesis rules of the “Simple Logic” to guide a backwards search: searching for suitable protocols from desired goals. Each of the security goals is evolved to a “sub-protocol”, then the “sub-protocols” are heuristically combined to generate a final protocol. ASPB is distinct in that other approaches typically search in a forward manner: start from assumptions, searching for protocols that achieve desired goals.

2.5.4 Techniques without Tool Support

Gong and Syverson [1995] present a methodology to facilitate the design and analysis of security protocols. In particular, they propose a notion of fail-stop protocols, which stop automatically when an active attack on a protocol run is detected, thus restricting the protocol analysis to passive attacks only. Their methodology consolidates the “secrecy assumption” in BAN logic and thus puts logic–based protocol analysis on a stronger basis. This methodology, however, may be impractical for some applications, and there may be other requirements which are in conflict with those of fail-stop protocols.

Boyd [1996] proposes a framework for design of key establishment pro-tocols. In this framework, Boyd uses secure logical channels to simulate the use of cryptography without involving implementation considerations. Boyd defines two classes of channels: confidentiality channel which pre-serves the confidentiality of a message and authentication channel which enables a message recipient to determine the sender of a message. Boyd’s

(50)

framework also classifies protocols into four types, depending on how a principal derives the name of the other key recipient and how a principal derives key freshness. This framework allows protocol designers to con-sider the necessary elements in a protocol and choose between a variety of different ways in which to include these. However, Boyd’s framework is not a comprehensive one for designing security protocols in general, and deals with key establishment protocols only.

A Search-Based Framework for Security Protocol Synthesis