A Centralized Trust-Based Efficient Routing ... - Semantic Scholar

3 downloads 0 Views 317KB Size Report
Trust-based Efficient Routing protocol for wireless sensor networks (WSN). .... interest since the authors highlight the energy saving benefits of a centralized ...
2012 Tenth Annual International Conference on Privacy, Security and Trust

CENTER: A Centralized Trust-Based Efficient Routing Protocol for Wireless Sensor Networks Ayman Tajeddine

Ayman Kayssi

Ali Chehab

Department of Electrical and Computer Engineering American University of Beirut Beirut 1107 2020, Lebanon {ast03, ayman, chehab}@aub.edu.lb Abstract — In this paper, we present CENTER, a CENtralized Trust-based Efficient Routing protocol for wireless sensor networks (WSN). CENTER is a secure and efficient routing protocol that utilizes the powerful sink base station (BS) to identify and ban different types of misbehaving nodes that may interrupt or abuse the functionality of the WSN. In CENTER, the BS periodically accumulates simple local observations of every node and deduces a detailed global view of the network. The BS calculates different quality metrics – namely the maliciousness, cooperation, and compatibility, approximates the battery life, and evaluates the Data Trust and Forwarding Trust values of each node. The BS then uses an effective technique to isolate all “bad” nodes, whether misbehaving or malicious, based on their history. Finally, the BS uses an efficient method to disseminate updated routing information, indicating the uplinks and the next hop downlink for every node. Through its centralized approach, CENTER provides more efficient and secure routing while accounting for the energy-constrained sensor nodes. We present simulation results of CENTER performed using TOSSIM to verify its correctness, security, and reliability. Keywords-component; Wireless Sensor Networks; Centralized Routing Protocol, misbehaving nodes.

I.

Trust;

INTRODUCTION

Wireless sensor network (WSN) technology has gained much attention in the past few years as it promises to improve data collection and statistical analysis [1]. However, with the severely-constrained sensor nodes, several security and energy concerns arise [2]. There are several methods to detect misbehaving nodes and provide secure routing, a critical issue in WSNs, while accounting for energy consumption and lengthening the network lifetime, another critical issue in WSNs. Among these are: reputation-based and trust-based methods [3], location isolation [4], and behavior-based techniques [5]. Reputation-based trust methods are essential to maintain secure routing and isolate misbehaving nodes; however these methods require energy-consuming inquiries from every node to its one-hop neighbors (and sometimes two-hops or farther neighbors). In addition, these methods incur additional processing overhead at sensor nodes to calculate the trust values of every neighbor. With the severely-constrained sensor nodes, it is essential to decrease the load on them to a

978-1-4673-2326-0/12/$31.00 ©2012 IEEE

minimum. It is therefore preferred to delegate these calculations and inquiries to a more powerful network entity. Most WSNs contain a sink node that is connected to AC power and usually possesses much higher processing and energy capabilities than the sensor nodes. The main function of this sink node is to gather the readings from the different sensors and make use of them in the way that the WSN was intended for. As a result, and with the knowledge that in a WSN all nodes have the same trust criteria – trust in correct routing of packets, we utilize in this paper the centralized approach and delegate the trust and reputation inquiries and calculations and the routing computations to this sink BS. An inherent benefit that is gained from this approach is that the BS has a global view of the network, which yields more trusted and correct routing information. We therefore present CENTER, based on our two previous schemes in [6] and [7], as a CENtralized Trust-based Efficient Routing protocol for WSNs. Utilizing the centralized approach, CENTER uses the more powerful and more knowledgeable BS to provide a more trusted network environment with more efficient and secure routing paths, while decreasing the load on the severely-constrained sensor nodes. In CENTER, the sink BS periodically gathers observations from the individual nodes about the number of packets sent through neighbors and then, it performs several checks and calculations to have a better and more accurate view of the network. Furthermore, the BS approximates the battery life of every node based on its presumed activity and calculates several quality metrics for every node, namely the maliciousness, cooperation, and competence levels. Then, the BS evaluates two trust values for each node – namely Data Trust and Forwarding Trust. Following the quality metrics calculations, the BS is able to detect several types of “bad” nodes: a malicious node sending false or illogical information, a non-cooperative node not reliably forwarding the packets of other nodes, or a malfunctioning/malicious node broadcasting packets. The bad nodes are isolated for a period of time that depends on their history. In addition to bad nodes, the BS can detect incompetent nodes that are unable to correctly deliver packets to it due to different non-malicious reasons. The BS will avoid

