IEEE TRANSACTIONS ON DEPENDABLE AND …weisong/papers/zhan11-tarf.pdfIEEE TRANSACTIONS ON DEPENDABLE...

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING 1

Design and Implementation of TARF: ATrust-Aware Routing Framework for WSNs

Guoxing Zhan, Weisong Shi, Senior Member, IEEE, and Julia Deng

Abstract—The multi-hop routing in wireless sensor networks (WSNs) offers little protection against identity deception through replayingrouting information. An adversary can exploit this defect to launch various harmful or even devastating attacks against the routingprotocols, including sinkhole attacks, wormhole attacks and Sybil attacks. The situation is further aggravated by mobile and harshnetwork conditions. Traditional cryptographic techniques or efforts at developing trust-aware routing protocols do not effectively addressthis severe problem. To secure the WSNs against adversaries misdirecting the multi-hop routing, we have designed and implementedTARF, a robust trust-aware routing framework for dynamic WSNs. Without tight time synchronization or known geographic information,TARF provides trustworthy and energy-efficient route. Most importantly, TARF proves effective against those harmful attacks developedout of identity deception; the resilience of TARF is verified through extensive evaluation with both simulation and empirical experimentson large-scale WSNs under various scenarios including mobile and RF-shielding network conditions. Further, we have implemented alow-overhead TARF module in TinyOS; as demonstrated, this implementation can be incorporated into existing routing protocols withthe least effort. Based on TARF, we also demonstrated a proof-of-concept mobile target detection application that functions well againstan anti-detection mechanism.

✦

1 INTRODUCTION

Wireless sensor networks (WSNs) [2] are ideal can-didates for applications to report detected events ofinterest, such as military surveillance and forest firemonitoring. A WSN comprises battery-powered senornodes with extremely limited processing capabilities.With a narrow radio communication range, a sensornode wirelessly sends messages to a base station viaa multi-hop path. However, the multi-hop routing ofWSNs often becomes the target of malicious attacks.An attacker may tamper nodes physically, create trafficcollision with seemingly valid transmission, drop ormisdirect messages in routes, or jam the communicationchannel by creating radio interference [3]. This paperfocuses on the kind of attacks in which adversariesmisdirect network traffic by identity deception throughreplaying routing information. Based on identity decep-tion, the adversary is capable of launching harmful andhard-to-detect attacks against routing, such as selectiveforwarding, wormhole attacks, sinkhole attacks and Sybilattacks [4].

As a harmful and easy-to-implement type of attack, amalicious node simply replays all the outgoing routingpackets from a valid node to forge the latter node’s iden-tity; the malicious node then uses this forged identity toparticipate in the network routing, thus disrupting the

• G. Zhan and W. Shi are with the Department of Computer Science, WayneState University, Detroit, MI, 48202.E-mail: [email protected], [email protected].

• J. Deng is with Intelligent Automation Inc., Rockville, MD 20855.Email: [email protected].

This work is in part supported by AFRL contract FA8650-10-C-1740 andNSF Career Award CCF-0643521. We also would like to thank the programmanager Mr. John Woods for his great support as well as the anonymousreviewers for their constructive comments and suggestions.

network traffic. Those routing packets, including theiroriginal headers, are replayed without any modification.Even if this malicious node cannot directly overhear thevalid node’s wireless transmission, it can collude withother malicious nodes to receive those routing packetsand replay them somewhere far away from the originalvalid node, which is known as a wormhole attack [5].Since a node in a WSN usually relies solely on thepackets received to know about the sender’s identity,replaying routing packets allows the malicious node toforge the identity of this valid node. After “stealing” thatvalid identity, this malicious node is able to misdirectthe network traffic. For instance, it may drop packetsreceived, forward packets to another node not supposedto be in the routing path, or even form a transmissionloop through which packets are passed among a fewmalicious nodes infinitely. It is often difficult to knowwhether a node forwards received packets correctly evenwith overhearing techniques [4]. Sinkhole attacks are an-other kind of attacks that can be launched after stealinga valid identity. In a sinkhole attack, a malicious nodemay claim itself to be a base station through replayingall the packets from a real base station [6]. Such a fakebase station could lure more than half the traffic, creatinga “black hole”. This same technique can be employed toconduct another strong form of attack - Sybil attack [7]:through replaying the routing information of multiplelegitimate nodes, an attacker may present multiple iden-tities to the network. A valid node, if compromised, canalso launch all these attacks.

The harm of such malicious attacks based on thetechnique of replaying routing information is furtheraggravated by the introduction of mobility into WSNsand the hostile network condition. Though mobility isintroduced into WSNs for efficient data collection and


various applications [8], [9], [10], [11], it greatly increasesthe chance of interaction between the honest nodesand the attackers. Additionally, a poor network connec-tion causes much difficulty in distinguishing betweenan attacker and a honest node with transient failure.Without proper protection, WSNs with existing routingprotocols can be completely devastated under certain cir-cumstances. In an emergent sensing application throughWSNs, saving the network from being devastated be-comes crucial to the success of the application.

Unfortunately, most existing routing protocols forWSNs either assume the honesty of nodes and focuson energy efficiency [12], or attempt to exclude unau-thorized participation by encrypting data and authen-ticating packets. Examples of these encryption and au-thentication schemes for WSNs include TinySec [13],Spins [14], TinyPK [15], and TinyECC [16]. Admittedly, itis important to consider efficient energy use for battery-powered sensor nodes and the robustness of routingunder topological changes as well as common faultsin a wild environment. However, it is also critical toincorporate security as one of the most important goals;meanwhile, even with perfect encryption and authen-tication, by replaying routing information, a maliciousnode can still participate in the network using anothervalid node’s identity. The gossiping-based routing proto-cols offer certain protection against attackers by selectingrandom neighbors to forward packets [17], but at aprice of considerable overhead in propagation time andenergy use.

In addition to the cryptographic methods, trust andreputation management has been employed in genericad hoc networks and WSNs to secure routing protocols.Basically, a system of trust and reputation managementassigns each node a trust value according to its pastperformance in routing. Then such trust values are usedto help decide a secure and efficient route. However,the proposed trust and reputation management systemsfor generic ad hoc networks target only relatively pow-erful hardware platforms such as laptops and smart-phones [18], [19], [20], [21]. Those systems can not beapplied to WSNs due to the excessive overhead forresource-constrained sensor nodes powered by batteries.As far as WSNs are concerned, secure routing solutionsbased on trust and reputation management rarely ad-dress the identity deception through replaying routinginformation [22], [23]. The countermeasures proposed sofar strongly depends on either tight time synchronizationor known geographic information while their effective-ness against attacks exploiting the replay of routinginformation has not been examined yet [4].

At this point, to protect WSNs from the harmfulattacks exploiting the replay of routing information, wehave designed and implemented a robust trust-awarerouting framework, TARF, to secure routing solutions inwireless sensor networks. Based on the unique character-istics of resource-constrained WSNs, the design of TARFcenters on trustworthiness and energy efficiency. Though

TARF can be developed into a complete and indepen-dent routing protocol, the purpose is to allow existingrouting protocols to incorporate our implementation ofTARF with the least effort and thus producing a secureand efficient fully-functional protocol. Unlike other se-curity measures, TARF requires neither tight time syn-chronization nor known geographic information. Mostimportantly, TARF proves resilient under various attacksexploiting the replay of routing information, which isnot achieved by previous security protocols. Even understrong attacks such as sinkhole attacks, wormhole attacksas well as Sybil attacks, and hostile mobile networkcondition, TARF demonstrates steady improvement innetwork performance. The effectiveness of TARF is ver-ified through extensive evaluation with simulation andempirical experiments on large-scale WSNs. Finally, wehave implemented a ready-to-use TARF module withlow overhead, which as demonstrated can be integratedinto existing routing protocols with ease; the demon-stration of a proof-of-concept mobile target detectionprogram indicates the potential of TARF in WSN appli-cations.

We start by stating the design considerations of TARFin Section 2. Then we elaborate the design of TARFin Section 3, including the routing procedure as wellas the EnergyWatcher and TrustManager components. InSection 4, we present the simulation results of TARFagainst various attacks through replaying routing in-formation in static, mobile and RF-shielding conditions.Section 5 further presents the implementation of TARF,empirical evaluation at a large sensor network and aresilient proof-of-concept mobile target detection appli-cation based on TARF. Finally, we discuss the relatedwork in Section 6 and conclude this paper in Section 7.

2 DESIGN CONSIDERATIONS

Before elaborating the detailed design of TARF, wewould like to clarify a few design considerations first,including certain assumptions in Section 2.1 and thegoals in Section 2.3.

2.1 Assumptions

