DEFENDING AGAINST MALICIOUS NODES IN CLOSED MANETS THROUGH PACKET AUTHENTICATION AND A HYBRID TRUST MANAGEMENT SYSTEM

APPROVED BY SUPERVISING COMMITTEE:

Turgay Korkmaz, Ph.D., Chair

Ali S. Tosun, Ph.D.

Gregory B. White, Ph.D.

William H. Winsborough, Ph.D

G.V.S. Raju, Ph.D.

ACCEPTED: Dean, Graduate School

DEDICATION
I dedicate this dissertation to my parents, Usman Ghani Akbani and Zarina Akbani.

DEFENDING AGAINST MALICIOUS NODES IN CLOSED MANETS THROUGH PACKET AUTHENTICATION AND A HYBRID TRUST MANAGEMENT SYSTEM

by REHAN AKBANI, M.S.

DISSERTATION Presented to the Graduate Faculty of The University of Texas at San Antonio In partial Fulllment Of the Requirements For the Degree of

DOCTOR OF PHILOSOPHY IN COMPUTER SCIENCE

THE UNIVERSITY OF TEXAS AT SAN ANTONIO College of Science Department of Computer Science August 2009

ACKNOWLEDGEMENTS

I would like to thank my Ph.D. advisor, Dr. Turgay Korkmaz, for his guidance and understanding support. I would also like to thank my committee members, Dr. Ali Saman Tosun, Dr. Greg White, Dr. William Winsborough, and especially Dr. G.V.S. Raju for their invaluable input and constructive criticism.

August 2009

iii

DEFENDING AGAINST MALICIOUS NODES IN CLOSED MANETS THROUGH PACKET AUTHENTICATION AND A HYBRID TRUST MANAGEMENT SYSTEM

Rehan Akbani, Ph.D. The University of Texas at San Antonio, 2009

Supervising Professor: Turgay Korkmaz, Ph.D. Wireless links and lack of central administration make MANETs far more susceptible to attacks than conventional networks. MANETs must provide various levels of security guarantees to dierent applications for their successful deployment and usage. Their security requirements depend greatly on their architecture. In this dissertation we are focusing on closed MANETs where only designated nodes are supposed to access the network (e.g., in a military or corporate setting). We dene outsider nodes as those nodes that are not authorized to access the network, and insider nodes as those that are allowed to access the network. The objective of this research is to develop mechanisms that protect a closed MANET against malicious behavior from outsider nodes as well as insider nodes through packet authentication and a Hybrid Trust Management System, respectively. To defend against outsider nodes, we present a new Hop-by-hop, Ecient Authentication Protocol, called HEAP, which is suitable for unicast or multicast applications. HEAP is independent of the routing protocol used and it is based on a modied HMAC algorithm that uses two keys and is very ecient. We compare the performance of HEAP against other algorithms and provide proofs of its security. iv

To combat against insider attacks, we propose a new hybrid trust management system that is based on Reputation Systems (RS) and Role Based Trust Management (RBTM). We develop a novel Machine Learning based RS, called EMLTrust and delineate its advantages. We compare its performance against other RSs and demonstrate the improvements in performance. We also highlight the challenges associated with using RBTMs in MANETs and oer some solutions. Finally, we propose a hybrid TM system that combines EMLTrust with RBTM, and evaluate it to illustrate its ecacy in thwarting insider attacks.

Table of Contents

1 Introduction 1.1 1.2 1.3 Overall Scope and Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problem Denition - Its Signicance and Challenges . . . . . . . . . . . . . . . . Main Contributions and Dissertation Overview . . . . . . . . . . . . . . . . . . .

1 1 2 5 8 8 9 11 12 13 14

2 Defending Against Outsider Attacks 2.1 2.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 2.2.3 2.3 2.4 TESLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LHAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lu and Pooch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Security Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HEAP: Hop-by-hop Ecient Authentication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 2.4.2 2.4.3 2.4.4 Key Generation and Distribution . . . . . . . . . . . . . . . . . . . . . . MAC Generation and Authentication in HEAP . . . . . . . . . . . . . . Index Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dierences between NMAC, HMAC and HEAPs construct . . . . . . . .

16 16 17 21 22 24 29 29

2.5 2.6

Security Analysis of HEAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulations and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

2.6.2 2.6.3 2.6.4 2.6.5 2.7

Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Throughput and Packet Delivery Ratio . . . . . . . . . . . . . . . . . . . Memory Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Computational Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30 32 36 37 40 42 42 44 44 47 48 50 52 52 54 56 57 58 59 59 60 60

Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Defending Against Insider Attacks 3.1 3.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 3.2.3 3.3 Monitoring Based Trust Management . . . . . . . . . . . . . . . . . . . . Reputation Based Trust Management . . . . . . . . . . . . . . . . . . . . Role Based Trust Management . . . . . . . . . . . . . . . . . . . . . . .

Trust Management Models for MANETs . . . . . . . . . . . . . . . . . . . . . .

4 A Basic Machine Learning Based Reputation System 4.1 4.2 4.3 4.4 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Machine Learning Approach . . . . . . . . . . . . . . . . . . . . . . . . . . Building the Core SVM based Reputation System . . . . . . . . . . . . . . . . . Factors in Building the Classier . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 Feature Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proportion of Malicious Nodes . . . . . . . . . . . . . . . . . . . . . . . . Size of Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evaluation Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . Evaluation Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii

4.4.6 4.4.7 4.5

Kernel Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Guarding Against Fake Feedbacks . . . . . . . . . . . . . . . . . . . . . .

61 61

Evaluations of the Core SVM based Reputation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 4.5.2 4.5.3 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Experiments and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 64 65 66 75 77 77 80 85 87 94

4.6

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 EMLTrust: An Enhanced Machine Learning Based Reputation System 5.1 Enhancing SVM with Fading Memories (SVM-FM) . . . . . . . . . . . . . . . . 5.1.1 5.1.2 5.2 5.3 Evaluating SVM with Fading Memories (SVM-FM) . . . . . . . . . . . . Fading Memories Enhanced with Digital Signatures . . . . . . . . . . . .

Introducing Dynamic Thresholds with SVM . . . . . . . . . . . . . . . . . . . . Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Hybrid Trust Management in MANETs based on Reputation and Role Based TM Systems 6.1 6.2 Introduction to Role Based Trust Management . . . . . . . . . . . . . . . . . . . Challenges of Using Role Based Trust Management in MANETs . . . . . . . . . 6.2.1 6.2.2 6.3 6.4 Credential Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 95 97 98

Credential Chain Distribution and Collection . . . . . . . . . . . . . . . . 100

Introduction to a Hybrid Trust Management System . . . . . . . . . . . . . . . 102 Proposed Hybrid Trust Management System (HTMS) . . . . . . . . . . . . . . . 103

viii

6.4.1 6.4.2 6.5

Determining the Exact Privilege Level . . . . . . . . . . . . . . . . . . . 105 Merits of HTMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Evaluating HTMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 6.5.1 6.5.2 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Experiments and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

6.6 6.7

Estimating Percentage of Malicious Nodes . . . . . . . . . . . . . . . . . . . . . 116 Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 119

7 Dissertation Summary and Future Work 7.1 7.2 7.3

Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Guarding Against Outsiders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Guarding Against Insiders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.3.1 7.3.2 7.3.3 7.3.4 Dierent Trust Management Approaches . . . . . . . . . . . . . . . . . . 121 Basic Machine Learning Based Reputation System . . . . . . . . . . . . . 122 Enhanced Machine Learning Based Reputation System . . . . . . . . . . 123 Hybrid Trust Management System for MANETs . . . . . . . . . . . . . . 123 127

A Comprehensive List of the Authors Publications

A.1 Book Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 A.2 Journal Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 A.3 Conference Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Vita 143

ix

List of Figures
Figure 2.1 Figure 2.2 Figure 2.3 Figure 2.4 Figure 2.5 Figure 2.6 Node A needs to transmit a packet to its neighbors A1 through A5. . . . . . Packet generation in the proposed HEAP. . . . . . . . . . . . . . . . . . . . Illustration of the NMAC construct. . . . . . . . . . . . . . . . . . . . . . . Illustration of the HMAC construct. . . . . . . . . . . . . . . . . . . . . . . Illustration of the HEAP construct. . . . . . . . . . . . . . . . . . . . . . . 18 21 22 22 23

Mean Latency (ms) plotted on a log axis vs. Number of hops for all al-

gorithms. The bottom curve represents ODMRP, LHAP Min and HEAP since all three overlap almost exactly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2.7 Mean Throughput (bytes/sec) vs. Packet Rate (pkts/sec) for all ve algo33 31

rithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2.8 Mean Packet Delivery Ratio (%) vs. Packet Rate (pkts/sec) for all ve

algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2.9 Mean Throughput (bytes/sec) vs. Packet Rate (pkts/sec) for all ve algo. . . . . . . . . . . . . . . . .

34

rithms when the nodes are moving about randomly.

35

Figure 2.10 Memory Requirement (bytes) on a log axis vs. Duration of Key Chain (mins) for all four algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2.11 CPU Time (micro seconds) vs. Number of Neighbors for HEAP. Figure 3.1 Figure 4.1 . . . . . . 38 39 50

Which architecture should be paired with which TM system . . . . . . . . . General framework of a Reputation System that decides whether to transact

with a given node or not. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

Figure 4.2 Figure 4.3 Figure 4.4 Figure 4.5 Figure 4.6 Figure 4.7 Figure 4.8 Figure 4.9

Classication Error vs. Proportion of malicious nodes for Attack 1. . . . . . Classication Error vs. Proportion of malicious nodes for Attack 2. . . . . . Classication Error vs. Proportion of malicious nodes for Attack 3. . . . . . Classication Error vs. Proportion of malicious nodes for Attack 4. . . . . . Classication Error vs. Proportion of malicious nodes for Attack 5. . . . . . ROC Curves for Attack 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ROC Curves for Attack 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ROC Curves for Attack 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68 68 69 69 70 71 72 72 73 73 74

Figure 4.10 ROC Curves for Attack 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4.11 ROC Curves for Attack 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 4.12 Bandwidth Overhead for each of the three algorithms. . . . . . . . . . . . . Figure 5.1 (Adapted from [60]) Updating Fading Memories: F T V [i] denotes the faded . . . . . . . .

values at time t and F T V [i] denotes the faded values at time t + 1. Figure 5.2

79

Classication Error vs. Percentage of Malicious Nodes for small, xed peri81

ods of oscillation for SVM with FM and SVM without FM. . . . . . . . . . . . . . Figure 5.3 Classication Error vs. Percentage of Malicious Nodes for large, variable

periods of oscillation for SVM with FM (FM error) and SVM without FM (Orig Error). Attack 1 has no oscillations. . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.4 Classication Error vs. Percentage of Malicious Nodes for large, variable 83 83

periods of oscillation in attack 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.5 Classication Error vs. Percentage of Malicious Nodes for large, variable

periods of oscillation in attack 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

xi

Figure 5.6

Classication Error vs. Percentage of Malicious Nodes for large, variable 84

periods of oscillation in attack 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.7 Classication Error vs. Percentage of Malicious Nodes for large, variable

periods of oscillation in attack 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.8 Classication Error vs. Malicious Nodes percentage for dierent algorithms

85

with FM in attack 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.9 Classication Error vs. Malicious Nodes percentage for dierent algorithms

89

with FM in attack 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.10 Classication Error vs. Malicious Nodes percentage for dierent algorithms with FM in attack 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5.11 SVMs best threshold vs. Malicious Nodes percentage for attack 5. . . . . . Figure 5.12 SVM error under the default threshold and under the best thresholds. . . . Figure 5.13 Dynamic Thresholds Error vs. Number of Samples taken for dierent proportions of malicious nodes in the network. . . . . . . . . . . . . . . . . . . . . . . Figure 5.14 Dynamic Thresholds Error with 20 and 25 samples compared to the default error and the minimum possible error. . . . . . . . . . . . . . . . . . . . . . . . . . Figure 6.1 Randomly generated behavior of a node vs. the corresponding ideal response

89

90 91 91

93

93

curve, along with maximum and minimum privilege levels. . . . . . . . . . . . . . . 110 Figure 6.2 Eect of varying proportions of malicious nodes in test sets. Training set

has 0% malicious nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Figure 6.3 Average daily discrepancy from the ideal curve vs. percentage of malicious

nodes in the network (smaller is better). Training set has 0% malicious nodes. . . . 113

xii

Figure 6.4

Eect of varying proportions of malicious nodes in test sets. Training set

has 30% malicious nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Figure 6.5 Average daily discrepancy from the ideal curve vs. percentage of malicious

nodes in the network. Training set has 30% malicious nodes. . . . . . . . . . . . . . 115 Figure 6.6 Eect of varying proportions of malicious nodes in test sets. Training set

has 70% malicious nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Figure 6.7 Average daily discrepancy from the ideal curve vs. percentage of malicious

nodes in the network. Training set has 70% malicious nodes. . . . . . . . . . . . . . 116

xiii

Chapter 1:
1.1

Introduction

Overall Scope and Background

Mobile Ad-hoc Networks (MANETs) have attracted the attention of researchers due to their potential use in exciting new applications. MANETs consist of wireless devices, such as laptops, PDAs, cell phones or sensors, that come together to form a wireless network without any xed infrastructure. They lack dedicated routers and their topology changes continuously based on the movement of the wireless devices, called nodes. Nodes can communicate with their neighbors who are within wireless range, as well as with distant nodes using intermediary nodes as routers [7]. These unique properties of MANETs allow them to be used in novel situations. For example, MANETs can be rapidly deployed in emergencies and disaster struck areas to allow reghters, paramedics and security personnel to communicate with each other and coordinate the relief eort. This capability would be indispensable in areas aicted with hurricanes or other natural disasters, or in areas targeted by terrorism where any pre-existing network infrastructure would have been destroyed. MANETs can also be used in a military setting where troops can exchange strategic information on the move [7]. The ability to cope with high mobility and the lack of xed infrastructure make MANETs very attractive for military and tactical applications. Another useful application for MANETs is mobile conferencing for business meetings and seminars involving a large group of people, where access points may be absent or inaccessible. They are also very useful for people doing eldwork such as geologists,

cartographers or archaeologists who may want to communicate with their colleagues on the eld. MANETs can be used to establish a wide wireless coverage area e.g. in airports, university campuses and even in city localities, where installing and maintaining access points at every few hundred feet would be expensive and sometimes impractical. MITs Media Lab has a $100 Laptop program where the aim is to develop cheap laptops for mass distribution to children in developing countries [33]. These laptops will be programmed to form a MANET out of the box so that the children can communicate with each other. In addition, MANETs can be used as sensor networks where several hundreds or thousands of sensors can be distributed throughout a region being studied. Each sensor records some information about its environment and transmits the data back to a processing station. These sensors may be mobile and may need to coordinate with each other to gather data.

1.2

Problem Denition - Its Signicance and Challenges

MANETs must provide various levels of security guarantees to dierent applications for their successful deployment and usage. These security requirements can be very stringent for military and anti-terrorism operations, to less stringent for business and personal use. Consider the scenario where an area has just been attacked by terrorists. We can envision a situation where policemen, paramedics, re ghters and rescue workers all need to communicate and coordinate their eorts in order to provide disaster relief. This is a life threatening situation where ecient and secure communication could result in lives being saved. On the ip side, we assume that terrorists have hidden wireless devices on the scene whose intent is to try to disrupt these

communications to maximize the impact of the terrorist incident. Once the use of MANETs becomes widespread in disaster relief eorts, it can become a potential target for terrorists who are rapidly increasing in computer know-how [21]. Other scenarios can also be construed, where in a military setting enemy forces may try to disrupt or inject false information into a MANET used by soldiers on the battleeld. A commercial MANET might become the victim of industrial espionage. A MANET for personal use could be exploited to hack into a users computer to commit identity theft, credit card theft or fraud. Unfortunately, due to their wireless links and lack of central administration, MANETs are far more susceptible to attacks than conventional networks [11, 19, 20, 25, 31]. For example, it is easy for attackers to enter or leave a wireless network and eavesdrop since no physical connection is required. They can also directly attack the network to drop packets, tamper with packets or inject false packets [8]. As a result, it is possible to launch sophisticated wormhole, man-in-the-middle and Denial of Service (DoS) attacks with ease, or impersonate another node. It is so easy to attack a MANET without security that the risk of using a MANET might actually outweigh the benets. It is therefore paramount to have eective security solutions in place for their successful deployment. The problem is further exacerbated by the fact that the architecture of the MANET may vary greatly based on its application. In an open MANET anyone is free to enter or leave the network (e.g., in airports and university campuses), whereas in a closed MANET only designated nodes may gain access (e.g., in a military setting). The network may be hierarchical, where nodes have dierent roles and privileges and provide dierent services (e.g., network administration, certifying authority (CA), security and access control), or it may be 3

at, where each node provides the same type of services (e.g., packet forwarding). Furthermore, the nodes may belong to a Single Administrative Domain (SAD), where only one administrator controls the network (e.g., the US army), or Multiple Administrative Domains (MAD), where there are multiple administrators (e.g., the US and UK armies in a joint operation) [84]. In general, it is more dicult to provide security in an open, at, MAD network, such as a city-wide public network. This is because there is no restriction on who may access the network, there are no designated nodes to provide security and the network may be administered dierently across dierent localities. Fortunately, the security requirements of such networks are also not very demanding since users expect public networks to be insecure. By contrast, closed, hierarchical, SAD networks may have very strict security requirements, such as in the military or in the police department. In this dissertation we are focusing on closed networks, which may be at or hierarchical, SAD or MAD. In the context of closed networks, we dene outsider nodes as those nodes that are not authorized to access the network, and insider nodes that are allowed to access the network. The objective of this research is to develop mechanisms that protect a closed MANET against malicious behavior from insider and outsider nodes through packet authentication and a Hybrid Trust Management system. The goal is not to protect an individual node from being compromised, but rather we expect some nodes to be compromised and the goal is to limit the damage such compromises can cause. The network on the whole should be able to function at a satisfactorily level and provide services with reasonable reliability even in the presence of such malicious intruders. We will investigate and quantify the impact of increasing the proportion of malicious nodes in the network. We only make minor assumptions, for instance that the network layer is able to relay 4

at least some untampered packets from the source to the destination node. Protocols such as IPSec [17] or HMAC [9] can be used to ensure that packets are not tampered with. If the bottom layers completely fail to relay any packets such as by jamming the wireless physical layer, the network is eectively crippled and any system at a higher layer cannot overcome that problem. In a real world setting, it may be possible to locate the jamming device through triangulation or a physical search and disable it. Dealing with complete failures at lower layers is beyond the scope of this research. In many cases, the attacker may be more interested in covert attacks such propagating false information through the network rather than completely disabling it. We are therefore focusing our research on attacks at the link layer or above.

1.3

Main Contributions and Dissertation Overview

Our research is divided into two parts. The rst part (Chapter 2) deals with guarding against outsider nodes, while the second part (Chapters 3 - 6) deals with guarding against insider nodes. In Chapter 2, we propose a scheme that defends against outsider attacks. We use packet authentication and propose a Hop-by-hop, Ecient Authentication Protocol, called HEAP. HEAP authenticates packets at every hop by using a modied HMAC-based algorithm that utilizes two keys and drops any packets that originate from outsiders. HEAP can be used with multicast, unicast or broadcast applications. The remaining chapters deal with defending against insider attacks. In Chapter 3, we present the background material related to guarding against insiders through Trust Management (TM) systems. We present the pros and cons of three traditional TM systems: Behavior based TM, Reputation based TM, and Role based TM systems. We also

discuss which TM approach is appropriate for which MANET architecture. In the following chapters, we investigate how to utilize various TM systems in the context of closed MANETs, and propose a hybrid TM system. In Chapter 4, we present a new Machine Learning (ML) based Reputation System (RS). We discuss the motivation behind developing an ML based solution and the challenges associated with using ML. Then we discuss the details of our Support Vector Machines (SVM) based RS and compare it against other RSs found in the literature. We perform detailed evaluations of our RS and illustrate its improvements over other RSs. In Chapter 5, two enhancements are proposed to the basic RS presented in Chapter 4. The rst enhancement uses an algorithm called Fading Memories with Digital Signatures in order to enable SVM to look at longer histories using only a few features. This forces adversaries to behave well for longer periods of time in order to boost their reputation scores. The second enhancement, called Dynamic Thresholds, improves the accuracy of SVM by relocating its decision boundary dynamically, based on the proportion of malicious nodes in the network. It allows SVM to keep up with varying levels of malicious behavior in the network as time progresses. We call our enhanced Reputation System EMLTrust. In Chapter 6, we highlight the problems associated with using a traditional Role based TM system with MANETs and suggest some solutions. Next, we propose a Hybrid Trust Management System that is based on Reputation Systems (RS) and Role Based Trust Management (RBTM). Such a system can overcome some of the limitations of both approaches when they are used in isolation. We describe the algorithm in detail and evaluate it in order to demonstrate its utility. Finally, we wrap up the dissertation and discuss overall conclusions and future work in Chapter 7. 6

The objectives of this dissertation can be outlined as follows Identify the inherent limitations of providing security in MANETs based on the MANETs architecture. Devise a mechanism that guards against attacks from outsider nodes by using hop-by-hop packet based authentication. Consider various TM models and develop an ecient hybrid TM model for guarding against insider nodes. Some important problems that need to be addressed include: How to compute a meaningful Reputation given the history of past interactions of the client with third parties. How to account for the level of trust we have in these third parties and how to guard against nodes that present false evidence. How to deal with clients that have little or no history. How to prevent clients with bad reputations from changing their identities in an attempt to appear as new nodes. How to make the system ecient and robust against node failures. How to guard the system against colluding nodes. How to store, collect and distribute credentials for Role based TM systems. How to subvert the problems associated with using a centralized Certifying Authority (CA), or Trust Authority (TA). Evaluate the proposed solutions using simulations and experiments.

