How To Write A Security Protocol In C#

(1)

Thesis for the Degree of

Doctor of Philosophy

Formal Analysis and Automatic Code

Generation of Security Protocols

by

Il-Gon Kim

Department of

Computer Science and Engineering

Graduate School

Korea University

(2)

(3)

Abstract

With the rapid development of communication networks, the use of security pro-tocols to achieve security goals such as confidentiality, authentication, integrity and non-repudiation is becoming more and more popular. However, many suppos-edly inviolable security protocols have been proposed in the literature and even exploited in practice, only to be found to be vulnerable later on.

Formal methods are used to guarantee the reliability and the correctness of security protocols in the design and implementation steps. This thesis firstly introduces a various types of security protocols and addresses general attack types of them. The tutorial description is completed by examples of BCY protocol, S/Key system, and RADIUS protocol.

Notwithstanding the successful verification of the design of security protocols, the implementation code for them may contain security flaws, due to the mistakes made by the programmers or bugs in the programming language itself.

Lastly, we propose an ACG-C# tool, which can be used to generate auto-matically C# implementation code for the security protocol verified with Casper and FDR. This tool enable to reduce the security weakness of security protocols which may be occurred in the implementation step. The ACG-C# approach has several different features, namely automatic code generation, secure code, and high confidence.

(4)

Acknowledgements

The work that led to this thesis would not have been possible without guidance and support from my supervisor, colleagues and family.

First and foremost, I like to thank my supervisor, Jin-Young Choi for the perfect mixture of knowledge, experience and patient with which he has guided my research.

I also would like to thank the other members of my committee, Prof. Hyuck Yoo, Prof. HeeJo Lee, Prof. Dongsu Seo and Prof. Inhye Kang, for their very helpful comments and questions.

I am also particulary grateful to all members in Formal Methods Lab., whose their friendship helped me broaden my views of life. Particulary, I would like to say thanks to Chul-Wuk Jeon, who has contributed to the research and implementation of ACG-C# tool, in section 5.

Finally, my deepest gratitude goes to my father, Hyoung-Seok Kim and my mother, Young-Ja Lee, for their ever-love and support.

(5)

5.3.1 Formal Analysis BCY protocol with Casper/FDR . . . 104 5.3.2 Formal Analysis of BCY Protocol . . . 106 5.3.3 Formal Analysis of CDF-BCY Protocol . . . 110 5.3.4 Automatic Implementation of CDF-BCY Protocol . . . 111 5.3.5 Generated C# Code for CDF-BCY Protocol . . . 113 5.3.6 Performance Results . . . 115

6 Discussion 117

6.1 Conclusion . . . 117 6.2 Future Work . . . 118

(8)

List of Figures

3.1 Transition diagrams for process P and Q using external choice

and internal choice . . . 54

3.2 Transition diagram for VM3 process . . . 56

4.1 EKE Protocol Attack Scenario . . . 70

4.2 Access-Request packet . . . 76

4.3 EAP-MD5 message flow . . . 81

5.1 The verification and code generation processes for the security protocol . . . 91

5.2 Protocol notation from ACG-C# to C# code . . . 92

5.3 C# implementation code with SCP API . . . 93

5.4 Message class diagram . . . 97

5.5 Running C# implementation code . . . 98 5.6 Generated C# implementation code for aS server(SERVCDFBCY.cs)114

(9)

List of Tables

3.1 Formal verification tools for security protocols . . . 40

3.2 Advantages and disadvantages of belief logics . . . 41

3.3 The analysis result of BCY protocol with GNY logic . . . 52

3.4 Section headers in Casper . . . 62

5.1 The Notation of BCY Protocol . . . 105

(10)

Chapter 1 Introduction

With the great development of Internet, the distribution of applications and data across computer systems is becoming more popular in society today. We use computers for everything from banking and investing to shopping and communicating with others through email or chat programs, with the great help of powerful computer systems and rapid networks.

However, the convenience and usefulness of computer systems and net-works brought about the problem of security. They are very critical to per-sonal users and every organization. Every day there is a new network security incident reported. Therefore, we always try to propose a new security solu-tion in order to protect the damage of important informasolu-tion and valuable assets against an malicious attacker. This is the reason why computer se-curity have been continuously required in academic research and our whole society.

Broadly speaking, computer security is the process of preventing and detecting unauthorized use of your computer systems. Prevention measures help you to stop unauthorized users (also known as “intruders”) from access-ing any part of your computer systems. Detection helps you to determine

(11)

whether or not someone attempted to break into your system, if they were successful, and what they may have done. But, intruders are always discov-ering new vulnerabilities (informally called “holes”) to exploit in computer systems and networks. The complexity of computer systems and networks makes it increasingly difficult to develop them in secure.

In more detail, computer systems can be considered in two aspects of

computer security and network security. To make secure computer systems,

many access controls(such as MAC, DAC, RBAC and etc) and security poli-cies are proposed. For the secure communication networks, a various of se-curity protocols(Kerberos, SSL, TLS and etc) have been proposed. They use cryptographic primitives as building blocks to achieve security goals such as confidentiality, authentication, integrity and non-repudiation. New applica-tions and systems eagerly demand security protocols suitable to their system requirements. However, many security protocols have found to be later bro-ken. Many examples of security protocols show that they are very difficult to design and implement correctly.

The research presented in this thesis lies in the area of formal verifica-tion and automatic code generaverifica-tion of security protocols. We continue this chapter by introducing the problem this thesis addresses in Section 1.1. We give an overview of the contents of this thesis in Section 1.2.

(12)

1.1 The problem this thesis addresses

A security protocol is a sequence of steps taken between two or more par-ties using cryptographic algorithms to establish security properpar-ties despite of presence of eavesdroppers. Guaranteeing security properties such as con-fidentiality(secrecy), authentication, integrity and non-repudiation are vital in security protocols.

However, many security protocols have been found that they have un-expected security flaws. In other words, design of security protocols is a very complex and difficult process. The design and implementation of security protocols are very intricate process for the following reasons[1][2] :

• Variety of requirements

As the network environments and devices prospers, new applica-tions emerge rapidly and require to develop new security protocols quickly. Different security protocols even with the same security properties vary in many system aspects such as computation over-head, communication overhead and battery power consumption. Therefore, it is not easy to design suitable security protocols that satisfy various requirements.

• Error-prone

Security protocols are intricate and attackers are powerful. If the designer has limited experience, it is likely that the security proto-col is flawed. Experiments show that even when security protoproto-cols are designed with care and examined intensely, they can still be fundamentally flawed. Due to the lack of formalism and mechan-ical assistance, manually designed protocols often suffer from the

(13)

fact that they contain undocumented assumptions. Since the im-plementation might not respect these assumptions the resulting protocols might be insecure.

• Inefficient and expensive

The current design process is often slow. It can be serious bottle-neck of the project and severely delay product development. If the protocol is flawed, high costs might incur, due to forced redesign, update plans, or liability claims.

• Software bug

Software is notoriously flawed due to unsafety of programming language itself or the mistakes of implementation progress by pro-grammers. Even if the design of security protocols is correct and secure, various implementation bugs could still easily break the network security.