We target secure routing for data collection tasks, whichare one of the most fundamental functions of WSNs. Ina data collection task, a sensor node sends its sampleddata to a remote base station with the aid of other inter-mediate nodes, as shown in Figure 1. Though there couldbe more than one base station, our routing approach isnot affected by the number of base stations; to simplifyour discussion, we assume that there is only one basestation. An adversary may forge the identity of any legalnode through replaying that node’s outgoing routingpackets and spoofing the acknowledgement packets,even remotely through a wormhole.

Additionally, to merely simplify the introduction ofTARF, we assume no data aggregation is involved.


Node

Base station

Fig. 1. Multi-hop routing for data collection of a WSN.

Nonetheless, our approach can still be applied to cluster-based WSNs with static clusters, where data are aggre-gated by clusters before being relayed [24]. Cluster-basedWSNs allows for the great savings of energy and band-width through aggregating data from children nodes andperforming routing and transmission for children nodes.In a cluster-based WSN, the cluster headers themselvesform a sub-network; after certain data reach a clusterheader, the aggregated data will be routed to a basestation only through such a sub-network consisting ofthe cluster headers. Our framework can then be appliedto this sub-network to achieve secure routing for cluster-based WSNs. TARF may run on cluster headers onlyand the cluster headers communicate with their childrennodes directly since a static cluster has known relation-ship between a cluster header and its children nodes,though any link-level security features may be furtheremployed.

Finally, we assume a data packet has at least thefollowing fields: the sender id, the sender sequencenumber, the next-hop node id (the receiver in this one-hop transmission), the source id (the node that initiatesthe data), and the source’s sequence number. We insistthat the source node’s information should be includedfor the following reasons because that allows the basestation to track whether a data packet is delivered. Itwould cause too much overhead to transmit all the one-hop information to the base station. Also, we assume therouting packet is sequenced.

2.2 Authentication Requirements

Though a specific application may determine whetherdata encryption is needed, TARF requires that the pack-ets are properly authenticated, especially the broadcastpackets from the base station. The broadcast from thebase station is asymmetrically authenticated so as toguarantee that an adversary is not able to manipulate orforge a broadcast message from the base station at will.Importantly, with authenticated broadcast, even withthe existence of attackers, TARF may use TrustManager(Section 3.4) and the received broadcast packets aboutdelivery information (Section 3.2.1) to choose trustwor-thy path by circumventing compromised nodes. Withoutbeing able to physically capturing the base station, it isgenerally very difficult for the adversary to manipulate

the base station broadcast packets which are asymmet-rically authenticated. The asymmetric authentication ofthose broadcast packets from the base station is crucial toany successful secure routing protocol. It can be achievedthrough existing asymmetrically authenticated broadcastschemes that may require loose time synchronization. Asan example, µTESLA [14] achieves asymmetric authen-ticated broadcast through a symmetric cryptographicalgorithm and a loose delay schedule to disclose thekeys from a key chain. Other examples of asymmetricauthenticated broadcast schemes requiring either looseor no time synchronization are found in [25], [26].

Considering the great computation cost incurred by astrong asymmetric authentication scheme and the diffi-culty in key management, a regular packet other than abase station broadcast packet may only be moderatelyauthenticated through existing symmetric schemes witha limited set of keys, such as the message authenticationcode provided by TinySec [13]. It is possible that anadversary physically captures a non-base legal node andreveals its key for the symmetric authentication [27].With that key, the adversary can forge the identity ofthat non-base legal node and joins the network “legally”.However, when the adversary uses its fake identity tofalsely attract a great amount of traffic, after receivingbroadcast packets about delivery information, other le-gal nodes that directly or indirectly forwards packetsthrough it will start to select a more trustworthy paththrough TrustManager (Section 3.4).

2.3 Goals

TARF mainly guards a WSN against the attacks mis-directing the multi-hop routing, especially those basedon identity theft through replaying the routing informa-tion. This paper does not address the denial-of-service(DoS) [3] attacks, where an attacker intends to damagethe network by exhausting its resource. For instance, wedo not address the DoS attack of congesting the networkby replaying numerous packets or physically jammingthe network. TARF aims to achieve the following desir-able properties:High Throughput Throughput is defined as the ratio ofthe number of all data packets delivered to the basestation to the number of all sampled data packets. Inour evaluation, throughput at a moment is computedover the period from the beginning time (0) until thatparticular moment. Note that single-hop re-transmissionmay happen, and that duplicate packets are consideredas one packet as far as throughput is concerned. Through-put reflects how efficiently the network is collecting anddelivering data. Here we regard high throughput as oneof our most important goals.Energy Efficiency Data transmission accounts for a ma-jor portion of the energy consumption. We evaluate en-ergy efficiency by the average energy cost to successfullydeliver a unit-sized data packet from a source node to thebase station. Note that link-level re-transmission should


be given enough attention when considering energy costsince each re-transmission causes a noticeable increase inenergy consumption. If every node in a WSN consumesapproximately the same energy to transmit a unit-sizeddata packet, we can use another metric hop-per-deliveryto evaluate energy efficiency. Under that assumption, theenergy consumption depends on the number of hops,i.e. the number of one-hop transmissions occurring. Toevaluate how efficiently energy is used, we can measurethe average hops that each delivery of a data packettakes, abbreviated as hop-per-delivery.Scalability & Adaptability TARF should work well withWSNs of large magnitude under highly dynamic con-texts. We will evaluate the scalability and adaptability ofTARF through experiments with large-scale WSNs andunder mobile and hash network conditions.

Here we do not include other aspects such as latency,load balance, or fairness. Low latency, balanced networkload, and good fairness requirements can be enforced inspecific routing protocols incorporating TARF.

3 DESIGN OF TARFTARF secures the multi-hop routing in WSNs against in-truders misdirecting the multi-hop routing by evaluatingthe trustworthiness of neighboring nodes. It identifiessuch intruders by their low trustworthiness and routesdata through paths circumventing those intruders toachieve satisfactory throughput. TARF is also energy-efficient, highly scalable, and well adaptable. Before in-troducing the detailed design, we first introduce severalnecessary notions here.Neighbor For a node N , a neighbor (neighboring node)of N is a node that is reachable from N with one-hopwireless transmission.Trust level For a node N , the trust level of a neighbor is adecimal number in [0, 1], representing N ’s opinion of thatneighbor’s level of trustworthiness. Specifically, the trustlevel of the neighbor is N ’s estimation of the probabilitythat this neighbor correctly delivers data received to thebase station. That trust level is denoted as T in this paper.Energy cost For a node N , the energy cost of a neighboris the average energy cost to successfully deliver a unit-sized data packet with this neighbor as its next-hopnode, from N to the base station. That energy cost isdenoted as E in this paper.

3.1 Overview

For a TARF-enabled node N to route a data packet to thebase station, N only needs to decide to which neighbor-ing node it should forward the data packet consideringboth the trustworthiness and the energy efficiency. Oncethe data packet is forwarded to that next-hop node, theremaining task to deliver the data to the base station isfully delegated to it, and N is totally unaware of whatrouting decision its next-hop node makes. N maintainsa neighborhood table with trust level values and energycost values for certain known neighbors. It is sometimes

necessary to delete some neighbors’ entries to keep thetable size acceptable. The technique of maintaining aneighborhood table of a moderate size is demonstratedby Woo, Tong and Culler [28]; TARF may employ thesame technique.

In TARF, in addition to data packet transmission, thereare two types of routing information that need to be ex-changed: broadcast messages from the base station aboutdata delivery and energy cost report messages fromeach node. Neither message needs acknowledgement. Abroadcast message from the base station is flooded to thewhole network. The freshness of a broadcast messageis checked through its field of source sequence number.The other type of exchanged routing information is theenergy cost report message from each node, which isbroadcast to only its neighbors once. Any node receivingsuch an energy cost report message will not forward it.

For each node N in a WSN, to maintain such a neigh-borhood table with trust level values and energy cost val-ues for certain known neighbors, two components, Ener-gyWatcher and TrustManager, run on the node (Figure 2).EnergyWatcher is responsible for recording the energycost for each known neighbor, based on N ’s observationof one-hop transmission to reach its neighbors and theenergy cost report from those neighbors. A compromisednode may falsely report an extremely low energy cost tolure its neighbors into selecting this compromised nodeas their next-hop node; however, these TARF-enabledneighbors eventually abandon that compromised next-hop node based on its low trustworthiness as trackedby TrustManager. TrustManager is responsible for trackingtrust level values of neighbors based on network loopdiscovery and broadcast messages from the base stationabout data delivery. Once N is able to decide its next-hop neighbor according to its neighborhood table, itsends out its energy report message: it broadcasts toall its neighbors its energy cost to deliver a packetfrom the node to the base station. The energy cost iscomputed as in Section 3.3 by EnergyWatcher. Such anenergy cost report also serves as the input of its receivers’EnergyWatcher.

Neighborhood

Table

TrustManager

Base Station

Broadcast

Energy Cost

Report

Network Loop

Discovery

EnergyWatcher

One-hop

Delivery

Neighbor

Energy Cost