Chapter 2:

Defending Against Outsider Attacks

2.1

Introduction

MANETs must provide various levels of security guarantees to dierent applications for their successful deployment and usage. However, due to their wireless links and lack of central administration, MANETs have far greater security concerns than conventional networks [8]. For example, it is easy for attackers to enter or leave a wireless network and eavesdrop since no physical connection is required. Without a security scheme in place, an outsider node can easily pretend to be an insider and participate in routing packets. Therefore, it can directly attack the network by dropping packets, tampering with packets, injecting false packets or ooding the network. As a result, it is possible to launch sophisticated wormhole, man-in-the-middle and Denial of Service (DoS) attacks with ease, or to impersonate another node. To combat such attacks, we study hop-by-hop packet authentication as a fundamental security strategy to block attacks from outsiders at the rst hop. We propose a Hop-by-hop, Ecient Authentication Protocol, called HEAP, which is suitable for multicast, unicast or broadcast applications. In essence, HEAP uses a modied HMAC [9] based algorithm that utilizes two keys. Specically, in the initial bootstrapping phase every node (i) shares a pairwise secret hash key, called okey, with each of its neighbors, and (ii) generates one common secret hash key, called ikey, and securely distributes it to all of its one-hop neighbors. Now consider the case where a node wants to broadcast a message to all of its neighbors. The naive 8

way would be to generate a new MAC for every individual neighbor using its pair-wise key. However, we present a more ecient way of generating MACs. We reexamined the working principles of the HMAC algorithm [9] and divided the HMAC computation into two steps so that we could signicantly lower the computational cost. In our scheme, we pay special attention to the eciency of the proposed authentication scheme since the nodes in MANETs are often constrained in battery power, memory, bandwidth, and CPU power. We explain the details of HEAP in Section 2.4. Using simulations in Section 2.6, we show that HEAP signicantly lowers memory requirements and latency compared to previous schemes. In addition, our simulations show that the extra CPU and bandwidth overhead incurred by HEAP is negligible when compared to using no security scheme at all. The rest of the chapter is organized as follows. We present related work in Section 2.2. We explain our security goals in Section 2.3. We then describe our proposed HEAP scheme and its security analysis in Sections 2.4 and 2.5. Using simulations, we compare HEAP with other packet authentication schemes in Section 2.6. Finally, we conclude this chapter and give some directions for future research in Section 2.7.

2.2

Related Work

MANETs security research includes areas such as intrusion detection, secure routing, key establishment and distribution, and authentication. Intrusion detection and response is addressed in various studies (e.g., [15, 16, 35, 48]). In [18] Dahill et al identify several security vulnerabilities in the popular routing protocols such as AODV and DSR. They propose to use asymmetric cryp-

tography to secure these protocols. Other secure routing protocols are presented in [47, 50, 52], but they assume the pre-existence and pre-sharing of public and secret keys for all initial members. The key sharing problem is considered by researchers in [22, 23, 24, 34, 94, 104]. Works such as [46, 56] aim at designing self securing MANETs without needing third party certifying authorities outside the network. Other researchers have proposed schemes, including SEAD [27] and Ariadne [28], for securing routing protocols [55, 91, 92, 99, 100, 101, 102]. Most of these schemes authenticate only control packets and not data packets. Extending these schemes to directly authenticate data packets would result in too much overhead. On the other hand, not authenticating data packets leads to serious vulnerabilities against attacks such as DoS, replay, man in the middle, wormhole, and impersonation attacks. Since it is important to guard against these attacks we need to authenticate data as well as control packets. We have designed our scheme, HEAP, to authenticate both types of packets. For comparison, three other packet authentication schemes presented in the literature are also designed to authenticate data as well as control packets: TESLA [49], LHAP [57, 58] and Lu and Poochs algorithm [45] (hereafter referred to as Lu). These three algorithms approach the problem of authentication in slightly dierent ways but all of them use one-way hash key chains. For example, TESLA provides end-to-end authentication. Although it is not specically designed for MANETs, it can easily be applied to them. LHAP and Lus algorithm build on the principles of TESLA and are specically intended for MANETs. They provide hop-by-hop authentication just like HEAP. For this reason, we found it suitable to compare the security and performance of our algorithm against theirs. In the rest of this section, we briey describe these schemes and discuss their major security merits and vulnerabilities.

10

2.2.1

TESLA

TESLA is a very ecient multicast stream authentication protocol that can be applied towards wired as well as wireless networks. It can be used for unicast and broadcast applications as well, and its parameters can be adjusted to adapt to varying network conditions, such as congestion. However, since TESLA was not specically designed for MANETs but for LANs in general, it has certain drawbacks which make it less suitable for MANETs. For instance, packets are not authenticated at every hop, instead they are only authenticated by the nal receiver after a delay of several seconds. The packets are held in a cache at the receiving node until the hash key used to authenticate them has been disclosed by the sender. If the hash key can regenerate the MAC of the packet, the packet is considered authentic; otherwise, it is dropped. Intermediate nodes simply forward the packets without authentication. As a result, an attacker can easily launch Denial of Service (DoS) attacks by ooding the network with bogus packets. These packets can ood the packet caches of all receiving nodes causing them to overow and drop legitimate packets. An attacker could also easily launch worms that would quickly propagate throughout the network unchecked by the forwarding nodes. Hop-byhop authentication restricts the damage of this type of attack by limiting its propagation. In addition, TESLA requires the clocks of all the nodes in the network to be loosely synchronized. This requires a secure time synchronization protocol and possibly time servers to synchronize with. Such time servers may not always be available or reachable in a MANET. Any vulnerability in the synchronization mechanism could potentially allow an attacker to compromise the scheme and successfully send forged packets. A secure time synchronization protocol suitable for MANETs needs to be developed and tested for TESLA to be applicable in

11

MANETs. However, as discussed in [57, 45], secure time synchronization is dicult to achieve in MANETs.

2.2.2

LHAP

LHAP was specically designed for MANETs and it introduces the idea of hop-by-hop authentication. It builds on the principles of TESLA and tries to overcome some of its drawbacks. For example, LHAP does not require loose time synchronization. It is also very ecient and it authenticates packets instantly, reducing latency and eliminating the need for a cache at every node. However, LHAP is vulnerable to wormhole and man-in-the-middle attacks. LHAPs authors themselves point out this vulnerability (see Section 3 of [57], Collaborative Outsider Attack). Briey speaking, this vulnerability allows an outside attacker to eavesdrop on authentic packets sent by a node, modify them and retransmit them to another node in the network that is outside the range of the original node. This can be done using a dedicated private channel between two colluding nodes (i.e., a wormhole) or by the attacker being in the middle of the sender and the receiver that are outside each others range. To thwart this attack, LHAPs authors suggest using GPS devices in all the nodes to ascertain whether a sending node should be within transmission range of the receiving node. We do not think it is practical to equip all the nodes with GPS devices, especially if those nodes are sensors or small wireless devices. We stress that even with GPS coordinates, it is very dicult to gure out whether another node is within transmission range because the range is aected by complex factors such as terrain, weather conditions, radio noise, and transmission power level. In a MANET, all of these factors may continually change and so it is not possible to verify whether a node is within transmission range, unless it is unambiguously too far o or 12

very close. LHAPs authors admit that their scheme does not fully address this attack. Because of this vulnerability an attacker can successfully send forged packets which will be considered authentic by the receiver. This goes against the purpose of the scheme which is to authenticate all incoming packets and prevent unauthentic packets from being propagated, leaving LHAP potentially vulnerable to wormhole, man in the middle, DoS and replay attacks.

2.2.3

Lu and Pooch

Lu and Poochs algorithm builds on LHAP. Like LHAP, Lus algorithm also uses hop-by-hop authentication and is ecient, but unlike LHAP it uses only one key at every node instead of two. Like TESLA, Lu also uses delayed key disclosure causing network latency to increase, but the delay is not as large as TESLAs. We show here that Lus algorithm is also vulnerable to wormhole and man-in-the-middle attack. Delayed key disclosure schemes like TESLA and Lu have a security condition that a data packet can only be considered safe and authentic if the receiver receives the packet before the sender discloses the corresponding key used to generate the MAC for that packet. Otherwise, an adversary would retrieve the disclosed key, generate the MAC for a forged packet and send it to the receiver. The receiver would consider that packet to be authentic since it would not know that the key had already been disclosed. To guard against this possibility, the sender in TESLA informs the receiver at what time it will transmit the key disclosure packet. If a data packet is received well before this time and its MAC is later authenticated with the disclosed key, the packet is considered authentic. But if a packet is received after the key disclosure time, then it is dropped even if the receiver has not yet received the key. This scheme requires that the clocks of the sender and the receiver must be synchronized, which is dicult to achieve. To circumvent this problem of 13

synchronization, Lu introduced an idea follows. Instead of the sender stating that the next key update packet will be broadcast at time t, the sender will state in the data packet a delay parameter that will state that the key will be disclosed d milliseconds after the transmission of this data packet. But there is a problem with this latter approach. A clever attacker can launch a wormhole or man-in-the-middle attack where it will forward all the packets from the sender to the receiver during the bootstrap phase so that the receiver mistakenly believes that the sender is its neighbor. Then the attacker will wait until it receives a key update packet from the sender. Once the key is received by the attacker, the attacker can forge many packets and send them to the receiver, and then disclose the key. Because the receiver does not expect a key update packet from the sender at a xed time t, it has no way of knowing that this key was transmitted by the sender some time ago and is now obsolete. The attacker can use this obsolete key and all subsequent keys to successfully transmit forged packets. In this way the attacker can thwart Lus scheme.

2.3

Security Goals

Outsider vs. Insider Nodes: An outsider node is a node that is not an authorized member of the MANET whereas an insider node is an authorized member. For instance, in a military setting each authorized soldier might possess a signed certicate from a trusted third party granting him membership in the MANET. Such a node is an insider node. Any node not possessing such a certicate or possessing a revoked certicate is considered an outsider node. In essence, the goal of this chapter is to thwart attacks from outsider nodes. Detecting

14

the attacks from insiders is left to the Intrusion Detection Systems. However, we do provide a foundation on which a response system can be based by providing the capability to eectively cut o a compromised insider from the MANET. In addition, HEAP oers some level of protection against insiders who try to forge packets and impersonate other insiders. But because insiders already have access to the MANET, it is easy for them to launch more sophisticated attacks rather than simply trying to forge packets. In Section 2.5, we discuss these issues in detail. We now list the keys security goals in defending the underlying network against outsider nodes. In Section 2.5, we explain how these goals are addressed by our proposed scheme. 1. Any packet transmitted by an outsider node should be immediately dropped by the receiving insider node at the rst hop with a very high probability. In other words, packets sent by outsiders should not be allowed to propagate through the MANET. By fullling this requirement, we can successfully guard against a myriad of attacks by the outsider, such as DoS attacks that attempt to ood the network, wormhole attacks, man-in-the-middle, SYN ooding etc. This is because we are eectively disabling the outsiders ability to route any packets to any node that is not its neighbor. Even a neighboring node will simply drop packets from the outsider. However, this requirement dictates that we authenticate every packet at every hop, which in turn means that the authentication mechanism should be extremely ecient. 2. The outsider node is assumed to have the capability to spoof its identity, such as spoong its IP and MAC addresses to impersonate an insider node. We cannot rely on these markers to verify the origin of a packet. 15

3. The outsider is assumed to have access to the wireless channel so it can eavesdrop on legitimate trac. If the trac is supposed to remain condential, end-to-end encryption should be used to protect it. However, we assume that the encrypted trac and any associated MAC tags are visible to the outsider. 4. If a third party Intrusion Detection System (IDS) discovers an insider to be compromised, we must be able to exclude that insider from propagating any more packets within the MANET. Certicate Revocation Lists (CRL) may be used to revoke the certicates of compromised insiders.

2.4

HEAP: Hop-by-hop Ecient Authentication Protocol

In this section, we describe the key steps in our proposed authentication protocol, HEAP. We then highlight the dierences between HEAP, HMAC and NMAC in generating MAC (message authentication code).

2.4.1

Key Generation and Distribution

A node that wants to join a network must rst generate a single group key, called ikey (for inner key), and one pair-wise key for each neighbor, called okey (for outer key). Thus each new node will generate n + 1 new keys (n okeys and 1 ikey), where n is the number of nodes in its neighborhood. The keys are simply random bit strings and are cheap to generate. The ikey is secretly shared with all the neighbors, while the pair-wise okey is only shared with the

16

corresponding neighbor. This can be done using standard key exchange mechanisms and trusted third party certicates, such as in the X.509 standard [5]. RSI or Elliptic Curve Cryptosystems (ECC) [51] can be used as the underlying PKI. A similar procedure is used in LHAP and Lu where keys are exchanged with each new neighbor as the node moves about. Key exchange is employed under any one of the following circumstances: 1. When a node moves to a new neighborhood it exchanges keys with its neighbors. 2. When an existing node in the neighborhood has remained idle for too long, for example for several minutes. The keys need to be expired after a certain period of inactivity. This is also to accommodate nodes that leave a neighborhood. 3. The keys should expire after a certain amount of time, for example after a few hours, even if they are being used continuously without any idle time. This is to guard against brute force attacks and crypt-analysis attacks by the adversary.

2.4.2

MAC Generation and Authentication in HEAP

After the key exchange phase, packet authentication can take place. We explain the authentication process in HEAP through an example. Consider the scenario given in Fig. 2.1. NodeA needs to transmit a packet to its neighbors, A1 through A5. We assume that all the nodes have joined the network and exchanged keys as described in Section 2.4.1. So, node A secretly shares an okey with each of its neighbors, okA1 to okA5 . In addition, node A has generated an ikey, ik, and has securely distributed it to all of its ve neighbors. Only node A and its one-hop neighbors have access to ik. All the keys are hash keys, so for example they are 128 or 160 bits long, respectively, if MD5 or SHA1 is the underlying hash function. Our proposed 17

Figure 2.1. Node A needs to transmit a packet to its neighbors A1 through A5. scheme is independent of the underlying hash function. We consider the case where node A wants to broadcast a message to all of its neighbors. We want each recipient of the packet, A1 through A5, to be able to authenticate that the packet originated from node A. One way to do this would be for node A to generate a new HMAC for every individual neighbor using its okey. However, we present a more computationally ecient algorithm using a slightly modied HMAC. A key insight into the working of the HMAC algorithm [9] can signicantly lower the amount of computational overhead for multicast and broadcast applications. Recall that HMAC is computed in the following way:

HM AC(M, K) = H(K opad | H(K ipad | M )),

where H(x) is the hash value of x using some hash function such as MD5 or SHA1; is the

18

XOR operation; M is the message that needs to be sent; opad is the hexadecimal number 5C that is used to pad each byte of K up to one block size, while ipad is the hexadecimal number 36 that is used to pad each byte of K up to one block size (i.e. 512 bits); the symbol | represents concatenation. We divide HMAC computation into the following two steps:

Step 1: H(K ipad | M )

Step 2: H(K opad | hash from Step 1) For long messages, Step 1 will result in most of the computational overhead. Step 2 only needs to hash 32 bytes for MD5 and 40 bytes for SHA1. This insight led us to develop the following MAC generation algorithm for multicast and broadcast applications. We use the previously described two keys, namely ikey and okey. We use ikey to generate the hash in Step 1. So the Step 1 for node A will be:

New Step 1: H(ik | M )

The ikey is padded with 0s to make it one block wide (i.e. 512 bits). Since all the one-hop neighbors share the same ikey, these neighbors can authenticate a packet received from node A by only computing this rst step. Therefore, the sender A only needs to compute this expensive step only once regardless of how many neighbors it has. However, we cannot use the same key for the second step as well. This is because all of As neighbors have the key and anyone of them could impersonate A and send forged packets. That is why we use the pair-wise okey,

19

okAi padded with 0s to make one block in Step 2:

New Step 2: H(okAi | hash from Step 1)

Since only the sender and the receiver have okAi no third party could generate this step. Of course, this step needs to be executed once for each neighbor. But fortunately, this step is computationally inexpensive because of the small input to the hash function of only 32 or 40 bytes. Using the above MAC generation scheme, node A generates a packet using the following format and sends it to all its neighbors:

A : indA , M, M AC1 (M | indA ) . . . M ACn (M | indA )

where represents any recipient, M is the message, indA is the last index number used by node A (discussed in Section 2.4.3), n is the number of neighbors, and M ACi represents the MAC for neighbor Ai. A pseudocode for generating a packet in HEAP is shown in Figure 2.2. When Ai receives the packet, it computes the MAC and if it matches any of the MAC tags in the message and the index number is greater than the last authentic index number received the message is accepted as authentic; otherwise, it is dropped. To save on bandwidth the whole MAC need not be transmitted. Only the last half of the MAC can be transmitted in accordance with the recommendation made in [9]. This reduces the tag size and still makes the search space large enough for the adversary so that the chances of generating the correct MAC for a forged message are remote.

20

Packet generation in HEAP: Input: Message M containing the payload and headers of upper layer, index number indA , keys okA1 to okAn , and ik Output: Packet S, new index number indA 1 2 3 4 5 6 7 8 9 10 11 12 13 if indA is null then indA := 1 else indA := indA + 1 end if mac1 := H(ik | M | indA ) // New Step 1 comp mac := {} for each neighbor Ai do mac2 := H(okAi | mac1) // New Step 2 comp mac := comp mac | last half of mac2 end for S := indA | M | comp mac return S and indA

Figure 2.2. Packet generation in the proposed HEAP.

2.4.3

Index Numbers

Packet index numbers are included in the packet to protect against message replays. Before transmission, an index number is concatenated with the payload data to give the message M . Each time a packet is sent, its index number is incremented by one. The hash generated is dependent on the index number so any tampering of the index number can be detected. Any attempt to store and then retransmit the packet by a malicious node will be thwarted because the receiving node expects to see an index number greater than the last authentic index number and so it will consider this packet to be unauthentic.

21

2.4.4

Dierences between NMAC, HMAC and HEAPs construct

Bellare et al. presented NMAC and HMAC in [9]. They listed two major dierences between NMAC and HMAC. First, NMAC (Fig. 2.3) uses two keys, k1 and k2 , while HMAC (Fig. 2.4) uses only one key, k. Second, NMAC replaces the xed Initialization Vector (IV) with the

Figure 2.3. Illustration of the NMAC construct.

Figure 2.4. Illustration of the HMAC construct. key. Normally, hashing algorithms such as MD5 and SHA1 use xed IVs. Replacing the IV with the key would necessitate a modication to the hashing algorithm so that it takes the IV as a parameter instead of keeping it xed. This would not be possible in o-the-shelf hardware 22

implementations of MD5 or SHA1 and it would involve modifying any software library code for MD5 and SHA1. Although the change required in software would be trivial, it would still be preferable if no change was required at all and that was one of the motivations for the authors of HMAC. In HEAP (Fig. 2.5), we wanted the ability to use o-the-shelf hardware or software implementations of the hashing algorithm like HMAC, but we also wanted to use two keys instead of one like NMAC. Therefore, neither HMAC nor NMAC was completely suited to our

Figure 2.5. Illustration of the HEAP construct.

purpose and we decided to modify the HMAC instead so it could accept two keys. In the gures above, the symbol represents padding by zeros to increase the size of the string from l bits

to b bits, where l is 128 bits for MD5 and 160 bits for SHA-1, while b is 512 bits for both. The keys in HMAC and HEAP are also padded with zeros to make them b bits long.

23

2.5

Security Analysis of HEAP

In this section, we present security analysis of HEAP and evaluate HEAP against our security goals that are stated in Section 2.3. Evaluation against Goal 1: The rst goal is to prevent all outsider trac from propagating through the MANET. By denition, we assume that the outside attacker does not have any control over insider nodes, otherwise it is no longer an outsider but an insider. We can see from the HEAP algorithm that the only way an outsider can successfully propagate a packet is if it is able to generate the correct MAC for the packet. This means that the overall security of HEAP is dependent on the security of HEAPs cryptographic construct. Therefore, we now analyze the security of HEAPs cryptographic construct. As discussed in Section 2.4.4, the primary dierence between HMAC and HEAPs construct is that HMAC uses one key while HEAP uses two keys. However, as pointed out by its authors, HMAC actually uses two pseudorandom keys that are generated from one key. This is accomplished by padding the key with ipad and opad to generate two dierent seeds and then using the compression function on them to generate two pseudorandom keys. HEAP already has two dierent keys that can form the seeds for the compression function, eliminating the need to pad the keys. We still need to run the keys through the compression function, however. Otherwise we would need to replace the IV with the keys, like in NMAC, and that would prevent us from using o-the-shelf hash function implementations. Because both HMAC and HEAP use two pseudorandom keys, we can apply the same security analysis for HMAC (or NMAC) to HEAP. For the case of an outsider that does not know any of the two keys in HEAP, the security analysis of HMAC given in [9] holds and we

24