195

these nodes in the routing paths as they severely affect the network functionality, without punishing them. Finally, the BS uses an efficient method to disseminate updated routing information to all the network nodes such that each node knows its uplink nodes to forward their packets to the BS, and its next hop downlink node to forward its own packets through it. CENTER provides a trust-based routing protocol while accounting for the severely-constrained sensor nodes batteries and preserving energy in the presence of misbehaving nodes by detecting and isolating them. CENTER eliminates the power-consuming reputation inquiries and computations required by a distributed approach; nodes are required to send minimal additional information, namely their next hop and a signle counter (s_counter), showing the number of packets sent through and forwarded by this next hop. The rest of the paper is organized as follows: Section 2 surveys the previous work in the area of trust-based routing protocols in WSNs. Section 3 presents CENTER, with the corresponding definitions and parameters. The simulationbased verification using TOSSIM is presented in Section 4. Finally, Section 5 presents some conclusions and future work. II.

PREVIOUS WORK

Wireless sensor networking is a valuable technology to observe and perceive data from the physical world and has an important role in pervasive computing. However, these benefits come with several limitations, vulnerabilities, and risks. Sensor nodes are severely constrained in memory, processing power, and energy resources; and due to their wireless communication and open deployments, they are prone to several security attacks. In this section, we will review the literature related to WSN trust and security. The authors of [1] explain the difference between sensor networks and traditional wireless ad-hoc networks. For each layer of the protocol stacks, they survey the different issues and technologies for the sensor networks and provide the available solutions for each. Also, they highlight the open research issues at each layer. The authors of [8] discuss the challenges in designing a routing protocol for wireless sensor networks and provide a survey of the different available routing techniques. They classify the techniques based on the network structure as flat, hierarchical, or location-based; and based on the protocol operation as query-based, multipath-based, quality-of-servicebased, coherent-based, and negotiation-based. For every routing technique, they state its advantages and shortcomings and study the energy and communication overhead tradeoffs. The authors of [2] consider routing security. They discuss the different attacks and present countermeasures. They analyze the security of the major routing protocols and energyconserving topology maintenance algorithms for sensor networks. They explain how attacks can be adapted from peerto-peer and ad-hoc networks into sensor networks, and present two new attacks: sink holes and HELLO floods. An energy-efficient routing technique is discussed in [9], where the authors develop and evaluate many techniques to enhance routing based either on energy histograms or solely

on localization. They show the network lifetime gains for each technique. Several methods are available to detect misbehaving nodes, to lengthen the network lifetime, and to decrease energy consumption while providing secure routing; among these are: reputation- and trust-based methods [3, 10], location isolation [4], and behavior-based techniques [5]. The authors in [10] explain the difference between sensor networks and traditional mobile ad-hoc networks and survey several trust-based systems in wireless sensor networks. They provide different trust definitions and properties as defined in the literature and state that the definition is applicationspecific and depends on the methods used to calculate the trust value. They extend the definition of trust to include the sensor data and reliability as a new component and introduce a new trust model that is believed, as per the authors, “to be very robust as it addresses all the drawbacks from the existing approaches.” The authors in [11] differentiate the security requirements between WSNs and other networks. They present iTrust, which depends on the presence of monitor nodes to assess the behavior of their neighbors and distribute the trust indices after each session. The authors evaluate their model and show its robustness against different attack scenarios. Trust models are surveyed in [12]. The author explains the difference between security and trust and between reputation and trust. He surveys the methodologies and factors used in the different trust models and states that in wireless sensor networks it is not enough to examine routing messages to infer trust; new methods are needed to calculate both communication trust and data trust while keeping in mind that data is sometimes continuous. In [13] the authors present a security survey on WSNs. They first target the network layer and identify the vulnerabilities and summarize the different defense methods at this protocol layer. Then, they divide the general security issues into seven categories, namely: cryptography, key management, attack detections and preventions, secure routing, location security, secure data fusion, and others. In this division, they summarize the different techniques used and point out their pros and cons. The authors in [14] assure that trust is an important factor for WSN security schemes and provide a detailed study on trust mechanisms and attacks and countermeasures. They provide a categorization of all trust-related attacks in WSNs. Also, they analyze the different trust schemes and illustrate the differences and challenges of each. In their work, they provide an extensive literature survey of trust mechanisms used in WSNs and they present open research directions. In [15] the authors focus on the energy limitations of the sensor nodes and propose a centralized energy-efficient routing protocol for WSNs to reduce energy consumption and thus, increase network lifetime. Their protocol, called BaseStation Controlled Dynamic Clustering Protocol (BCDCP), increases network lifetime and average energy savings by evenly spreading the energy dissipation among all nodes. Although this work does not target trust or security, it is of interest since the authors highlight the energy saving benefits of a centralized routing scheme.