Neighbor Trust

Level

Next-hop

Selection

Energy Cost

Report

Fig. 2. Each node selects a next-hop node based on itsneighborhood table, and broadcast its energy cost within itsneighborhood. To maintain this neighborhood table, Energy-Watcher and TrustManager on the node keep track of relatedevents (on the left) to record the energy cost and the trust levelvalues of its neighbors.


3.2 Routing Procedure

TARF, as with many other routing protocols, runs as aperiodic service. The length of that period determineshow frequently routing information is exchanged andupdated. At the beginning of each period, the basestation broadcasts a message about data delivery duringlast period to the whole network consisting of a fewcontiguous packets (one packet may not hold all theinformation). Each such packet has a field to indicatehow many packets are remaining to complete the broad-cast of the current message. The completion of the basestation broadcast triggers the exchange of energy reportin this new period. Whenever a node receives such abroadcast message from the base station, it knows thatthe most recent period has ended and a new period hasjust started. No tight time synchronization is requiredfor a node to keep track of the beginning or ending of aperiod. During each period, the EnergyWatcher on a nodemonitors energy consumption of one-hop transmissionto its neighbors and processes energy cost reports fromthose neighbors to maintain energy cost entries in itsneighborhood table; its TrustManager also keeps track ofnetwork loops and processes broadcast messages fromthe base station about data delivery to maintain trustlevel entries in its neighborhood table.

To maintain the stability of its routing path, a nodemay retain the same next-hop node until the next freshbroadcast message from the base station occurs. Mean-while, to reduce traffic, its energy cost report couldbe configured to not occur again until the next freshbroadcast message from the base station. If a node doesnot change its next-hop node selection until the nextbroadcast message from the base station, that guaran-tees all paths to be loop-free, as can be deducted fromthe procedure of next-hop node selection. However, asnoted in our experiments, that would lead to slowimprovement in routing paths. Therefore, we allow anode to change its next-hop selection in a period whenits current next-hop node performs the task of receivingand delivering data poorly.

Next, we introduce the structure and exchange ofrouting information as well as how nodes make routingdecisions in TARF.

3.2.1 Structure and Exchange of Routing Information

A broadcast message from the base station fits into atmost a fixed small number of packets. Such a messageconsists of some pairs of <node id of a source node, anundelivered sequence interval [a, b] with a significantlength>, <node id of a source node, minimal sequencenumber received in last period, maximum sequencenumber received in last period>, as well as several nodeid intervals of those without any delivery record in lastperiod. To reduce overhead to an acceptable amount,our implementation selects only a limited number ofsuch pairs to broadcast (Section 5.1) and proved effec-tive (Section 5.3, 5.4). Roughly, the effectiveness can be

explained as follows: the fact that an attacker attracts agreat deal of traffic from many nodes often gets revealedby at least several of those nodes being deceived witha high likelihood. The undelivered sequence interval [a,b] is explained as follows: the base station searches thesource sequence numbers received in last period, identi-fies which source sequence numbers for the source nodewith this id are missing, and chooses certain significantinterval [a, b] of missing source sequence numbers asan undelivered sequence interval. For example, the basestation may have all the source sequence numbers for thesource node 2 as {109, 110, 111, 150, 151} in last period.Then [112, 149] is an undelivered sequence interval;[109, 151] is also recorded as the sequence boundaryof delivered packets. Since the base station is usuallyconnected to a powerful platform such as a desktop, aprogram can be developed on that powerful platform toassist in recording all the source sequence numbers andfinding undelivered sequence intervals.

Accordingly, each node in the network stores a tableof <node id of a source node, a forwarded sequenceinterval [a, b] with a significant length> about lastperiod. The data packets with the source node and thesequence numbers falling in this forwarded sequenceinterval [a, b] have already been forwarded by this node.When the node receives a broadcast message about datadelivery, its TrustManager will be able to identify whichdata packets forwarded by this node are not delivered tothe base station. Considering the overhead to store sucha table, old entries will be deleted once the table is full.

Once a fresh broadcast message from the base stationis received, a node immediately invalidates all the ex-isting energy cost entries: it is ready to receive a newenergy report from its neighbors and choose its newnext-hop node afterwards. Also, it is going to select anode either after a timeout is reached or after it hasreceived an energy cost report from some highly trustedcandidates with acceptable energy cost. A node imme-diately broadcasts its energy cost to its neighbors onlyafter it has selected a new next-hop node. That energycost is computed by its EnergyWatcher (see Section 3.3).A natural question is which node starts reporting itsenergy cost first. For that, note that when the base stationis sending a broadcast message, a side effect is that itsneighbors receiving that message will also regard thisas an energy report: the base station needs 0 amountof energy to reach itself. As long as the original basestation is faithful, it will be viewed as a trustworthycandidate by TrustManager on the neighbors of the basestation. Therefore, those neighbors will be the first nodesto decide their next-hop node, which is the base station;they will start reporting their energy cost once thatdecision is made.

3.2.2 Route SelectionNow, we introduce how TARF decides routes in a WSN.Each node N relies on its neighborhood table to select anoptimal route, considering both energy consumption and


reliability. TARF makes good efforts in excluding thosenodes that misdirect traffic by exploiting the replay ofrouting information.

For a node N to select a route for delivering datato the base station, N will select an optimal next-hopnode from its neighbors based on trust level and energycost and forward the data to the chosen next-hop nodeimmediately. The neighbors with trust levels below acertain threshold will be excluded from being consideredas candidates. Among the remaining known neighbors,N will select its next-hop node through evaluating eachneighbor b based on a trade-off between TNb and ENb

TNb

,with ENb and TNb being b’s energy cost and trust levelvalue in the neighborhood table respectively (see Sec-tion 3.3, 3.4). Basically, ENb reflects the energy cost ofdelivering a packet to the base station from N assumingthat all the nodes in the route are honest; 1

TNb

approx-imately reflects the number of the needed attempts tosend a packet from N to the base station via multiplehops before such an attempt succeeds, considering thetrust level of b. Thus, ENb

TNb

combines the trustworthiness

and energy cost. However, the metric ENb

TNb

suffers fromthe fact that an adversary may falsely reports extremelylow energy cost to attract traffic and thus resulting in alow value of ENb

TNb

even with a low TNb. Therefore, TARFprefers nodes with significantly higher trust values; thispreference of trustworthiness effectively protects the net-work from an adversary who forges the identity of anattractive node such as a base station. For deciding thenext-hop node, a specific trade-off between TNb and ENb

TNb

is demonstrated in Figure 5 (see Section 5.2).Observe that in an ideal misbehavior-free environ-

ment, all nodes are absolutely faithful, and each nodewill choose a neighbor through which the routing pathis optimized in terms of energy; thus, an energy-drivenroute is achieved.

3.3 EnergyWatcher

Here we describe how a node N ’s EnergyWatcher com-putes the energy cost ENb for its neighbor b in N ’sneighborhood table and how N decides its own energycost EN . Before going further, we will clarify somenotations. ENb mentioned is the average energy costof successfully delivering a unit-sized data packet fromN to the base station, with b as N ’s next-hop nodebeing responsible for the remaining route. Here, one-hopre-transmission may occur until the acknowledgementis received or the number of re-transmissions reachesa certain threshold. The cost caused by one-hop re-transmissions should be included when computing ENb.Suppose N decides that A should be its next-hop nodeafter comparing energy cost and trust level. Then N ’senergy cost is EN = ENA. Denote EN→b as the averageenergy cost of successfully delivering a data packet fromN to its neighbor b with one hop. Note that the re-transmission cost needs to be considered. With the abovenotations, it is straightforward to establish the following

relation:

ENb = EN→b + Eb

Since each known neighbor b of N is supposed tobroadcast its own energy cost Eb to N , to compute ENb,N still needs to know the value EN→b, i.e., the averageenergy cost of successfully delivering a data packet fromN to its neighbor b with one hop. For that, assumingthat the endings (being acknowledged or not) of one-hop transmissions from N to b are independent withthe same probability psucc of being acknowledged, wefirst compute the average number of one-hop sendingsneeded before the acknowledgement is received as fol-lows:

∞∑

i=1

i · psucc · (1− psucc)i−1 =

1

psucc

Denote Eunit as the energy cost for node N to send aunit-sized data packet once regardless of whether it isreceived or not. Then we have

ENb =Eunit

psucc+ Eb

The remaining job for computing ENb is to get the proba-bility psucc that a one-hop transmission is acknowledged.Considering the variable wireless connection amongwireless sensor nodes, we do not use the simplisticaveraging method to compute psucc. Instead, after eachtransmission from N to b, N ’s EnergyWatcher will updatepsucc based on whether that transmission is acknowl-edged or not with a weighted averaging technique. Weuse a binary variable Ack to record the result of currenttransmission: 1 if an acknowledgement is received; oth-erwise, 0. Given Ack and the last probability value of anacknowledged transmission pold succ, an intuitive way isto use a simply weighted average of Ack and pold succ asthe value of pnew succ. That is what is essentially adoptedin the aging mechanism [29]. However, that method usedagainst sleeper attacks still suffers periodic attacks [30].To solve this problem, we update the psucc value usingtwo different weights as in our previous work [30], arelatively big wdegrade ∈ (0, 1) and a relatively smallwupgrade ∈ (0, 1) as follows:

pnew succ =

(1− wdegrade)× pold succ + wdegrade ×Ack,

if Ack = 0.(1− wupgrade)× pold succ + wupgrade ×Ack,

if Ack = .1

The two parameters wdegrade and wupgrade allow flexibleapplication requirements. wdegrade and wupgrade repre-sent the extent to which upgraded and degraded per-formance are rewarded and penalized, respectively. Ifany fault and compromise is very likely to be associatedwith a high risk, wdegrade should be assigned a relativelyhigh value to penalize fault and compromise relativelyheavily; if a few positive transactions can’t constitute ev-idence of good connectivity which requires many morepositive transactions, then wupgrade should be assigneda relatively low value.


3.4 TrustManager

A node N ’s TrustManager decides the trust level ofeach neighbor based on the following events: discoveryof network loops, and broadcast from the base stationabout data delivery. For each neighbor b of N , TNb

denotes the trust level of b in N ’s neighborhood table.At the beginning, each neighbor is given a neutral trustlevel 0.5. After any of those events occurs, the relevantneighbors’ trust levels are updated.

Note that many existing routing protocols have theirown mechanisms to detect routing loops and to reactaccordingly [31], [32], [28]. In that case, when integratingTARF into those protocols with anti-loop mechanisms,TrustManager may solely depend on the broadcast fromthe base station to decide the trust level; we adoptedsuch a policy when implementing TARF later (see Sec-tion 5). If anti-loop mechanisms are both enforced inthe TARF component and the routing protocol that in-tegrates TARF, then the resulting hybrid protocol mayoverly react towards the discovery of loops. Though so-phisticated loop-discovery methods exist in the currentlydeveloped protocols, they often rely on the comparisonof specific routing cost to reject routes likely leading toloops [32]. To minimize the effort to integrate TARF andthe existing protocol and to reduce the overhead, whenan existing routing protocol does not provide any anti-loop mechanism, we adopt the following mechanism todetect routing loops. To detect loops, the TrustManageron N reuses the table of <node id of a source node,a forwarded sequence interval [a, b] with a significantlength> (see Section 3.2) in last period. If N finds that areceived data packet is already in that record table, notonly will the packet be discarded, but the TrustManageron N also degrades its next-hop node’s trust level. Ifthat next-hop node is b, then Told Nb is the latest trustlevel value of b. We use a binary variable Loop to recordthe result of loop discovery: 0 if a loop is received; 1otherwise. As in the update of energy cost, the new trustlevel of b is

Tnew Nb =

(1− wdegrade)× Told Nb + wdegrade × Loop,

if Loop = 0.(1− wupgrade)× Told Nb + wupgrade × Loop,

if Loop = 1.

Once a loop has been detected by N for a few timesso that the trust level of the next-hop node is too low,N will change its next-hop selection; thus, that loop isbroken. Though N can not tell which node should beheld responsible for the occurrence of a loop, degradingits next-hop node’s trust level gradually leads to thebreaking of the loop. On the other hand, to detect thetraffic misdirection by nodes exploiting the replay ofrouting information, TrustManager on N compares N’sstored table of <node id of a source node, forwarded se-quence interval [a, b] with a significant length> recordedin last period with the broadcast messages from thebase station about data delivery. It computes the ratioof the number of successfully delivered packets which

are forwarded by this node to the number of thoseforwarded data packets, denoted as DeliveryRatio. ThenN ’s TrustManager updates its next-hop node b’s trustlevel as follows:

Tnew Nb =

(1− wdegrade)× Told Nb

+wdegrade ×DeliveryRatio,

if DeliveryRatio < Told Nb.

(1− wupgrade)× Told Nb

+wupgrade ×DeliveryRatio,

if DeliveryRatio >= Told Nb.

3.5 Analysis on EnergyWatcher and TrustManager

Now that a node N relies on its EnergyWatcher andTrustManager to select an optimal neighbor as its next-hop node, we would like to clarify a few importantpoints on the design of EnergyWatcher and TrustManager.

First, as described in Section 3.1, the energy cost reportis the only information that a node is to passively receiveand take as “fact”. It appears that such acceptance of en-ergy cost report could be a pitfall when an attacker or acompromised node forges false report of its energy cost.Note that the main interest of an attacker is to preventdata delivery rather than to trick a data packet into a lessefficient route, considering the effort it takes to launchan attack. As far as an attack aiming at preventing datadelivery is concerned, TARF well mitigates the effect ofthis pitfall through the operation of TrustManager. Notethat the TrustManager on one node does not take any rec-ommendation from the TrustManager on another node.If an attacker forges false energy report to form a falseroute, such intention will be defeated by TrustManager:when the TrustManager on one node finds out the manydelivery failures from the broadcast messages of the basestation, it degrades the trust level of its current next-hopnode; when that trust level goes below certain threshold,it causes the node to switch to a more promising next-hop node.

Second, TrustManager identities the low trustworthi-ness of various attackers misdirecting the multi-hoprouting, especially those exploiting the replay of routinginformation. It is noteworthy that TrustManager does notdistinguish whether an error or an attack occurs to thenext-hop node or other succeeding nodes in the route.It seems unfair that TrustManager downgrades the trustlevel of an honest next-hop node while the attack occurssomewhere after that next-hop node in the route. Con-trary to that belief, TrustManager significantly improvesdata delivery ratio in the existence of attack attempts ofpreventing data delivery. First of all, it is often difficult toidentify an attacker who participates in the network us-ing an id “stolen” from another legal node. For example,it is extremely difficult to detect a few attackers colludingto launch a combined wormhole and sinkhole attack [4].Additionally, despite the certain inevitable unfairnessinvolved, TrustManager encourages a node to chooseanother route when its current route frequently fails to


deliver data to the base station. Though only those legalneighboring nodes of an attacker might have correctlyidentified the adversary, our evaluation results indicatethat the strategy of switching to a new route withoutidentifying the attacker actually significantly improvesthe network performance, even with the existence ofwormhole and sinkhole attacks. Fig 3 gives an example toillustrate this point. In this example, node A, B, C and Dare all honest nodes and not compromised. Node A hasnode B as its current next-hop node while node B has anattacker node as its next-hop node. The attacker dropsevery packet received and thus any data packet passingnode A will not arrive at the base station. After a while,node A discovers that the data packets it forwarded didnot get delivered. The TrustManager on node A starts todegrade the trust level of its current next-hop node Balthough node B is absolutely honest. Once that trustlevel becomes too low, node A decides to select node Cas its new next-hop node. In this way node A identifies abetter and successful route (A - C - D - base). In spite ofthe sacrifice of node B’s trust level, the network performsbetter. Further, concerning the stability of routing path,

A

B

Base Station

DC

Attacker

Fig. 3. An example to illustrate how TrustManager works.

once a valid node identifies a trustworthy honest neigh-bor as its next-hop node, it tends to keep that next-hopselection without considering other seemingly attractivenodes such as a fake base station. That tendency iscaused by both the preference to maintain stable routesand the preference to highly trustable nodes.

Finally, we would like to stress that TARF is designedto guard a WSN against the attacks misdirecting themulti-hop routing, especially those based on identitytheft through replaying the routing information. Othertypes of attacks such as the denial-of-service (DoS) [3]attacks are out of the discussion of this paper. Forinstance, we do not address the attacks of injectinginto the network a number of data packets containingfalse sensing data but authenticated (possibly throughhacking). That type of attacks aim to exhaust the networkresource instead of misdirecting the routing. However, ifthe attacker intends to periodically inject a few routingpackets to cause wrong route, such attacks can still bedefended by TARF through TrustManager.

4 SIMULATION

We have developed a reconfigurable emulator of wire-less sensor networks on a two-dimensional plane with

Matlab to test TARF. We have conducted extensive sim-ulation experiments; however, due to the page limit,interested readers may refer to our technical report [33]and the conference version of paper [1] for detailedsimulation settings and experimental results. In our ex-periments, initially, 35 nodes are randomly distributedwithin a 300*300 rectangular area, with unreliable wire-less transmission. All the nodes have the same powerlevel and the same maximal transmission range of 100m.Each node samples 6 times in every period; the timinggap between every two consecutive samplings of thesame node is equivalent. We simulate the sensor networkin 1440 consecutive periods.

Regarding the network topology, we set up three typesof network topologies. The first type is the static-locationcase under which all nodes stand still. The second typeis a customized group-motion-with-noise case based onReference Point Group Mobility (RPGM) model thatmimics the behavior of a set of nodes moving in oneor more groups [34], [35]. The last type of dynamicnetwork incorporated in the experiments is the additionof scattered RF-shielded areas to the aforementionedgroup-motion-with-noise case.