can apply the same proof of security to HEAPs construct. Adversarial Model: The adversarial model used in [9], as well as in this chapter, is that the adversary is allowed to query the function HEAP and obtain the correct MAC for up to q messages of length L, even though the keys are unknown to him. The adversary spends a total processing time t in the attack. This is a very strong adversarial model since it is unlikely that an outsider will be able to query HEAP using several messages of its choice and getting the correct MAC. The insider nodes will simply drop its requests. However, it serves to give a worst-case analysis. Based on [9], we can give the following theorem. Theorem 1 If the keyed compression function f is an (f , q, t, b)-secure MAC on messages of length b bits, and the keyed iterated hash F is (F , q, t, L)-weakly collision-resistant then the HEAP construct is an (f + F , q, t, L)-secure MAC, assuming both the ikey and the okey are unknown to the attacker. The theorem states that any outsider that launches an attack against HEAP has a probability of success that is no more than the sum of F , the probability of nding collisions in the secretly keyed iterated function F , and f , the probability of breaking the keyed compression function, f , given t amount of time. The attacker is allowed to make q queries of its choice to HEAP, where each query has a size of at most L bits. The size of the message that the compression function takes is b bits. Proof 1 Rather than repeat the entire proof here, we refer the reader to Section 4.2 in [9] since the proof for HEAP is the same as HMAC when the attacker is an outsider and both keys are unknown to him. 25

Insider Adversarial Model: For an insider, the adversarial model stated above now becomes more realistic since an adversarial insider can send an arbitrary number of messages to a neighboring target node and observe the correct MAC for them. Furthermore, the probabilities in Theorem 1 no longer hold. This is because the neighbor knows the ikey so the security is reduced. The security for an insider adversarial model can be stated in the following theorem. Theorem 2 For a neighboring attacker that knows the ikey but not the okey, HEAP is an (f + kF , q, t, L)-secure MAC, where kF is the probability of nding collisions in the underlying hash function when the IV is xed and known to the attacker. Proof 2 Following Theorem 1 and the proof in [9], we can see that HEAP (and also HMAC) can be broken in one of two ways. The attacker can either break the underlying keyed compression function, f , with probability f ,, or the attacker can nd collisions in the keyed iterated hash function, F , with probability F . Knowing the ikey makes nding collisions in F much easier. In fact, as the theorem states, the probability of nding such collisions is equal to the probability of nding collisions when the IV is xed and known, i.e. F , reduces to kF . Suppose there exist two dierent messages, M and M , such that H(M ) = H(M ) when the IV is H(ik). Let us assume the probability of nding such messages that collide is kF .We will show that for an insider, F = kF . This can be shown by observing the two steps of HEAP: Step 1: H(ik|M ) = M ACi Step 2: H(okAi |M ACi ) = M ACo Following our adversarial mode, rst the attacker will query the target node using message M and obtain the correct MAC for it, M ACo . Being an insider, the attacker knows ik 26

but not okAi. From Fig. 2.4 we can see that if H(M ) = H(M ), then H(ik|M ) = H(ik|M ). This is because the output from the leftmost stage f is the same for both cases so the IV for the second stage is H(ik), and as we assumed H(M ) = H(M ) when the IV is H(ik). Therefore, M ACi will be the same for both M and M .

H(ik|M ) = H(ik|M ) = M ACi

It follows that if M ACi is the same for both messages then M ACo will also be the same for both messages regardless of the value of okAi since Step 2 would be identical for both. Therefore:

HEAP (M ) = HEAP (M ) = M ACo

Thus, the attacker simply needs to obtain the MAC for M and then construct a new packet, replacing M with M , and retaining the same MAC, M ACo . The message will be accepted as genuine by the recipient regardless of the value of okAi . So for an insider, the probability, F , of breaking F reduces to the probability, kF , of nding two colliding messages, M and M when the IV is H(ik), i.e. F = kF . However, note that the security is reduced only against insiders that are neighbors and that already have access to the MANET. For outsiders that are not members of the MANET, the security of HEAP is the same as the security of HMAC. Finding collisions in the underlying hash function is still non-trivial and requires considerable amount of resources and time. The insider is already capable of propagating packets through the MANET so there would be no point in it trying to forge packets by nding colli-

27

sions. If it wants to incriminate another node, it can simply change the source IP and MAC address headers in each packet and transmit them using its own keys so that the receiver would think that the packet did not originate from the attacker but the attacker simply forwarded it. The inside attacker would be better o using its resources to launch direct attacks rather than trying to forge packets by nding collisions. HEAPs security is further improved by having the security layer below the network layer and including the IP headers in the message to be hashed. This is because the IP checksum is included in the message and it reduces the likelihood that a message found through collisions would contain valid IP headers and checksum. If the headers and checksum are not valid, the network layer would end up dropping the forged packet even if the packet were able to slip through the security layer. Evaluation against Goal 2: HEAP does not make any assumptions about the IP or MAC address of the packet. Even if these addresses are spoofed by an outsider, the outsider will not be able to propagate a packet unless it can generate the correct MAC for it. Therefore, HEAP is secure against IP and MAC address spoong. Evaluation against Goal 3: In our analysis of HEAP, we made an even stronger assumption than simply that the attacker can eavesdrop on packets and view the message and its MAC tags. We considered the case where the attacker is able to choose its own messages and obtain their correct MAC tags, known as the chosen message attack. Therefore, our security analysis holds even if the attacker were able to view a very large number of messages. Evaluation against Goal 4: As stated, HEAP is not designed to detect insider attacks. But if a third party Intrusion Detection System (IDS) were to detect a compromised insider node and alert other nodes about it, HEAP provides a framework for an eective Re28

sponse System. The compromised node would be placed on a Certicate Revocation List (CRL) that would be propagated throughout the network. Nodes neighboring the compromised node would re-initiate the bootstrapping phase and exchange new keys with their legitimate neighbors but not with the compromised node. If the compromised node moved to another locality the other nodes would not exchange keys with it either because it is on the CRL. In this way, the compromised node would not be in possession of valid keys any more and it would be treated just like an outsider. We do not deal with the implementation details of the IDS and the CRL in this chapter.

2.6

Simulations and Results

We ran simulations in order to evaluate the performance of HEAP and compare it against TESLA, LHAP, and Lus algorithm and also against a scenario without any security.

2.6.1

Simulation Setup

We used GloMoSim v2.03 [32] simulator for our experiments and used ODMRP [34] as our underlying multicast routing protocol. Other popular protocols, such as AODV or DSR, do not support multicast routing. Unfortunately, GloMoSims ODMRP implementation had a critical bug in it and we had to x it before we could use it. The MAC protocol used was IEEE 802.11 and the transport layer protocol was UDP. The size of the data packets was 512 bytes, except in the CPU time simulation where the packet size was variable. The trac sources were Constant Bit Rate (CBR). For all other parameters, GloMoSims default conguration was used where a nodes range was found to be 140 meters.

29

We ran simulations where the nodes were static, as well as where the nodes were mobile. For the static case, we used a grid network containing 10 X 10 nodes (100 nodes total). Each node was 100 meters away from its neighbor. For the mobile case, all of the 100 nodes were free to move about randomly. The starting positions of all the nodes were chosen randomly in a terrain measuring 1200 x 1200 meters. To set the parameters of TESLA, LHAP and Lu, we studied the recommendations made by their respective authors in their papers. TESLAs authors recommend in Section 2.9 of their paper [49] under Sender Tasks that wireless networks should have a key disclosure delay of 15 to 30 seconds, so we used a delay of 15 seconds. LHAPs authors mention using a TESLA interval of 1 or 2 seconds in the example in Section 4 of their paper [57]. We used an interval of 1 second for LHAP. Lus authors mention using a 2 or 3 second key disclosure delay in Section IV.C.2 of their paper [45], so we used a delay of 2 seconds. In each case, we have used the minimum delay recommended by the authors and biased the results in their favor so that we could conservatively assess the performance of HEAP against their algorithms. The following metrics were collected.

2.6.2

Latency

One source node was used to send packets to ve dierent nodes that were 1, 2, 3, 4 and 5 hops away from the source, respectively. 10,000 packets were sent by the source and the mean end-to-end latency of all the packets was measured. The results of mean latency vs. number of hops between sender and receiver are plotted in Fig. 2.6 (on a logarithmic y-axis) for all four algorithms, as well as for plain ODMRP. In LHAPs case, if any node on a path from the source to the destination has just joined or rejoined the network after a short delay, it may wait as 30

Figure 2.6. Mean Latency (ms) plotted on a log axis vs. Number of hops for all algorithms. The bottom curve represents ODMRP, LHAP Min and HEAP since all three overlap almost exactly. long as one TESLA interval in order to authenticate packets. That scenario is depicted by the curve LHAP Max. Similarly, LHAP Min represents the minimum latency under the ideal case that no node needs to wait for a key update. The curves for plain ODMRP, LHAP Min, and HEAP are almost the same and are overlapping. The results show that HEAPs latency is the lowest and is almost the same as the latency without any security scheme, using only ODMRP. LHAPs minimum latency is also the same, but its maximum latency is much higher. TESLA and Lus latency is several orders of magnitude higher than HEAPs, especially at large hop counts. This is because TESLA and Lu use delayed key disclosure and cache packets until their key is disclosed. While TESLA caches packets only at the nal recipient node, Lu caches packets at every hop, so Lus latency increases linearly with the number of hops. The latency of several seconds or tens of seconds can 31

become critical in real time applications or in QoS applications. HEAP would be the preferable choice for such applications.

2.6.3

Throughput and Packet Delivery Ratio

Two simulations were run, one where all the nodes were static and one where the nodes were moving about randomly.

Static Case In this simulation, one source node sent packets to nine receiving nodes. Three of those nodes were one-hop away from the source, three nodes were two hops away, and three nodes were three hops away. The senders transmission rate was varied from 1 packet per second to 100 packets per second, where each packet contained 512 bytes of data. A total of 10,000 packets were transmitted by the sender in each simulation run. Five dierent algorithms were tested: Plain ODMRP, TESLA, LHAP, Lu and HEAP. The throughput was computed for each node and the mean of all nine nodes was taken. The results are plotted in Fig. 2.7. The number of packets successfully received by each node was also measured and then divided by the total number of packets sent (i.e. 10,000) to compute the packet delivery ratio for each node. Then the mean of these ratios was taken and the results are plotted in Fig. 2.8. Fig. 2.8 shows that the peak delivery ratio is about 84% and is sustained up to a packet rate of about 25 packets/sec for ODMRP, TESLA, LHAP and HEAP. For higher packet rates, the ratio reduces sharply and then tapers o to about 12. Similarly, in Fig. 3, the peak throughput is achieved at about 25 packets/sec. This is because the throughput is a product 32

Figure 2.7. Mean Throughput (bytes/sec) vs. Packet Rate (pkts/sec) for all ve algorithms. of the packet rate as well as the delivery ratio. Beyond 25 packets/sec, the delivery ratio falls sharply cutting throughput. Between 40 to 100 packets/sec, the eect of decreasing delivery ratio is oset by the increasing packet rate so the throughput is nearly constant. Lus algorithm performs signicantly worse than all the others in both throughput and delivery ratio simulations. This is because Lus algorithm caches packets at forwarding nodes. The source node sends out packets uniformly in time (due to CBR) but these packets are cached at the rst forwarding node until a key update packet is received. Once the key update is received, the forwarding node authenticates all the packets at once and transmits all of the packets in the cache, one after another in rapid succession, causing a burst of transmission.

33

Figure 2.8. Mean Packet Delivery Ratio (%) vs. Packet Rate (pkts/sec) for all ve algorithms. After that burst is over, the cache is empty again. The result is that all the intermediate nodes transmit packets in bursts and then stop transmissions completely, then transmit a burst, then stop. This is very inecient and wastes available bandwidth. If two or more neighboring nodes happen to transmit their bursts simultaneously, there is contention on the channel and collisions may occur, causing packets to be dropped. In addition, if a node is unable to empty the cache quickly enough due to channel congestion the cache may overow and cause packets to be dropped. This theory is supported by the observation that most of the nodes that were 3 hops away received zero packets out of the 10,000 packets sent by the source. There is no statistically signicant dierence between the curves for ODMRP, TESLA, LHAP and HEAP, so we deduce that the characteristics of ODMRP dominate the throughput

34

and delivery ratio and the eects of TESLA, LHAP and HEAP are negligible. This result shows that the byte overhead introduced by HEAP is negligible since it has an insignicant eect on throughput and packet delivery ratio.

Mobile Case In this simulation, the nodes were free to move about randomly as stated in the beginning of this section. All the other parameters were the same as for the static case where one node was sending packets to nine dierent receiving nodes. The results are plotted in Fig. 2.9.

Figure 2.9. Mean Throughput (bytes/sec) vs. Packet Rate (pkts/sec) for all ve algorithms when the nodes are moving about randomly. The results show that Lu and TESLA perform signicantly worse than ODMRP, LHAP 35

and HEAP. This is probably due to the fact that TESLA and Lu use delayed key disclosure and if the keys are never received, the packets they authenticate also need to be dropped. Mobility causes packet delivery ratio to deteriorate causing more lost keys and lower throughput for TESLA and Lu. The results of ODMRP, LHAP and HEAP are not signicantly dierent and HEAP does not cause any noticeable loss in ODMRPs performance under mobility.

2.6.4

Memory Requirement

TESLA, LHAP and Lu all use precomputed hash key chains that must be generated and stored oine, before transmissions can begin. When a node runs out of keys, it must stop and generate new key chains and store them before it can continue transmissions. Therefore, it is desirable to generate and store long key chains in each node to make cessation of transmissions as infrequent as possible. In addition, TESLA and Lu use delayed packet authentication. This means that all the received packets should be stored in a cache in the node until their key is disclosed. The cache should be large enough to store all incoming packets until the key is received. In TESLA, only the receiving node needs to have a cache, but since in a MANET any node can become the recipient, all the nodes need to have a cache anyway. The necessity to have a large cache and store long key chains in each node balloons the memory requirement of each scheme. HEAP does not have any of these requirements and it only needs to store one pair-wise key per neighbor and one neighborhood key, making its memory requirements minute compared to the others. We computed the memory requirements of each scheme based on how large we want the cache and the key chains to be. We selected a cache size that was large enough to store all the packets between key updates, using the key update intervals mentioned above and the 36

simulations maximum packet rate of 100 packets/sec. The results for throughput, delivery ratio and latency all use this cache size as smaller caches would drop packets and adversely aect the simulation results. Since LHAP does not use any caches, to compute its memory requirements we used the packet rate that maximizes it throughput, namely 25 packets/sec according to our simulations. LHAP rapidly consumes its keys (one key per packet) and so we need extra long key chains for LHAP. The results are plotted in Fig. 2.10 on a logarithmic y-axis. We plotted the memory requirement vs. how long a key chain would last (shown on the x-axis). HEAP does not use key chains and its memory requirement is independent of time. We assumed an average of ten neighbors per node for HEAP. In all the algorithms, the memory requirement shown is per node, so that every node would have to have that much memory set aside. HEAP uses only 176 bytes per node. The results clearly show that HEAP is extremely economical in terms of memory compared to the other three schemes. This is especially useful for MANETs where small wireless devices or sensors may be constrained in memory.

2.6.5

Computational Cost

To compare the computational cost of HEAP against other schemes, we measured the CPU time needed to compute the Message Authentication Code (MAC) for dierent message sizes and dierent number of neighbors. We measured the CPU time taken by TESLA, Lu and HEAP on a 2.0 GHz Intel Pentium M processor. Note that LHAP does not compute MACs for the message for eciency reasons, but LHAPs authors concede in Section 2.3 of their paper [57] that this makes their algorithm less secure than TESLA. The time taken by TESLA, Lu and HEAP is identical when there is only one neighbor and depends on the message size. However, HEAPs CPU time increases with the number of neighbors since it computes a dierent MAC 37

Figure 2.10. Memory Requirement (bytes) on a log axis vs. Duration of Key Chain (mins) for all four algorithms. for each neighbor. To quantify this computational cost and compare it to that of TESLA and Lus, we actually run the algorithms on a 2.0 GHz Intel Pentium M processor and measured the CPU time taken by HEAP, TESLA and Lu. Fig. 2.11 shows the time taken by HEAP when the number of neighbors is varied for dierent packet sizes. Note that TESLA and Lus times with any number of neighbors are the same with that of HEAPs with one neighbor since they just compute one MAC for all neighbors. The graph shows that even with six neighbors, HEAP only adds an overhead of about 5 microseconds regardless of message size, over TESLA, Lu or any other scheme that computes

38

Figure 2.11. CPU Time (micro seconds) vs. Number of Neighbors for HEAP. HMAC over the entire message. If we would have used the unmodied version of HMAC for HEAP, the CPU time would have been six times that of TESLA for six neighbors, ten times for ten neighbors and so on. Due to our modications to HMAC, the algorithm becomes very ecient. Even on a very constrained CPU device, we do not expect this overhead to be more than 100 microseconds. The mean one hop latency that we found for ODMRP was about 6,000 microseconds and so, it is clear that the overhead of 5 to 100 microseconds is negligible, especially in view of the level of security the algorithm oers.

39

2.7

Conclusions and Future Work

In this chapter we presented a new Hop-by-hop, Ecient Authentication Protocol, called HEAP, that is intended to guard against attacks from outsiders. This protocol is suitable for use in MANETs for unicast, multicast or broadcast applications, and is independent of the routing protocol used. It is based on a modied HMAC algorithm that uses two keys and is very ecient. We stated our security goals for HEAP and presented a security analysis of HEAP to evaluate it against those goals. We showed that the security of HEAP is equivalent to the security of HMAC for attacks against outsiders. We compared the performance of HEAP with three other previously published authentication algorithms, namely TESLA, LHAP and Lu and Poochs algorithm using simulations. TESLA is vulnerable to DoS attacks and requires secure time synchronization of all the nodes. It introduces very large latencies of several seconds making it unsuitable for real time or QoS applications. It also has huge memory requirements at every node (over 1MB in our simulations) and has mediocre throughput when the nodes are mobile. LHAP is vulnerable to wormhole and man-in-the-middle attacks as pointed out by its authors. We do not think using GPS devices at every node, as recommended by its authors, is a practical solution. An attacker can successfully transmit forged packets using these attacks, defeating the purpose of authentication. It also has very large memory requirements at every node (about 1MB for a one hour key chain) and consumes keys very rapidly. Once a node runs out of keys in its key chain, it needs to stop and regenerate the key chain causing cessation in its transmissions. Lus scheme has low overall performance. Their scheme signicantly degrades through-

40

put and packet delivery ratio, both in static as well as mobile nodes. In addition, it introduces large latencies making it unsuitable for real time applications. HEAP is resistant to several outsider attacks such DoS, wormhole, replay, impersonation and man-in-the-middle attacks by making it very dicult for an outsider to propagate any forged packet. It has extremely low memory requirements (only 176 bytes in our simulations) and its CPU overhead is negligible, making it suitable for constrained wireless devices. Its byte overhead is also negligible since it has an insignicant eect on overall throughput and packet delivery ratio. Its latency is almost the same as without any security scheme, making it ideal for real time and QoS applications. In future work, we plan to reduce the bootstrapping and key exchange overhead by proposing ID based, Certicateless key exchange. The concept of ID based PKC was introduced in [66] and it was enhanced in [65] to overcome the key escrow problem. The key escrow problem is that in ID based PKC, the private key generating agency generates all the keys for the participants. This means that the key generator is in possession of all the private keys. In [65], an algorithm was proposed to overcome this problem by allowing the key generator to generate part of the key, while the rest of it is generated by the user secretly. We can use this algorithm to design a more robust ID based key exchange mechanism suitable for MANETs. By relying on ID based keys, we no longer need to verify traditional X.509 style certicates with third party signatures. This reduces the overhead in exchanging keys and makes the overall scheme more ecient.

41

Chapter 3:
3.1

Defending Against Insider Attacks

Introduction

As explained in Chapter 2, HEAP is designed to defend against attacks originating from outsiders. It is not designed to defend against attacks coming from insiders. We are now focusing our attention on designing a separate system that will work with HEAP to guard against insider attacks. A typical MANET may have several resources, such as printers, le servers, databases, web servers etc. In addition, many nodes may provide dierent services as part of a larger Service Oriented Architecture (SOA) [67] approach. In SOA, large applications are modularized into smaller services which run on heterogeneous devices. It especially makes sense to use SOA in MANETs so that large, computationally expensive applications can be implemented on resource constrained devices in a distributed fashion. But from a security standpoint, we need a mechanism to regulate access to these resources and services by clients. We would like to guard against insider clients who would misuse these resources or launch attacks against them. On the ip side, we would like to ascertain that the service provider itself is reliable. To accomplish this, we are developing a hybrid Trust Management (TM) model for MANETs, based on Role and Reputation Systems, that will control access to various resources on the network. The exact form of the model will vary depending on the architecture of the MANET. The idea is that when a client requests a resource from a server, the client sends signed credentials to the server informing the server of the role assigned to the client. This is

42

like a traditional role based TM. At this point, one of three rules would apply: 1. If the client has a highly privileged role that grants unrestricted access to the resource, service would be granted to it. 2. If the client has an under-privileged role below a certain minimum level, service would be denied to it. 3. If the client has a role that is above the minimum privilege level but below the unrestricted access level, then the clients reputation is queried. If it is found to be acceptable, access is granted; otherwise, it is denied. To discover the reputation of a client the server will query other resource providers that have had some prior interactions with this client. The other providers will inform the server how many past interactions with the client have been satisfactory and how many have been unsatisfactory. Based on this information the server will compute the reputation for the client and if it is satisfactory, access to the resource will be granted, otherwise it will be denied. The motivation for this model is based on real world scenarios. Suppose you are the inventory manager for a large retailer. If your supervisor, who has a privileged role, asks for write access to the inventory records you grant access to him. If the companys custodian asks for the same access, you refuse. But if another manager, who is your peer, asks for write access, you base your judgment on how well you, or other people you trust, know him. If he is new to the company or if he is suspected of trying to defraud the company, you may ask him to get written authorization from a supervisor. However, if youve known him for a long time and found him to be trustworthy, you may grant him access without further verication. In other words, whenever a role is in a borderline or gray area, we turn to the individuals reputation to 43