196

Figure 1. Different Message Formats

All of the surveyed papers focus on distributed methods to calculate trust and reputation and to provide security for the wireless sensor network. However, we find it more logical to utilize the centralized approach in a WSN and make use of the more powerful BS to perform these calculations and lessen the burden of the power-consuming reputation inquiries and computations on the sensor nodes. III.

the Activity Report Accumulation block is initiated for the node to know its downlink. TABLE I.

CENTER: TRUST BASED ROUTING PROTOCOL

Based on our previous work, TRACE [7], the proposed CENTER implements a secure trust-based routing protocol for WSNs placing almost the entire processing load on the more powerful sink BS. Having the global view of the network, the BS is responsible for the reputation and trust calculations, bad node isolation, and routing information distribution, while taking into account the energy requirements of the severely constrained network nodes. CENTER is divided into several functional building blocks to ensure a trusted and efficient sensor network environment. A. Neighbor Discovery Block Initially, on network bootstrapping or with the introduction of a new node, Neighbor Discovery is activated. In this phase, every node broadcasts a one-hop hello message having the following format – {Message Type = 1 [one byte], Sender ID [one or two bytes]} as shown in Figure 1. Upon receipt of the hello message, each node within range, adds the Sender ID to its neighbors list and sends (unicasts) a hello reply packet back to the original sender. The hello reply message has the same format as the hello message with the Message Type = 2. B. Node Observations Block After the neighborhood introductions, each node keeps a neighbor activity table containing each neighbor node ID and a counter value (s_counter) keeping track of all the packets it sent through this specific neighbor. Also, this table contains a flag identifying the uplink (UL) nodes and downlink (DL) node, extracted from the path fragment message sent by the BS (explained shortly). Note that a node sends its packets to the BS only through its DL node and drops any packet received from a node other that its UL nodes. A Node Neighbor Activity Table is shown with some example values in Table I. However, before the Node Observations block can be initiated and every node can start forwarding its data to the BS,

NODE NEIGHBOR ACTIVITY TABLE AT NODE X Node

s_counter

UL

DL

Node Y Node Z Node U Node V

30 0 0 0

No Yes Yes No

Yes No No No

C. Activity Report Accumulation Block The Activity Report Accumulation block, which is initiated periodically, requires every node to send its activity report containing its neighbor nodes and their corresponding s_counter values, which indicate the number of packets forwarded through them towards the BS. Note that the time period of sending this activity report is a network parameter that must be chosen to be of the order of several magnitudes larger than the period of sending a normal packet containing readings to the BS. To ensure proper receipt at the BS, each node sends its activity report through its next hop neighbor, and listens to that next hop for a time t_timeout (a time chosen higher but comparable to the node’s time to process and transmit a packet) in order to make sure that the latter has in fact forwarded its packet. If the next hop fails to forward the packet during the timeout interval, the node broadcasts its activity report through all of its neighbors. Every receiving node will send the packet normally through its next hop and performs a similar action. Note that the overhead incurred is justified in two folds. The first is to assure that the activity report reaches the BS which is an essential part of CENTER. The second is to help the BS locate and punish the uncooperative nodes. Also note that the broadcasting will not occur frequently in all the nodes, since bad nodes not correctly performing their jobs in sending/forwarding activity reports will eventually be isolated. The nodes’ activity report, shown in Figure 1, has the following format – {Message Type = 11 [one byte], Sender ID [one or two bytes], Message Number [one byte], Total Neighbors [one byte], MESSAGE [(twice the number of neighbors) bytes]}. The message number is needed for nodes to drop multiple copies of the same packet (in case of

197

broadcasting). The message contains each neighbor ID followed by its corresponding s_counter. Initially the s_counters are set to zero. Note that a node does not send normal reading packets until it receives its UL nodes and its next hop DL node from the BS. D. Nodes Attributes and Quality Metrics Calculations Block After the BS collects the activity reports of all the nodes, the Nodes Attributes and Quality Metrics Calculations block is initiated. The BS validates the activity reports from all the nodes and assesses the values of the counters using its estimated knowledge about: (1) the frequency of sending packets by a node, and comparing this value to the number of packets sent by this node through all its neighbors during the time since the last report was received, and (2) the number of events causing a node to send a packet and comparing this number to the total number of packets sent by this node (this is estimated from the received events from all the nodes in the network). The sink BS also verifies that the neighbors of a node are in fact its neighbors since the BS has the full topology of the network, constructed from the messages received. The BS then compares the readings received within other messages from other nodes to check their correctness. If the packet is considered bad, i.e. the counter is falsely manipulated by the source or the readings are not logically correct, the sink BS disregards the packet and does not include these counters in its calculations. The BS then approximates the battery life of every node based on its estimated activity and calculates the different quality metrics for each. Note that all the quality metrics assume values between 0 and 1. The maliciousness is calculated based on the ratio of the bad packets to the total packets received, as follows:

Using information from all the good packets it received, the sink BS calculates the competence and cooperation of all the WSN nodes. The competence shows the ability of a node to properly deliver a packet to the sink BS and is calculated as the ratio of the packets received by the BS to the packets sent by the node, as follows:

where the count of packets sent by a node is calculated using its s_counters, which can be checked against the s_counters of the downlink nodes. The cooperation shows the willingness of a node N to cooperate and forward packets sent by others towards the sink BS. Cooperation is calculated as the weighted ratio of the number of packets sent by the ULs of N, through N, out of the total number of packets sent by those ULs, as follows: ∑



Note that a is the weight of each uplink node, (inversely) related to its maliciousness, as follows: 1 The sink BS then calculates two trust values for each node: a Data Trust value and a Forwarding Trust value. The Data Trust of a node is an indication of the benign nature of the packets of this node. It is calculated based on the maliciousness of the node while taking into account the cooperation value (in order to force nodes to cooperate in order to increase their Data Trust). Data Trust assumes values between 0 and 1 and is calculated as follows: 1 The Forwarding Trust of a node is an indication of the trust in a node’s ability to forward a packet and being confident that the packet will be delivered successfully to the sink BS. The Forwarding Trust is calculated based on the approximated battery level and the competence values of a node, as follows:

E. Bad Nodes Isolation Block After calculating the quality metrics and trust values for all nodes, the Bad Nodes Isolation block is initiated. This block utilizes an effective and efficient method to isolate the different types of bad nodes as follows: Malicious nodes are nodes that send bad packets, whether corrupt or with malicious intent, to the BS. If such nodes send at least one bad packet during the last period, they are punished by being banned from the network for a period of time, as shown below. Uncooperative nodes are nodes that are not cooperating, i.e. not forwarding their neighbors packets. The BS can detect such nodes by comparing the cooperation level to the actual capability which is inferred from the competence level. If the cooperation of a node is less that its competence, this node is not serving others as it is serving itself. Such a node can severely degrade the network functionality and thus should be punished by being banned from the network, as shown below. Nodes broadcasting packets that are gibberish. These nodes have the intention to degrade the network performance; however in CENTER they are not able to affect the system because their packets will be dropped anyway by all their neighbors that are not their assigned DL nodes, as determined by the BS. CENTER thus provides an implicit defense against such an attack. The detected bad nodes, namely the first two types explained above, are punished by being isolated from the network. The bad node is isolated for a number of periods, calculated based on its Data Trust value and its behavioral history. The lower its Data Trust, the more periods the node is banned. The behavioral history is memorized by the BS by keeping a record of the number of times the node has been

198