The performance of TARF is compared to that of alink connectivity-based routing protocol adapted fromwhat is proposed by Alec Woo, Terence Tong andDavid Culler [28]. We denote the link connectivity-based routing protocol as Link-connectivity. With theLink-connectivity protocol, each node selects its next-hopnode among its neighborhood table according to anlink estimator based on exponentially weighted movingaverage (EWMA). The simulation results show, in thepresence of misbehaviors, the throughput in TARF is oftenmuch higher than that in Link-connectivity; the hop-per-delivery in the Link-connectivity protocol is generally atleast comparable to that in TARF.

Under a misbehavior-free environment, the simula-tion results show that TARF and Link-connectivity havecomparable performance when there is no adversary.Both protocols are also evaluated under three commontypes of attacks: (1) a certain node forges the identity ofthe based station by replaying broadcast messages, alsoknown as the sinkhole attack; (2) a set of nodes colludes toform a forwarding loop; and (3) a set of nodes drops re-ceived data packets. These experiments were conductedin the static case, the group-motion-with-noise case, andthe addition of RF-shielded areas to the group-motion-with-noise case separately. Generally, under these com-mon attacks, TARF produces a substantial improvementover Link-connectivity in terms of data collection and en-ergy efficiency. Further, we have evaluated TARF undermore severe attacks: multiple moving fake bases andmultiple Sybil attackers. As before, the experiments areconducted under all the three types of network topology.Under these two types of most severe attacks whichalmost devastates the Link-connectivity protocol, TARFsucceeds in achieving a steady improvement over theLink-connectivity protocol. Finally, we have conducted


certain experiments to explore the choice of the periodlength and the trust updating scheme. Our experimentsreveal that a shorter period or a faster trust updatingscheme may not necessarily benefit TARF.

5 IMPLEMENTATION AND EMPIRICAL EVALUA-TION

In order to evaluate TARF in a real-world setting, weimplemented the TrustManager component on TinyOS2.x, which can be integrated into the existing routing pro-tocols for WSNs with the least effort. Originally, we hadimplemented TARF as a self-contained routing proto-col [1] on TinyOS 1.x before this second implementation.However, we decided to re-design the implementationconsidering the following factors. First, the first imple-mentation only supports TinyOS 1.x, which was replacedby TinyOS 2.x; the porting procedure from TinyOS 1.xto TinyOS 2.x tends to frustrate the developers. Second,rather than developing a self-contained routing protocol,the second implementation only provides a TrustMan-ager component that can be easily incorporated into theexisting protocols for routing decisions. The detectionof routing loops and the corresponding reaction areexcluded from the implementation of TrustManager sincemany existing protocols, such as Collection Tree Proto-col [32] and the link connectivity-based protocol [28],already provide that feature. As we worked on the firstimplementation, we noted that the existing protocolsprovide many nice features, such as the analysis oflink quality, the loop detection and the routing decisionmainly considering the communication cost. Instead ofproviding those features, our implementation focuseson the trust evaluation based on the base broadcastof the data delivery, and such trust information canbe easily reused by other protocols. Finally, instead ofusing TinySec [13] exclusively for encryption and au-thentication as in the first implementation on TinyOS 1.x,this re-implementation let the developers decide whichencryption or authentication techniques to employ; theencryption and authentication techniques of TARF maybe different than that of the existing protocol.

5.1 TrustManager Implementation Details

The TrustManager component in TARF is wrappedinto an independent TinyOS configuration namedTrustManagerC. TrustManagerC uses a dedicatedlogic channel for communication and runs as a periodicservice with a configurable period, thus not interferingwith the application code. Though it is possible to im-plement TARF with a period always synchronized withthe routing protocol’s period, that would cause much in-trusion into the source code of the routing protocol. Thecurrent TrustManagerC uses a period of 30 seconds;for specific applications, by modifying a certain headerfile, the period length may be re-configured to reflect the

sensing frequency, the energy efficiency and trustworthi-ness requirement. TrustManagerC provides two inter-faces (see Figure 4), TrustControl and Record, whichare implemented in other modules. The TrustControlinterface provides the commands to enable and disablethe trust evaluation, while the Record interface providesthe commands for a root, i.e., a base station, to adddelivered message record, for a non-root node to addforwarded message record, and for a node to retrieve thetrust level of any neighboring node. The implementationon a root node differs from that on a non-root node: aroot node stores the information of messages received(delivered) during the current period into a record tableand broadcast delivery failure record; a non-root nodestores the information of forwarded messages during thecurrent period also in a record table and compute thetrust of its neighbors based on that and the broadcast in-formation. Noting that much implementation overheadfor a root can always be transferred to a more powerfuldevice connected to the root, it is reasonable to assumethat the root would have great capability of processingand storage.

configuration TrustManagerC {

provides {

interface TrustControl;

interface Record;

}

implementation {

...........................................

}

}

interface Record

{

//for a root to add delivered record <source node id, source sequence number>

command void addDelivered(am_addr_t src, uint8_t seq);

//for a non-root node to add forwarded record <source id, source sequence, next-hop id>

command void addForwarded(am_addr_t src, uint8_t seq, am_addr_t next);

//return the trust level of a node

command uint16_t getTrust(am_addr_t id);

}

interface TrustControl

{

//enable trust evaluation

command error_t start();

//disable trust evaluation

command error_t stop();

}

Fig. 4. TrustManager component.

A root broadcasts two types of delivery failure record:at most three packets of significant undelivered intervalsfor individual origins and at most two packets of the id’sof the origins without any record in the current period.For each origin, at most three significant undeliveredintervals are broadcast. For a non-root node, consideringthe processing and memory usage overhead, the recordtable keeps the forwarded message intervals for up to 20source nodes, with up to 5 non-overlapped intervals foreach individual origin. Our later experiments verify thatsuch size limit of the table on a non-root node produces aresilient TARF with moderate overhead. The record tableon a node keeps adding entries for new origins until itis full.

With our current implementation, a valid trust value isan integer between 0 and 100, and any node is assignedan initial trust value of 50. The weigh parameters are:wupgrade = 0.1, wdegrade = 0.3. The trust table of a


non-root node node keeps the trust level for up to 10neighbors. Considering that an attacker may presentmultiple fake id’s, the implementation evicts entries witha trust level close to the initial trust of any node. Sucheviction policy is to ensure that the trust table remembersthose neighbors with high trust and low trust; any otherneighbor not in this table is deemed to have the initialtrust value of 50.

5.2 Incorporation of TARF into Existing Protocols

To demonstrate how this TARF implementation can beintegrated into the exiting protocols with the least effort,we incorporated TARF into a collection tree routingprotocol (CTP) [32]. The CTP protocol is efficient, robust,and reliable in a network with highly dynamic linktopology. It quantifies link quality estimation in orderto choose a next-hop node. The software platform isTinyOS 2.x. To perform the integration, after properinterface wiring, invoke the TrustControl.startcommand to enable the trust evaluation; call theRecord.addForwarded command for a non-root nodeto add forwarded record once a data packet has beenforwarded; call the Record.addDelivered commandfor a root to add delivered record once a data packet hasbeen received by the root. Finally, inside the CTP’s taskto update the routing path, call the Record.getTrustcommand to retrieve the trust level of each next-hopcandidate; an algorithm taking trust into routing consid-eration is executed to decide the new next-hop neighbor(see Figure 5).

Similar to the original CTP’s implementation, the im-plementation of this new protocol decides the next-hopneighbor for a node with two steps (see Figure 5): Step1 traverses the neighborhood table for an optimal candi-date for the next hop; Step 2 decides whether to switchfrom the current next-hop node to the optimal candidatefound. For Step 1, as in the CTP implementation, anode would not consider those links congested, likelyto cause a loop, or having a poor quality lower thana certain threshold. This new implementation prefersthose candidates with higher trust levels; in certaincircumstances, regardless of the link quality, the rulesdeems a neighbor with a much higher trust level tobe a better candidate (see Figure 5). The preference ofhighly trustable candidates is based on the followingconsideration: on the one hand, it creates the least chancefor an adversary to misguide other nodes into a wrongrouting path by forging the identity of an attractivenode such as a root; on the other hand, forwarding datapackets to a candidate with a low trust level would resultin many unsuccessful link-level transmission attempts,thus leading to much re-transmission and a potentialwaste of energy. When the network throughput becomeslow and a node has a list of low-trust neighbors, thenode will exclusively use the trust as the criterion toevaluate those neighbors for routing decisions. As showin Figure 5, it uses trust/cost as a criteria only when the