make a decision. Thus, well behaved individuals would be granted access without many hurdles while less trusted individuals will have to provide further verications. The scheme provides an incentive to users to behave well regardless of their role so that they may enjoy more privileges in the future. Reputation based systems have been suggested before for peer-to-peer systems and on the Internet, however we are designing them so that they can be used in MANETs. This means we have to account for factors such as limited computational resources, no online central authority, nodes that cannot be completely trusted, and malicious nodes that may be colluding [3]. We are also combining the principles of reputation and role based systems, as mentioned above, to overcome the drawbacks of either system.

3.2

Related Work

In general, Trust Management (TM) has traditionally taken three broad approaches: Monitoring based TM, Reputation based TM, and Role based TM. In this chapter we discuss each approach and compare their advantages and disadvantages. In the following chapters, we propose a new hybrid Trust Management model for MANETs that attempts to capture the advantages of the existing schemes while alleviating most of their disadvantages.

3.2.1

Monitoring Based Trust Management

In this approach, each nodes wireless trac is monitored by its neighbors and conclusions are drawn based on its behavior [6, 31]. Many monitoring based systems have been proposed in the literature [4, 35, 36, 37, 38] and the principle behind its operation is that trac from a

44

node is classied as legitimate or illegitimate by its neighbors. Examples of illegitimate trac include known attack signatures, viruses and worms, or anomalous behavior. A node that is behaving well and communicating mostly legitimate trac is deemed to be trustworthy. Such a node accumulates good credit points through its good behavior and slowly gains access to increasingly sensitive resources.

Advantages 1. This model has a very fast response time. A misbehaving node can quickly be detected and its trac can rapidly be blocked. This is because all the information gathering and decision making is done within a nodes one hop neighborhood. Any detected malicious trac cannot pass beyond this one hop neighborhood. 2. The model relies solely on the observed behavior of the node and not on third party recommendations made from outside the neighborhood. This reduces the possibility of false recommendations being made in favor of or against the node. Of course, we still have to deal with the possibility of a malicious neighbor raising a false alarm against the node. But this would be easier to verify since other neighbors are also monitoring the same node and too many false alarms by a single neighbor would raise suspicions against the neighbor itself.

Disadvantages 1. The most serious disadvantage of using monitoring based trust management systems is that they have been shown to raise too many false positives due to noise. According to [85], traditional simulated noise models do not mimic the behavior of observed noise 45

patterns in an actual setting, leading to optimistic results in simulations. In experiments done on MANET testbeds, it was shown that monitoring based systems do not work well as they raise too many false alarms [86]. Therefore, in our research, we do not consider using monitoring based systems. 2. Another drawback of this approach is that a malicious node might pretend to be well behaved for a sucient length of time until it acquires enough credits to gain access to its target resource. Once it has gained that access it could successfully launch its attack, which might go undetected. Examples include gaining read access to a le server that stores condential les, or issuing well formed but malicious commands to a military mass communications device. 3. Since the monitoring and response system is based on the immediate neighborhood alone, a blocked node could simply move to a new neighborhood and start over. This problem can be mitigated by maintaining Certicate Revocation Lists (CRLs) across the network, but that is not easy to do. 4. Information about a nodes past behavior is not retained except for a short time and future interactions are independent of it. A previously malicious node gets to start again with a clean slate. This is contrary to human interactions where convicted felons, for example, are unable to gain membership in authoritative government agencies. Again the problem could be reduced by maintaining CRLs, but it is not easy to do so. 5. Another drawback is that due to the absence of any prior information, the network is forced to allow a new node to join the network, albeit with limited access rights.

46

3.2.2

Reputation Based Trust Management

This form of trust management is based on the reputation of a node as judged by other nodes. Reputation is the opinion of one entity about another [89]. This model is inspired by PGPs web of trust model [29] in which a member node can vouch for a client node that wants access to a resource. The model is based on prior information about the client node [10, 53, 54]. A node builds its reputation by previous positive experiences with other nodes. What constitutes a positive experience is left to the discretion of the node that vouches for it. In this way this model overlaps with the monitoring based approach. A vouching node might have received positive recommendation for the client from someone it trusts, or it could personally know and trust the owner of the client node, or the client node could have accumulated trust through prior positive interactions.

Advantages 1. This model is similar to how human beings gain each others trust over a long period of time through experience. 2. Records for every node and every interaction are kept so a nodes history is permanently tied to it. This will encourage potential adversaries to behave well so that they could maintain a good reputation.

Disadvantages 1. The drawback of this approach is that there are no xed criteria to build a reputation. One vouching node may easily trust another node while another vouching node may not. It is dicult to assess the reliability and value of another nodes subjective recommendation. 47

Some attempt could be made to assign standardized scores to each type of (mis)behavior but it is not always easy to classify the type of behavior being observed in a given instance. 2. Consider the case where only a few nodes could grant access to a sensitive resource and they had insucient information to grant access to a client node. It would take too long for that client node to build a reputation strong enough to gain access to the resource. 3. Reputation based systems are very slow to react. It takes a long time to build or diminish a reputation and consequently it takes too long to respond to a threat. A node with good reputation and elevated access rights may launch a serious attack and it would go undetected until it is too late. In a real world scenario, this is referred to as an inside job, such as a security guard on a night shift robbing a bank.

3.2.3

Role Based Trust Management

This approach assigns roles to entities [39, 40]. So for instance, in a commercial organization, some nodes might belong to the role manager, some might belong to clerical sta, and some to executive. All nodes belonging to a given role have the same privileges. All executives might have complete access to a le server while all clerks might have read only access. The kinds of access rights granted to a given role are xed beforehand. However, roles may be dynamically assigned to individual nodes, so for instance an external auditor might temporarily be assigned a manager role for a xed period of time.

48

Advantages 1. The rights granted to a node are directly related to the job they need to perform in the network. This again follows the real world example where employees have access rights based on their job title. 2. There is no need to issue and maintain dierent passwords for each node at a central server. Each node can validate itself to any other node simply by presenting to it its signed credential that assigns to it a given role. 3. Temporary role assignments are easy to implement since each credential carries a time of expiry for the role. Visitors can therefore be granted access for a preset amount of time. 4. Because only a few entities have the authority to assign roles, the evidence needed to trust an entity with a given role can be standardized. It is no longer as subjective as the reputation based case.

Disadvantages 1. This approach treats all entities within a role equally. Common observation tells us that not all managers can be equally trusted, for example. Some are most trustworthy then others based on their past experience and duration of employment with the rm. It would not be practical to assign such ne-tuned roles as managers with 10 years experience, managers with 5 years experience, etc. because then each role would contain very few entities, perhaps even just one entity. 2. This model also suers from a slow response time, although not as slow as the reputation based system. This is because if a privileged node behaves maliciously, there is no way 49

of stopping it except to demote its role. Only a few nodes have the authority to promote or demote another nodes role. These authoritative nodes need to be sent the evidence against a node, which would then be processed by them and a role revocation credential against the node would be broadcast to the entire network. This would make the response time against the malicious behavior unacceptable since by then the damage would already be done.

3.3

Trust Management Models for MANETs

The specic TM model used for a MANET depends on the MANETs architecture. Since monitoring based TM has been shown to be ineective in detecting malicious behavior accurately due to many false positives [86], we decided not to pursue this approach in our research and instead focus on Reputation and Role Based Systems. The gure below summarizes when it makes sense to use a TM system based only on Roles, or only on Reputation, or a combination of both. Architecture Hierarchical, SAD Hierarchical, MAD Flat, Open Flat, Closed Role Only Reputation Only Hyrbid (Role + Reputation)

Figure 3.1. Which architecture should be paired with which TM system A hierarchical MANET is, by denition, a closed MANET where each node is assigned one or more roles by a Trust Authority (TA). It could be administered by a single administrator (SAD), or multiple administrators (MAD) [84]. Since roles are preassigned, we cannot opt for a reputation only based TM. On the other hand, a at network, by denition, has no roles and 50

no administrators. It can be open, such as on the Internet or an airport, or closed [84]. Since it cannot have roles, we can only use reputation based TM. Using Reputation or Role based TM in MANETs presents a new set of challenges. This has to do with factors such as there is no online central authority, many nodes are limited in their computational resources, nodes may go oine at any time necessitating redundancy, and nodes are not guaranteed to be completely trustworthy [8]. In the next chapter we propose a new Reputation System based on Machine Learning that is suitable for MANETs. We will then combine this Reputation System with a Role based system to develop a hybrid Trust Management model that can eectively defend against insider attacks.

51

Chapter 4:

A Basic Machine Learning Based Reputation System

4.1

Introduction

In this chapter we will be focusing on developing a Machine Learning based Reputation System (RS) for closed networks. Earlier we presented a technique, called HEAP, for guarding against outsider nodes. We are now directing our attention on the more challenging problem of securing the network against attacks from insider nodes that have been compromised. Such compromises may occur by an adversary hacking into and gaining access to a legitimate node, or by obtaining the secret key of a legitimate node so that it can assume its identity, or in some other way being able to convince the network to accept its node as being legitimate. Unfortunately, there is no litmus test to enable one to verify whether an insider node is malicious or benign. We can only guess the intentions of a node by observing its behavior and trying to discriminate legitimate behavior from malicious behavior. Many researchers have utilized this approach in the context of P2P networks, large scale distributed networks, and on the Internet by utilizing Reputation Systems [59, 60, 61, 75, 88, 90, 103]. Others have used Reputation Systems for securing MANETs and their routing protocols [87, 88, 96, 97, 98], and in sensor networks [4, 93]. Reputation systems have been proposed that try to predict the future behavior of a node by analyzing its past behavior. The basic idea is that the past behavior of a node (such as the number of good vs. bad transactions) is stored in the network in a distributed 52

fashion. Each node that interacts with another node stores some feedback about the interaction. The interaction is either classied as legitimate or suspicious (or some value in between). If, for instance, the interaction consisted of downloading a le, the client could determine if the downloaded le was indeed the one requested, or it was a Trojan, a virus, or spam. Based on the feedback of various nodes, a new node can decide whether to transact with a given node or not, even though they may never have interacted before. For example, eBay utilizes this form of reputation system where users leave feedback about other users [72], and Google uses PageRank where web pages are ranked for relevance by other pages [73]. In general, we can summarize existing RSs [59, 60, 61, 74, 76, 78] within the general framework shown in Fig. 4.1. According to this framework, a node that needs to decide whether to transact with another node or not must rst gather historical data about that node (e.g., the proportion of good vs. bad transactions in the last x minutes). Then it applies a customized mathematical equation or statistical model to the data to produce an output score. For example, the RS in [61] is based on using Eigen values from Linear Algebra , the one in [60] is based on using derivatives and integrals, whereas the one in [76] is based on Bayesian systems utilizing the Beta distribution. Depending on the output of the equation or model, the system then decides how to respond. In most cases, the equation or model is customized to detect specic types of malicious behavior only. For instance, the algorithm in [60] is designed to detect malicious behavior that alternates with good behavior and varies over time.

53

Figure 4.1. General framework of a Reputation System that decides whether to transact with a given node or not.

In contrast to developing a separate module for each attack pattern, we employ Machine Learning, specically Support Vector Machines (SVM), to build a exible and dynamic RS that can be trained to thwart a multitude of attack patterns easily and eciently. It can also be retrained to detect new, previously unknown attack patterns. The rest of this chapter is organized as follows. In Section 4.2, we dene the RS problem in more detail and justify why Support Vector Machine (SVM) is a suitable candidate for solving it. In Section 4.3, we describe the three principle challenges associated with designing any RS and explain how our core SVM based RS tries to solve them. In Section 4.4, we discuss the factors associated with building the SVM based classier. Then, in Section 4.5, we evaluate our core RS and compare it against another RS mentioned in the literature, called TrustGuard. Finally, in Section 4.6 we present our conclusions.

4.2

Basic Machine Learning Approach

Using Fig. 4.1, we can redene the problem of designing Reputation Systems (RS) into one of nding the optimal set of input features and equations (steps 1 and 2 in Fig. 4.1) that allow us to distinguish between malicious and benign nodes with high accuracy. Machine Learning (ML) 54

is of particular signicance in this context since many ML algorithms are able to determine and approximate the optimal equation needed to classify a given set of data. We envision the problem of RS as a time series prediction problem, which states: Given the values of the dependent variable at times (t, t 1, t 2, ..., t n), predict the value of the variable at time (t + 1) [81, 82]. The dependent variable in this case is the proportion of good transactions conducted by a node in a given time slot. Predicting this variable at time (t + 1) gives us the probability that the node will behave well if we choose to transact with it at time (t + 1). Therefore, we opted to use Support Vector Machines (SVM) as our ML algorithm because it has been shown to successfully approximate mathematical functions [62] and make time series predictions [70]. In our scheme, we build SVM models against dierent types of malicious behaviors oine, and then upload those models to the nodes in the network. The nodes can use those models to classify new nodes and predict if a new node is malicious or not. Constructing models is computationally expensive so it is done oine, possibly by a third party. However, the classication step is not very expensive and can be done on the node in real time. When a new type of attack is discovered, a new model can be constructed against it. This is similar to how anti-virus systems work where the anti-virus is developed oine and then uploaded to clients. Similarly, in our scheme the vendor of the RS might update its subscribers with SVM models against new attacks. An implied assumption is that after a transaction has taken place, a node can determine if the transaction was good or bad with a certain high probability. This is true in many cases, such as in commercial transactions on eBay, as well as in le downloads (where a corrupted or virus infected le would be considered bad), or in providing network services [62, 70]. Another 55

assumption is that the feedbacks can be reliably transmitted without being tampered with. This can be accomplished by a node digitally signing every feedback it sends. These assumptions are made by many researchers in the eld [59, 60, 61] and we also make the same assumptions in our study. However, a few transactions might be incorrectly labeled good or bad. SVM can handle fair amounts of such noise in the dataset [62].

4.3

Building the Core SVM based Reputation System

If all the nodes in a network gave honest and correct feedbacks about the transactions they conducted, then it would be trivial to spot malicious nodes since all the good nodes would have 100% positive feedbacks, whereas the malicious nodes would not. But in reality, this is not the case and we have to deal with three principle challenges: 1. Dishonest feedback given by malicious nodes against other nodes they have transacted with. 2. Incorrect feedback from legitimate nodes by mistake. 3. Fake feedback given by malicious nodes about transactions that never really occurred. Our goal is to use SVM to tackle problems 1 and 2. However, SVM cannot detect if a feedback was fake, so we propose another mechanism in Section 4.4.7 to deal with 3. We assume that the proportion of dishonest to honest feedbacks given by malicious nodes is much higher than the proportion of incorrect to correct feedbacks given by legitimate nodes. This is how we can distinguish between inadvertent and deliberately false feedbacks. If malicious

56

nodes reduce the proportion of dishonest feedbacks to match those of incorrect feedbacks, we have still succeeded in our goal of reducing malicious behavior. Several factors govern the construction of ML classiers and the next section discusses some of them.

4.4

Factors in Building the Classier

There are many factors to consider in building the classier that will be used to distinguish malicious nodes from good nodes. The following factors should be taken into account: 1. Feature Selection: The features used to train and test the classier. Must be the same in the train as well as the test set. 2. Proportion of Malicious Nodes: The proportion of good vs. bad nodes in the dataset. This relates to the degree of imbalance in the dataset. It need not be the same in the train and test sets. 3. Size of Dataset: The number of instances in the train and test sets. 4. Evaluation Methodology: The method used to evaluate the performance of the classier, such as train/test split, n-fold cross validation, leave one out, etc. 5. Evaluation Metrics: The metrics used to evaluate the classier, such as accuracy, precision (specicity), recall (sensitivity), etc. 6. Kernel Used: For SVM, which kernel should be used. The last factor is only valid for Kernel Machines, such as SVM, while the other factors are valid for all types of ML classiers. 57

4.4.1

Feature Selection

Feature selection is a critical step in constructing the classier. You cannot make good wine from bad grapes and you cannot make a good classier from bad features. Using too few features might not provide sucient information to the classier, while using too many might result in the Curse of Dimensionality. It is common knowledge in ML that increasing the number of features increases the accuracy up to a certain point. Thereafter, increasing the number of features results in a degradation in performance. This phenomenon is called the Curse of Dimensionality [62]. To construct our features, we divided time into regular intervals called time slots. The network administrator can choose and x a time slot that is a few minutes to a few hours long, depending on how frequently nodes in the network transact on average. The features in our experiments consist of the proportion of positive vs. negative feedbacks assigned to a node during a given time slot by the nodes it has transacted with. To collect features for a test node, we need to query all the nodes in the network and ask them to provide us any feedbacks they have about the node for a given slot. The fraction of positive feedbacks versus total feedbacks for that slot forms a single feature. Each time slot then corresponds to one feature. This is in accordance with [60], and is also based on features used in time series prediction problems [70]. We can vary the number of features by varying the number of time slots used. We use 15 time slots for our core SVM. In the next chapter, we present an algorithm that will enable us to look further back in time using only a few features.

58

4.4.2

Proportion of Malicious Nodes

In a real world setting, we would not know the true proportion of malicious nodes vs. good nodes in the network. The ratio, or degree of imbalance, could vary from zero to very large. As a result, in our experiments we use multiple test sets with dierent ratios and graph the performance with respect to it. We would expect the accuracy to deteriorate as the ratio of imbalance becomes larger. Next, we need to consider the imbalance ratio for the training set. In an actual setting, we would not know the proportion of malicious nodes in the network, so the testing should be done with varying imbalance ratios. However, the training set can only have one imbalance ratio since we need to build just one SVM model. We use a malicious node proportion of about 60% since that gave us the best results

4.4.3

Size of Dataset

If the training dataset is too small, the classier will not have enough instances to properly train itself and the accuracy will suer due to overtting. A small test dataset can lead to wide variations between the test error and the true error. However, using very large datasets increases computational costs without necessarily increasing performance. Based on our past experience we decided to use 1,000 instances for the training set and another 1,000 instances for the test set, achieving a good trade-o between computational cost and accuracy.

59

4.4.4

Evaluation Methodology

Several traditional ways of evaluating the classier exist in Machine Learning. In one common approach, two independent sets of data are used, one for training the classier and another one for testing it. We also use two independently constructed datasets in our experiments. Other common techniques for testing include n-fold cross validation and leave-one-out, where a randomly chosen portion of the data is used for training and the remainder of the date is used for testing. This procedure is repeated many times. These techniques usually provide a better estimate of the true error than using simple train and test sets. However, since the proportion of good vs. bad nodes needs to be varied in our test set while keeping the train set constant, cross validation is not the appropriate choice for our experiments.

4.4.5

Evaluation Metrics

Many ubiquitous evaluation metrics are used in ML to evaluate classiers. The most common metric is accuracy, which simply measures the fraction of correct predictions. Other common metrics include precision and recall (or sensitivity) [71]. Graphs such as ROC curves are based on these metrics. The metrics are dened below:

Accuracy =

N umber of Correct P redictions T otal N umber of P redictions

P recision =

T rue P ositives T rue P ositives + F alse P ositives

60

Recall =

T rue P ositives T rue P ositives + F alse N egatives

In our preliminary experiments, we have used accuracy as our evaluation metric as it is also used in [60]. In future, we will also use precision and recall to evaluate the classier.

4.4.6

Kernel Used

Unfortunately, there is no easy way to pre-compute which is the best kernel to use for a given dataset [63]. As a result, for most applications we have to use trial and error to evaluate commonly used kernels and determine the most appropriate one. Common kernels include polynomial kernels of varying degrees, exponential kernels, and Radial Basis Function (RBF) kernel. In our experiments, the linear kernel (polynomial kernel of degree 1) has shown good results and increasing the degree of the kernel has not signicantly increased performance. In general, it is desirable to use the lowest degree kernel that gives good results to save on computational costs. Exponential and RBF kernels have also been tried and they did not signicantly increase performance beyond the linear kernel either. In the next section, we describe how to solve problem 3, guarding against fake feedbacks.

4.4.7

Guarding Against Fake Feedbacks

Fake feedbacks are feedbacks about transactions that never actually occurred. So, for instance, node x may provide some feedback (either good or bad) about another node y, when in reality

61

y never transacted with x. A malicious node may try to provide several bad feedbacks about another node in order to reduce its reputation. To guard against this, TrustGuard [60] proposed a mechanism for binding transactions to transaction proofs, such that (i) a proof cannot be forged and (ii) is always exchanged atomically. These proofs ensure that every feedback is tied to a transaction that actually took place. TrustGuard ensures atomicity by using trusted third parties that must become online frequently to resolve disputes. In our work, we also propose to use transaction proofs that cannot be forged, but we relax the restriction of atomicity. This is because we would like to eliminate the need for a trusted third party that must be frequently online. This in itself provides a window of opportunity to adversaries when the third party becomes oine, as pointed out in [60] itself. In our implementation, each node has a pair of public and private keys. A client contacts a server and requests service. The server responds and it either denies the request or commits to providing the service. If it commits, the server will send the client a certicate to sign. The certicate has the following elds: Server ID, Client ID, T ime Slot ID, T ransaction N umber Cert. (1)