To solve these problems, we use formal verification methods to show the safety of security protocols and implement ACG-C# tool which stands for Automatic Implementation of Security Protocols to C# Code.

There are many research which use formal methods for the analysis and verification of security protocols[3]. These methods have proved successful at discovering flaws with existing protocols, sometimes previously unrecognized ones. CSP/Casper and FDR tool have proved to be a very useful and effec-tive for modelling and analysis of security protocols. With Casper tool, the designer can model the message sequence of security protocols more easily, without knowing CSP notation. This process helps to reduce the complexity of design of security protocols. With formal verification methods, especially

(14)

CSP/Casper and FDR tool, we verify whether security protocols satisfies security properties(confidentiality, authentication and etc) or not; so far, no research about formal verification of S/Key and RADIUS protocols has been carried out on the literature of formal methods.

This approach guarantees the completeness and correctness of designing security protocols.

Many research efforts have been dedicated to the problem of analyzing the logical correctness of security protocols, whereas the implementation cor-rectness problem has not yet been considered so much. One of the possible approaches to ensure implementation correctness is to produce the implemen-tation code automatically from high level design of security protocols. If the design of security protocols is secure, the implementation code can show the correctness between design specification and implementation model. With ACG-C# tool, we generate C# implementation code automatically for se-curity protocols. In conclusion, our approach gets rid of implementation mistakes by programmers and software bugs(buffer overflow, type flaw and etc).

(15)

1.2 Thesis overview

We briefly outline here the following chapters with contents. Chapter 2

We introduce the background knowledge which this thesis is depen-dent. We begin by introducing cryptographic algorithms which plays a important roles in security protocols. This is followed by security prop-erties that we must guarantee in security protocols. We classify and define the meaning of security properties. Then we give an overview of security protocols and show the simple example of them. Finally, we introduce the formal methods and its two techniques(Model Checking and Theorem Proving) for the analysis of security protocols.

Chapter 3

We present the detailed modelling and verification techniques : GNY logic, Casper/CSP and FDR. GNY logic casts security protocols in formal terms to reason about the state of belief among principals in a system. This is followed by explaining the notation of GNY logic and introducing tools(SPEAR II[4] and gnytool[5]). Similarly, we present the way how to model and verify security protocols using Casper/CSP and FDR tool.

Chapter 4

We describe the modelling and verification of S/Key system which is an authentication protocol using one-time passwords scheme. S/Key system is based on Challenge & Response authentication mechanism and one-time password generator. However, it is vulnerable to the

(16)

dictionary attack which an attacker guess passphrase on the off-line. With Casper/CSP and FDR tool, we show the security weakness in S/Key system and we modify it to be strong against attackers. Finally, we confirm that modified version are robust against man-in-the-middle attack and dictionary attack.

We show PAP and EAP-MD5 based security protocol models, which are written in Casper script. Then we verify whether or not they sat-isfy such security properties as secrecy and authentication, using FDR model checking tool. In verifying these protocols with FDR tool, we were able to reconfirm some of the known security vulnerabilities which are likely to occur in wireless networks. These vulnerabilities are rela-tively simple but nevertheless constitute serious dangers, because only a few access point devices currently support enhanced security mech-anisms and software level upgrading. Finally, we discuss the counter-measure for the security of RADIUS protocol and propose a modified version against man-in-the-middle and reply attack.

Chapter 5

We introduce the overview, the input notation, the process of code gen-eration, the architecture, API of the ACG-C# tool and the advantages of our approach. We show a case study of the automatic C# code generation for the Yahalom, BCY, and CDF-BCY security protocols. Chapter 6

We present the conclusions of this thesis and the research presented throughout the dissertations is summarized. We also discuss future work that we are interested in pursuing as a result of this work.

(17)

Chapter 2 Background

This chapter describe the basic concept and terminology of Cryptographic algorithms, security properties and security protocols. The remainder of this thesis will elaborate on these concepts.

We begin with the introduction to cryptographic relying mainly on symmetric-key and public-key cryptography. Then we categorize the area of security properties that security protocols must satisfy. Lastly, we will investigate the definition and types of security protocols.

2.1 Cryptography

For the exchange of information and commerce to be secure on any network, a system or process must be put in place that satisfies security properties for confidentiality, authentication, integrity and non-repudiation. The key to the securing information on a security protocol is cryptography. Cryptogra-phy can be used as a tool to provide secrecy, to authenticate the identities of communicating parties, and to ensure message integrity. Cryptographic algorithm is the process or procedure to turn plaintext into cryptotext. A

(18)

cryptographic algorithm is also known as a “cipher”. It is very important that cryptographic algorithms that have been analyzed completely and at length are trustworthy. Theoretically, all algorithms can be broken and inherent weakness that an attacker can easily exploit. However, in the remainder of this thesis in this thesis, we assumer that all of cryptographic algorithms used in security protocols are secure against crypto-analysis.

The class of formal analysis and implementation of security protocols that we will address throughout this thesis mainly use following terminology of cryptography[10][11]:

• Encryption is the art of generating a cipher tex from a clear text, making the clear text unrecognizable. In security protocols, encryp-tion involves the use of “key”. There are two types of encrypencryp-tion : symmetric(private/secret) key and asymmetric(public) encryption. • Decryption is the art of generating a clear text from a cipher text.

In security protocols, decryption involves knowledge of “key” such as secret, private and public key.

• Symmetric Key Encryption is also referred to as private key or secret key, is based on a single key and algorithm being shared between the parties who are exchanging encrypted information. The same key both encrypts and decrypts messages. The message M encrypted by key K can be represented as MK.

• Asymmetric Key Encryption is also known as public key cryptog-raphy. Public key cryptography uses two keys as opposed to one key for asymmetric system. With public key cryptography there are two key pairs of a public key and a private key. The key’s names describe their function. One key is kept private, and the other key is made public.

(19)

Knowing the public key does not reveal the private key. A message en-crypted by the private key can only be deen-crypted by the corresponding public key. Conversely, a message encrypted by the public key can only be decrypted by the private key.

• Session Key is a secret encryption key established between two prin-cipals for communication purposes. As the name implies, this key is intended for one session only. Sometimes this session is only on protocol run; often it lasts for the lifetime of a ticket or token.

• Nonceis an identifier, usually a large random number, that is used only once. The main purpose of a nonce is to link two messages together so that a response can be recognized as fresh. A nonce is usually represented as Na or Nb etc.

• Hash Function is used to ensure the integrity of a message or file. It takes a message of any length and computes a product value of fixed length. The product is referred to as a “has value”. The length of the original message does not alter the length of the hash value. Using the actual message or file, a hash function computes a hash value, which is a cryptographic checksum of the message. This checksum can be thought of as a fingerprint for that message. The hash value can be used to determine if the message or file has been altered since the value was originally computed.

• Diffie-Hellman was the first usable public key algorithm. Diffie-Hellman is based on the difficulty of computing discrete logarithms. It can be used to establish a shared secret key that can be used by two parties for symmetric encryption. A modulus p and a primitive element a are publicly known and can be the same for all participants.