candidate has a trust level above certain threshold. Thereason is, the sole trust/cost criteria could be exploitedby an adversary replaying the routing information froma base station and thus pretending to be an extremelyattractive node. As for Step 2, compared to the CTPimplementation, we add two more circumstances whena node decides to switch to the optimal candidate foundat Step 1: that candidate has a higher trust level, or thecurrent next-hop neighbor has a too low trust level.

//Step 1. traverse the neighborhood table for an optimal candidate for the next hop

optimal_candidate = NULL

//the cost of routing via the optimal candidate provided by the existing protocol, initially infinity

optimal_cost = MAX_COST

//the trust level of the optimal candidate, initially 0

optimal_trust = MIN_TRUST

for each candidate in the neighborhood table

if link is congested, or may cause a loop, or does not pass quality threshold

continue

better = false

if candidate.trust >= optimal_trust && candidate.cost < optimal_cost

better = true

//prefer trustworthy candidates

if candidate.trust >= TRUST_THRESHOLD && optimal_trust < TRUST_THRESHOLD

better = true

if candidate.trust >= ESSENTIAL_DIFFERENCE_THRESHOLD + optimal_trust

better = true

//effective when all nodes have low trust due to network change or poor connectivity

if candidate.trust >= 3 * optimal_trust / 2

better = true

//add restriction of trust level requirement

if candidate.trust >= TRUST_THRESHOLD && candidate.trust / candidate.cost >

optimal_trust / optimal_cost

better = true

if better == true

optimal_candidate = candidate

optimal_cost = candidate.cost

optimal_trust = candidate.trust

//Step 2. decide whether to switch from the current next-hop node to the optimal candidate found:

if optimal_trust >= currentNextHop.trust \

|| currentNextHop.trust <= TRUST_THRESHOLD \

|| current link is congested and switching is not likely to cause loops \

|| optimal_cost + NEXTHOP_SWITCH_THRESHOLD < currentNextHop.cost \

currentNextHop = optimal_candidate

Fig. 5. Routing decision incorporating trust management.

This new implementation integrating TARF requiresmoderate program storage and memory usage. We im-plemented a typical TinyOS data collection application,MultihopOscilloscope, based on this new protocol. TheMultihopOscilloscope application, with certain modifiedsensing parameters for our later evaluation purpose,periodically makes sensing samples and sends out thesensed data to a root via multiple routing hops. Orig-inally, MultihopOscilloscope uses CTP as its routingprotocol. Now, we list the ROM size and RAM sizerequirement of both implementation of MultihopOscillo-scope on non-root Telosb motes in Table 1. The enablingof TARF in MultihopOscilloscope increases the size ofROM by around 1.3KB and the size of memory byaround 1.2KB.

TABLE 1Size comparison of MultihopOscilloscope implementation

Protocol ROM (bytes) RAM (bytes)CTP 31164 3579

TARF-enabled CTP 34290 4767


5.3 Empirical Evaluation on Motelab

We evaluated the performance of TARF against a com-bined sinkhole and wormhole attack on Motelab [36] atHarvard University. 184 TMote Sky sensor motes weredeployed across many rooms at three floors in the de-partment building (see Figure 6), with two to four motesin most rooms. Around 97 nodes functioned properlywhile the rest were either removed or disabled. Eachmote has a 2.4GHz Chipcon CC2420 radio with anindoor range of approximately 100 meters. In Figure 6,the thin green lines indicate the direct (one-hop) wirelessconnection between motes. Certain wireless connectionalso exists between nodes from different floors.

Fig. 6. Connectivity map of Motelab (not including the inter-floor connectivity), adapted from Motelab[Motelab].

We developed a simple data collection application inTinyOS 2.x that sends a data packet every five seconds toa base station node (root) via multi-hop. This applicationwas executed on 91 functioning non-root nodes on Mote-lab. For comparison, we used CTP and the TARF-enabledCTP implementation as the routing protocols for the datacollection program separately. The TARF-enabled CTPhas a TARF period of 30 seconds. We conducted an attackwith five fake base stations that formed a wormhole. Asin Figure 6, whenever the base station sent out anypacket, three fake base stations which overheard thatpacket replayed the complete packet without changingany content including the node id. Other fake basestations overhearing that replayed packet would alsoreplay the same packet. Each fake base station essentiallylaunched a sinkhole attack. Note that there is a distinctionbetween such malicious replay and the forwarding whena well-behaved node receives a broadcast from the basestation. When a well-behaved node forwards a broadcastpacket from the base station, it will include its ownid in the packet so that its receivers will not recognizethe forwarder as a base station. We conducted the firstexperiment by uploading the program with the CTPprotocol onto 91 motes (not including those 5 selectedmotes as fake bases in later experiments), and no attackwas involved here. Then, in another experiment, in

addition to programming those 91 motes with CTP, wealso programmed the five fake base stations so that theystole the id the base station through replaying. In thelast experiment, we programmed those 91 motes withthe TARF-enabled CTP, and programmed the five fakebase stations as in the second experiment. Each of ourprograms run for 30 minutes.

As illustrated in Figure 7(a), the existence of the fivewormhole attackers greatly degraded the performanceof CTP: the number of the delivered data packets inthe case of CTP with the five-node wormhole is no morethan 14% that in the case of CTP without adversaries.The TARF-enabled CTP succeeded in bringing animmense improvement over CTP in the presence ofthe five-node wormhole, almost doubling the throughput.That improvement did not show any sign of slowingdown as time elapsed. The number of nodes from eachfloor that delivered at least one data packet in eachsix-minute sub-period is plotted in Figure 7(a), 7(b) and7(c) separately. On each floor, without any adversary,at least 24 CTP nodes were able to find a successfulroute in each six minute. However, with the five fakebase stations in the wormhole, the number of CTP nodesthat could find a successful route goes down to 9 forthe first floor; it decreases to no more than 4 for thesecond floor; as the worst impact, none of the nodes onthe third floor ever found a successful route. A furtherlook at the data showed that all the nine nodes fromthe first floor with successful delivery record were allclose to the real base station. The CTP nodes relativelyfar away from the base station, such as those on thesecond and the third floor, had little luck in makinggood routing decisions. When TARF was enabled oneach node, most nodes made correct routing decisionscircumventing the attackers. That improvement canbe verified by the fact that the number of the TARF-enabled nodes with successful delivery record underthe threat of the wormhole is close to that of CTP nodeswith no attackers, as shown in Figure 7(a), 7(b) and 7(c).

5.4 Application: Mobile Target Detection in the Pres-ence of an Anti-Detection Mechanism

To demonstrate how TARF can be applied in networkedsensing systems, we developed a proof-of-concept re-silient application of target detection. This applicationrelies on a deployed wireless sensor network to detecta target that could move, and to deliver the detectionevents to a base station via multiple hops with the TARF-enabled CTP protocol. For simplification, the target is aLEGO MINDSTORM NXT 2.0 vehicle robot equippedwith a TelosB mote that sends out an AM (ActiveMessage) packet every three seconds. A sensor nodereceiving such a packet from the target issues a detectionreport, which will be sent to the base station with theaforementioned TARF-enabled CTP protocol.

The experiment is set up within a clear floor space of90 by 40 inches with 15 TelosB motes (see Figure 8(a)). To


0 5 10 15 20 25 300

0.5

1

1.5

2

2.5

3x 10

4

Time in minutes

Num

ber

of

deliv

ere

d p

ackets

CTP without adversaries

CTP with 5-node wormhole

TARF-enabled CTP with 5-node wormhole

(a) All three floors.

25 2526

25 25

9 9 9 9 9

2624

2120

24

[0min, 6min] [6min,

12min]

[12min,

18min]

[18min,

24min]

[24min,

30min]

Time

Nu

mb

er

of

no

de

s w

ith

de

liv

ery

re

co

rd




(b) First floor.

36 36 36 37 36

2 24 3 2

3634

3033 32

[0min, 6min] [6min,

12min]

[12min,

18min]

[18min,

24min]

[24min,

30min]

Time

Nu

mb

er

of

no

de

s w

ith

de

liv

ery

re

co

rd




(c) Second floor.

25 25 25 2524

2524

2322

23

0000 0

[0min, 6min] [6min,

12min]

[12min,

18min]

[18min,

24min]

[24min,

30min]

Time

Nu

mb

er

of

no

de

s w

ith

de

liv

ery

re

co

rd




(d) Third floor.

Fig. 7. Empirical comparison of CTP and TARF-enabled CTPon Motelab: (a) number of all delivered data packets since thebeginning; number of nodes on (b) the first floor, (c) the secondfloor and (d) the third floor that delivered at least one data packetin sub-periods.

make the multi-hop delivery necessary, the transmission