The server and client IDs are self-explanatory (e.g. IP addresses of each). The Time Slot ID is the time stamp of when the current time slot began. If, for instance, a time slot is 30 minutes long, the client should check that the time slot ID should be no more than 30 minutes prior to the current time. All the nodes in the network must be aware of how long the time slots are and when a new time slot starts. The Transaction Number is the number of transactions that have occurred (including the current one) between the client and the server in the current time slot. All of these elds are veried by the client and then signed. Note that 62

each node only needs to keep track of the transactions that it has conducted within the current time slot. A node will never need to sign a certicate for a previous time slot. After verication, the client sends the signed certicate back to the server. The server veries the signature and then signs the same certicate with its own private key and sends it to the client. Then it provides the requested service. In this way, both the client and the server end up with copies of the certicate signed by each other. In future, if a node z, asks either of them to provide feedback about the other, it will provide the feedback and present the signed certicate. In this way, z can verify the number of transactions that actually occurred between the two nodes in the given time slot, and the number of feedbacks expected for that time slot. We realize that because of the lack of exchange atomicity, after receiving the signed certicate from the client a malicious server might refuse to provide the client with a certicate signed by it. In that case, the server will get only one opportunity to give bad feedback about the client. In addition, the client will know that the server is malicious and not transact with it in future. If the server continues to do this with other nodes, several nodes will quickly realize that the server is malicious. Furthermore, since no transactions were actually completed with those nodes, the server would not achieve its goals of conducting many malicious transactions. On the other hand, if the server were to go ahead and complete the transaction, the client would not know for sure that the server is malicious and might transact with it in future again. This will give the server more than one opportunity to give bad feedbacks about the client and conduct many malicious transactions. Therefore, we argue that it is in the malicious servers interest to complete a transaction, so we do not need to enforce exchange atomicity and employ trusted third parties that must remain online frequently.

63

4.5

Evaluations of the Core SVM based Reputation System

4.5.1

Simulation Setup

We generated the datasets using simulations of a network consisting of 1,000 nodes. Time was divided into slots and in each time slot, several transactions were conducted between two randomly chosen pairs of nodes. Each node would then label the transaction as good or bad and store that label. The label may or may not reect the true observation of a node, i.e. a node may lie about a transaction and give dishonest feedback (problem 1). Good Behavior: Good behavior is characterized as a node conducting a normal transaction and giving honest feedback about it. Bad Behavior: Bad behavior is characterized as a node conducting a malicious transaction and/or giving dishonest feedback. In addition, we introduced a random error of 5% to account for the fact that a node may incorrectly detect a transaction and mistakenly label it good or bad. This corresponds to problem 2 described above. The simulation was allowed to run for several time slots and then data about each node was gathered. To gather data about a node x, all the other nodes in the network were queried and asked to give information about x going back a certain number of time slots. The total number of good and bad transactions conducted by x in a given time slot were accumulated and the proportion of positive feedback was computed. This computation was repeated for each time slot of interest. In this way a concise, aggregate historical record of x was obtained. The

64

correct label of malicious or benign was assigned to x by us, based on its role in the simulation, for testing purposes only. The following attack scenarios were tested.

4.5.2

Attack Scenarios

In each attack scenario all the good nodes behave well consistently throughout the simulation, however the behavior of malicious nodes varies with the attack type as described below. Attack 1: This is the simplest attack scenario in which all the malicious nodes consistently behave maliciously. These nodes do not collude amongst each other. Attack 2: In this scenario, the behavior of malicious nodes oscillates between good and bad at regular intervals. The aim of the malicious node is to boost its reputation by being good rst, and then use its high reputation to conduct malicious transactions. As a result, its reputation would decrease again, so it will oscillate into good behavior once again to boost its reputation. Again there is no collusion between the nodes. Attack 3: This attack is similar to attack 2, except that now the malicious nodes collude with each other. Every time they happen to transact with each other, they recognize each other and leave positive feedback to boost each others scores. The nodes might recognize each other, for instance, if they belong to the same owner or colluding groups of owners. Attack 4: This attack is more severe than attack 3 because this time whenever malicious nodes recognize each other, not only do they leave positive feedback about each other, but they also conduct further transactions with each other to leave even more positive feedback. But of course, there is a limit to the number of fake transactions they can conduct without being caught as obviously fake. In our simulations we conduct a random number of fake transactions, up to a maximum of ten, within one time slot. 65

Attack 5: In this attack scenario we combined all four types of malicious nodes described above. A quarter of all the malicious nodes behave as in attack 1, another quarter behave as in attack 2 and so on. In a real world setting we would not know which, if any, attack was being launched by any given node, so the performance of the RS in this attack scenario would tell us what would happen if all the attacks were conducted simultaneously.

4.5.3

Experiments and Results

We evaluated our core SVM based RS against two other algorithms, TrustGuard Nave and TrustGuard TVM (Trust Value based credibility Measure) [60]. Each of the ve attack scenarios described above were tested. We set the same parameters for TrustGuard that their authors used in their paper. TrustGuards authors have shown that it performs very well compared to eBays reputation system, which is commonly used as a benchmark in the literature for RSs. Therefore, we decided to directly compare our performance with TrustGuard, instead of eBay. We collected data going back 15 time slots for each simulation run. For oscillating behavior, the period of oscillations was kept less than 15 to ensure it was distinguishable from legitimate behavior. In the next chapter, we propose a system to overcome this limitation by looking at many more timeslots and compressing their data into a few features using Fading Memories. For SVM, a separate set of training data was also generated and SVM was trained on it using the Weka Machine Learning software [64]. The training data had a xed proportion of malicious nodes (about 60%). For each node, its transaction history for the last 15 slots was fed into each RS. Then using the output of the RS, a determination was made about whether the node was malicious or benign. For SVM this was done by looking at the distance between the test node and the decision boundary. If this distance was greater than a threshold, the 66

node was considered benign. Larger thresholds result in fewer false positives, but also fewer true positives. This might be desirable in critical applications where we want to be sure that a node that is given access to a resource is indeed good, even if that means denying access to some legitimate nodes. We discuss thresholds in greater detail in the next chapter, when we introduce Dynamic Thresholds. TrustGuard also outputs a score that can also be compared against a threshold and access can be granted if the score is greater than the xed threshold. Classication Error: In the rst set of experiments, the thresholds were xed at their midpoint values so that the results were not articially biased either towards increasing true positives (lower thresholds) or decreasing false positives (higher thresholds) but were halfway. Since the range of thresholds for SVM is (, ), its threshold was set to 0. The range for TrustGuard is [0, 1], so its threshold was set to 0.5. Then the percentage of malicious nodes in the network was varied. The proportion of nodes that were misclassied, or the classication error, was measured. The results for each attack type are illustrated in Figs. 4.2 - 4.6. The results show that SVM signicantly outperforms TrustGuards Nave and TVM algorithms for all attack types, even if the proportion of malicious nodes is very large (i.e. 80%). The dierence is especially stark in attacks 2 to 5, when the attackers behavior oscillates between good and bad. It is also interesting to note that, with the exception of attack 1, there is not much dierence between TrustGuards TVM and Nave algorithms, even though TVM is much more complex.

67

Figure 4.2. Classication Error vs. Proportion of malicious nodes for Attack 1.

Figure 4.3. Classication Error vs. Proportion of malicious nodes for Attack 2.

68

Figure 4.4. Classication Error vs. Proportion of malicious nodes for Attack 3.

Figure 4.5. Classication Error vs. Proportion of malicious nodes for Attack 4.

69

Figure 4.6. Classication Error vs. Proportion of malicious nodes for Attack 5.

ROC Curves: We generated ROC curves for all three RSs. ROC curves are commonly used in Machine Learning to evaluate classiers, irrespective of the thresholds used. The curve is obtained by varying the threshold, so that we can compare how the true positive rate varies with the false positive rate. The area under the ROC curve shows how good a classier is. Classiers with larger areas under the curve are better. The ideal ROC curve is an upside down L-shaped curve, containing the point (0, 1) that corresponds to 100% true positive rate and 0% false positive rate. Each point on the curve was obtained by running 30 simulations with dierent random number seeds, and then taking their mean. Condence Intervals were taken around each point to ensure that the curve of SVM did not overlap with that of TrustGuard (the condence intervals are too small to be visible on the graphs). The results are shown in Figs. 4.7 - 4.11,

70

along with the diagonal random Guessing line. The results show that SVM outperforms TrustGuard, regardless of the thresholds used. The area under the curve is greater for SVM than TrustGuard in all cases.

Figure 4.7. ROC Curves for Attack 1.

71

Figure 4.8. ROC Curves for Attack 2.

Figure 4.9. ROC Curves for Attack 3.

72

Figure 4.10. ROC Curves for Attack 4.

Figure 4.11. ROC Curves for Attack 5.

73

Bandwidth Overhead: Next we measured the bandwidth overhead involved in using SVM vs. TrustGuard. This overhead is due to passing feedbacks betweens the nodes. The overhead is consistent, regardless of the attack scenario, or proportion of malicious nodes, or thresholds used since the number of nodes transacted with in each time slot, and hence the number of feedback messages, will be the same for all cases. This overhead is illustrated in Fig. 4.12.

Figure 4.12. Bandwidth Overhead for each of the three algorithms.

The overhead shown corresponds to the average number of messages (or feedbacks) exchanged to classify one node. The results show that the overhead is the same for SVM and TrustGuard Nave (around 30), whereas the overhead for TrustGuard TVM is much higher (around 960), since TVM traverses one more level to obtain further feedbacks about nodes that gave the original feedbacks.

74

4.6

Conclusions

In this chapter, we proposed a Machine Learning based Reputation System (RS) that can be used to guard against malicious nodes in mission critical networks. The nodes can try to attack the network by conducting malicious transactions, or spreading viruses and worms, or attacking known vulnerabilities. Although there is no way of knowing whether a future transaction will be malicious or not, we try to predict the future behavior of a node by observing its past behavior. We discussed why using Machine Learning (ML), and especially Support Vector Machines (SVM), is a good approach for designing RSs. We explained that the Reputation System problem can be viewed as a time series prediction problem and SVM has been shown to be well suited to time series prediction problems [70] and for approximating unknown functions [62]. We then proposed our SVM based RS and specied what features we used, the kernel and other parameters used. We illustrated the three problems that any Reputation System must solve and SVM tries to solve two of them; dishonest feedback and incorrect feedback. To solve the third problem, we proposed a Digital Signature based scheme for guarding against fake transactions that does not need online trusted third parties. We developed and evaluated our core SVM based RS using simulations. Its performance was compared against two other algorithms found in the literature called TrustGuard Nave and TrustGuard TVM [60]. We chose TrustGuard because it has been shown by its authors to perform very well compared to eBays reputation system. We simulated 5 dierent attack scenarios and showed that our model outperforms TrustGuard in all 5 scenarios, whether there is oscillating or steady behavior, collusive or non collusive behavior. Our scheme can achieve high accuracy and correctly predict good vs.

75

malicious nodes, even when the proportion of malicious nodes in the network is very high. The ROC curves show that the improvement of SVM over TrustGuard is statistically signicant, as their condence intervals do not overlap each other. We also showed that SVM has the same bandwidth overhead as TrustGuard Nave, but much better overhead than TrustGuard TVM. In the next chapter, we propose enhancements to the basic RS design that will allow us to look back at longer histories using only a few features. This enhancements forces the adversary to behave well for longer periods of time in order to boost its reputation score. In addition, we introduce an algorithm called Dynamic Thresholds that further improves the accuracy of SVM by dynamically shifting the SVM decision boundary based on the proportion of malicious nodes in the network.

76

Chapter 5: EMLTrust: An Enhanced Machine Learning Based Reputation System

This chapter describes two enhancements that we propose to our core SVM classier. The rst enhancement, SVM with Fading Memories and Digital Signatures (Section 5.1), allows us to look back at longer histories using only a few features. The second enhancement, Dynamic Thresholds (Section 5.2), allows us to better estimate where to place the SVM boundary in order to improve classication accuracy. Finally, Section 5.3 describes conclusions and future work.

5.1

Enhancing SVM with Fading Memories (SVM-FM)

As described in Section 4.4.1, each feature used in our SVM classier corresponds to one time slot. This means that for n features, we can only look back at the behavior of a node going back n time slots. From an adversarys point of view, the adversary only needs to behave well for n time slots since any behavior before that will be forgotten and it can have a fresh start. We would like our security system to be able to look back far into the past so that it is not easy for an adversary to behave well for a short period of time and then wipe its slate clean. However, we cannot make n, the number of SVM features, arbitrarily large for several reasons: Using too many features may result in the well known Machine Learning problem of the Curse of Dimensionality which causes accuracy to decrease as n increases beyond a certain threshold [62]. 77

 Storage requirements increase as n increases because the nodes have to store n features. Computational requirements increase as the SVM models become more complex. It takes longer to build new SVM models as well as to classify new nodes [62]. Ideally, we would like to use fewer features while retaining the ability to look back further into the past. In other words, a feature should be able to summarize the data for several time slots into one value. To accomplish this goal, we build on the concepts presented in the Fading Memories algorithm of TrustGuard [60] and enhance them for use with SVM and digital signatures.

78

Figure 5.1. (Adapted from [60]) Updating Fading Memories: F T V [i] denotes the faded values at time t and F T V [i] denotes the faded values at time t + 1.

The basic idea in Fading Memories (as explained in [60]) is that data is aggregated over intervals of exponentially increasing length in the past {k 0 , k 1 , ..., k m1 } into m values (for some integer k > 0) (Fig. 5.1). For more recent data, the interval size is smaller so fewer time slots are aggregated together resulting in greater precision. For older data, larger intervals are used so more time slots are aggregated together resulting in lower precision but greater compression. This enables us to retain more detailed information about the recent past, while storing less detailed information for older data. The value of k can be chosen so as to allow a tradeo between compression and precision. We chose a value of 2 for simplicity.
t+1 More specically, for a given node x during time slot (t+1), feature Fx [0] is initialized

to pt , the proportion of positive feedbacks given to x during the previous time slot t (Eq. (1)). x The remaining features are computed using Eq. (2). In TrustGuard all the features are updated after each time slot. 79

t+1 Fx [0] = pt x

Eq. 1 Eq. 2

t+1 Fx [j]

t t (Fx [j](2j 1)+Fx [j1]) = for j > 0 2j

The advantage of Fading Memories (FM) is that it allows us to look back further in time to evaluate a given nodes behavior. Without FM, an adversary would only need to behave well for a short period of time before its history is erased and then it can start behaving maliciously again. It can oscillate its behavior between good and bad indenitely, as long as its period of good behavior is greater than the history we are looking at. Fading Memories is an attempt to elongate the history size so as to force the adversary into choosing longer periods of good behavior. We were interested in nding out if Fading Memories would work with SVM, so we compared the performance of SVM with Fading Memories (SVM-FM) versus without Fading Memories.

5.1.1

Evaluating SVM with Fading Memories (SVM-FM)

Small Fixed Periods Fading Memories (FM) aggregates data in several time slots resulting in lower precision as compared to one feature representing one time slot. As a result, we would expect the performance of SVM with FM to be worse than SVM without FM when dealing with small oscillation periods. We conducted experiments in order to test this. We generated datasets using simulations of Attack 5 in a network of 1,000 nodes, similar to those described in the previous chapter. Once again, all the good nodes behave well consistently, while malicious nodes that oscillate their behavior have xed periods of size n, where n was chosen to be 8. They behave well for 4 time 80

slots, then maliciously for 4 time slots. The number of features used in both, SVM-FM and SVM without FM is also n.

Figure 5.2. Classication Error vs. Percentage of Malicious Nodes for small, xed periods of oscillation for SVM with FM and SVM without FM.

As described in Section 4.4, in SVM without FM each feature corresponds to one time slot, whereas in SVM-FM each feature was computed using equation (2) at each new time slot as the simulation progressed. At the end of the simulation the features were collected and used in building and testing SVM models. The training and testing datasets were distinct and were generated using dierent random number seeds. The percentage of malicious nodes in the training dataset was xed at 50%. In the testing datasets the percentage was varied and the classication error was plotted against it. The results are summarized in Fig. 5.2. They show that the change in error with FM is insignicant compared to that without FM. The dierence between them is not statistically signicant so Fading Memories is a viable option for use with SVM even when the period of oscillation is small. 81

Long Variable Periods The real benet of SVM with FM is apparent when we vary the period of oscillation. To illustrate this, another set of experiments were conducted where the datasets were generated as before, but the period of oscillation for each malicious node was randomly selected up to a maximum of 250 time slots for good behavior and 250 time slots for bad behavior. Given 8 features and k = 2, with FM we can look back at 28 1 = 255 time slots, whereas we can only look back at the last 8 time slots without FM. As a result we would expect a signicant improvement in classication error with FM. We tested this through simulations and the results are plotted for each of the ve attack patterns in Figs. 5.3 - 5.7. The results clearly show the advantage of using SVM-FM when the periods of oscillation are long. The error with SVM-FM is much lower than the error without FM, especially at smaller percentages of malicious nodes. In attack 1, there are no oscillations and the nodes have consistent behavior. By reducing the error for longer periods, we can successfully force the adversary to behave well for longer periods of time. In general, the error keeps rising as the percentage of malicious nodes increases until at some point, almost all the good nodes are being classied as bad. This happens when malicious nodes overwhelm the network and leave too many negative feedbacks. SVM concludes that almost every node is malicious, which happens at around 70%. After 70%, virtually all the nodes are classied as bad. The error then becomes proportional to the percentage of good nodes in the network. As the percentage of good nodes decreases, so does the error, which explains the dip in error. We combat this phenomenon using Dynamic Thresholds as discussed in Section 5.2.

82

Figure 5.3. Classication Error vs. Percentage of Malicious Nodes for large, variable periods of oscillation for SVM with FM (FM error) and SVM without FM (Orig Error). Attack 1 has no oscillations.

Figure 5.4. Classication Error vs. Percentage of Malicious Nodes for large, variable periods of oscillation in attack 2.

83

Figure 5.5. Classication Error vs. Percentage of Malicious Nodes for large, variable periods of oscillation in attack 3.

Figure 5.6. Classication Error vs. Percentage of Malicious Nodes for large, variable periods of oscillation in attack 4.

84

Figure 5.7. Classication Error vs. Percentage of Malicious Nodes for large, variable periods of oscillation in attack 5.

5.1.2

Fading Memories Enhanced with Digital Signatures

In Section 5.1, we showed that by using Fading Memories we can successfully compress the data in several time slots into a few features that SVM can use. This helps us in using longer histories without needing extra storage to store those histories. However, we run into a problem when we try to use Fading Memories along with the Digital Signature scheme presented in Section 4.4.7. The digital signature scheme is needed to protect against fake feedbacks, so that one can verify that a given feedback pertains to a transaction that actually took place. As mentioned in Section 4.4.7, at the beginning of every transaction the client and the server exchange digital certicates. The certicate elds are: Server ID, Client ID, T ime Slot ID, T ransaction N umber 85 Cert. (1)

Transaction number tells us how many transactions took place in the given time slot. If a new transaction occurs in the same time slot, the transaction number is incremented by one. This in turn corresponds to the number of feedbacks that one of the nodes, lets say the client, can legitimately give about the other node (the server) for that time slot. But when we start aggregating the data in dierent time slots in Fading Memories, we run into the problem of trying to aggregate two or more digital certicates into one. As the client moves into a new time slot t + 1, it must aggregate the data in time slot t with the data in time slot t 1, and continue aggregating the data in time slots further back (Fig. 5.1). However, it is unable to combine the digital certicate for t with the certicate for t 1 to get a single certicate because the new certicate would not have a valid signature by the server. As a result, it would be forced to store the certicates for each time slot individually, defeating the purpose of using Fading Memories. To circumvent this problem, we propose a new protocol for the digital signature scheme. Suppose n features are being used by SVM and the system is currently in time slot t. The client and the server will transact for the rst time and exchange certicates similar to Cert. (1). If they transact again within the same time slot, they will update this certicate by incrementing the number of transactions and re-signing it. Now lets assume that at some point in the future, t + x, the client again transacts with the server. This time, the client and the server both update their certicates by moving along the time line and using the update step of Fading Memories (Eq. 2). This will allow them to aggregate all the previous time slots according to the Fading Memories formula and then insert the current time slot as a new feature. Since both the client and the server use the same formula, both will end up with the same results about the aggregated number of transactions in previous time slots. Then each will present this new 86

certicate for the other to sign. This new certicate will have the following elds: Server ID, Client ID, T ime Slot ID, N1 , N2 , ..., Nn Cert. (2)

Where Ni is the aggregate number of transactions that took place for feature slot i (not time slot), beginning at T ime Slot ID. Although this increases the size of each certicate by n 1 more elds, note that only one certicate now needs to be stored by the client for all the transactions it has conducted with the server. In the original scheme, it stored one certicate per time slot, so we have considerable savings in storage space with this new scheme. The certicate is updated whenever a new transaction occurs with the server, so the certicate can tell us the number of transactions in each previous feature slot. Of course, this certicate may be requested at any point in the future after the given time slot has expired. In that case, the receiving node will start at Time Slot ID and update the number of transactions and their feedback data till the present time slot using the update step of Fading Memories (Eq. 2). Using this new protocol, we can use digital signatures to detect fake feedbacks while still using Fading Memories to look at longer histories without increasing storage requirements.

5.2

Introducing Dynamic Thresholds with SVM

Figs. 5.8 - 5.10 show SVM with Fading Memories compared to TrustGuard Nave and TVM with Fading Memories for some of the attack patterns. In addition, for attacks 3 and 5, another biased SVM curve was also plotted. The general equation of a linear SVM is [62]: w.x + b 0 w.x + b < 0 for positive class for negative class 87