previously found bad. Every time a node is banned from the system, the number of periods is incremented. F. Basic Routing Block With the bad nodes isolated from the network, the BS starts the Basic Routing phase to find the shortest path for every node towards itself. In this phase, the BS performs Dijkstra’s Algorithm on the set of remaining unbanned nodes using the Forwarding Trust value as the weight for each. From Dijkstra’s results, the BS discovers the best route that each node must use to reach it. Thus it sets the next hop DL neighbor that each node uses to send packets to the BS, and the UL neighbors that are solely allowed to send their packets through this node to the BS. From the point of view of the BS, each node is designated a single DL node and any number of UL nodes (if any). In this block, the BS sets the full active topology of the network, namely the paths and the routes that packets will traverse from all nodes. G. Routing Information Dissemination Block Finally, the Routing Information Dissemination block is initiated to distribute the routing information to the network sensor nodes. In order to disseminate the information efficiently, we minimize duplicate information sent over the nodes. This is done by calculating the path fragments in the WSN. Note that a path fragment is a path or a set of adjacent nodes in the network without any bisection. The BS uses the active topology set in the Basic Routing block and determines the full path from every node to reach it. These paths are very likely to contain overlapping and redundant information, which if sent without any optimization will highly degrade the protocol efficiency. Therefore, the BS deduces from the full paths the list of all the path fragments overlapping by a maximum of one node. These path fragments contain a part of the path from any node towards the BS, without necessarily reaching it. Note that together all the path fragments contain the total information to constitute the full network topology from any node towards the BS. Every fragment is uniquely numbered by the BS. This way the overhead of the update messages transmitted through the sensor nodes is decreased to a minimum. The path fragments, shown in Figure 1, have the following format – {Message Type = 21 [one byte], Path Number [one byte or two bytes], Path Intersection [one byte of the form path.node], Total Number [one byte or two bytes], List of N Nodes [N or 2N bytes] } The path number is the unique number that the BS gives to each path, and the path intersection has the format path.node specifying to which node of which path is the current path connected to. The total number specifies the number of nodes in the current path. When a node receives a path fragment, it may encounter three cases: a.

If the node finds itself to be part of the path, it saves the path number together with its location in the current path

and the uplink node for that path. In addition, it performs the following: i. it sets its next hop as the previous location node in the path fragment ii. it adds to its uplink neighbors the next location node in the path fragment iii. it forwards the packet to the next location node in the path fragment b. If the node finds itself to be the intersection byte node (path.node = itself) i. it adds the new path number to the paths it belongs to, together with the uplink to reach that path (in case there were more paths fragmenting from that path) ii. it adds to its uplink neighbors the next location node in the path fragment iii. it forwards the packet to the next location node in the path fragment c. If the node is not part of the path and it is not itself the intersection node, it checks if it has previously saved the path in the intersection node (path.node). This case occurs when a further-away path fragment is sent through the preceding distributed fragments from the BS; in other words, a closer node to the BS will not appear in the farther path fragment even though it is part of the full path. i. The node adds the new path number to the paths it belongs to, together with the uplink to reach that path (in case there were more paths fragmenting from that path) ii. it forwards the packet to its uplink neighbor to reach the path in the intersection node (path.node) – this uplink neighbor is saved from a previous packet From this point on and until the next path fragment message, every node sends its periodic reading only through its next hop neighbor and forwards only the packets of its designated uplink neighbors as instructed by the BS. IV.

SYSTEM SIMULATION

A. Simulation Setup In order to evaluate CENTER and prove its correctness in providing routing information while creating a trusted environment and isolating the bad nodes, we used the TOSSIM simulator to simulate a grid of micaz sensors running TinyOS [16] in a 7-by-7 grid network. The network topology is shown in Figure 2a. Note that the network topology is a logical grid and the distances separating two nodes depict radio ranges and not necessarily physical distances. A link is shown between two nodes within radio range of each other. Figure 2b shows an example of how the nodes may be distributed physically in space with distances between them representing actual physical distances.

199

1

2

3

4

5

6

7

1

2

3

4

5

6

7

8

9

10

11

12

13

14

8

9

10

11

12

13

14

15

16

17

18

19

20

21

15

16

17

18

19

20

21

22

23

24

26

27

28

22

23

24

26

27

28

29

30

31

32

33

34

35

29

30

31

32

33

34

35

36

37

38

39

40

41

42

36

37

38

39

40

41

42

43

44

45

46

47

48

49

43

44

45

46

47

48

49

Figure 2a. Wireless Sensor Network Topology.

9

15

43

17

11 18

37

44

31 38

45

6

12 19 26

24

30 36

10

16

23

29

5

2

8

22

4

3

1

32

39 46

33 40

47

13 20

Figure 3. The Initial Routing Paths.

1

2

3

4

5

6

7

14

8

9

10

11

12

13

14

21

15

16

17

18

19

20

21

22

23

24

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

7

27

34

28 35

41 48

42 49

Figure 2b. Spatial Network Topology (An Example).

Figure 4. The Updated Routing Paths.