(20)

The participants X and Y randomly choose their own secret keys x, and y respectively. Because of the discrete logarithm assumption, the values ax _and_ay _{can be published as public keys. Now the participants}

can calculate the shared secret key k = (ax₎y _{= (}_ay₎x₌_axy_.

• Digital Signature is used to ensure message integrity and authenti-cation. In its simplest form, a digital signature is created by using the sender’s private key to hash the entire contents of the message being sent to create a message digest. The recipient uses the sender’s public key to verify the integrity of the message by recreating the message digest. By this process you ensure the integrity of the message and authenticate the sender.

• Digital Certificate is usually issued by a trusted third party(CA) to bind an individual or entity to a public key. The digital certificate is digitally signed by the CA with the CA’s private key. This provides independent confirmation that an individual or entity is in fact who it claims to be. A digital certificate provides a high level of confidence in the identity of the individual or entity with which you are communicat-ing. A digital certificate is a means to authenticate identity. It would include the name and address of the individual, certificate expiration date, serial number of the certificate, and the individual’s public key. • Stream Ciphers are a symmetric encryption algorithm. Stream

ci-phers can be designed to be exceptionally fast, much faster in fact than any block cipher. While block ciphers operate on large blocks of data, stream ciphers typically operate on smaller units of plaintext, usually bits. The encryption of any particular plaintext with a block cipher will result in the same ciphertext when the same key is used. With a

(21)

stream cipher, the transformation of these smaller plaintext units will vary, depending on when they are encountered during the encryption process. A stream cipher generates what is called a keystream and encryption is provided by combining the keystream with the plaintext, usually with the bitwise XOR operation.

• Block Ciphersare a type of symmetric-key encryption algorithm that transforms a fixed-length block of plaintext data into a block of cipher-text data of the same length. This transformation takes place under the action of a user-provided secret key. Decryption is performed by applying the reverse transformation to the ciphertext block using the same secret key. The fixed length is called the block size, and for many block ciphers, the block size is 64 bits. In the coming years the block size will increase to 128 bits as processors become more sophisticated.

(22)

2.2 Security Properties

To be secure against a powerful attacker, a security protocols must have cer-tain characteristic or properties. A wide variety of desirable security prop-erties have been identified for security protocols. In formal verification that a system meets a desired property by checking that a mathematical model of the system meets a formal specification that describes the property. Of special interest are properties asserting that observed behavior the system always stays within some allowed of finite behaviors, in which nothing “bad” happens. Such properties are calledsafety properties. However,liveness

prop-erties show that something ’good’ will eventually happen, may be a concern

for non-repudiation property. In this theis, safety and liveness properties are unified and called security properties. In this section, we describe the definition of security properties’ terminology[13][12][14] :

• Confidentialityproperty the concealment of information or resources. It is the protection of transmitted data from passive attacks(it is in the nature of eavesdropping on, or monitoring of, transmissions). Confiden-tiality is also called “Secrecy”. With respect to the release of message contents, several levels of protection can be identified. Confidential-ity requires that only the intended recipient can read an encrypted message[15]. To achieve this requirement only the sender and receiver may know the appropriate key[16]. This also implies that any newly created key must be fresh, and that an agent can possess a unique datum created by another only if the owner has previously agreed to share it[17].

• Authenticationproperty requires that two agents that have just com-municated using a certain key can be certain of the origin and

(23)

destina-tion of the message, respectively[18]. Authenticadestina-tion property is con-cerned with assuring that a communication is authentic. In the case of a single message, such as a warning or alarm signal, the function of the authentication property is to assure the recipient that the message is from the source that is claims to be from. Authentication property can be considered in two viewpoints : initiator authentication by responser

and responder authentication by initiator.

• Integrity property refers to the trustworthiness of data or resources, and it is usually phrased in terms of preventing improper or unau-thorized change. To attain a high level of confidence in the integrity of a message or data, a process must be put in place to prevent or detect alteration during transit. Integrity includes data integrity(the content of the information or message) and origin integrity(the source of the data, often calledauthentication). In this thesis, integrity prop-erty means the first meaning. One technique employed is called hash

function.

• Non-repudiation property means that it can be verified that the sender and the recipient were, in fact, the parties who claimed to send or receive the message, respectively. Thus, when a message is sent, the receiver can prove that the message is sent, the receiver can prove that the message was in fact sent by the alleged sender. Similarly, when a message is received, the sender can prove that the message was in fact received by the alleged server. Non-repudiation property can be consid-ered in two viewpoints : Non-repudiation of originandNon-repudiation

recept. Non-repudiation of origin is a safety property concerning the

ability of the receiver of a message to convince a third party that it was indeed sent by its supposed originator[19]. Non-repudiation of receipt

(24)

is a liveness property concerning the ability of a sender to convince a third party that the message was received[20], or will be received, by its intended recipient[19].

2.3 Security protocols

The meaning of protocol is taken as usual : a prescribed sequence of in-teractions between agents(entities) designed to achieve a certain goal and end. Protocols are nothing more than a set of formal rules or standards that are used as a basis for communication[21]. Security protocols can be defined as “sequence of message exchanges between agents designed to meet security properties such as confidentiality, authentication, integrity and non-repudiation.” Security protocols defines the rules for exchanging information between communicating agents[22]. It defines the sequence in messages must be sent and the required contents of each message. Security protocols as-sume that communicating agents already have access to appropriate keys. In symmetric systems all keys must be kept secret, but asymmetric systems rely on both public keys and private keys. The public key is freely available and is used to encrypt data that is to be sent to a particular agent. The cor-responding private key is known to the receiving agent only, and is used to decrypt the message received. The message themselves may consist of some combination of agent identity, data, keys(session key, password, private key, public key and etc), nonces, in either plaintext or encrypted forms[12]. Se-curity protocols can be mainly divided into two types of protocols according to its certain goal : key distribution protocol and authentication protocol.

(25)

2.3.1 Key distribution protocol

It determines how keys are maintained and distributed to agents that wish to communicate. Key distribution can be divided into the distribution of secret keys and public keys. The most widely known example of a key distribu-tion protocol is the Needham-Schroeder public key protocol, which exists in both flawed[18][23][24], and corrected versions[24][25][27][26]. Another exam-ples of key distribution protocols include SSL[32], TLS[33], Otway-Rees[34], Yahalom[9], Wide Mouthed Frog[9], TMN[35] protocols.

2.3.2 Authentication protocol

It is used to verify the identities of communicating agents. Authentication protocols work via the use of digital signatures. The sender of a message create a signature by hashing the message to be sent with a publicly known hashing function, and then encrypting the resulting hash value with the sender’s private key. The receiver can the check that the signature and encrypted message both came from the same source by decrypting both the signature and encrypted message with the sender’s public key, hashing the plaintext, and checking that the resulting hash value is the same as the decrypted signature. Some examples of authentication protocols include the Kerberos[29][23][28], SPX[28] and SELANE[28], S/Key[30] and RADIUS[31] and BCY[36] protocols.

Traditionally, security protocols are described using a compact and semi-formal form based on the standard list notation[37]. We now turn to show some examples of security protocols to give an overview of the notation of them.

(26)

2.3.3 Examples of security protocols

Security protocols are formulated as a sequence of message, together with the names of agents(senders, receivers and third party servers). The trans-fer of message data from A agent to B agent generally is represented as following[21].

Message n. A _→B : _{data_}

The message content data can include following notations and meanings. Atoms : This may be agents names, address and identity of agents. In addition, S generally represents the third party sever to distribute a key to each agent.

Message n. A_→B : A

Above notation means that A agent sends his identity or address of A to B in the nth message,.

Nonces : A nonce is un unpredictable, freshly generated unique number. The notation of Na means a nonce of A agent. The subscript indicates

which participant created it, but that is just a notational convenience. Encryption : The term datak represents the message data encrypted with key k. There are mainly three kinds of key types : session key(shared

key/symmetric key), private key andpublic key.

Session Key(shared key/symmetric key) : The term of Kab means the

session key that A and B agent have shared together before starting

communication. Similarly, P asswdab means the password between A and B

(27)

Message n. A _→B : dataKab

Above notation means that A agent send thedata encrypted with session key Kab to B agent in the nth message.

Private(Secret) Key : The term of SK(A) represents the public key of agent A. It is usually used to denote digital signature. Therefore,

dataSK(A) means the digital signature of data using the private key SK(A). Public Key : The term of PK(A) represents the public key of agent A. It is generally used to denote the data encryption or key distribution using public keys respectively as belows.

Message n. A_→B : dataP K(A) Message n. A_→B : KabP K(A)

Concatenation : The terms of data, data’ denotes the sequencing of data

and data’. The two terms are sent consecutively.

Message n. A_→B : A, Na

Above notation means that agent A sends the data of his identity A and nonce Na sequentially to agent B in the nth message.

Vernam Encryption : The terms ofdata (+) data’ represents the

bit-wise exclusive-or(also known as Vernam encrytption) of data and data’. The receiver should be able to create at least one of data and data’ in order to obtain other.

(28)

Hash Function : The term off represents a hash function such as MD4, MD5, SHA and etc. The notation of f(data) denotes the application of f to message data. In this case, both the sender and the recipient should be able to create f(data); the recipient will only accept a value for this message if the value received matches the value he calculates for himself. It is assumed that all hash functions are known to all agents.

Timestamp : The terms of T S1 and T Sa represent the current time and

main subject of the issued ticket. Timestamp is used to prevent replay attack.

According to the notation of security protocols mentioned in above, we summarize a various security protocols introduced in many research.

Examples 2.1 Needham-Schroeder Protocol Message1. A_→S : A, B, Na

Message2. S _→A : _{Na, B, Kab, {Kab, A}}Kas

Message3. A_→B : _{Kab, A}Kbs

Message4. B _→A : _{Nb}Kab

Message5. A_→B : _{Nb - 1}Kab

Needham-Schroeder Protocol is one of the landmark authentication pro-tocols. In the protocol, A wants to set up a connection with the responder B, and he sends his own nonce Na(Message1). Then the sever S distribute the

session key Kab to the initiator A for making a session with the responder

B(Message2). The initiator A the encrypted message of _{Kab, A} including

(29)

{Nb}to A, meaning that he received the session key safely(Message4). In the

last message, the initiator A returns back the decrement message of_{Nb−1}

to B(Message5).

Examples 2.2 Needham-Schroeder Public-Key Potocol Message1. A_→B : _{Na, A}P K(B)

Message2. B _→A : _{Na, Nb}P K(A)

Message3. A_→B : _{Nb}P K(B)

Needham-Schroeder Public Key Protocol is also one of the most land-mark authentication protocols in the literature of formal verification of secu-rity protocols. In the protocol, A seeks to establish a connection with B, and to achieve mutual authentication. Then the protocol begins with A selecting a nonce na, and sending it along with its identity to B(Message 1), encrypted using B agent’s public key. When B receives this message, it decrypts the message to obtain the nonce Na. It then returns the nonce Na, along with a

new nonce Nb, to A. encrypted with A agent’s public key(Message2). When

A agent receives this message, he should be assured that he is talking to B agent, since only B should be able to decrypt Message 1 to obtainNa. A then

returns the nonce Nb to B, encrypted with B agent’s public key(Message3).

When B receives this message, it would seem that he should be assured that he is talking to A, since only A should be able to decrypt Message2 to obtain

Nb.

Examples 2.3 TMN Protocol

(30)

Message2. S _→B : A

Message3. B _→S : A,_{Kb}P K(S)

Message4. B _→S : A,_{Ka(+)Kb}P K(S)

[Ka and Kb are session keys]

TMN(Tatebayashi Matsuzaki and Newman) Protocol concerns a mo-bile communications system. It consists of three players: an initiator A, a repsponder B and a third-party server S. In order to two agents to set up a secure session, communicating over an open channel, they must first de-cide upon a cryptographic session key, which should be kept secret from all eavesdroppers.

When the initiator A wants to connect with the responder B, he chooses a keyKa, encrypted it with the server’s public key sends it to the server(Message1).

The server S sends a message to the responder, telling him that A wants to start a session with B(Message2). The responder B acknowledges by choos-ing a session key Kb, encrypting it with the server’s public key, and sending

it to S(Message 3). The server S forms the Vernam encryption of the two keys he has received, and returns this to A(Message4). When A receives this message, he can decrypt it using key Ka, to recover the session key Kb.

Examples 2.4 The Wide-mouthed-frog Protocol Message1. A_→S : _{T Sa, B, Kab}

Message2. S _→B : _{T Ss, A, Kab}

In the Wide-mouthed-frog Protocol, we assume that the encryption is done in such a way that we know the whole message was sent at once. If two separate encrypted sections are included in one message, we treat them as

(31)

though they arrived in separate messages. A message cannot be understood by a principal who does not know the key (or, in the case of public-key cryptography, by a principal who does not know the inverse of the key); the key cannot be deduced from the encrypted message. Each encrypted message contains sufficient redundancy to allow a principal who decrypts it to verify that he has used the right key. In addition, messages contain sufficient information for a principal to detect (and ignore) his own messages.

The Wide-mouthed-frog protocol aims to establish a session key Kab

and to authenticate A to B. A invents a session key and sends it to S along with a timestamp T Sa. S checks that the first message is timely, and if it is,

it forwards the message to B, together with its own timestamp Ts. B then

checks that the timestamp from S is later than any other it has received from S.

Examples 2.5 Yahalom Protocol Message1. A_→S : Na

Message2. B _→S : _{A, Na, Nb}Kbs

Message3. S _→A : _{B, Kab, Na, Nb},{A, Kab}Kbs

Message4. A_→B : _{Nb}Kab

The Yahalom protocol is a good example of showing a mutual authenti-cation protocol. The Yahalom protocol must guarantee the secrecy of Kab: in every session, the value of Kab must be known only by the participants playing the roles of A, B and S. In this protocol, the fresh symmetric shared key Kab is created by the server S and sent encrypted, both to A and to

(32)

Examples 2.6 Otway-Rees Protocol

Message1. A_→B : M, A, B,_{Na, M, A, B}Kas

Message2. B _→S : M, A, B,_{Na, M, A, B}Kas,{Nb, M, A, B}Kbs

Message3. S _→B : M,_{Na, Kab}Kas,{Nb, Kab}Kbs

Message3. B _→A : M,_{Na, Kab}Kas

[M and Na are a nonce of agent A]

Otway and Rees proposed a shared-key authentication protocol which involves two principals and an authentication server. Otway-Rees is a com-puter network authentication protocol designed for use on insecure networks (the Internet for example). It allows individuals communicating over a net-work to prove their identity to each other while also preventing evesdropping or replay attacks, and provides for detection of modification and the preven-tion of unauthorized reading. The protocol is attractive in that it provides good timeliness guarantees in a small number of messages. This protocol con-sists of three agents : the initiator A, the responder B and the third-party server S.

First, the initiator A sends to the responder B some encrypted material useful only to the server, together with enough information for B to make up a similar encrypted message. Then the responder B forwards both messages to the server, who decrypts and checks whether the components M, A, and B match in the encrypted messages. If so, S generates Kab and embeds it

in two encrypted messages, one for each participant, accompanied by the appropriate nonces. Both are sent to B, who forwards the appropriate part to A. Then A and decrypt, check their nonces, and if satisfied proceed to use

(33)

Examples 2.7 Woo-Lam Protocol Message1. A_→B : A Message2. B _→A : Nb Message3. A_→B : _{A, B, Nb}Kas Message4. B _→S : _{A, B,_{A, B, Nb}Kas}Kbs Message5. S _→B : _{A, B, Nb}Kbs

Whenever the responder B finishes the execution of the protocol, the initiator of the protocol execution is in fact the principal A claimed in message 1. Initially, A only knows Kas and the name of B, B only knows Kas and S

knows all shared keys : Kas is a long term symmetric key shared by A and

S. Initially, A only knows Kas and the name of B, B only knows Kbs and S

knows all shared keys.

Examples 2.8 Neuman-Stubblebine Protocol Message1. A_→B : A, Na

Message2. B _→S : B,_{A, Na, Tb}Kbs, Nb

Message3. S _→A : _{B, Na, Kab, Tb}Kas,{A, Kab, Tb}Kbs

Message4. A_→B : _{A, Kab, Tb}Kbs,{Nb}Kab

The Neuman-Stubblenine protocol is a mutual authentication authen-tication protocol among three party agents and the server S distributes a symmetric session key to A and B. In other words, this protocol uses a trusted key distributed server in the exchange of session key. This protocol

(34)

uses timestamp to prevent relay attack. The Neuman-Stubblenine protocol is very similar to Otway-Rees protocol. In the protocol, the initiator A in-dicates to the responder B to start a protocol by sending its identity along with a random number. If the responder B is willing to run the protocol it sends a signed time stamped message with contains the random nonce Na

from A. It also includes its identity along with a random nonce it generates. If the server S is able to decrypt the message with the secret of key the user in the message then it generates a symmetric session key Kab and sends it,

along with the user generated random nonce, encrypted with corresponding users secret key.

Examples 2.9 SSL Protocol Message1. S _→A : _{P K(A)_}SK(S),_{f(P K(A)), A, T1}SK(S) Message2. S _→B : _{P K(B)_}SK(S),_{f(P K(B)), B, T2}SK(S) Message3. A_→B : sslnoa Message4. B _→A : sslnob Message5. B _→A : P K(B),_{f(P K(B)), B, T2}SK(S) Message6. A_→B : _{P K(A)_}SK(S),_{f(P K(A)), A, T1}SK(S) Message7. A_→B : _{Kab}P K(B)

[sslnoa : SSL version of agent A, sslnob : SSL version of agent B]

Examples 2.10 Kerberos Protocol Message1. A_→S : A, B

(35)

Message3. A_→B : _{T1, A, Kab},{A, Ta}Kab

Message4. B _→A : _{T a+ 1_}Kab

[_{T1, A, Kab}Kbs} : ticket]

2.4 Attack Types

Attack types can be divided into two parts according to the design and im-plementation level. There are some attack types by the flaw in the design of security protocols. For a example, the man-in-the middle attack in the Needham-Schroeder Public Key Protocol involves in the attack types in the design level. Furthermore, there are another attack types in the implemen-tation level. For a example, buffer overflow in security protocol’s program involves in the attack type of implementation level. In this section, we illus-trate the kind of attack to which security protocols can fall prey we outline a number of well-known strategies that an intruder might employ.

2.4.1 Man-in-the-middle Attack

As implied by the name, this style of attack involves the intruder imposing himself between the communications between two participants A and B. If the protocol is poorly designed he may be able to subvert it in various ways. In cryptography, the man in the middle attack(MITM) is an attack in which an attacker is able to read, and modify at will, messages between two parties without either party knowing that the link between them has been compro-mised. The attacker must be able to observe and intercept messages going between the two victims. In connection with public keys, such an attack might look as follows:

(36)

Suppose Alice wishes to communicate with Bob. Eve wishes to eaves-drop on the conversation, or possibly deliver a false message to Bob. To get started, Alice must ask Bob for his public key. If Bob sends his public key to Alice, but Eve is able to intercept it, a man in the middle attack can begin. Eve can simply send Alice a public key for which she has the private, match-ing, key. Alice then encrypts her message with Eve’s key (which she believes to be Bob’s) and sends the encrypted message back to Bob. Eve again inter-cepts, decrypts the message, keeps a copy, and reencyphers it(after alteration if desired) using the public key Bob originally sent to Alice. When Bob re-ceives the newly encyphered message, he will believe it came from Alice. A similar attack is possible, in principle, against any message sent using public key technology, including data packets carried on computer networks.

The possibility of a “man in the middle” attack remains a serious security problem for public-key based cryptosystems. A widely used mechanism for defeating such attacks is the use of digitally signed keys: if Bob’s key is signed by a trusted third party vouching for his identity, Alice can have considerable confidence that a signed key she receives is not an attempt to intercept by Eve. Such signed keys (eg, signed by a certificate authority) are one of the primary mechanisms used for secure world wide web traffic (eg, HTTPS, SSL or Transport Layer Security protocols). However, lack of care in endorsing the match between identity information and public keys by certificate authorities is a problem for these systems.

2.4.2 Reflection Attack

This attack, which is also known as “Mirror Attack”, has its name from the trick to let a participant answer his own questions. A simple analogy might be responding to a sentry’s ’what is the password?’ with ’what is

(37)

the password?’ to which, if he is conditioned to respond automatically to that request, he might respond with the password. You can then supply the password to him. This is a bit simple-minded but just such an attack has been used against some real type friend-or-foe protocols.

2.4.3 Replay Attack

Replay attack indicates an malicious attempt on a security protocol using re-play of messages from a different context into the intended(or original and ex-pected)context, thereby fooling the honest participant(s) into thinking they have successfully completed the protocol run. If the protocol does not have any mechanism to distinguish between separate runs or to detect the stale-ness of a message, it is quite possible to fool the honest agents into rerunning all or parts of the protocol.

As an example, suppose a military ship which gets its commands from a base using an encrypted protocol. An attacker must not be able to creak any cipher, he must not even know what protocol is used. If he observes the communication and the ship for a while, then after some time he will have a fairly rich table mapping a certain dialog to the ship’s reaction. This enables him to control the ship just be repeating a described dialog. This style of attack can be foiled with devices like nonce, run identifiers, timestamps, and indeterministic encryption.

2.4.4 Interleave Attack

Here the attack uses parallel runs of a protocol to exploit their interactions. To illustrate the example of interleave attack, we consider the Needham-Public Key Protocol shown in Example 2.2. We think that this is a very simple and effective example to understand the attack type of interleave

(38)

attack and its countermeasure.

Example 2.11 Attack Scenario of Needham-Schroeder Public Key Potocol Message1. A_→M : _{Na, A}P K(M) Message2. M(A)_→B : _{Na, A}P K(B) Message3. B _→M(A) : _{Na, Nb}P K(A) Message4. M _→A : _{Na, Nb}P K(A) Message5. A_→M : _{Nb}P K(M) Message6. M(A)_→B : _{Nb}P K(B)

In Example 2.11, the notation of M is the attacker who has the ability of having sniffing and spoofing techniques. Therefore, M(A) means the intruder taking the identity of the initiator A, either to fake a message or to intercept a message intended for A.

At first glance, the Needham-Schroeder public-key protocol looks like it might work as a means to enable the agent A to communicate security with the agent B. However, it turns out that the intruder M can easy subvert it by intercepting the messages between A and B. The attack works as follows. Firstly, the initiator A believes that the nonce Na is a secret known only

to herself and M. Secondly, the agent B believes that the nonce Nb is a

secret known only to himself and A. Lastly, the intruder M knows the secret information of Nb to be authenticated to B.

Interleave attack still arises due to the lack of any form of authentication in this protocol. In this protocol, the responder B has no way of checking that the message he gets back is really from the initiator A as B expects.

(39)

Therefore, the countermeasure against interleave attack in the Needham-Schroeder public-key protocol puts an identity of B in the message 2. Gavin lowe found the the weakness and fixed it in the protocol[24]. Example 2.12 shows a modified version of Needham-Schroeder public-key protocol.

Example 2.12 Modified Needham-Schroeder Public-Key Protocol Message1. A_→B : _{Na, A}P K(B)

Message2. B _→A : _{B, Na, Nb}P K(A)

Message3. A_→B : _{Nb}P K(B)

2.4.5 Dictionary Attack

Dictionary attack is a general threat to all passwords. An attacker who obtains some sensitive password-derived data, such as a hashed-password, performs a series of computations using every possible guess for the pass-word. Since passwords are typically small by cryptographic standards, the password can often be determined by brute-force. This attack is very dan-gerous because many people tend to choose a poor password. Depending on the system, the password, and the skills of the attacker, such an attack can be completed in days, hours, or perhaps only a few seconds.

The term dictionary attack initially referred to finding passwords in a specific list, such as an English dictionary. Today, a brute-force approach can compute likely passwords, such as all five-letter combinations, “on-the-fly” instead of using a pre-built list. Since these threats are roughly equivalent, we use the term in the broader sense to include all brute-force attacks.

A password database should always be kept secret to prevent dictionary attack on the data. Obsolete password methods also permit dictionary attack

(40)

by someone who eavesdrops on the network. Strong methods prevent this. Example 2.13 shows a simple example of security protocol which is vulnerable to dictionary attack.

Example 2.13 Dictionary Attack Example Message1. A_→B : A, B

Message2. B _→A : Nb

Message3. A_→B : _{Nb}P asswdab

In Example 2.13, the protocol aims to authenticate a initiator A to the responder B, using a shared password key P asswdab. An attacker can

over-hear the nonce Nb in the message 2 and he can try to guess the password

P asswdab if it is short and guessable. In more detail, he can intercept the

message of _{Nb}P asswdab and he already knows the nonce Nb. Now, he

at-tempts to guessP asswdabusing a dictionary attack tool in the off-line. If the

password is in the list of dictionary files, he could generate his own message of _{Nm}P asswdab to be authenticate to B(Nm : nonce of an attacker).

The countermeasure of dictionary attack is to use a long-length and random password. To do that, the service provider usually recommend that a user generates a long-length(more than 8 characters) and english-alphabet mixed password.

2.4.6 Type-flaw Attack

A type flaw attack on a security protocol is an attack where a field that was originally intended to have one type is subsequently interpreted as having another type. For example, consider the Woo-Lam protocol shown in Ex-ample 2.7[39]. In the Woo-Lam protocol, the responder B cannot decrypt

(41)

the message he receives in message 3, but instead simply includes it inside message 4. The following type flaw attack exploit this :

Examples 2.14 Type Flaw Attack in Woo-Lam Protocol Message1. M(A)_→B : A

Message2. B _→M(A) : Nb

Message3. M(A)_→B : Nb

Message4. B _→M(S) : _{A, B, Nb}Kbs

Message5. M(S)_→B : _{A, B, Nb}Kbs

The attacker replays the nonceNb at B in message 3, which B accepts as

being of the form _{A, B, Nb}Kbs. The responder B encrypts N b in message

4. However this is precisely the form of message that the attacker requires to fake message 5.

To prevent type flaw attack on security protocols, James Heather in [39] proposed the technique using tags with some extra information indicating their intended type. This tags corresponding to each base type(agent, nonce, public key, secret key and etc). Simply, you can think of the tag as a few bits attached to the field, with different bit patterns allocated to different types. For example, we will write “(nonce, Na)” to represent a value Na

tagged in such a way to indicate that it is intended as a nonce. He also tagged compound messages; for example, a pair of values Na and NB can be

represented as “(pair, ((nonce, Na),(nonce, Nb)))”.

In the paper[39], he showed how to prevent type flaw attack using tag scheme in the Woo-Lam protocol. According to his countermeasure, the nonce in message 2 would become (nonce, Nb). The attacker cannot replay

(42)

the nonce in this form in message 3, but can retag the nonce with the tag that B is expecting (_{|agent, agent, nonce_|}shared−key, Nb). Then Message 4

could be expressed as followings :

(_{|agent, agent,_{|agent, agent, nonce_|}shared−key|}shared−key,

{(agent, A),(agent, B),(_{|agent, agent, nonce_|}shared−key, Nb)}Kbs)

But this message could not now be replayed as an instance of message 5, because B is expecting a message where the third field inside the encryption is tagged as being a nonce. The penetrator could change the outer most tag, to create :

(_{|agent, agent, nonce_|}shared−key,{(agent, A),(agent, B),

(_{|agent, agent, nonce_|}shared−key, Nb)}Kbs)

But the penetrator cannot change the inner tag without access to the appropriate key. Again this tagging scheme prevents the attack. Observer that the type attack is prevented simply by having the participants examine the tags.

2.4.7 Buffer Overflow Attack

Buffer overflow problems always have been associated with security vulner-abilities. This problem arises due to the bug or programming language or the mistake of programmer, not the design fault of security protocols. For example, a worm called “Slapper” infected 12,000 severs running the SSL module of Apcahe mod ssl. The worm does not exploit an attack against the SSL protocol itself, but is a buffer overflow attack.

In the past, lots of security breaches have occurred due to buffer over-flow. Especially, the program languages such as C and C++ is reported that they are vulnerable to buffer overflow attack. In C and C++, there are no automatic bounds checking on the buffer, which means a user can write past

(43)

a buffer. Example 2.14 shows a simple example of buffer overflow attack[38]. Example 2.14 Buffer Overflow Example

void function(char *str) { char buffer[16]; strcpy (buffer, str); } int main( ) {

char *str = ‘‘I am greater than 16 bytes’’; // length of str = 27 bytes

function (str); }

The above C program is a valid program, and every compiler can com-pile it without any errors. However, this program is guaranteed to cause unexpected behavior, because a string str of 27 bytes has been copied to a location buffer that has been allocated for only 16 bytes. The extra bytes run past the buffer and overwrites the space allocated for the FP(function’s return address pointer), return address and so on. This, in turn, corrupts the process stack. The function used to copy the string is strcpy, which completes no checking of bounds. Using strncpy would have prevented this corruption of the stack. However, this classic example shows that a buffer overflow can overwrite a function’s return address, which in turn can alter

(44)

the program’s execution path. Recall that a function’s return address is the address of the next instruction in memory, which is executed immediately after the function returns.

The solutions proposed for buffer overflow problems mainly target the prevention of large-scale system attacks through the loopholes described above. None of the methods described below can claim to prevent all possible attacks. These methods, however, can make it more difficult to access buffer overflows and, hence, destroy the consistency of stacks.

• Write secure code: Buffer overflows are the result of stuffing more code into a buffer than it is meant to hold. C library functions such as

strcpy, strcat, sprintf and vsprintf operate on null terminated strings

and perform no bounds checking. The gets is another function that reads user input (into a buffer) from stdin until a terminating newline or EOF is found. Thescanf family of functions also may result in buffer overflows. Hence, the best way to deal with buffer overflow problems is to not allow them to occur in the first place. Developers should be educated about how to minimize the use of these vulnerable functions. • Stack execute invalidation: Because malicious code (for example, assembly instructions to spawn a root shell) is an input argument to the program, it resides in the stack and not in the code segment. Therefore, the simplest solution is to invalidate the stack to execute any instruc-tions. Any code that attempts to execute any other code residing in the stack will cause a segmentation violation. However, the solution is not easy to implement. Although possible in Linux, some compilers (including GCC) use trampoline functions (see Resources) to imple-ment taking the address of a nested function that works on the system stack being executable. A trampoline is a small piece of code created

(45)

at run-time when the address of a nested function is taken. It normally resides in the stack, in the stack frame of the containing function and thus requires the stack to be executable. However, a version of the Linux kernel that enforces the non executable stack is freely available. • Compiler tools: Over the years, compilers have become more and more aggressive in optimizations and the checks they perform. Various compiler tools already offer warnings on the use of unsafe constructs such as gets, strcpy and the like.

(46)

Chapter 3 Formal Methods for Security

Protocols

In this chapter, we classify formal method based approaches for the analysis of security protocols. In addition, we describe more detail techniques of formal specification and verification of security protocols, using GNY logic and Casper/FDR.

The common problem in security engineering is, that vulnerabilities arise at the boundary between two protection technologies; the weakness is in the design and implementation of cryptographic protocol. Analyzing crypto-graphic protocols in Ad-Hoc manner seems too hard to conduct, especially they have special security properties compared with common communica-tion protocols. Formal methods have long been used to prove correctness of communication protocol, and recently researcher are focusing in proving authentication and secrecy properties in cryptographic protocols are working as they are expected to be.

Formal methods have long been used in the design and analysis of com-munication protocols in general. Formal techniques can be used in various

(47)

phases of the design of a cryptographic protocol. These phases include the specification, the construction, and the verification. There are a lot of ap-proaches to verify safety of security protocols. Among them, model checking and theorem is the most popular approaches.

• Model checking is a method to verify whether finite state model sat-isfies given properties such as safety, liveness, deadlock and etc. When a violated state is found that, the model checking tool shows the coun-terexamples which represent the vulnerable status.

One attractive option is model checking, a fully automatic verification technique that searches for error states in a given system by systemat-ically enumerating the possible states of the system. In addition, one can implement compilers that translate a high level description of a security protocol to the input language of a given model checker. The disadvantage is that the state space being searched needs to be finite and relatively small(state explosion problem).

A number general purpose model checkers have proved to be extremely effective at finding attacks on security protocols. NRL Protocol Analyzer[40], ASTRAL[41], Murphi[42], SMV[43], SPIN[44], CADP[45] and FDR[8] tools are based on model checking.

• Theorem proving is another method for performing verification on formal specifications of system models. Theorem provers apply rules of inference to a specification in order to derive new properties of interest. The theorem proving tools consist of a powerful collection of inference steps that can be used to reduce a proof goal to simpler sub-goals that can be discharged automatically by the primitive proof steps of the prover.

(48)

One of the advantages of theorem provers is that they are not limited by the size of the state space. Large systems that cannot be verified using the model checker, can still be verified by the theorem prover. Since state space explosion is not a problem, no abstraction techniques need to be applied and the verification can be done on the complete model. Most theorem provers are highly expressive. Some properties that cannot be easily specified using model checkers (such as comparing properties of two arbitrary states that are not temporally related) can be easily specified in the languages of most theorem provers. These are some of the major advantages of using theorem provers. One of the major disadvantages of using theorem provers is these proofs are not automatic and require a high level of user interaction and exper-tise to generate them. Therefore, if you fail to complete the proof of a property, the tool will not tell you whether the property is indeed unprovable or whether the user is not providing it with enough infor-mation to complete the proof.

BAN[23], GNY[34], SVO[46] are using belief logic based on theorem proving, and the objective of logic based approach is to verify whether the desired goals of security protocols can be derived from the initial assumptions and protocol step.

(49)

Table 3.1: Formal verification tools for security protocols Tool Verification Method Input Language SPEAR Theorem Proving BAN, GNY gnytool Theorem Proving GNY

PVS Theorem Proving Predicate Logic

FDR Model Checking CSP

Murphi Model Checking Murphi CADP Model Checking LOTOS

SMV Model Checking SMV

SPIN Model Checking ProMeLa

NRL Theorem Proving NRL Protocol Analyzer Design/CPN Model Checking Petri-Nets

UPPAAL Model Checking Timed Automat

Table 3.1 shows some lists of formal verification tools for the analysis of security protocols.

(50)

Table 3.2: Advantages and disadvantages of belief logics Advantages

1) They help formalize reasoning about useful abstract properties of cryptographic protocols