Where x is the instance vector, w is the normal to the SVM hyperplane, and b is a bias threshold. We noticed that in Figs. 5.9 - 5.10, the reason why the default SVM model performed poorly when the malicious nodes percentage was high in attacks 3 and 5 was because it was misclassifying the positive (non-malicious) instances. Therefore, we increased the threshold, b, slightly so that those instances close to the SVM boundary are classied as positive. In other words, by increasing b we eectively trade false negatives with false positives. The results are shown in the second, biased SVM curve in Figs. 5.9 - 5.10 (attacks 3 and 5). As expected, the bias pays o at higher proportions of malicious nodes when there are more false negatives than false positives. However, it costs us when the proportion of malicious nodes is small since there are more false positives than false negatives. This increases the error for small proportions. This observation led us to the idea that if we could know the proportion of malicious nodes in the network, we could adjust the bias threshold accordingly to optimize accuracy. The threshold would be decreased for fewer malicious nodes, and increased for more malicious nodes. We propose a scheme called Dynamic Thresholds that utilizes this idea. To begin with, we discovered what the ideal thresholds were for given proportions of malicious nodes using brute force trial and error. The ideal threshold is dened as that threshold which maximizes accuracy. We expect the threshold curve to be specic for a given SVM model, and each model would have its own associated curve. For our tests, we used the model that was trained using attack 5 since it combines all the other four attack patterns. The ideal thresholds curve is given in Fig. 5.11.

88

Figure 5.8. Classication Error vs. Malicious Nodes percentage for dierent algorithms with FM in attack 2.

Figure 5.9. Classication Error vs. Malicious Nodes percentage for dierent algorithms with FM in attack 3.

89

Figure 5.10. Classication Error vs. Malicious Nodes percentage for dierent algorithms with FM in attack 5.

In our SVM simulation, all the w.x values are normalized between the range (-1, 1). The threshold value, b, is with reference to this range. Fig.5.12 shows the reduction in error achieved using the optimum thresholds versus the default threshold of zero. The results clearly show that dynamic thresholds can be very useful for signicantly reducing the error. However, the challenge is that in a real world setting, we do not know the proportion of malicious nodes in the network and therefore, we cannot decide what threshold to use. To overcome this, we propose estimating the proportion of malicious nodes through sampling.

90

Figure 5.11. SVMs best threshold vs. Malicious Nodes percentage for attack 5.

Figure 5.12. SVM error under the default threshold and under the best thresholds.

The idea is that a new node that joins the network would initially use the default threshold of zero. It would conduct transactions as usual and estimate the proportion of 91

malicious nodes from all the nodes it has interacted with. A node is considered malicious if either the Reputation System classies it as malicious, or if a transaction is conducted with the node and the transaction is deemed to be malicious. Once a large enough sample is collected by the node, it can use that sample to estimate the proportion of malicious nodes in the network and then dynamically adjust its threshold to improve the RSs accuracy. We conducted experiments to determine what a good sample size would be before adjusting the threshold. We ran simulations with dierent proportions of malicious nodes in the network. Then we randomly sampled the nodes and determined which of them were malicious. Based on the proportion of malicious nodes in our random sample, we estimated the actual proportion in the entire network. Next, we used the estimated proportion to decide which threshold to use. Finally, we obtained the RS error over all the nodes using that threshold. The sample size was varied and the error plotted against it. The results are plotted in Fig. 5.13. The results show that the error is erratic and unstable until a sample size of about 20. After 20 samples, a fairly good estimate of the actual proportion can be obtained. We therefore recommend that nodes should obtain a sample of at least 20 before adjusting their thresholds. Fig. 5.14 shows the reduction in error when Dynamic Thresholds are put into practice. Sample sizes of 20 and 25 are used. These samples are randomly collected and classied, based on a nodes interactions with other nodes, and used to estimate the proportion of malicious nodes in the network. The threshold is adjusted based on the estimated proportions. The results show a signicant reduction in error even at high proportions. Once the threshold has been adjusted, the sample is discarded and a fresh sample is started. In this way, the node can continuously monitor the proportion of malicious nodes and adjust its threshold as the proportion changes. 92

Figure 5.13. Dynamic Thresholds Error vs. Number of Samples taken for dierent proportions of malicious nodes in the network.

Figure 5.14. Dynamic Thresholds Error with 20 and 25 samples compared to the default error and the minimum possible error.

93

5.3

Conclusions and Future Work

In this chapter, we enhanced the core SVM based RS presented in the previous chapter with Fading Memories and modied our digital signature scheme so that we could look back at longer histories without using too many features. We evaluated its performance and showed that it was much better at detecting malicious behavior that varied over longer periods. Finally, we introduced a new technique, called Dynamic Thresholds, that varied the SVM threshold based on its estimation of the proportion of malicious nodes in the network. We showed that Dynamic Thresholds can signicantly reduce the classication error. In future we plan to enhance our classier by taking into account the reliability of the agent providing the feedback. This is done in TrustGuards PSM (Personalized Similarity Measure) algorithm, however the overhead involved in PSM is similar to TVM since we have to recursively collect further feedback about agents that gave us the original feedback. In future, we will study and try to minimize the overhead associated with collecting these features.

94

Chapter 6:

Hybrid Trust Management in

MANETs based on Reputation and Role Based TM Systems

This chapter proposes a new Hybrid Trust Management System, which is based on merging our EMLTrust Reputation System with Role Based Trust Management (RBTM) to combine the advantages of both. We rst discuss some background material about RBTMs and outline some of the problems in utilizing RBTMs in MANETs, followed by suggested solutions. Then we describe the Hybrid TM System in detail and evaluate its performance.

6.1

Introduction to Role Based Trust Management

Role Based Trust Management (RBTM) was introduced by Li et al. in [39] as the next step in the evolution of access control mechanisms. It combined the merits of some earlier works by merging the concept of Roles from RBAC [40] with Trust Management [41, 42, 43]. The general idea in RBTM is that entities are granted access to resources based on the roles they possess [79]. Roles serve to characterize entities and can represent arbitrary entity attributes, such as student, faculty, or sta [80]. All users belonging to a given role are granted certain access rights using policy statements called credentials. Each credential is issued by an issuer to grant access rights to a subject. The issuer also digitally signs the credential to avoid counterfeiting, possibly using X.509 style certicates [77].

95

For example, lets say the University of Texas wants to grant all enrolled students the right to check out books from its library and the right to purchase parking permits. A tedious way of doing this would be that Enrollment Services (ES) would give the librarian as well as the police department an updated list of enrolled students each semester. However, role based TM makes the job much easier. In RBTM, the librarian (issuer) issues a credential to ES (subject) and delegates to it the right to decide who gets access to the library. The police department also issues another credential to ES, delegating to it the right to decide who can purchase a parking permit. This is illustrated by the following notation. Library.Checkout EnrollmentServices.Student PoliceDept.Permit EnrollmentServices.Student ES in turn, issues a credential to all enrolled students each semester. The credential is set to expire at the end of the semester. For instance, the student Alice would receive the following signed credential. EnrollmentServices.Student Alice If Alice needs to use the library, she only needs to show this credential to the librarian. The librarian can reconstruct the following credential chain: Library.Checkout EnrollmentServices.Student Alice and grant access to Alice. The police department can similarly reconstruct its credential chain and allow Alice to purchase a parking permit. In this way, every enrolled student can enjoy the same access rights easily, without the need for ES to send an updated list of students every semester to every single department at the university. 96

6.2

Challenges of Using Role Based Trust Management in MANETs

Many issues need to be addressed before Role based TM can be pragmatically deployed in MANETs. In this section, we discuss several issues and propose possible solutions for them. Some of the issues of using TM in MANETS, along with their solutions, have been highlighted in [1, 2, 83]. They include problems such as: 1. Attacks on the authenticity of entities, such as impersonation and Sybil attacks, which is relatively easy to do in MANETs. 2. Ease of eavesdropping which exposes the identity of communicating entities. This may be a problem if we would like to keep the identity of a user condential, such as in a military, or nancial, or medical setting. 3. Problem of selsh nodes which refuse to cooperate, such as not providing or storing credentials, not complying with rules regarding access rights, etc. 4. Unauthorized alteration of distributed resources and of stored or exchanged data. It is dicult to police nodes that are in charge of a distributed resource. 5. Limited computational resources, especially on the client side, where devices such as PDAs and cell phones might request services. In addition, we discuss some other issues in detail that are involved in using RBTM in MANETs.

97

6.2.1

Credential Storage

MANET system administrators need to decide who should store credentials and whether they are stored redundantly or not. As dened in [39], a credential is a signed certicate from an issuer, X, that grants certain rights to the subject, Y, denoted by:

X Y

So X could grant Y access rights to a resource. X could also delegate authority to Y so that Y could authorize other nodes. A credential chain can thus be formed:

X Y Z

In this case, X authorizes Y and Y grants access rights to Z. The chain could be arbitrarily long. It is also possible to construct a web of credentials where multiple issuers issue credentials to multiple subjects: X Y Z U V T

S W

This creates the problem of who should store the credentials [44]. Should the issuer of a credential store it, or the subject, or a third party? A third party could for instance be a credential storage server, but this would create scalability and availability issues since if the server goes down, the system would be incapacitated. It is therefore desirable to have distributed 98

storage of credentials. The location of the credential has signicant consequences when it comes to credential distribution and collection, which is discussed in the next subsection. Another problem that we need to address is whether the credentials should be stored redundantly or not. In the chain X Y Z, consider what would happen if Y were to suddenly go oine. Regardless of whether the issuer or the subject chooses to store a credential, if Y goes oine we cannot complete the chain since Y is both an issuer and a subject. In this case Z will not be able to gain access rights even though it is entitled to it. Let us say we choose to store a credential with both its issuer as well as its subject for the sake of redundancy. Then the scheme still fails in cases such as W X Y Z if both X and Y were to go oine simultaneously, since the middle credential would become inaccessible. There is a tradeo between redundancy and storage requirement based on the degree of robustness a network desires. Redundancy: Ideally, a MANET must store credentials redundantly. Since the entire system is distributed, we cannot store all the credentials at a centralized server. Therefore, each issuer (or subject) stores its own credentials. However, if an issuer such as X goes oine we would like Z to be able to contact some other node in order to obtain Xs credentials. One possibility is that we designate another node, W, to store a duplicate of all of Xs credentials. If X is unreachable, Z would contact W to obtain the credentials. But if a malicious node wants to target X and remove all its credentials, it only needs to attack X and W and disable them. We propose that instead of storing all the credentials in one backup node, X would randomly divide all its credentials into r equal sized groups and distribute each group to r dierent nodes to store. Since each credential is signed by X it cannot be tampered with. If X becomes unreachable, Z can contact each of the r nodes in turn to obtain the complete 99

set of Xs credentials. Using this approach, we do not increase the storage or bandwidth requirements, but we make it harder for an attacker to disable access to all of Xs credentials (the total number of nodes accessed by Z is increased however). To disable access to all of Xs credentials the attacker must bring down all r nodes along with X. Further redundancy can be introduced by storing each group of credentials on more than one node. This would increase storage requirement though so a balance needs to be reached between storage requirement and the degree of redundancy. Which group of nodes X chooses to store its credentials on depends on the implementation. One possibility is that X can simply choose the nodes with the next higher (or lower) IP address compared to its own. Another possibility is that X would take a hash of its own ID. It would then mod the hash value with the number of nodes in the network, n, to decide which node should store the credentials. X can hash its ID twice, or thrice to obtain the next node that stores the credentials. When Z needs to access Xs credentials and X is oine, Z can repeat the same procedure to determine which node has Xs credentials. The advantage of this approach is that it can distribute credentials in a pseudo-random fashion within the network and avoid possible clustering, where a small group of nodes end up storing most of the credentials.

6.2.2

Credential Chain Distribution and Collection

The problem of searching for credentials is directly correlated with where the credentials are stored. In [44], the authors discuss three approaches for constructing the chain of credentials going from the subject, the client requesting a service, to the issuer, the server oering the service. The rst approach is a top down approach where one would begin constructing the 100

chain starting from the issuers end and spanning out until one would encounter the subject at the end of the chain. The second approach is a bottom up approach in which one would start at the subjects end and span out backwards until the issuer is reached. The third approach is a meet-in-the-middle approach where one would start at both the issuers and the subjects ends and meet in the middle. It is important to realize that a node storing a given credential could be located anywhere within the MANET, so a credential such as X Y does not imply that X and Y are neighbors. Some practical considerations need to be kept in mind when designing the system. Consider the case where Z needs to use a service provided by X. Z must nd and present to X a credential chain authorizing Z to use its services. We assume that the chain X Y Z exists. Suppose we choose to store the credential with the subject. In such a case, it would make sense to use the bottom up approach. Since Z has the credential Y Z, it knows it must contact Y in order to obtain the next link up in the chain. Z would contact Y and ask for all the credentials it possesses to see if a chain back to X can be constructed. Once Z receives the credential X Y, it stops searching. If such a credential is not found, it would in turn contact each of the issuers of Ys credentials and fan out from there until it reaches X, or the maximum allowed search depth is reached. The maximum search depth should be chosen so as to allow most of the chains to be found while not being so large as to place an excessive load on the network and on the node performing the search. Conversely, if the credential is stored with the issuer then we should use the top down approach. In that case, Z would begin at X and know that it needs to contact Y next when it sees the credential X Y. A meet-in-the-middle approach would be eective if both the issuer and the subject store the credential. 101

6.3

Introduction to a Hybrid Trust Management System

A given organization may consist of many resources and entities who want to access those resources. For example, in a military setting there may be resources such as battle plans, communication systems, surveillance equipment, and weapons systems that may need to be accessed by dierent personnel at dierent times. Not all personnel are granted full access rights to every resource, so there must be a Trust Management System (TMS) in place to enforce those access rights. However, it is cumbersome to enforce access rights based merely on an entitys username. Every resource would need to have a database of usernames that are allowed to access it, along with authentication mechanisms to verify the authenticity of usernames provided by users. Making changes to a persons access rights would be a daunting task as every resource that the person accesses would need to have its database updated. Furthermore, having separate databases and authentication mechanisms for each resource makes an attackers task easier by providing him with more potential points of entry. Role Based Trust Management (RBTM) was introduced to solve some of these problems as the next step in the evolution of access control mechanisms. In RBTM, entities are granted access to resources based on the roles they possess. By contrast, Reputation Systems (RS) grant access to entities based on their past behavior [75]. Good behavior results in escalation of access rights, whereas bad behavior results in the reduction of rights. There is no notion of roles, making RSs unsuitable for organizations consisting of designated roles, such as the military, or corporations. In Chapters 4 and 5, we developed a Machine Learning based Reputation System [14] and showed that it performed better than some other approaches presented in the literature [60].

102

In this chapter, we propose to combine our Reputation System with RBTM in order to create a new Hybrid Trust Management System (HTMS). Its motivation is derived from real life. For example, a soldier with a long history of working with the army is more reliable than a brand new soldier. HTMS takes into account the role of an entity, as well as its historical behavior and experiences in order to decide which access rights to grant to an entity. This approach has the advantages of not granting complete access to a new role, but gradually transferring more rights as the entity becomes more experienced. The process is automatic and it grants rights in small steps, making the access control ne grained. On the other hand, if an entity is deemed to misbehave and abuse its rights, its rights are reduced even though it still belongs to the same role. In addition, the system stores a history of past transactions and their feedbacks so that administrators and supervisors can review the performance of any entity. In Section 6.4, we describe the details of our proposed Hybrid Trust Management System (HTMS), and discuss its merits. In Section 6.5, we evaluate HTMS and present results. Section 6.6 suggests how we can estimate the proportion of malicious nodes in the network to further improve performance. Finally, conclusions and future work and given in Section 6.7.

6.4

Proposed Hybrid Trust Management System (HTMS)

Our Hybrid Trust Management model utilizes a combination of Role based and Reputation based trust management in order to benet from the advantages of both. In this model, each entity is assigned a role beforehand by an administrative authority. However, all entities belonging to the same role do not necessarily have the same access rights. Within each role, a range of access rights is dened from a minimum privilege level, to a maximum privilege level.

103

For instance, minimum privilege level access could mean that a soldier can only receive communications. Soldiers with higher privilege levels could receive as well as send communications, whereas soldiers with maximum privilege levels could access battle plans. Privilege levels are values between 0 and 1, with 0 being the least privileged, and 1 being the most privileged. Nodes with 0 privilege level cannot access any resource on the network, whereas nodes with privilege level 1 have full access to all the resources on the network. When the administrative authority assigns a role to a new node, it denes a minimum and a maximum privilege level that the node can possess. At any point in time, the exact privilege level of the node is determined by its reputation score, but it will always fall within this range. The administrator then issues a digitally signed certicate to the node, with the following credentials: N ode ID, Role, M aximum P rivilege, M inimum P rivilege, Expiration T ime Where N odeID is the ID of the node, and Role is the role title, such as private, major, colonel, or general and is only meant for human consumption. It has no bearing when deciding access rights by machines. Maximum and minimum privilege levels are numbers between 0 and 1, where minimum privilege maximum privilege. Expiration time is the time when the certicate becomes invalid and must be renewed. The certicate is signed by the administrator and given to the node. Whenever the node needs to access any service on the network, it will present this certicate to the server. The server will check what is the minimum privilege level required to access that particular service. This required privilege level is decided beforehand by the server administrator. Then the server will proceed as follows: 104

1. Verify the signature to ensure that the certicate originated from the administrative authority. 2. If the required privilege level for the service is greater than the maximum privilege level on the certicate, deny service. 3. If the required privilege level for the service is less than the minimum privilege level on the certicate, grant service. 4. If the required privilege level for the service is in between the minimum and the maximum privilege on the certicate, obtain the reputation score of the node and compute its privilege level at that point in time (explained below). 5. Grant service if nodes privilege level is greater than or equal to the required privilege level. Otherwise, deny service.

6.4.1

Determining the Exact Privilege Level

As mentioned, the exact privilege level of a node at a given point in time is determined by its reputation score. Reputation Systems (RS) work by obtaining feedbacks about a node from other nodes it has transacted with in the past. The underlying principle is that a node that has behaved well in the past is likely to behave well in the future, and a node that has misbehaved in the past is likely to misbehave in the future. Such a system is utilized by eBay with its seller rating, where previous buyers leave feedback about the seller so that prospective buyers can decide whether to buy from the seller or not [72]. A similar system is also used by Googles PageRank, where web pages are assigned importance based on the number of other web pages

105

that link to it, eectively giving a positive recommendation to it. Pages with higher ranks are shown higher up in Googles search results [73]. In HTMS, a server that needs to obtain the reputation score of the client broadcasts a feedback request throughout the network. Any node that has transacted with the client before responds to the request and sends back encrypted and digitally signed feedbacks to the server. The server decrypts and veries the signature of the feedback, and then computes a reputation score using any RS implementation. Although any RS can be used with HTMS [60, 61, 75, 76], we chose to use our previously proposed SVM based RS [14] for our experiments. The reasons for this choice are mentioned in Section 6.5.2. In any case, whichever RS the network administrator decides to use, the only requirement is that the RS output a reputation score between 0 and 1, with 0 being the least reputable. The RS needs to guard against the possibility of malicious nodes giving incorrect feedback in order to malign another node. In case the node has no history, the RS outputs a preset default score, for example 0.5. Once this reputation score is obtained, the nal privilege level is computed using the following equation: P L = (M axP L M inP L) RScore + M inP L (eq. 1)

Where PL is the current privilege level, MaxPL and MinPL are the maximum and minimum privilege levels respectively, according to the role certicate, and RScore is the reputation score, as output by the RS. Equation 1 simply normalizes the privilege level between the minimum and maximum levels. An RScore of 0 yields the minimum privilege level, whereas an RScore of 1 yields the maximum privilege level. A server will grant access to the requested service if PL minimum required privilege level for that service. 106

6.4.2

Merits of HTMS

Thwarting Global Attacks: The rationale behind HTMS is to nd a solution to the problem where a privileged node is compromised by an attacker and then used to damage the network in some way. This could be by trying to attack other nodes, or by conducting malicious transactions with servers. One transaction on its own may not seem malicious, but when a combination of potentially harmful transactions occur globally throughout the network, the results could be disastrous. For instance, one update by a colonel to battle plans may not seem harmful, but a series of small updates over time may change the battle plans entirely. HTMS aims to thwart such attacks by collecting data from multiple parties that have transacted with the node before, and then deciding whether to grant access to this node using a global picture. For this to work, each server assigns a feedback score between -1 and 1 to every transaction that takes place on the server. Potentially harmful transactions, such as updates to battle plans, or changes to passwords are assigned a negative feedback score, whereas harmless transactions, such as reading or printing non-classied les, are assigned positive feedback scores. Similarly, transactions deemed to be malicious, such as uploading viruses or worms, or trying to initiate a buer overow attack, will be given negative feedback scores. All of these feedbacks are then used by the Reputation System to compute the overall reliability of the node, which in turn is used to determine access rights. A node that has conducted many potentially harmful transactions in the recent past will have a low reputation score and service will be denied to it, even if it possesses a privileged role, thus thwarting any potential global attacks. At the very least, the attacker will have to slow down the attack, giving more time to the authorities to detect and defeat the attacker.

107