In the network shown we assigned several bad nodes as follows: Node 4 is a totally malicious node always sending bad packets towards the BS, while node 10 is partially malicious sending 1 bad packet every three packets it sends. Also node 20 is a totally non-cooperative node dropping all the packets forwarded through it, and node 38 is partially noncooperative dropping 1 out of every 3 packets forwarded through it. Node 23 is a node broadcasting packets through all of its neighbors and informing the BS through its Activity Report about this. In addition, we introduced node 33 as partially uncooperative and partially malicious, and node 41 as totally uncooperative and totally malicious. Note that the positions of these nodes are distributed evenly in the network.

with various symbols indicating their classification. For example, node 20 is not forwarding the packets of 6 and 13 at all; whereas node 38 is partially forwarding the packets of nodes 36 and 37. TABLE II.

B. Simulation Results Initially, the different blocks of CENTER execute correctly and the BS is able to create shortest paths routing information and distribute such information to the different nodes. Figure 3 shows the network initial routing paths for the different network nodes. Note that the various bad nodes are highlighted

200

DIFFERENT VALUES OF NODE 10 AT SINK BS EVERY PERIOD

Trust Report Number

0

1

2

3

4

5

6

7

Received at Sink Bad Received Maliciousness Competence Cooperation Forwarding Trust Data Trust Banned Periods Banned So Far

0 1

4 2 0.5 1 1 1 0.5 5 2

0 0 4 2

0 0 3 2

0 0 2 2

0 0 1 2

4 2 0.5 1 1 1 0.5 10 2

9 3

Node 23 is trying to broadcast packets through nodes 16, 22, 24, and 30, either due to a malfunction or in order to disrupt the whole network. However, it is clear how CENTER forced nodes 16, 22, and 30 to drop the packets from 23 because they are not the DL node of node 23 as indicated by the BS. Only node 24 is forwarding the packets of node 23. Thus we can directly see the first benefit of CENTER in preventing broadcast storms that can increase the noise levels in the network and affect the network functionality and lifetime. After the first time period, each node starts acting per its nature. This directly gets reflected in the routing paths that now avoid the bad nodes. It is clear in Figure 4 how the routing paths are updated to avoid the bad nodes and pass only through “good” nodes. So, all of the bad nodes are isolated and no other node is forwarding their packets. As an example, we look at the different values of node 10 and node 38 at the sink BS and show how the banning period of each is changing with every period. Table II shows the different values of the partiallymalicious node 10 at the BS. We notice that in the first period, the BS received 4 packets from node 10, two of which are malicious. This produces a maliciousness level and a Data Trust value of 0.5. Because this is the first time that node 10 misbehaves, the BS isolates node 10 for 5 periods only. In the 6th period, node 10 was given another opportunity to interact with its surroundings again. However, node 10 behaves exactly the same as the first time. So this time and because the Data Trust value is still 0.5, the BS bans it for 10 periods, that is twice as much as the first time. An example of a partially-uncooperative node is node 38. Table III shows its different values for every period as calculated at the BS. In the first period the cooperation level of node 38 is 0.5. So, similar to the previous reasoning for node 10, the BS isolates it for 5 periods. In its second chance to prove itself worthy, in the 6th period, node 38 got a cooperation value and a Data Trust value of 0.25. Based on the banning algorithm, it is banned for 14 periods this time. V.

CONCLUSIONS AND FUTURE WORK

In this paper, we presented CENTER as a centralized trustbased efficient routing protocol for wireless sensor networks which periodically send readings and sensed data to a powerful sink BS. CENTER provides secure routing and a trusted network where the bad nodes are isolated and their attacks eliminated. We classified four different types of bad nodes – namely malicious, incompetent, non-cooperative, and broadcasting nodes that affect the routing functionality of the network. CENTER utilizes the centralized approach, where the more powerful BS periodically accumulates simple counter observations from the sensor nodes and decides on the network topology and routes, and isolates the bad nodes. The BS calculates several quality metrics and two trust levels of each node and uses an effective banning system to isolate the different bad nodes from the network. Also, CENTER uses a very efficient method to distribute the routing information to every node. The nodes only forward through their next hop DL neighbor and forward the packets of their UL neighbors, as indicated to them by the BS, and drop any other packet.

TABLE III.

DIFFERENT VALUES OF NODE 38 AT SINK BS EVERY PERIOD

Trust Report Number

0

1

2

3

4

5

6

7

Received at Sink Bad Received Maliciousness Competence Cooperation Forwarding Trust Data Trust Banned Periods Banned So Far

0 1