power of all the Telosb motes except two fake basestations in the network is reduced through both softwarereduction and attenuator devices to within 30 inches. Thetarget uses an anti-detection mechanism utilizing a fakebase station close to the real base station, and anotherremote base station close to the target and mounted onanother LEGO vehicle robot. The two fake base stations,with a transmission range of at least 100 feet, colludeto form a wormhole: the fake base station close to thebase station replays all the packets from the base stationimmediately; the remote fake base station, after receivingthose packets, immediately replays it again. This anti-detection mechanism tricks some network nodes intosending their event reports into these fake base stationsinstead of the real base station. Though the fake basestation close to the real base station is capable of cheatingthe whole network alone by itself with its powerful radiofor a certain amount of time, it can be easily recognizedby remote nodes as a poor next-hop candidate soon bymost routing protocols based on link quality: that fakebase station does not acknowledge the packets “sent”to it from remote nodes with a weak radio via a singlehop since it can not really receive them. Thus, the anti-detection mechanism needs to create such a wormhole toreplay the packets from the base station remotely.

(a) A snapshot of the network.

(b) A closer look.

Fig. 8. Deployment of a TARF-enabled wireless sensor networkto detect a moving target under the umbrella of two fake basestations in a wormhole.

The target node 14 and the fake base station 13 close toit move across the network along two parallel tracks of22 inches back and forth (see Figure 8(b)); they travel


on each forward or backward path of 22 inches inaround 10 minutes. The experiment lasts 30 minutes. Forcomparison, three nodes 9, 10 and 11 programmed withthe CTP protocol are paired with another three nodes 6, 7and 8 programmed with the TARF-enabled CTP (see Fig-ure 8(b)); each pair of nodes are physically placed closeenough. All the other nodes, except for the fake basestations and the target node, are programmed with theTARF-enabled CTP. To fairly compare the performancebetween CTP and the TARF-enabled CTP, we now focuson the delivered detection reports originating from thesethree pairs of nodes: pair (9, 6), (10, 7) and (11, 8). For thetimestamp of each detection report from these six nodes,we plot a corresponding symbol: a purple circle for thenodes with the TARF-enabled CTP; a black cross for theCTP nodes. The resulting detection report is visualizedin Figure 9(a). Roughly, the TARF nodes report theexistence of the target seven times as often as the CTPnodes do. More specifically, as shown in Figure 9(b), inthe pair (9, 6), no report from CTP node 9 is deliveredwhile 46 reports from TARF node 6 is delivered; in thepair (10, 7), no report from CTP node 10 is deliveredwhile 80 reports from TARF node 7 is delivered; in thepair (11, 8), 40 reports from CTP node 11 is deliveredwhile 167 reports from TARF node 8 is delivered. Takinginto account the spatial proximity between each pairof nodes, the TARF-enabled CTP achieves an enormousimprovement in target detection over the original CTP.

0 5 10 15 20 25 30

Time in minutes

Deliv

ere

d r

eport

of dete

ction Detection reported by TARF nodes

Detection reported by CTP nodes

(a) Detection report.

4046

80

167

0 0

From node pair(9, 6) From node pair(10, 7) From node pair(11, 8)

Nu

mb

er

of

rep

ort

ed

dete

cti

on

s

From CTP node

From TARF-enabled node

(b) Number of reported detections.

Fig. 9. Comparison of CTP and the TARF-enabled CTP indetecting the moving target.

The demonstration of our TARF-based target detectionapplication implies the significance of adopting a securerouting protocol in certain critical applications. The ex-perimental results indicate that TARF greatly enhancesthe security of applications involving multi-hop datadelivery.

6 RELATED WORK

We discuss more related work here in addition to theintroduction in Section 1. It is generally hard to protectWSNs from wormhole attacks, sinkhole attacks and Sybilattacks based on identity deception. The countermea-sures often requires either tight time synchronizationor known geographic information [4]. FBSR[37], as afeedback-based secure routing protocol for WSNs , usesa statistics-based detection on a base station to dis-cover potentially compromised nodes. But the claim thatFBSR is resilient against wormhole and Sybil attacks isnever evaluated or examined; the Keyed-OWHC-basedauthentication used by FBSR also causes considerableoverhead. There also exists other work on trust-awaresecure routing that is evaluated only through computersimulation, such as [38].

There are certain existing secure routing solutionsfor WSNs based on trust and reputation management;however, they rarely address the “identity theft” ex-ploiting the replay of routing information. Two suchrepresentative solutions are ATSR [22] and TARP [23].Neither ATSR nor TARP offers protection against theidentity deception through replaying routing informa-tion. ATSR [22] is a location-based trust-aware routingsolution for large WSNs. ATSR incorporates a distributedtrust model utilizing both direct and indirect trust,geographical information as well as authentication toprotect the WSNs from packet misforwarding, packetmanipulation and acknowledgements spoofing. Anothertrust-aware routing protocol for WSNs is TARP [23],which exploits nodes’ past routing behavior and linkquality to determine efficient paths.

7 CONCLUSIONS

We have designed and implemented TARF, a robusttrust-aware routing framework for WSNs, to securemulti-hop routing in dynamic WSNs against harmfulattackers exploiting the replay of routing information.TARF focuses on trustworthiness and energy efficiency,which are vital to the survival of a WSN in a hostileenvironment. With the idea of trust management, TARFenables a node to keep track of the trustworthiness of itsneighbors and thus to select a reliable route. Our maincontributions are listed as follows. (1) Unlike previousefforts at secure routing for WSNs, TARF effectivelyprotects WSNs from severe attacks through replayingrouting information; it requires neither tight time syn-chronization nor known geographic information. (2) Theresilience and scalability of TARF is proved throughboth extensive simulation and empirical evaluation with


large-scale WSNs; the evaluation involves both static andmobile settings, hostile network conditions, as well asstrong attacks such as wormhole attacks and Sybil attacks.(3) We have implemented a ready-to-use TinyOS moduleof TARF with low overhead; as demonstrated in thepaper, this TARF module can be integrated into existingrouting protocols with the least effort, thus producingsecure and efficient fully-functional protocols. (4) Finally,we demonstrate a proof-of-concept mobile target detec-tion application that is built on top of TARF and isresilient in the presence of an anti-detection mechanism;that indicates the potential of TARF in WSN applications.

REFERENCES

[1] G. Zhan, W. Shi, and J. Deng, “Tarf: A trust-aware routingframework for wireless sensor networks,” in Proceeding of the 7thEuropean Conference on Wireless Sensor Networks (EWSN’10), 2010.

[2] F. Zhao and L. Guibas, Wireless Sensor Networks: An InformationProcessing Approach. Morgan Kaufmann Publishers, 2004.

[3] A. Wood and J. Stankovic, “Denial of service in sensor networks,”Computer, vol. 35, no. 10, pp. 54–62, Oct 2002.

[4] C. Karlof and D. Wagner, “Secure routing in wireless sensornetworks: attacks and countermeasures,” in Proceedings of the1st IEEE International Workshop on Sensor Network Protocols andApplications, 2003.

[5] M. Jain and H. Kandwal, “A survey on complex wormhole attackin wireless ad hoc networks,” in Proceedings of International Con-ference on Advances in Computing, Control, and TelecommunicationTechnologies (ACT ’09), 28-29 2009, pp. 555 –558.

[6] I. Krontiris, T. Giannetsos, and T. Dimitriou, “Launching a sink-hole attack in wireless sensor networks; the intruder side,” inProceedings of IEEE International Conference on Wireless and MobileComputing, Networking and Communications(WIMOB ’08), 12-142008, pp. 526 –531.

[7] J. Newsome, E. Shi, D. Song, and A. Perrig, “The sybil attackin sensor networks: Analysis and defenses,” in Proc. of the 3rdInternational Conference on Information Processing in Sensor Networks(IPSN’04), Apr. 2004.

[8] L. Bai, F. Ferrese, K. Ploskina, and S. Biswas, “Performance analy-sis of mobile agent-based wireless sensor network,” in Proceedingsof the 8th International Conference on Reliability, Maintainability andSafety (ICRMS 2009), 20-24 2009, pp. 16 –19.

[9] L. Zhang, Q. Wang, and X. Shu, “A mobile-agent-based middle-ware for wireless sensor networks data fusion,” in Proceedingsof Instrumentation and Measurement Technology Conference (I2MTC’09), 5-7 2009, pp. 378 –383.

[10] W. Xue, J. Aiguo, and W. Sheng, “Mobile agent based movingtarget methods in wireless sensor networks,” in IEEE InternationalSymposium on Communications and Information Technology (ISCIT2005), vol. 1, 12-14 2005, pp. 22 – 26.

[11] J. Hee-Jin, N. Choon-Sung, J. Yi-Seok, and S. Dong-Ryeol, “Amobile agent based leach in wireless sensor networks,” in Proceed-ings of the 10th International Conference on Advanced CommunicationTechnology (ICACT 2008), vol. 1, 17-20 2008, pp. 75 –78.

[12] J. Al-Karaki and A. Kamal, “Routing techniques in wireless sensornetworks: a survey,” Wireless Communications, vol. 11, no. 6, pp.6–28, Dec. 2004.