Modeling Real World Scenario: The scheme models the real world where an employee is given access rights based on her job title. At rst, she is given a certain level of privilege. If she is observed to abuse her rights, some of her privileges are revoked. On the other hand, if she behaves well and gains the trust of her colleagues, she is rewarded with progressively higher access rights. This increase in rights may also be based on the fact that she will become more experienced over time and less likely to abuse the system inadvertently. Eventually, she may gain more and more trust and be promoted to a better position. Our scheme follows this model and it is therefore intuitive. Defense Against False Evidence: By maintaining a Reputation System, we can deter a malicious node, M, from continuously presenting false evidence against X. Because the Reputation System is based on evidence presented by several nodes, no single node can falsely incriminate X to signicantly reduce its access rights. In any case, Xs rights can never go below the minimum level within its role. Furthermore, if M repeatedly gives a low score to other nodes, it will hurt Ms own reputation and diminish its own access rights. Decentralized System: No single node holds all the evidence regarding any node. Therefore, if any one or a few nodes go oine the system can still function well. The Reputation System may be marginally aected since the contribution from the oine nodes will be missing, but it will usually not be critical if only a few nodes are oine. Updating Roles: Periodically, the administrators responsible for role assignment can look at a nodes past behavior and reconsider the role assigned to it. They could demote or promote a node to a dierent role (or job title) based on the behavior. Since each role credential carries an expiry date and time, temporary roles could also be assigned to guest entities for a predetermined amount of time. 108

Historical Record Keeping: This will encourage each node to always behave well so that it may retain or upgrade its access rights. This is similar to the credit score system maintained by credit agencies for individuals in the United States.

6.5
6.5.1

Evaluating HTMS
Simulation Setup

We used simulations to evaluate the ecacy of HTMS. We simulated the scenario where a node, x, is present within a large network of 1,000 nodes. The behavior of node x varies randomly with time. Time is measured in units of days from 1 to 365, i.e. one year. The behavior of a node on any given day is quantied as the proportion of legitimate or non-risky transactions it conducts during that day, versus the total number of transactions conducted by the node during the day. Each transaction is between node X and any other random node on the network. A randomly generated behavior curve that uctuated slowly over time was used as the basis of the experiments. The behavior curve is illustrated in Fig. 6.1. This curve simulates the behavior of an actual node over time that may have been compromised. Privilege levels are dened on a scale of 0 to 1, where 0 represents no access rights to any resource on the network and 1 represents complete access to all available resources. In our simulation, the system administrator has assigned to node x a certain role, with a maximum privilege level of 0.8 and a minimum privilege level of 0.2. The actual privilege level at any given point in time maybe anywhere between this range, but under no circumstances will the privilege level be higher than 0.8, or lower than 0.2. Other roles may have other corresponding minimum and maximum levels assigned by the administrator. 109

In the ideal case, we would like the privilege level at any given time to be proportional to the behavior of the node at that time. If the behavior is 1, the privilege level should be maximum, i.e. 0.8. If the behavior is 0, the privilege level should be minimum, i.e. 0.2. If the behavior is between 0 and 1, the privilege level should be between 0.2 and 0.8 correspondingly. The ideal curve for the simulated behavior is illustrated in Fig. 6.1.

Figure 6.1. Randomly generated behavior of a node vs. the corresponding ideal response curve, along with maximum and minimum privilege levels.

Our goal is to construct a system that will mimic the ideal curve as closely as possible. The ideal curve, therefore, represents the yardstick against which an implementation of the system can be compared. Of course, in an actual setting, since we would not know the exact behavior of a node, we would need to estimate it using a Reputation System as dened in Section 6.4.1.

110

6.5.2

Experiments and Results

We used an implementation of the Support Vector Machines (SVM) based Reputation System (RS) that we proposed in a previous work [14] for the following reasons: 1. This RS has been shown to perform well with varying patterns of malicious behavior and varying proportions of malicious nodes. 2. It protects against fake feedbacks about transactions that never really occurred. 3. Since it is based on Machine Learning and SVM, it is easy to construct the RS model and automatically determine the models parameters if there is training data available [62]. We generated the training data using simulations on a dierent behavior curve. The proportion of malicious nodes in the network was varied in dierent simulations to obtain dierent training sets. A malicious node is dened as a node that lies and gives incorrect feedback about a node in an attempt to either decrease its reputation, or to increase it if the node is another colluding malicious node. The training sets were then used to train SVM. The test sets were generated using the behavior curve illustrated in Fig. 6.1. Feedbacks were taken from the nodes in the network that had transacted with node X. Again, the proportion of malicious in the network was varied between 0% and 70% so that the feedbacks were not always reliable. Each train and test instance consists of feedbacks obtained over the last seven days (i.e. one week). Accordingly, the privilege levels are automatically updated every seven days so that a given privilege level is valid for one week. In the rst set of experiments, we used a training set consisting of 0% malicious nodes to train SVM. Then we tested this model against ve dierent test sets consisting of 111

0% to 70% malicious nodes. The output of the model for each test set over time is plotted in Fig. 6.2. The gure shows that the model closely mimics the ideal curve when the proportion of malicious nodes in the test set is also 0%, same as in the training set. For other proportions, the output deviates from the ideal curve, becoming almost a horizontal line at 50%. It becomes a mirror image of the ideal curve above 50%, increasing when the ideal curve decreases and vice versa. This is because after 50%, a majority of the nodes lie about the feedback, giving good feedback when the node is bad, and bad feedback when the node is good. This malicious majority overwhelms the feedback from the minority legitimate nodes, leading SVM to reverse its output. At 50%, neither malicious nor legitimate nodes can overwhelm each other, so SVM produces a constant output of approximately 0.5.

Figure 6.2. Eect of varying proportions of malicious nodes in test sets. Training set has 0% malicious nodes. We quantied the deviations of the test curves from the ideal curve by measuring the average overestimations of the curve, when the system grants more privilege than it should, 112

and underestimations of the curve, when the system grants fewer privileges than it should. The daily averages of the over and under estimations are plotted in Fig. 6.3. The sum of over and under estimation gives the overall average discrepancy from the ideal curve. As expected, the smallest discrepancy occurs when the percentage of malicious nodes in the test set is 0%, the same as in the training set. At 0%, the discrepancy is only about 0.008, which means that on average the system is o from the ideal privilege level by 0.004. However, the discrepancy can be as high as 0.27 when 70% of the nodes are malicious.

Figure 6.3. Average daily discrepancy from the ideal curve vs. percentage of malicious nodes in the network (smaller is better). Training set has 0% malicious nodes.

We hypothesized that the discrepancy for a given test set would be minimized when the percentage of malicious nodes in the test set would be the same as in the training set. To test this hypothesis, we conducted further experiments, this time using dierent percentages of malicious nodes in the training sets. For the second set of experiments, we used 30% malicious nodes in the training set and repeated the experiments with the same test sets as before. The 113

results are shown in Figs. 6.4 and 6.5. Then we repeated the experiments with 70% malicious nodes in the training set. The results are shown in Figs. 6.6 and 6.7. The results support our hypothesis that the discrepancy is minimized when the percentage of malicious nodes in the test set is the same as in the training set.

Figure 6.4. Eect of varying proportions of malicious nodes in test sets. Training set has 30% malicious nodes.

114

Figure 6.5. Average daily discrepancy from the ideal curve vs. percentage of malicious nodes in the network. Training set has 30% malicious nodes.

Figure 6.6. Eect of varying proportions of malicious nodes in test sets. Training set has 70% malicious nodes.

115

Figure 6.7. Average daily discrepancy from the ideal curve vs. percentage of malicious nodes in the network. Training set has 70% malicious nodes.

6.6

Estimating Percentage of Malicious Nodes

Based on our results, we can conclude that in order to minimize the discrepancy, we need to train the SVM model using a training set that has approximately the same percentage of malicious nodes as the test set. Unfortunately, in a real world setting, we do not know what the percentage of malicious nodes actually is, and it may vary with time. To work around this problem, we propose generating several SVM models using dierent percentages of malicious nodes, for example 0%, 10%, 20% and so on. Then, we need to estimate the percentage of malicious nodes in the network so that we can apply the appropriate model. Estimation of the percentage of malicious nodes can be done by sampling. To begin with, a node uses a default SVM model, for instance, the one with 10% malicious nodes. 116

Using this model, the node classies other nodes that try to transact with it as legitimate or malicious and stores this sample. If the node ends up transacting with other nodes, then the outcomes of those transactions are also used to estimate the proportion of malicious nodes. When a sample of a certain size has been gathered in this way, the proportion of legitimate vs. malicious nodes is estimated and the SVM model corresponding to that estimate is used for future classications. In this way, the proportion estimation is done dynamically and may vary with time. Our experiments in the previous chapter have shown that a sample size of about 20 to 25 is sucient for estimating the percentage of malicious nodes in a large network and selecting an SVM model with reasonable accuracy. However, even if we cannot accurately estimate this percentage, HTMS still performs better than just using RBTM by itself, since in that case the node would simply have maximum privilege all the time.

6.7

Conclusions and Future Work

In this chapter, we proposed a new Hybrid Trust Management System (HTMS) that combines Role Based Trust Management (RBTM) with Reputation Systems (RS). At any given point in time, the privilege level of a node is determined not only by its role in the system, but also by its reputation score. The advantages of HTMS are that it allows automatic, ne-grained access control to network resources based on a nodes behavior. If a privileged node becomes compromised and conducts several malicious or risky transactions, its privilege level is quickly reduced to limit its access to resources and minimize the damage it can further inict. This is accomplished by utilizing a global picture that is constructed by obtaining feedbacks from many sources on the network in order to determine access rights. If a node behaves well and

117

conducts legitimate transactions, more privileges are granted to it, providing an incentive to users to behave well. Such ne-grained access control and dynamically assigning privilege levels would be very dicult to accomplish manually. Other advantages of the system are that it models real world scenarios where experience and good behavior are rewarded with higher privileges, whereas novices and unreliable entities are only given limited rights. Furthermore, the system is decentralized and prevents a single node from damaging the reputation of others. It also keeps historical records of every nodes behavior, making it easy for system administrators to monitor their behavior and promote or demote a nodes role. We evaluated the performance of a particular implementation of HTMS on a simulated network, using our previously proposed SVM based RS [14]. We determined the ideal response that the system should have and compared the actual response with the ideal as a benchmark. The results show that the actual response is very close to the ideal response if the percentages of malicious nodes in the training and test sets are the same. Since we do not know this percentage in an actual network, we recommended using sampling to estimate this percentage and then using this estimate to determine which SVM model to use for maximum accuracy. Even if the estimate is not accurate, HTMS still performs better than just RBTM by itself, since RBTM would simply allow maximum privileges to the node all the time. In future, we aim to devise better estimation mechanisms that can more accurately determine the percentage of malicious nodes in the network. We also aim to construct better SVM models that are more resilient to changes in the percentage of malicious nodes and give us better results. This may be accomplished by trying dierent SVM kernels and varying its parameters. 118

Chapter 7:

Dissertation Summary and Future Work

7.1

Research Objectives

MANETs must provide various levels of security guarantees to dierent applications for their successful deployment and usage. These security requirements can be very stringent for military and anti-terrorism operations, to less stringent for business and personal use. Unfortunately, due to their wireless links and lack of central administration, MANETs are far more susceptible to attacks than conventional networks. For example, it is easy for attackers to enter or leave a wireless network and eavesdrop since no physical connection is required. They can also directly attack the network to drop packets, tamper with packets or inject false packets. As a result, it is possible to launch sophisticated wormhole, man-in-the-middle and Denial of Service (DoS) attacks with ease, or impersonate another node. The risk of using an unsecured MANET might actually outweigh the benets. It is therefore paramount to have eective security solutions in place for their successful deployment. The architecture of the MANET may vary greatly based on its application. In an open MANET anyone is free to enter or leave the network, whereas in a closed MANET only designated nodes may gain access. The network may be hierarchical, where nodes have dierent roles and privileges and provide dierent services, or it may be at, where each node provides the same type of services. Furthermore, the nodes may belong to a Single Administrative Domain (SAD), where only one administrator controls the network, or Multiple Administrative 119

Domains (MAD), where there are multiple administrators. In this dissertation we are focusing on closed networks, which may be at or hierarchical, SAD or MAD. In the context of closed networks, we dene outsider nodes as those nodes that are not authorized to access the network, and insider nodes as those that are allowed to access the network. The objective of this research is to develop mechanisms that protect a closed MANET against malicious behavior from outsider and insider nodes through packet authentication and a Hybrid Trust Management System, respectively. The goal is not to protect an individual node from being compromised, but rather we expect some nodes to be compromised and the goal is to limit the damage such compromises can cause. The network on the whole should be able to function at a satisfactorily level and provide services with reasonable reliability even in the presence of such malicious intruders. In future, we plan to investigate the impact of increasing the proportion of malicious nodes in the network on network performance and reliability.

7.2

Guarding Against Outsiders

In Chapter 2, we presented a new Hop-by-hop, Ecient Authentication Protocol, called HEAP, that is intended to guard against attacks from outsiders. This protocol is suitable for use in MANETs for unicast, multicast or broadcast applications, and is independent of the routing protocol used. It is based on a modied HMAC algorithm that uses two keys and is very ecient. We stated our security goals for HEAP and presented a security analysis of HEAP to evaluate it against those goals. We showed that the security of HEAP is equivalent to the security of HMAC for attacks against outsiders. We compared the performance of HEAP with

120

three other authentication algorithms, namely TESLA, LHAP and Lu and Poochs algorithm using simulations. We highlighted some of the shortcomings of those algorithms and showed how our algorithm was able to overcome many of those shortcomings. We demonstrated how HEAP is resistant to several outsider attacks such DoS, wormhole, replay, impersonation and man-in-the-middle attacks by making it very dicult for an outsider to propagate any forged packet. It has extremely low memory requirements (only 176 bytes in our simulations) and its CPU overhead is negligible, making it suitable for constrained wireless devices. Its byte overhead is also negligible since it has an insignicant eect on overall throughput and packet delivery ratio. Its latency is almost the same as without any security scheme, making it ideal for real time and QoS applications. Future Work: In future, we plan to reduce the bootstrapping and key exchange overhead by proposing ID based, Certicateless key exchange proposed in [65]. We can use this algorithm to design a more robust ID based key exchange mechanism suitable for MANETs. By relying on ID based keys, we no longer need to verify traditional X.509 style certicates with third party signatures. This reduces the overhead in exchanging keys and makes the overall scheme more ecient.

7.3
7.3.1

Guarding Against Insiders

Dierent Trust Management Approaches

In Chapter 3, we presented the background material related to guarding against insiders through Trust Management (TM) systems. We presented the pros and cons of three traditional TM systems: Behavior based TM, Reputation based TM, and Role based TM systems. We also 121

compared which TM approach was appropriate for which MANET architecture. We discussed how to utilize various TM systems in the context of closed MANETs, and accordingly proposed a hybrid TM system.

7.3.2

Basic Machine Learning Based Reputation System

In Chapter 4, we presented a new Machine Learning (ML) based Reputation System (RS). We discussed the motivation behind developing an ML solution and the challenges associated with using ML. We discussed why using Machine Learning (ML), and especially Support Vector Machines (SVM), is a good approach for designing RSs. We then proposed our SVM based RS and specied what features we used, the kernel and other parameters used. Then, we proposed a scheme for guarding against fake transactions that does not need online trusted third parties. We developed and evaluated our core SVM based RS using simulations. Its performance was compared against two other algorithms found in the literature called TrustGuard Nave and TrustGuard TVM [60]. We chose TrustGuard because it has been shown by its authors to perform very well compared to eBays reputation system. We simulated 5 dierent attack scenarios and showed that our model outperforms TrustGuard in all 5 scenarios, whether there is oscillating or steady behavior, collusive or non collusive behavior. Our scheme can achieve high accuracy and correctly predict good vs. malicious nodes, even when the proportion of malicious nodes in the network is very high. The ROC curves show that the improvement of SVM over TrustGuard is statistically signicant, as their condence intervals do not overlap each other. We also showed that SVM has the same bandwidth overhead as TrustGuard Nave, but much better overhead than TrustGuard TVM.

122

7.3.3

Enhanced Machine Learning Based Reputation System

In Chapter 5, we enhanced the core SVM based RS presented in Chapter 4 with Fading Memories and modied our digital signature scheme so that we could look back at longer histories without using too many features. This forces adversaries to behave well for longer periods of time in order to boost their reputation scores. We evaluated its performance and showed that it was much better at detecting malicious behavior that varied over longer periods. Next, we introduced a new technique, called Dynamic Thresholds, that varied the SVM threshold based on its estimation of the proportion of malicious nodes in the network. We showed that Dynamic Thresholds can signicantly reduce the classication error and allow SVM to keep up with varying levels of malicious behavior in the network as time progresses. We call our enhanced Reputation System EMLTrust. Future Work: In future we plan to enhance our classier by taking into account the reliability of the agent providing the feedback. This is done in TrustGuards PSM (Personalized Similarity Measure) algorithm, however the overhead involved in PSM is similar to TVM since we have to recursively collect further feedback about agents that gave us the original feedback. In future, we will study and try to minimize the overhead associated with collecting these features.

7.3.4

Hybrid Trust Management System for MANETs

In Chapter 6, we proposed a new Hybrid Trust Management System for MANETs, that was based on merging our EMLTrust Reputation System with Role Based Trust Management (RBTM). We highlighted the problems associated with using a traditional Role based TM

123

system (RBTM) with MANETs. These problems were due to factors such as the absence of an online central authority, the limitation of many nodes in their computational resources, nodes going oine at any time necessitating redundancy, and nodes were not guaranteed to be completely trustworthy. This led to challenges associated with credential storage and discovery, computational eciency, distributing the RBTM over multiple nodes, and issues related to privacy. Some solutions were presented to alleviate these problems. Then the chapter goes on to propose a hybrid Reputation and Role based TM system that can overcome some of the limitations of Role and Reputation systems used in isolation. At any given point in time, the privilege level of a node is determined not only by its role in the system, but also by its reputation score. The model can be described briey by the following rules: 1. If the client requesting a service has a highly privileged role that grants unrestricted access to the resource, service would be granted to it. 2. If the client has an under-privileged role below a certain minimum level, service would be denied to it. 3. If the client has a role that is above the minimum privilege level but below the unrestricted access level, then the clients reputation is queried. If it is found to be acceptable, access is granted; otherwise, it is denied. The advantages of HTMS are that it allows automatic, ne-grained access control to network resources based on a nodes behavior. If a privileged node becomes compromised and conducts several malicious or risky transactions, its privilege level is quickly reduced to limit its access to resources and minimize the damage it can further inict. This is accomplished by 124

utilizing a global picture that is constructed by obtaining feedbacks from many sources on the network in order to determine access rights. If a node behaves well and conducts legitimate transactions, more privileges are granted to it, providing an incentive to users to behave well. Such ne-grained access control and dynamically assigning privilege levels would be very dicult to accomplish manually. Other advantages of the system are that it models real world scenarios where experience and good behavior are rewarded with higher privileges, whereas novices and unreliable entities are only given limited rights. Furthermore, the system is decentralized and prevents a single node from damaging the reputation of others. It also keeps historical records of every nodes behavior, making it easy for system administrators to monitor their behavior and promote or demote a nodes role. We evaluated the performance of a particular implementation of HTMS on a simulated network, using our previously proposed SVM based RS [14]. We determined the ideal response that the system should have and compared the actual response with the ideal as a benchmark. The results show that the actual response is very close to the ideal response if the percentages of malicious nodes in the training and test sets are the same. Since we do not know this percentage in an actual network, we recommended using sampling to estimate this percentage and then using this estimate to determine which SVM model to use for maximum accuracy. Even if the estimate is not accurate, HTMS still performs better than just RBTM by itself, since RBTM would simply allow maximum privileges to the node all the time. Future Work: In future, we aim to devise better estimation mechanisms that can more accurately determine the percentage of malicious nodes in the network. We also aim to construct better SVM models that are more resilient to changes in the percentage of malicious 125

nodes and give us better results. This may be accomplished by trying dierent SVM kernels and varying its parameters.

In this dissertation, we presented three new algorithms, HEAP, EMLTrust and Hybrid TMS in order to safeguard MANETs from attacks from outsiders as well as insiders. We evaluated all three algorithms in detail and illustrated their features and benets to demonstrate their utility.

126

Appendix A: Comprehensive List of the Authors Publications

A.1 Book Chapter

1. R. Akbani. Applications of Support Vector Machines in Network Security and Bioinformatics. Chapter in the book Machine Learning, ISBN 978-953-7619-X-X, accepted for publication, 2009.

A.2

Journal Publications

1. R. Akbani, T. Korkmaz and G.V.S. Raju. EMLTrust: An Enhanced Machine Learning Based Reputation System. Submitted to IEEE Journal on Selected Areas in Communications: Mission Critical Networking, 2009. 2. R. Akbani, T. Korkmaz, and G.V.S. Raju. HEAP: A Packet Authentication Scheme

for Mobile Ad-hoc Networks. Ad Hoc Networks Journal, Elsevier, Vol. 6, Issue 7, pp. 1134-1150, September 2008.

A.3

Conference Publications
A Hybrid Trust Management System for

1. R. Akbani, T. Korkmaz and G.V.S. Raju.

Automated Fine-Grained Access Control. Submitted to MILCOM, 2009.

127