2) They force designers to make explicit security assumptions

3) They achieve a reasonably well-defined set of authentication goals Disadvantages

1) They require a thorough understanding of the used belief logic and their verification process is complicated

2) Wrong formalised protocol may bring about a different proof result

3) Lack of clarity about the protocol goals and initial assumptions is a further cause for concern ; in some cases the security protocol may be used for slightly different purposes

3.1 Belief Logic

3.1.1 GNY Logic

The technique of ’belief logic’ based approach is accredited largely to Burrow, Abadi and Needham, developers of the BAN logic[23]. BAN logic assumes that authentication is a function of integrity and freshness, and uses logical postulates to trace both of those attributes through the protocol. Table 3.2 shows the list of advantages and disadvantages of belief logics[47][36].

GNY logic[34] was proposed by Gong, Needham and Yahalom, increas-ing the scope of BAN logic. GNY logic aims to analyze a protocol step-by-step, making explicit any assumptions required, and drawing conclusions about the final position it attains.

(51)

This logic offers important advantages over BAN logic. The GNY ap-proach places a strong emphasis on the separation between the content and meaning of messages which increases consistency in the analysis and intro-duces the ability to reason at more than one level. In particular, GNY logic does not assume that redundancy exists in encrypted messages. Instead, they introduce the notion of recognizability to represent the fact that a principal expects certain formats in the messages it receives. Furthermore, GNY logic explicitly represents whether a principal generated a message itself. One of the important contributions of the GNY logic is the recognition that belief