4 0 0 1 0.5 1 0.5 5 2

0 0 4 2

0 0 3 2

0 0 2 2

0 0 1 2

4 0 0 1 0.25 1 0.25 14 2

0 0 13 3

We simulated CENTER using TinyOS and proved its correctness in providing secure routing information through trusted paths. Also, in CENTER, bad nodes were isolated for a specific time depending on their history, and then given another chance to try to improve. Our future work will consider more complex yet effective improvements for the detection of uncooperative nodes and their differentiation from bad nodes that fake their counter values. These improvements will take place in the Activity Report Accumulation block and the Bad Node Isolation block. In addition, we will introduce an authentication block to defend against more complex attacks such as node impersonation. We will also perform scalability tests by extending the simulations to include larger WSN grid sizes. ACKNOWLEDGEMENT The authors acknowledge the support of the Lebanese National Council for Scientific Research. REFERENCES [1]

I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “A Survey on Sensor Networks,” IEEE Communications Magazine, pp. 102-114, 2002. [2] C. Karlof and D. Wagner, “Secure routing in wireless sensor networks: attacks and countermeasures,” Ad Hoc Networks, pp. 293-315, 2003. [3] A. Srinivasan, J. Teitelbaum, H. Liang, J. Wu, and M. Cardei, “Reputation and Trust-based Systems for Ad Hoc and Sensor Networks,” Algorithms and Protocols for Wireless Ad Hoc and Sensor Networks, 2006. [4] S. Tanachaiwiwat, P. Dave1, R. Bhindwale, and A. Helmy, “Locationcentric Isolation of Misbehavior and Trust Routing in Energyconstrained Sensor Networks,” in Proc. EWCN’04, in conjunction with IEEE IPCCC, 2004. [5] L. Huang, L. Li, and Q. Tan, ‘‘Behavior-Based Trust in Wireless Sensor Network,’’ in Proc. APWeb Workshops, LNCS 3842, pp. 214-223, 2006. [6] A. Tajeddine, A. Kayssi, A. Chehab, “A Centralized Energy-Aware Trust-Based Routing Scheme for Wireless Sensor Networks,” in Proc. First Annual International Conference on Energy Aware Computing (ICEAC), December 16-18, 2010, Cairo, Egypt. [7] A. Tajeddine, A. Kayssi, and A. Chehab, “TRACE: A Centralized Trust and Competence-Based Energy-Efficient Routing Scheme for Wireless Sensor Networks,” in Proc. IEEE International Wireless Communications and Mobile Computing Conference (IWCMC 2011), July 5-8, 2011, Istanbul, Turkey. [8] J. Al-Karaki and A. Kamal, “Routing Techniques in Wireless Sensor Networks: A Survey,” IEEE Wireless Communications, pp. 6-28, 2004. [9] C. Schurgers and M. Srivastava, “Energy Efficient Routing in Wireless Sensor Network,” MILCOM'01, pp. 357-361, 2001, Vienna, VA. [10] M. Momani, S. Challa, K. Aboura, “Modelling Trust in Wireless Sensor Networks from the Sensor Reliability Prospective,” Innovative

201

Algorithms and Techniques, Industrial Electronics and Telecommunications, pp. 317-321, 2007. [11] K. Yadav and A. Srinivasan, "iTrust: An Integrated Trust Framework for Wireless Sensor Networks," in Proceedings of the 2010 ACM Symposium on Applied Computing, 2010, pp. 1466-1471. [12] M. Momani, "Trust Models in Wireless Sensor Networks: A Survey," Recent Trends in Network Security and Applications, pp. 37-46, 2010. [13] X. Chen, K. Makki, K. Yen, and N. Pissinou, “Sensor Network Security: A Survey,” IEEE Communications Surveys & Tutorials, Vol. 11, No. 2,

Second Quarter, pp. 52-73, 2009. [14] Y. Yu, K. Li, W. Zhou, P. Li, “Trust mechanisms in wireless sensor networks: Attack analysis and countermeasures,” Journal of Network Computer Applications (2011), doi:10.1016/j.jnca.2011.03.005 [15] S. Muruganathan, D. Ma, R. Bhasin, and A. Fapojuwo, “A Centralized Energy-Efficient Routing Protocol for Wireless Sensor Networks,” IEEE Radio Communications, pp. S8-S13, March 2005. [16] TinyOS homepage: http://www.tinyos.net/

202

Suggest Documents