2. R. Akbani, T. Korkmaz and G.V.S. Raju. Defending Against Malicious Nodes Using an SVM Based Reputation System. Proc. of MILCOM 2008, Sponsored by Raytheon, IEEE, AFCEA, 2008. 3. R. Akbani, T. Korkmaz and G.V.S. Raju. A Machine Learning Based Reputation System for Defending Against Malicious Node Behavior. Proc. of the IEEE Global Communications Conference (GLOBECOM), 2008. 4. R. Akbani, T. Korkmaz, and G.V.S. Raju. HEAP: Hop-by-hop ecient authentication protocol for mobile ad-hoc networks. Proc. of the 10th Communications and Networking Simulation Symposium, SCS and ACM, pp 157-165, March 2007. 5. R. Akbani, T. Korkmaz, and G.V.S. Raju. A packet authentication scheme for wireless sensor networks. Proc. of the 22nd International Conference on Computers and Their Applications (CATA), pp 401-407, March 2007. 6. G.V.S. Raju and R. Akbani. Authentication in Wireless Networks. Proceedings of the 40th annual Hawaii International Conference on System Sciences (HICSS), pp 270, 2007. 7. G.V.S. Raju and R. Akbani. Mobile Ad-Hoc Networks Security. International Engineering Consortium, Annual Review of Communications, vol. 58, pp. 625-628, 2006. 8. S. Kwek and R. Akbani. Adapting Support Vector Machines to Predict Translation IEEE Computational Systems Bioinformatics

Initiation Sites in the Human Genome. (CSB), Poster Session, 2005.

9. R. Akbani, S. Kwek and N. Japkowicz Applying Support Vector Machines to Imbalanced Datasets. Proceedings of the 15th European Conference on Machine Learning (ECML), 128

pp. 39-50, 2004. 10. G.V.S. Raju and R. Akbani. Security Issues in Mobile Ad-hoc Networks. Center of

Excellence In Wireless and Information Technology (CEWIT), 2004. 11. G.V.S. Raju and R. Akbani. Elliptic Curve Cryptosystem and its Applications. Proceedings of the IEEE International Conference on Systems, Man and Cybernetics (IEEESMC), 2003.

129

Bibliography
[1] Q. Memon, S. Akhtar, and A. A. Aly. Role Management in Adhoc Networks. Proc. of the 10th Communications and Networking Simulation Symposium, SCS and ACM, pp 131-137, March 2007. [2] V. Tsetsos, G. F. Marias, and S. Paskalis. Trust Management Issues for Ad Hoc and Selforganized Networks. Autonomic Communication, LNCS, vol. 3854, Springer, pp 153-164, 2006. [3] J. Hu, and M. Burmester. Cooperation in Mobile Ad Hoc Networks. Computer Communications and Networks, ISBN 978-1-84800-328-6, Springer-Verlag London, 2009. [4] A. Srinivasan, J. Wu, and J. Teitelbaum. Distributed Reputation-based Secure Localization in Sensor Networks. Special Issue of Journal of Autonomic and Trusted Computing, 2008. [5] A. Aresenault, and S. Turner. Internet X.509 public key infrastructure: PKIX roadmap. IETF Internet draft, PKIX Working Group, 2000. [6] J. S. Baras, and T. Jiang. Managing trust in self-organized mobile ad hoc networks. Workshop NDSS, Extended abstract, 2005. [7] I. Chlamtac, M. Conti, and J.J.N. Liu. Mobile ad hoc networking: imperatives and challenges. Ad Hoc Networks, vol. 1, no. 1, pp. 1364, 2003. [8] H. Yang, H. Luo, F. Ye, S. Lu, and L. Zhang. Security in mobile ad hoc networks: challenges and solutions. IEEE Wireless Communications, vol. 11, no. 1, pp. 38-47, 2004.

130

[9] M. Bellare, R. Canetti, and H. Krawczyk. Keying hash functions for message authentication. Proc. of Advances in Cryptology, 1996. [10] M. Bhattacharyya, S. Nandi, and S. Saha. A soft dynamic service specic trust management and authentication scheme for mobile adhoc networks. IEEE: Wireless and Optical Communications Networks, 2006. [11] M. Blaze and J. Ioannidis. Trust management for ipsec. CM Transactions on Information and System Security (TISSEC), 5(2), May 2002. [12] R. Akbani, T. Korkmaz, and G.V.S. Raju. HEAP: Hop-by-hop ecient authentication protocol for mobile ad-hoc networks. Proc. of the 10th Communications and Networking Simulation Symposium, SCS and ACM, pp 157-165, March 2007. [13] R. Akbani, T. Korkmaz, and G.V.S. Raju. A packet authentication scheme for wireless sensor networks. Proc. of the 22nd International Conference on Computers and Their Applications (CATA), pp 401-407, March 2007. [14] R. Akbani, T. Korkmaz, and G.V.S. Raju. Defending against malicious nodes using an SVM based reputation system. Proc. of MILCOM, 2008. [15] K. A. Bradley, S. Cheung, N. Puketza, B. Mukherjee, and R. A. Olsson. Detecting disruptive routers: A distributed network monitoring approach. In IEEE Symposium on Security and Privacy, 1998. [16] S. Cheung and K. Levitt. Protecting routing infrastructures from denial of service using cooperative intrusion detection. In New Security Paradigms Workshop, 1997.

131

[17] S. Kent, and R. Atkinson. RFC 2406 IP Encapsulating Security Payload (ESP). Internet Engineering Task Force (IETF), 1998. [18] B. Dahill, B. Levine, E. Royer, and Shields C. A secure routing protocol for ad-hoc networks. In Proceedings of the 10th Conference on Network Protocols (ICNP), 2002. [19] C. R. Davis. A localized trust management scheme for ad hoc networks. In The 3rd International Conference on Networking (ICN04), pages 671675, March 2004. [20] L. Eschenauer, J. S. Baras, and V. Gligor. Distributed trust establishment in manets swarm intelligence. In Proceedings of the Collaborative Technology Alliances (CTA) Communications & Networks (C&N) Alliance-2003Annual Symposium, pages 125129, 2003. [21] J. Michaels. Military Beefs up Internet Arsenal; Terrorists expand use of computers. USA Today newspaper, pp A.1, March 28th, 2007. [22] L. Eschenauer and V. D. Gligor. A key-management scheme for distributed sensor networks. In ACM CCS, 2002. [23] A. Srinivasan, F. Li, J. Wu, and M. Li. CAGE: Clique-based Assignment of Group Key. Proc. of the Second International Conference on Communications and Networking (ChinaCom), 2007. [24] A. Srinivasan, F. Li, J. Wu, and M. Li. Clique-based group key assignment in Wireless Sensor Networks. International Journal of Security and Networks, 2008. [25] L. Eschenauer, V. D. Gligor, and J. S. Baras. On trust establishment in mobile ad-hoc networks. In Proceedings of 10th International Workshop on Security Protocols, Cambridge, UK,, April 17-19 2002. (also in LNCS 2845 pp. 47-66, 2004). 132

[26] P. Gutmann. Pki: Its not dead, just resting. University of Auckland. [27] Y. Hu, D. Johnson, and A. Perrig. SEAD: Secure ecient distance vector routing for mobile wireless ad hoc networks. In Proceedings of the 4th IEEE Workshop on Mobile Computing Systems & Applications (WMCSA 2002), Calicoon, NY,, 2002. [28] Y. Hu, A. Perrig, and D. Johnson. Ariadne: A secure on-demand routing protocol for ad hoc networks. In Proceedings of Mobicom, 2002. [29] Network Associates Inc. An introduction to cryptography.

ftp://ftp.pgpi.org/pub/pgp/6.5/docs/english/IntroToCrypto.pdf. Chp 1, pp. 30-33. [30] T. Jiang and J. S. Baras. Trust evaluation in anarchy: A case study on autonomous networks. In Proceedings of the 25th Conference on Computer Communications, pages 2329, Barcelona, Spain, April 2006. [31] T. Jiang and J.S. Baras. Ant-based adaptive trust evidence distribution in manet.

In Proceedings of 24th International Conference on Distributed Computing Systems, Tokyo,Japan, March 23-26 2004. [32] UCLA Parallel Computing Lab. GloMoSim. [33] MIT Media Labs. One laptop per child. http://laptop.media.mit.edu/. [34] S. Lee, W. Su, , and M. Gerla. On-demand multicast routing protocol in multihop wireless mobile networks. Mobile Networks and Applications, 7(6):441453, 2002.

133

[35] S. Marti, T. J. Giuli, K. Lai, and M. Baker. Mitigating routing misbehavior in mobile ad hoc networks. In Proc. of the 6th Annual International Conference on Mobile Computing and Networking (MobiCom), pp. 255265, August 2000. [36] S. Buchegger and J. Y. L. Boudec. Performance analysis of the condant protocol: Cooperation of nodes fairness in dynamic ad-hoc networks. In Proc. of IEEE/ACM MobiHOC, 2002. [37] R. M. Pietro Michiardi. Core: A collaborative reputation mechanism to enforce node cooperation in mobile ad hoc networks. In IFIP Communication and Multimedia Security Conference, 2002. [38] S. Bansal and M. Baker. Observation-based cooperation enforcement in ad hoc networks. Research Report cs. NI/0307012, Standford University, 2003. [39] N. Li, J. C. Mitchell, and W. Winsborough. Design of a role-based trust management framework. Proc. of the 2002 IEEE Symposium on Security and Privacy, May 2002. [40] R.S. Sandhu, E.J. Coyne, H.L. Feinstein, and C.E. Youman. Role-based access control models. IEEE Computer, 29(2):3847, February 1996. [41] M. Blaze, J. Feigenbaum, J. Ioannidis, and A.D. Keromytis. The KeyNote trustmanagement system, version 2. IETF RFC 2704, September 1999. [42] C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, and T. Ylonen. SPKI certicate theory. IETF RFC 2693, September 1999. [43] D. Clarke, J. Elien, C. Ellison, M. Fredette, A. Morcos, and R.L. Rivest. Certicate chain discovery in SPKI/SDSI. Journal of Computer Security, 9(4):285322, 2001. 134

[44] N. Li, W. Winsborough, and J. C. Mitchell. Distributed credential chain discovery in trust management. Journal of Computer Security, 11(1):3586, Feb. 2003. [45] B. Lu and U. W. Pooch. A lightweight authentication protocol for mobile ad hoc networks. International Journal of Information Technology, 11(2):119135, 2005. [46] H. Luo, P. Zerfos, J. Kong, S. Lu, and L. Zhang. Self-securing ad hoc wireless networks. In IEEE ISCC (IEEE Symposium on Computers and Communications), July 2002. [47] P. Papadimitratos and Z. Haas. Secure routing for mobile ad hoc networks. In Communication Networks and Distributed Systems Modeling and Simulation Conference, 2002. [48] R. Perlman. Network Layer Protocols with Byzantine Robustness. Phd thesis, MIT, LCS TR-429, 1988. [49] A. Perrig, R. Canetti, J. Tygar, and D. Song. Ecient authentication and signing of multicast streams over lossy channels. In Proc. of IEEE Symposium on Security and Privacy, May 2000. [50] A. Perrig, R. Szewcyzk, V. Wen, D. Culler, and J.D. Tygar. Spins: Security protocols for sensor networks. In Proceedings of Mobile Computing and Networking, 2001. [51] G.V.S Raju and R. Akbani. Elliptic curve cryptosystem and its applications. In Proc. of the IEEE International Conference on Systems, Man & Cybernetics (IEEE-SMC), 2003. [52] G.V.S. Raju and G. Hernandez. Routing in ad hoc networks. In IEEE-SMC International conference, October 2002.

135

[53] G. Theodorakopoulos and J. S. Baras. On trust models and trust evaluation metrics for ad hoc networks. IEEE Journal on Selected Areas in Communications, 24(2):318328, Feb. 2006. [54] L. Xiaoqi. Trust model based self-organized routing protocol for secure ad hoc networks. PhD term paper, Chinese University of Hong Kong, 2003. [55] X. Li. Secure and Anonymous Routing in Wireless Ad-hoc Networks. Masters Thesis, Uni. of Ottawa, May 2005. [56] L. Zhou and Z. Haas. Securing ad hoc networks. IEEE Network Magazine, 13(6), November/December 1999. [57] S. Zhu, S. Xu, S. Setia, and S. Jajodia. LHAP: A light-weight hop-by-hop authentication protocol for ad-hoc networks. In Proc. of the 23rd ICDCS Workshop, 2003. [58] S. Zhu, S. Xu, S. Setia, and Z. Jajodia. Lhap: A lightweight network access control protocol for ad-hoc networks. Elsevier Ad Hoc Networks Journal, 4(5):567585, Sept. 2006. [59] T. Jiang, and J.S. Baras. Trust Evaluation in Anarchy: A Case Study on Autonomous Networks. Proceedings of the 25th Conference on Computer Communications, April 2006. [60] M. Srivatsa,L. Xiong, and L. Liu. TrustGuard: Countering vulnerabilities in reputation management for decentralized overlay networks. In International World Wide Web Conference, WWW, 2005. [61] S. D. Kamvar, M.T. Schlosser, and H. Garcia-Molina. The EigenTrust Algorithm for Reputation Management in P2P Networks. In Proceedings of WWW, 2003.

136

[62] S. Abe. Support Vector Machines for Pattern Classication (Advances in Pattern Recognition). Springer, ISBN: 1852339292, Chp 6,11, July 2005. [63] S. Ruping. SVM Kernels for Time Series Analysis. Workshop, LLWA (Lehren - Lernen Wissen - Adaptivitt), 2001. [64] I.H. Witten, and E. Frank. Data Mining: Practical machine learning tools and techniques. 2nd Edition, Morgan Kaufmann, San Francisco, 2005. [65] S. Al-Riyami, and K. Paterson. Certicateless Public Key Cryptography. Asiacrypt 2003, Lecture Notes in Computer Science, Springer-Verlag, vol 2894, pp 452-473, 2003. [66] A. Shamir. Identity based cryptosystems and signature schemes. Crypto 84, Lecture Notes in Computer Science, vol. 196, pp 47-53, Springer-Verlag, 1984. [67] T. Erl. Service-Oriented Architecture: Concepts, Technology, and Design. Upper Saddle River: Prentice Hall PTR, ISBN 0-13-185858-0, 2005. [68] R. J. Frank, N. Davey, and S.P. Hunt. Time Series Prediction and Neural Networks. Journal of Intelligent and Robotic Systems, pp 91-103, 2000. [69] C. L. Giles, S. Lawrence, and A. C. Tsoi. Noisy Time Series Prediction using a Recurrent Neural Network and Grammatical Inference. Machine Learning, Vol. 44, Number 1/2, July/August, pp 161-183, 2001. [70] F. Camastra, and M. Filippone. SVM-Based Time Series Prediction with Nonlinear Dynamics Methods. Knowledge-Based Intelligent Information and Engineering Systems, Lecture Notes in Computer Science, Springer, vol 4694, pp 300-307, 2007.

137

[71] J. Han, and M. Kamber. Data Mining: Concepts and Techniques. Morgan Kaufmann, ISBN 1558604898, pp 325-326, 2001. [72] eBay. http://www.ebay.com/ [73] Wikipedia - PageRank. http://en.wikipedia.org/wiki/Pagerank [74] J. Liu, and V. Issarny Enhanced Reputation Mechanism for Mobile Ad Hoc Networks. Lecture Notes in Computer Science, ISBN 978-3-540-21312-3, Springer-Verlag, 2004. [75] A. Josang, R. Ismail, and C. Boyd. A survey of trust and reputation systems for online service provision. Decision Support Systems, Vol. 43, Issue 2, pp 618-644, March 2007. [76] A. Josang, and R. Ismail. The beta reputation system. Proc. of the 15th Bled Electronic Commerce Conference, Slovenia, June, 2002. [77] D. Chadwick, A. Otenko, and E. Ball. Role-based access control with X.509 attribute certicates. IEEE Internet Computing, vol. 7, issue 2, pp 62-69, 2003. [78] L. Mui, M. Mohtashemi, and A. Halberstadt. A Computational Model of Trust and Reputation. In Proc. of the 35th Hawaii International Conference on System Sciences, pp 188196, 2002. [79] T. Simon, and M. Zurko. Separation of duty in role-based environments. In Proc. of the 10th Computer Security Foundations Workshop, pp 183194, IEEE Computer Society Press, June 1997.

138

[80] A. Herzberg, Y. Mass, J. Michaeli, D. Naor, and Y. Ravid. Access Control Meets Public Key Infrastructure, Or: Assigning Roles to Strangers. In Proc. of the IEEE Symposium on Security and Privacy, pp 214, Berkeley, May 2000. [81] J. S. Baras, and T. Jiang. Managing trust in self-organized mobile ad hoc networks Workshop NDSS, Extended abstract, 2005. [82] T. Jiang, and J. S. Baras. Ant-based adaptive trust evidence distribution in MANET Proc. 24th International Conference on Distributed Computing Systems, Tokyo, Japan, March, 2004. [83] S.L. Keoh, E. Lupu, and M. Sloman. PEACE : a policy-based establishment of ad-hoc communities. In Proc. of the 20th Annual Computer Security Applications Conference, 2004. [84] Y. Zhang, J. Luo, and H. Hu. Wireless mesh networking: architectures, protocols and standards. Technology and Engineering, Auerbach Publications, pp 188-189, 2006. [85] X. Su and R. V. Boppana. On the impact of noise on mobile ad hoc networks. In Proc. of ACM International Wireless Communications and Mobile Computing Conference (IWCMC), pp. 208213, 2007. [86] R. V. Boppana and X. Su. An Analysis of Monitoring Based Intrusion Detection for Ad Hoc Networks. Proc. of IEEE Globecom: Computer and Communication Network Security Symposium, 2008. [87] T. Ciszkowski, and Z. Kotulski. Secure Routing with Reputation in MANET. Chapter 28, Handbook of Research on Wireless Security, Technology and Engineering, 2008. 139

[88] S. Ganeriwal, and M. Srivastava. Reputation-based framework for high integrity sensor networks. In Proc. of the 2nd ACM workshop on Security of ad hoc and sensor networks (SASN), pp. 66-77, October 2004. [89] A. Srinivasan, J. Teitelbaum, H. Liang, J. Wu, and M. Cardei. Reputation and Trust based System for Ad Hoc and Sensor Networks. In Algorithms and Protocols for Wireless Ad Hoc and Sensor Networks, Wiley & Sons, 2006. [90] A. Srinivasan, J. Teitelbaum, and J. Wu. DRBTS: Distributed Reputation based Beacon Trust System. In the 2nd IEEE International Symposium on Dependable, Autonomic and Secure Computing (DASC), Indianapolis, USA, 2006. [91] A. Srinivasan, and J. Wu. Secure and reliable broadcasting in wireless sensor networks using multi-parent trees. Security and Communication Networks, John Wiley and Sons, pp 239-253, 2009. [92] A. Boukerche, K. El-Khatiba, L. Xua, and L. Korba. An ecient secure distributed anonymous routing protocol for mobile and wireless ad hoc networks. Computer Communications, pp 1193-1203, 2005. [93] A. Boukerche, and X. Li. An Agent-based Trust and Reputation Management Scheme for Wireless Sensor Networks. In Proc. of IEEE GLOBECOM, 2005. [94] G.C. Hadjichristo, W.J. Adams, and N.J. Davis. A framework for key management in mobile ad hoc networks. Information Technology: Coding and Computing, 2005.

140

[95] Y. Wang, and J. Vassileva. Trust and Reputation Model in Peer-to-Peer Networks In Proc. of the 3rd International Conference on Peer-to-Peer Computing (P2P), pp 150157, Sweden, Sep. 2003. [96] S. Buchegger, and J.Y.L. Boudec. A robust reputation system for P2P and mobile adhoc networks. In Proc. of the 2nd Workshop on the Economics of Peer-to-Peer Systems, Cambridge, June 2004. [97] Q. He, O. D. Wu, and P. Khosla. SORI: A Secure and Objective Reputation-based Incentive Scheme for Ad-hoc Networks. In Proc. of IEEE Wireless Comm. and Networking Conf., 2004. [98] S. Buchegger. Self-policing mobile ad hoc networks by reputation systems. IEEE Communications Magazine, pp 101-107, 2005. [99] P. Papadimitratos, and Z. Haas. Secure routing for mobile ad hoc networks. In Proc. of the SCS Communication Networks and Distributed Systems Modeling and Simulation Conference, San Antonio, 2002. [100] K. Sanzgiri, B. Dahill, B. Levine, C. Shields, and E.M. Belding-Royer. A secure routing protocol for ad hoc networks. In Proc. of 10th IEEE International Conference on Network Protocols, IEEE Press, 2002. [101] Z.G. Zapata, and N. Asokan. Securing Ad Hoc Routing Protocols. In Proc. of ACM Workshop on Wireless Security, ACM Press, 2002. [102] Y. Hu, and A. Perrig. A survey of secure wireless ad hoc routing. IEEE Security and Privacy Magazine, pp 28-39, 2004. 141

[103] C. Huang, H. Hu, and Z. Wang. A dynamic trust model based on feedback control mechanism for P2P applications. In Proc. of Third International Conference on Autonomic and Trusted Computing, 2006. [104] K. Mangipudi, R. Katti, and H. Fu. Authentication and key agreement protocols preserving anonymity. International Journal of Network Security, pp 259-270, 2006.

142

VITA

Rehan Akbani was born in Karachi, Pakistan. He studied under the British GCE system of education and achieved the best result in the history of Pakistan in his Advanced Level exams. As a result, he was awarded an undergraduate scholarship at the University of Texas at San Antonio (UTSA). He received his B.S. degree in Computer Science at UTSA in 2002. He then went on to receive his M.S. degree in 2005, and subsequently his Ph.D. in Computer Science from UTSA in 2009. His areas of research include machine learning, network security, and bioinformatics. His work has been published in renowned conferences and journals, including MILCOM, IEEE GLOBECOM, Elsevier and ECML. In future, he aims to continue conducting high class research and become a renowned gure in the research community.