and possession are different. In the following section, we describe the

nota-tion of GNY logic to express initial assumpnota-tions, formalized protocols and security goals.

3.1.2 Notation

In this section, we present the basic notation of formula and statements underlying GNY logic to make up a formalized security protocol[34]. A formula is a name refer to a bit string, which would have a particular value in a run. In the following notation, X and Y are formula.

• (X, Y) : conjunction of two formula. This notation is associativity and commutativity.

• {X_}K and {X}−

1

K : conventional encryption and decryption notation.

It is assumed that the cryptosystems used are resistant to ciphertext-only and know plaintext attacks.

• {X_}+K and {X}−K : public key and secret key notation. They satisfy

(52)

• H(X) : a one-way function X. It is required that given X it is com-putationally feasible to computer H(X) given H(X) it is infeasible to computer X; it is infeasible to computer X and X’ such that X ₆= X’ but H(X)= H(X’).

• F(X) : it denotes a computationally feasible one-to-one function whose inverse is also computationally feasible.

• P _X _{: P is told formula X. P receives X, possibly after performing}

some computation such as decryption. A formal being told can be the message itself, as well as any computable content of that message. • P ₃ X : P possesses, or is capable of possessing, formula X. At a

par-ticular stage of a run, this includes the formula that P has been told, all the formula started the session with, and all the ones he has gener-ated in that run. In addition P possesses, or ic capable of possessing, everything that is computable from the formula he already possesses. • P _|∼X : P once conveyed formula X. X can be message itself or some