[13] C. Karlof, N. Sastry, and D. Wagner, “Tinysec: A link layer securityarchitecture for wireless sensor networks,” in Proc. of ACM SenSys2004, Nov. 2004.

[14] A. Perrig, R. Szewczyk, W. Wen, D. Culler, and J. Tygar, “SPINS:Security protocols for sensor networks,” Wireless Networks Journal(WINET), vol. 8, no. 5, pp. 521–534, Sep. 2002.

[15] R. Watro, D. Kong, S. Cuti, C. Gardiner, C. Lynn, and P. Kruus,“Tinypk: securing sensor networks with public key technology,”in Proceedings of the 2nd ACM workshop on Security of ad hoc andsensor networks (SASN ’04). New York, NY, USA: ACM, 2004, pp.59–64.

[16] A. Liu and P. Ning, “Tinyecc: A configurable library for ellipticcurve cryptography in wireless sensor networks,” in Proceedingsof the 7th international conference on Information processing in sensornetworks (IPSN ’08). IEEE Computer Society, 2008, pp. 245–256.

[17] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci,“A survey on sensor networks,” IEEE Communications Magazine,vol. 40, no. 8, pp. 102–114, Aug. 2002.

[18] H. Safa, H. Artail, and D. Tabet, “A cluster-based trust-awarerouting protocol for mobile ad hoc networks,” Wirel. Netw., vol. 16,no. 4, pp. 969–984, 2010.

[19] W. Gong, Z. You, D. Chen, X. Zhao, M. Gu, and K. Lam, “Trustbased routing for misbehavior detection in ad hoc networks,”Journal of Networks, vol. 5, no. 5, May 2010.

[20] Z. Yan, P. Zhang, and T. Virtanen, “Trust evaluation based securitysolution in ad hoc networks,” in Proceeding of the 7th NordicWorkshop on Secure IT Systems, 2003.

[21] J. L. X. Li, M. R. Lyu, “Taodv: A trusted aodv routing protocolfor mobile ad hoc networks,” in Proceedings of Aerospace Conference,2004.

[22] T. Zahariadis, H. Leligou, P. Karkazis, P. Trakadas, I. Papaefs-tathiou, C. Vangelatos, and L. Besson, “Design and implementa-tion of a trust-aware routing protocol for large wsns,” InternationalJournal of Network Security & Its Applications (IJNSA), vol. 2, no. 3,Jul. 2010.

[23] A. Rezgui and M. Eltoweissy, “Tarp: A trust-aware routing proto-col for sensor-actuator networks,” in IEEE Internatonal Conferenceon Mobile Adhoc and Sensor Systems (MASS 2007), 8-11 2007.

[24] A. Abbasi and M. Younis, “A survey on clustering algorithms forwireless sensor networks,” Comput. Commun., vol. 30, pp. 2826–2841, October 2007.

[25] S. Chang, S. Shieh, W. Lin, and C. Hsieh, “An efficient broadcastauthentication scheme in wireless sensor networks,” in Proceedingsof the 2006 ACM Symposium on Information, computer and communi-cations security (ASIACCS ’06). New York, NY, USA: ACM, 2006,pp. 311–320.

[26] K. Ren, W. Lou, K. Zeng, and P. Moran, “On broadcast authenti-cation in wireless sensor networks,” IEEE Transactions on WirelessCommunications, vol. 6, no. 11, pp. 4136 –4144, november 2007.

[27] P. De, Y. Liu, and S. K. Das, “Modeling node compromise spreadin wireless sensor networks using epidemic theory,” in World ofWireless, Mobile and Multimedia Networks, 2006. WoWMoM 2006.International Symposium on a, 2006, pp. 7 pp. –243.

[28] A. Woo, T. Tong, and D. Culler, “Taming the underlying chal-lenges of reliable multihop routing in sensor networks,” in Pro-ceedings of the First ACM SenSys’03, Nov. 2003.

[29] S. Ganeriwal, L. Balzano, and M. Srivastava, “Reputation-basedframework for high integrity sensor networks,” ACM Trans. Sen.Netw., 2008.

[30] G. Zhan, W. Shi, and J. Deng, “Poster abstract: Sensortrust - a re-silient trust model for wsns,” in Proceedings of the 7th InternationalConference on Embedded Networked Sensor Systems (SenSys’09), 2009.

[31] C. Perkins and P. Bhagwat, “Highly dynamic destination-sequenced distance-vector routing (dsdv) for mobile computers,”SIGCOMM Comput. Commun. Rev., vol. 24, no. 4, pp. 234–244,1994.

[32] O. Gnawali, R. Fonseca, K. Jamieson, D. Moss, and P. Levis,“Collection tree protocol,” in Proceedings of the 7th ACM Conferenceon Embedded Networked Sensor Systems (SenSys ’09). New York,NY, USA: ACM, 2009, pp. 1–14.

[33] G. Zhan, W. Shi, and J. Deng, “Design, implementationand evaluation of tarf: A trust-aware routing framework fordynamic wsns,” http://mine.cs.wayne.edu/∼guoxing/tarf.pdf,Wayne State University, Tech. Rep. MIST-TR-2010-003, Oct. 2010.

[34] Q. Zheng, X. Hong, and S. Ray, “Recent advances in mobilitymodeling for mobile ad hoc network research,” in Proceedings ofthe 42nd Annual Southeast Regional Conference (ACM-SE 42). NewYork, NY, USA: ACM, 2004, pp. 70–75.

[35] X. Hong, M. Gerla, G. Pei, and C. Chiang, “A group mobilitymodel for ad hoc wireless networks,” in Proceedings of the 2ndACM International Workshop on Modeling, Analysis and Simulationof Wireless and Mobile Systems (MSWiM ’99). New York, NY, USA:ACM, 1999, pp. 53–60.

[36] “Motelab,” http://motelab.eecs.harvard.edu, 2005.[37] Z. Cao, J. Hu, Z. Chen, M. Xu, and X. Zhou, “Fbsr: feedback-

based secure routing protocol for wireless sensor networks,”International Journal of Pervasive Computing and Communications,2008.

[38] T. Ghosh, N. Pissinou, and K. Makki, “Collaborative trust-basedsecure routing against colluding malicious nodes in multi-hop adhoc networks,” in Local Computer Networks, 2004. 29th Annual IEEEInternational Conference on, Nov. 2004, pp. 224 – 231.

http://mine.cs.wayne.edu/~guoxing/tarf.pdf

http://motelab.eecs.harvard.edu


Guoxing Zhan Guoxing Zhan is currently aPh.D. candidate in the Department of ComputerScience at Wayne State University. He receiveda M.S. in Mathematics from Chinese Academy ofSciences in 2007 and another M.S in ComputerScience from Wayne State University in 2009.Mr. Zhan is interested in research on participa-tory sensing, wireless sensor network, mobilecomputing, networking and systems Security,trust Management, and information processing.Several of his research papers have been pre-

sented at international conferences or published in journals. Additionally,Mr. Zhan has instructed a few computer science labs consisting ofinteractive short lectures and hands-on experience.

Weisong Shi Dr. Weisong Shi is an AssociateProfessor of Computer Science at Wayne StateUniversity. He received his B.S. from XidianUniversity in 1995, and Ph.D. degree from theChinese Academy of Sciences in 2000, bothin Computer Engineering. His current researchfocuses on computer systems, mobile and cloudcomputing. Dr. Shi has published more than 100peer reviewed journal and conference papers.He is the author of the book “Performance Opti-mization of Software Distributed Shared Memory

Systems” (High Education Press, 2004). He has served the programchairs and technical program committee members of several inter-national conferences. He is a recipient of the NSF CAREER award,one of 100 outstanding Ph.D. dissertations (China) in 2002, CareerDevelopment Chair Award of Wayne State University in 2009, and the“Best Paper Award” of ICWE’04 and IPDPS’05.

Julia Deng Dr. Julia (Hongmei) Deng currentlyis a Principal Scientist at Intelligent Automa-tion Inc. Her primary research interests includeprotocol design, analysis and implementation inwireless ad hoc/sensor networks, network secu-rity, information assurance, and network man-agement. Dr Deng received her Ph.D. in theDepartment of Electrical Engineering from theUniversity of Cincinnati in 2004, majoring in com-munications and computer networks. At IAI, sheserves as the PI and leads many network and

security related projects, such as secure routing for airborne Networks,network service for airborne Networks, DoS mitigation for tactical net-works, trust-aware querying for sensor networks, trusted routing forsensor networks, agent-based intrusion detection system, just to namea few.

IEEE TRANSACTIONS ON DEPENDABLE AND …weisong/papers/zhan11-tarf.pdfIEEE TRANSACTIONS ON DEPENDABLE...

Documents

Transcript of IEEE TRANSACTIONS ON DEPENDABLE AND …weisong/papers/zhan11-tarf.pdfIEEE TRANSACTIONS ON DEPENDABLE...