content computable from such message.

• P _|≡C : P believes, or P would be entitled to believe, that statement C holds.

• P _|≡ ](X) : P believes, or is entitled to believe, the formula X is fresh. It means that X has not been used for the same purpose at any time before the current run of the protocol. For example, a counter or a random number generator can server to produce formula that a principal believes to be fresh(also known as nonces).

• P_|≡φ(X) : P believes, or is entitled to believe, the formula X is recog-nizable. If P believes φ(X), then P would recognize X if P had certain

(53)

expectations about the nature of X. P may recognize a particular value, a particular structure, or a particular form of redundancy.

• P_|≡ P_←_→S Q : P believes, or is entitled to believe, that S is a suitable secret for P and Q. They may properly use it to mutually prove identity. They may also use it as, or derive from it, a key to communicate. S will never be discovered by any principal except P, Q, or a principal trusted by either P or Q. This notation is commutative : Q_←_→S P and P_←_→S Q can be used.

• P _|≡+_7→KQ : P believes, or is entitled to believe, that +K is a suitable public key for Q. The matching secret key -K will never be discovered by any principal except Q or a principal trusted by Q.

• P _|≡ Q _{| ⇒} C : P believes that Q has jurisdiction over statement C. He believes that Q has authority on C and should be trusted in this respect.

• P _|≡ Q _{| ⇒} Q _|≡ * : P believes that Q has jurisdiction over all his beliefs. P considers Q to be competent and honest.

• C1, C2 : This notation is the conjunction of two statements and it

allows the rules of associative and commutativity.

• ?X: The notation of?is anot-originated-here formula. Statement ?X indicates that P is told a formula which he did not convey previously in the current run. A not-originated-here formula implies that it was not first conveyed by the recipient in this session. A principal can believe that he has never conveyed a formula that he receives if it is a not-originated-here formula and he also believes the formula to be fresh.

(54)

The protocol analysis using belief logic takes the following steps : – The idealised protocol is derived form the original one – Assumptions about the initial state are written

– Logical formulae are attached to statements of the protocol, as assertions about the state of the system after each statement – The logical postulates are applied to the assumptions and the

assertions, in order to discover beliefs held by the parties in the protocol

3.1.3 SPEAR II

SPEAR II stands for “Security Protocol Engineering and Analysis Resource”

and it is a protocol engineering tool which focused on security protocols. The original SPEAR describes an envisaged tool which allows effective de-sign, analysis and implementation of security protocols. Security analysis of SPEAR tool is based on BAN logic and Java code can be generated from high level design of security protocols. However, SPEAR II tool describes a graphical GNY statements that form the initial assumptions and final goals for a given protocol. When using GNY logic carry out an analysis, many in-dividuals struggle to understand the notation and formula syntactically and semantically correct statements. Furthermore, after specifying a set of initial beliefs and possessions, one is often left with a collection of cryptic looking statements that have no structure or organization of any form. The graphi-cal based interface allows a user to specify the GNY formula and statement without knowing the complicated syntax.

The SPEAR II tool consists of four components : GYPSIE(a proto-col specification environment), Visual GNY(a GNY statement construction

How To Write A Security Protocol In C#

Thesis for the Degree of

Doctor of Philosophy

Formal Analysis and Automatic Code

Generation of Security Protocols

by

Il-Gon Kim

Department of

Computer Science and Engineering

Graduate School

Korea University

Abstract

Acknowledgements

Contents

List of Figures

List of Tables

Chapter 1

Introduction

1.1

The problem this thesis addresses

1.2

Thesis overview

Chapter 2

Background

2.1

Cryptography

2.2

Security Properties

2.3

Security protocols

2.3.1

Key distribution protocol

2.3.2

Authentication protocol

2.3.3

Examples of security protocols

2.4

Attack Types

2.4.1

Man-in-the-middle Attack

2.4.2

Reflection Attack

2.4.3

Replay Attack

2.4.4

Interleave Attack

2.4.5

Dictionary Attack

2.4.6

Type-flaw Attack

2.4.7

Buffer Overflow Attack

Chapter 3

Formal Methods for Security

Protocols

3.1

Belief Logic

3.1.1

GNY Logic

3.1.2

Notation

3.1.3

SPEAR II