secure multihop network programming

Secure Multihop Network Programmingwith Multiple One-Way Key Chains

Hailun Tan, Student Member, IEEE, John Zic, Member, IEEE,

Sanjay K. Jha, Senior Member, IEEE, and Diethelm Ostry, Member, IEEE

Abstract—Current network programming protocols provide an efficient way to update program images running on sensor nodes

without having physical access to them. Securing these updates, however, remains a challenging and important issue, given the open

environment where sensor nodes are often deployed. Several approaches addressing these issues have been reported, but their use

of cryptographically strong protocols means that their computational costs (and hence, power consumption and communication costs)

are relatively high. In this paper, we propose a novel scheme to secure a multihop network programming protocol through the use of

multiple one-way hash chains. The scheme is shown to be lower in computational, power consumption, and communication costs yet

still able to secure multihop propagation of program images. We demonstrate the use of this scheme and provide some results using

the popular network programming protocol, Deluge. In addition, we include a performance evaluation of our scheme, implemented in

TinyOS, in terms of latency and energy consumption.

Index Terms—Network programming protocols, broadcast authentication, code dissemination, sensor network security.

Ç

1 INTRODUCTION

NETWORK programming is becoming necessary forwireless sensor networks (WSNs) because there is

always a need to fix bugs in program images or insert newfunctionalities after WSN is deployed in an evolving,dynamic environment [1].

Early network programming protocols [2], [3], [4], [5]concentrated on reliable program image dissemination andminimal end-to-end update latency using distributionmethods having epidemic-like characteristics. However,they provided no authentication or security mechanisms.The absence of authentication of the broadcast of programimage means that a malicious node could install arbitraryprogram images in the sensor nodes. An adversary couldjust capture one sensor node, inject malicious programimages into the network, and thereby take control of theentire WSN.

The goal of this paper is to present a design andimplementation for a new scheme to verify the authenticityand integrity of program updates in network programmingprotocols. Our work is motivated by the following challenges.

First, as a significant class of WSN sensor nodes isresource-impoverished, traditional cryptographic schemesare impractical. For example, the Tmote [6] has 10 KB RAM,48 KB flash memory, 1 MB storage, and 250 kbpscommunication bandwidth. This is barely sufficient toexecute traditional asymmetric cryptography (e.g., RSA [7]

or Diffie and Hellman [8]). It is important that a securityscheme for WSNs should be low in power consumption andhave low computational overhead.

The second challenge arises from the open wirelessenvironment in which WSNs are typically deployed. Sinceprogram updates are also broadcast through the wirelessmedium, an adversary can readily intercept the programupdates and attempt to forge a malicious program imagewhile avoiding detection. Another complication arises fromthe way that sensor nodes are deployed. Typically, these areleft unattended after deployment, and as such are at risk ofphysical or functional capture. It is possible to physicallysecure a sensor network node against theft or tampering bya variety of means, but these physical approaches areoutside the scope of this paper. Our paper presents ascheme that is resilient against brute-force attack and nodecompromise.

The rest of the paper is organized as follows: Related workin secure network programming is reviewed and ourcontributions in this work are outlined in Section 2. Oursecurity requirements and assumptions are given in Section 3.The new scheme itself is briefly described in Section 4, and adetailed implementation and other related issues are dis-cussed in Section 5. Finally, the performance of our scheme isevaluated in Section 6, and the paper is concluded in Section 7.

2 RELATED WORK AND OUR CONTRIBUTIONS

2.1 Review of Network Programming

Deluge [2], currently distributed as part of TinyOS, is one ofthe most popular multihop network programming proto-cols. In Deluge, program updates are divided into fixed-sizepages, with each page further divided into fixed-size packets.Packets are the basic transmission units. Deluge employs athree-stage (advertise-request-update) process to propagatea program update between sensor nodes. Pages are

16 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 1, JANUARY 2011

. H. Tan and S.K. Jha are with the School of Computer Science andEngineering, University of New South Wales, Sydney, Australia.E-mail: {thailun, sanjay}@cse.unsw.edu.au.

. J. Zic and D. Ostry are with the Network Technologies Laboratory, CSIROICT Centre, Australia. E-mail: {john.zic, diet.ostry}@csiro.au.

Manuscript received 14 June 2008; revised 12 July 2009; accepted 21 Dec.2009; published online 22 July 2010.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TMC-2008-06-0231.Digital Object Identifier no. 10.1109/TMC.2010.140.

1536-1233/11/$26.00 � 2011 IEEE Published by the IEEE CS, CASS, ComSoc, IES, & SPS

disseminated in a pipelined fashion, whereby the nodes areallowed to forward the pages that they have completelyreceived without waiting for the receipt of the wholeprogram update. However, pages are received sequentially,i.e., a node cannot forward a page without having receivedall previous pages.

Other network programming protocols include MOAP[3], MNP [4], and incremental programming [5]. MOAPadopts the publisher-subscriber mechanism to disseminateprogram updates among neighbor nodes. It focuses onsimplicity of network programming and does not use apipeline to propagate updates, so the nodes in MOAP haveto wait for the entire program update before furtherpropagation. In MNP, program update propagation is doneby having each node compete with its peers. Nodes thatwere unsuccessful in a propagation attempt are put intosleep for a time period, and compete again when this timeelapses and they wake up. MNP also exploits a pipelinemechanism to enhance the efficiency. Incremental program-ming employs the rsync algorithm [9] to reduce theoverhead of program updates by propagating differencesbetween old and new program images.

Although we have used Deluge for our referenceimplementation, our scheme can be extended to otherpopular network programming protocols, with the assump-tions listed in Section 3.2. In the rest of this paper, unlessotherwise specified, we assume that Deluge is used as thenetwork programming protocol.

2.2 Existing Work on Secure Network Programming

Since the program image is composed of pages, and eachpage consists a series of packets, secure network program-ming protocols have typically computed a hash function ofthe last packet [10] or the last page [11], and then, attachedthis hash to the previous packet or page. The packet or pagewith the hash appended is then itself hashed and this hashvalue is attached to the previous packet or page. Thisprocess is continued until the first packet/page is reached.The first packet or page is signed with the private key of thebase station. Each receiving sensor node verifies the firstpacket or page with the base station’s public key, thenrecursively authenticates each packet or page using thehashed value from the predecessor packet/page until theentire program update has been successfully received.Another approach has been adopted by Deng et al. [12]who use a Merkle tree instead of recursive hashing forpacket authentication. However, in most cases, whetherthey are recursive or a variant such as a Merkle tree, all arebased on the use of a digital signature to sign the firstpacket or page. There are three problems associated withthis approach. First, signature verification incurs a compu-tation overhead, which is a concern given the limited powerresources of sensor nodes. Second, memory usage requiredto include the signature is significantly higher, as shown inFigs. 12 and 13. Third, these approaches require the numberof data packets to be known in advance of the networkprogramming process, since they construct a hash chainwhich starts from the last data packet and works back to thefirst. This requirement limits the expansion of theseapproaches to other broadcast applications where thenumber of broadcast packets is not known in advance.

Jaleel et al. proposed one-way key chain to ensure theconfidentiality of program updates [13] without public-keycryptography. Their scheme does not, however, supportmultihop program propagation. Recently, Lanigan et al.have proposed an enhancement of Sluice by exploitingsymmetric cryptography [14], [15]. However, the overheadissues such as power consumption have not been fullyaddressed. Hyun et al. [16] employed an architecturesimilar to Deng’s work [12]. In addition, they proposed aweak authenticator based on digital signature to counter asignature-based DOS attack. Their scheme is similar to theother schemes in [10], [11], [12] in terms of overhead as theyalso rely on the digital signature to bootstrap the networkprogramming process.

Perrig et al. proposed �-TELSA [17] to authenticatebroadcast packets in WSNs. It employs symmetric crypto-graphy primitives with delayed key disclosure to authenti-cate the claimed sender of a broadcast packet. It is able toauthenticate program updates since the program image isbroadcasted in packets. However, �-TELSA requires loosetime synchronization among sensor nodes, which leads tomore complicated measures to secure synchronization. Inaddition, the sensor nodes cannot authenticate packetsimmediately, but must wait until the respective keys aredisclosed, resulting in excessive verification latency and arequirement to store unauthenticated packets.

2.3 Our Contributions

The following are the key contributions of this paper:

. A cost-effective security scheme for network program-ming. In our scheme, a digital signature is notrequired to bootstrap the network programmingprocess. Instead, multiple distinct one-way keychains are distributed to the nodes based on theirhop distances to base station for packet authentica-tion. This obviates the need for digital signature,resulting in efficient use of the limited computa-tional power of each sensor node.

. A simple but effective method to counter tunnel (worm-hole) attack. This [18] is a well-known attackmechanism in multihop networks. We propose asimple-to-implement prevention mechanism andpresent an initial analysis of the mechanism.

. Power consumption evaluation. Power conservation isimperative in WSNs. To the best of our knowledge,we are the first to evaluate power consumption ofsecure network programming schemes through theuse of Power Tossim [19].

. Immediate verification. In our scheme, no timesynchronization among sensor nodes is required,and consequently, the packets of a program updatecan be verified immediately as they are received.

. Extensibility to other broadcast application in WSNs. Toour knowledge, all existing methods to securingnetwork programming [10], [11], [12] are data-dependent. The implication of this is that thenumber of packets in a base station broadcast mustbe known beforehand. This information is requiredby the base station to insert the initial digitalsignature for the whole program image. In contrast,

TAN ET AL.: SECURE MULTIHOP NETWORK PROGRAMMING WITH MULTIPLE ONE-WAY KEY CHAINS 17

our scheme does not require prior knowledge of thenumber of broadcast packets. The only proviso isthat the base station must generate long enough keychains to cover the lifetime of the WSN. Thisproperty makes our scheme extensible to authenti-cate other WSN broadcast applications.

3 PROBLEM DEFINITION

3.1 Scheme Properties

Luk et al. listed seven properties for broadcast WSNauthentication [20]. They argued that any broadcastauthentication scheme in WSNs can only provide any sixof them at most. We provide a description of the propertiesthat our scheme meets.

. Resistance to node compromise: Our scheme is resilient tonode compromise regardless of the number ofcompromised nodes, as long as the subset of non-compromised nodes can still form a connected graph.

. Low computational overhead: Our scheme employssymmetric cryptography to authenticate broadcastprogram updates. As a result, the computationaloverhead is relatively low compared to the existingwork in secure network programming [10], [11], [12].

. Low communication overhead: In our scheme, thecommunication overhead depends on the numberof hops needed to reach all nodes in the network. Theanalysis of this is further discussed in Section 5.1.

. Robustness to packet loss: Our scheme inherits robust-ness to packet loss from underlying protocolcomponents. For example, Deluge itself providesreliable data dissemination.

. Immediate authentication: Time synchronization be-tween base station and sensor nodes is not requiredin our scheme. This allows immediate authenticationof packets as they are received.

. Messages sent at irregular times: Since our methoddoes not require time synchronization, no assump-tions are made about the time interval betweenconsecutive packets.

. High message entropy: Our scheme also makes noassumptions about the content of the message itselfor its entropy.

3.2 Assumptions

Our scheme is based on the following assumptions:

. The base station cannot be compromised, and istrusted. In Deluge, the base station is the origin of alllegitimate program updates. If it were not trusted,nothing else in the WSN could be trusted.

. The base station has unlimited computational powercompared with sensor nodes.

. We assume that the wireless sensor network has astatic topology and the nodes are evenly distributedwithin this topology.

. If a node has k disjoint paths to the base station,then it is protected against k� 1 compromisednodes in our scheme. In other words, given anyhealthy node A which has k one-hop neighbors, anadversary can compromise at most k� 1 neighbors

without compromising A. The value of k dependson our deployment model, which will be furtherdiscussed in Section 5.3.

. Attacks from an adversary with resources able tocompromise the base station are out of scope of thispaper. Such an adversary could compromise orreplace sensor nodes, allowing the compromisedsensor nodes to alter or delay packets. No securitymechanism in the network programming protocolcould stop such an attack unless tamper-proofhardware is used.

. In our scheme, we do not consider Denial of Service(DOS) attacks such as jamming [21], [22] or powerdepletion attacks [16].

. We assume that all packets are delivered in correct,sequential order. Out-of-order packet delivery is notconsidered since the network programming serviceemployed is assumed to buffer and pipeline on pageboundaries and use selective negative acknowledg-ments to request retransmission of missing packets.Even though compromised nodes can resequenceforwarded packets, our scheme includes thesesequence numbers as part of the integrity check,and so such attacks are readily detectable by down-stream nodes.

4 DESIGN AND IMPLEMENTATION

This section describes the design of our secure networkprogramming scheme. As described in Section 2.1, Delugehas a hierarchical organization of program images (pro-gram images ! pages ! packets). Our scheme works atthe packet level and consists of two phases: first, initializa-tion and key predistribution, and second, packet preproces-sing and verification. The notations used in this paper areprovided in Table 1. The two phases of our scheme arepresented in Section 4.1 and Section 4.2, respectively.

4.1 Phase 1: Initialization and Key Predistribution

Our scheme employs multiple one-way hash chains [23] tosecure the Deluge protocol. Hash chains1 are based on afunction H with the property that its computation is easy,whereas its inverse H�1 is extremely difficult to compute. Ahash chain with length L is generated by applying H to aninitial element repeatedly for L times (i.e., 80 � i � L; 1 �j � S;Ki;j ¼ HðKiþ1;jÞ, as shown in Fig. 1). The last valueafter H has been applied L times is called the committedvalue of the hash chain (see Fig. 1).

Before the sensor nodes are deployed, the base stationconstructs S hash chains. It generates S distinct randomseed numbers and computes a one-way hash chain withlength of Lþ 1 starting from each seed, as shown in Fig. 1(the ðL� iþ 1Þth output of hash function derived from jthrandom seed number is denoted as Ki;j).

Sensor nodes are divided into S groups according totheir hop distance to the base station (see Fig. 2). Thecommitted value of the ith key chain (K0;i in Fig. 1),corresponding to the hop distance, is predistributed tonodes in the ith hop group before they are deployed. Asecure method suitable for key distribution before node


1. In this paper, we use hash chain and key chain interchangeably.

deployment is the Message-In-Bottle (MIB) protocol [24].2

We adopt this approach to the distribution of the commit-

ment values because

. predistribution will not incur the overhead of aDiffie-Hellman key exchange protocol [8], and

. key agreement between the base station and allsensor nodes would require Diffie-Hellman ex-changes for each node if the Diffie-Hellman ap-proach is adopted.

4.2 Phase 2: Packet Preprocessing and Verification

After the node deployment, when the base station has a

program update to be broadcast, the program image is

divided into fixed-size packets (e.g., the program image is

divided into P0; P1; . . .PL�1 in Fig. 4). The base station

preprocesses these packets so that the sensor nodes can

verify the packets accordingly.

4.2.1 Packet Preprocessing

First, we describe the packet preprocessing of the very first

packet of program image (P0). The committed value of the

first key chain (K0;1 in Fig. 1) is used to encrypt the next key

element in the order of key dissemination (K1;1 in Fig. 1).

The encrypted result (EK0;1ðK1;1Þ) is the key update segment

for the first hop group. Then, K1;1 is concatenated with P0

and the result is hashed, yielding the packet authentication

segment (HðP0kK1;1Þ). The key update segments and packet

authentication segments for the successive hop groups are

generated in the same way using their corresponding key

chains. Finally, all these segments are concatenated with P0

as shown in Fig. 3, giving the first packet to be transmitted.

The way in which the key update and packet authentication

segments are concatenated with the data packet is used in a

countermeasure against tunnel attack, further discussed in

Section 5.4.The above packet preprocessing procedure is repeated

for successive packets in the image to be broadcast. The


Fig. 1. Establishment of multiple one-way key chains.

Fig. 2. Grouping of nodes when S ¼ 2, A1;2;:: are nodes in the one-hopgroup, while B1;2;:: are nodes in the two-hop group.

TABLE 1The Notations in Section 4 and Section 5

Fig. 3. The packet preprocessing for the first data packet: P 00 ¼P0kT0;SkU0;Sk . . . kT0;1kU0;1, where T0;j ¼ HðP0kK1;jÞ; U0;j ¼ EK0;j

ðK1;jÞ;80 � j � S.

2. Key agreement protocols in the WSNs are out of the scope of thispaper. Interested readers are recommended to refer to [24].

packet preprocessing result (P 0i ) for the ith (8i; 0 � i < L)

packet (Pi) propagated to S hops is

P 0i ¼ PikTi;SkUi;Sk . . . kTi;1kUi;1;

where

Ti;j ¼ HðPikKiþ1;jÞ; ð1Þ

and

Ui;j ¼ EKi;jðKiþ1;jÞ: ð2Þ

The complete mechanism of packet preprocessing is

illustrated in Fig. 4, while the complete verification of

ith packet in node A (A 2 Gj) is shown in Algorithm 1.3

Algorithm 1. The ithð1 � i � LÞ packet(Pi) verification in

node(A) where A 2 Gjð1 � j � SÞ1: base station: Key Section ij( EKi�1;j

ðKi;jÞ2: base station: Pi Ki;j

( HðPikKi;jÞ3: base station: Pi

0 ( PikPi Ki;jkKey Section ij

4: base station ! � : Pi0

5: Pi0 has been propagated by j� 1 nodes

6: A: receive P 0i8A 2 Gj group

7: if HðDKi;jðKey Section ijÞÞ ¼ Ki;j then

8: A : Kiþ1;j ( DKi;jðKey Section ijÞ

9: A: remove Key Section ij from P 0i10: if HðPikKAÞ ¼ Pi Ki;j

then

11: A: remove Pi Ki;jfrom P 0i

12: A: accept Pi13: A: advertise Pi14: else

15: A: drop P 0i16: end if

17: else

18: A: drop P 0i19: endif

20: if Pi is requested then

21: A! � : P 0i22: end if

4.2.2 Packet Verification

In this section, the packet verification for the first data

packet destined to the first hop group will be described. The

verification of subsequent packets in the other hop groups

uses the same procedure with keys corresponding to those

that were used in the packet preprocessing.After the preprocessing of a packet and the respective

concatenation (i.e., P 00 ¼ P0kT0;1kU0;1), P 00 is transmitted to

nodes in the first hop group. After retrieving the correct

group information from P 00 (i.e., the sensor node parses the

right fields T0;1 and U0;1), the sensor nodes verify the key

update segment (U0;1) and packet authentication (T0;1) segments

as follows:

. key update segment: The sensor node decrypts U0;1

with K0;1, i.e., DK0;1ðU0;1Þ. The sensor node checks if

HðDK0;1ðU0;1ÞÞ is the same as K0;1 (line 7 in

Algorithm 1). If it is, the authenticity of U0;1 isensured and K0;1 is replaced by K1;1 for the nextpacket verification (line 8 in Algorithm 1). Otherwise,this packet is discarded (line 17 in Algorithm 1).

. packet authentication segment: After the sensor noderetrieves the authenticated K1;1 from U0;1, it per-forms HðP0kK1;1Þ to see if it matches T0;1 (line 10 inAlgorithm 1). If it does, the integrity of packet isassured (line 12 in algorithm 1). Otherwise, thispacket is discarded (line 14 in Algorithm 1).

4.2.3 Justification of Key Update Segment and Packet

Authentication Segment

. Key update segment (Ui;j in Fig. 4). This segment isneeded for three reasons. First, the key in jth groupcan be dynamically updated by packets (line 8 inAlgorithm 1) without time synchronization betweenbase station and sensor nodes. With the keyupdated, compromised nodes cannot launch areplay attack (lines 17-19 in Algorithm 1). Second,since different hop groups of nodes employ differentone-way key chains, attacks on compromised nodesfrom different groups can be prevented (especially aman-in-the-middle attack).4 Third, the encryptedpart contains the next element of the respective keyin the dissemination order (see Fig. 1), so theupdated key can be verified as a consequence of


Fig. 4. Packet preprocessing in the base station: Ui;j ¼ EKi;jðKiþ1;jÞ,

Ti;j ¼ HðPikKiþ1;jÞ.

3. For clarity, the segments required for other groups of downstreamnodes are not shown.

4. The attack from compromised node in the same group will beinvestigated in Section 5.2.

the one-way property of the hash chain (line 7 inAlgorithm 1).

. Packet authentication segment (Ti;j in Fig. 4). Integrityof the packet content is ensured with this segment.Had Pi been altered, the verification of this segment(line 10 in Algorithm 1) would fail (lines 14-16 inAlgorithm 1). This segment serves as a “signature”from the base station. However, due to the absence ofnonrepudiation in symmetric cryptography, thissignature could be forged by a compromised node.However, the difficulty of forging this signature ismade great enough by selecting appropriate designparameters (e.g., size of this segment) (see Sections5.1 and 5.4).

5 DISCUSSION

In this section, we analyze potential attacks that anadversary might launch and the corresponding counter-measures our scheme employs to maximize the difficulty inlaunching such attacks.

5.1 Trade-Off between Brute Force and Costs in OurScheme

Brute-force attack is a method to defeat a cryptographicscheme by trying every possible key to discover the secretkey shared by communicating parties. This is particularproblem in WSNs because sensor nodes are resource-impoverished and there is a trade-off between securityrequirements (in terms of key length and computation) andresource availability. For example, the maximum packetsize in TinyOS is 128 bytes. Our scheme has twocryptographic operations: the SHA-1 hash function andthe RC5 encryption/decryption.

. SHA-1 has a default size of 20 bytes [25]. This isaround 1=6 of the maximum packet size in TinyOS.On the one hand, we need to truncate k bytes out of20 for the size of packet authentication segment sothat it would not consume too much resource in thesensor nodes. On the other hand, we need to ensurethat the hashed value is robust to brute-force attack.Our scheme truncates the first 8 bytes from thehashed value in the one-way key chains.

. RC5 encryption/decryption has a key size of 8 bytes dueto the availability of open source in Tinysec [35].5

For a typical sensor node (the Tmote), the time taken forthese operations are: RC5 encryption/decryption takes7.2 msec, and the SHA-1 hash operation takes 14 msec[35], [10].

Assuming that the size of packet authentication segmentis k bytes, the average time taken to discover a key by brute-force depends on cracking either the key update segment orthe packet authentication segment in Section 4.2. Thismeans that a compromised node needs to either brute forcedecrypt one RC5 encryption and one SHA-1 hash operation(line 7 in Algorithm 1) or one SHA-1 hash operation (line 10in Algorithm 1). The time taken to brute force our scheme(TforgeðkÞ in millisecond) is

Tbrute�forceðkÞ ¼ minð14 � 28k�1; ð21:2Þ � 263Þð1 � k � 20Þ:ð3Þ

If the packet is propagated through S hops, the first hopbetween the base station and its immediate neighbors willhave the maximum number of bytes to transmit. Thecommunication overhead (WCommunicationðkÞ in byte) is

WCommunicationðkÞ ¼ ðkþ 8ÞS: ð4Þ

The maximum packet size in TinyOS is 128 bytes, the payloadof a Deluge packet is 23 bytes, and the header is 5 bytes [2]. So,the maximum number of hops our scheme can support givenone base station is

SðkÞ ¼ 100

kþ 8

� �: ð5Þ

As to the memory usage, the average number of extrabytes stored in each node (WMemoryðkÞ in byte) in ourscheme is

WMemoryðkÞ ¼ðkþ 8ÞðSðkÞ þ 1Þ

2: ð6Þ

Table 2 lists how k affects Tforge, S, and Wmemory in ourscheme. When k ¼ 4, it would take around 347 days forcompromised node to brute force our scheme. In addition,the minimum memory overhead can be achieved whenk ¼ 4. Most practical wireless networks will be restricted tofewer hops than 4 since the throughput would besignificantly degraded for larger hop counts. This hop limitcan be ensured without restricting the overall network sizeby deploying a hybrid sensor network [26]. Strong crypto-graphic algorithms such as RSA can be used in thecommunications between base stations in an upper tier,while our scheme could be employed between base stationand sensor nodes or among sensor nodes in the lower tiers.

5.2 Sybil Attack

In order to reduce power consumption and computationaloverhead, we do not adopt any asymmetric cryptography inour scheme. Employing only symmetric cryptographicprimitives comes with the price that nonrepudiation cannotbe fully ensured. One possible attack exploiting this is theSybil Attack, which is a falsified identity attack firstproposed in [27]. For example, in Fig. 5a, the compromised


TABLE 2Overhead Analysis for Algorithm 1 and

Brute-Force Attack on Our Scheme

5. We adopt this key length from Tinysec in our implementation only asa proof of concept. Our scheme can be adapted to a required cryptographicstrength by using a much longer key.

node (A1) in Gj can exploit the condition that it has the

same key as other nodes in Gj. Hence, after it receives P 0ifrom nodes in Gj�1 (e.g., B1) and finishes the verification for

key update segment (lines 7-9 in Algorithm 1), it can forge a

malicious packet (Pi0bad

) as

Pi0bad¼ PibadkHðPibadkKi;jÞkKey Section ij:

Then, A1 can broadcast the above malicious packet to its

neighbors in the same group (e.g., A2) claiming to be a node

from Gj�1.However, the above Sybil attack is difficult to launch

since it has a strict timing requirement to be successful.

First, A1 has to wait for the packet from Gj�1 so that it can

obtain Ki;j. Second, it needs some time to operate one

symmetric decryption (line 7 in Algorithm 1) and two

hashing operations (line 7 and line 2 in Algorithm 1) so

that it can forge Pi0bad

as above. Last, it needs to transmit

Pi0bad

to A2.Since the time taken for RC5 and SHA-1 is 7.2 ms [35]

and 14 ms [10], respectively, the time for Algorithm 1

(Talgorithm 1 in milliseconds) can be computed as

Talgorithm 1 ¼ 14 � 2þ 7:2 ¼ 35:2 ms: ð7Þ

As to the packet delivery time betweenB2 andA2, since they

are neighbors, the distance between them might be taken as

100 m at most [28]. Thus, the propagation time for one-hop

distance is negligible ( 1003�108 ¼ 3:3 � 10�4 ms). The bandwidth

in our sensor nodes is 250 kbps [28], the maximum packet

size in TinyOS is 128 bytes. Hence, the total time taken for

one-hop packet delivery (Tone hop in milliseconds) is

Tone hop ¼ 2 � 128 � 8

250 � 103¼ 8:2 ms: ð8Þ

With the values from (7) and (8), the total time taken for

A1 to launch a Sybil attack (Tsybil in milliseconds) is

Tsybil ¼ TB1!�:P 0i þ Talgorithm 1 þ TA1!�:Pi0bad

¼ 51:6 ms:

According to Section 3.2, there will be at least one

healthy node in Gj�1 connected to A2 (B2 in Fig. 5a). The

time taken for a legitimate update (Tauthentication in milli-

seconds) is

Tauthentication ¼ TB2!�:P 0i þ Tline 7 ¼ 8:2þ 21:2 ¼ 29:4 ms;

for A2 to update KA2(e.g., from B2 in Fig. 5a). This is much

shorter than TSybil. In order to make a Sybil attack

successful, an adversary must do the following:

. Launch the jamming attack or produce interferencein order to delay the packet delivery from thehealthy upstream nodes so that the adversary hassufficient time to discover the session key toconstruct a malicious packet forgery. Such an attackcould definitely disrupt not only the networkreprogramming but also other network operations.However, jamming attacks and network interferenceare beyond the scope of this paper. Several effectiveapproaches have been reported [21], [22] to detectand defend against them.

. Employ a PC-class device to accelerate maliciouspacket forgery so that the malicious packets reachthe downstream neighbors before the correct packetsdo. In this case, the length of the symmetric key canbe made sufficiently large to ensure a significantdelay before an adversary could brute force decryptthe key even with PC-class capability. For example,the average time required to exploit 60 percent of the64-bit RC5 key space with a contemporary computeris 1,470 days [29] certainly long enough for thecorrect packets to reach downstream nodes. If nodecompromise was available to adversary with a PC-class device, the adversary could always connect thesensor nodes via the serial port of his/her pc-classdevice and reprogram the nodes physically. Thisattack would be much simpler and more powerfulthan accelerating malicious packet forgery. More-over, no security mechanism in network program-ming protocols could prevent this attack unless atamper-proof hardware was used for sensor nodes.

. Completely compromise all upstream neighbors ofA2 in Gj�1 (i.e., network partition attack). Such aneffort would significantly increase the attack cost foran adversary if the density of nodes in the WSN ishigh. It also makes detection of an adversary easierby requiring more nodes to be compromised. Thisattack will be further discussed quantitatively inSection 5.3.


Fig. 5. Potential attacks against our scheme (the colored nodes have been compromised). (a) Sybil attack. (b) Tunnel (wormhole) attack.

. Or launch a tunnel (wormhole) attack, which wefurther discuss in Section 5.4.

5.3 Security Analysis of a Network Partition Attack

In Section 3.2, the nodes are assumed to be uniformlydistributed. Thus, the number of nodes in Gi (ni) is

ni ¼�R2ði2 � ði� 1Þ2ÞN

�ðSRÞ2¼ ð2i� 1ÞN

S2ð1 � i � SÞ: ð9Þ

Given any node k where k 2 Gi (Fig. 6a), we can assumeði� 1ÞR � rk � iR. In our scheme, node k will receivebroadcast packets from nodes in Gi�1 (i.e., upstreamneighbors of node k) and relay broadcast packets to nodesin Giþ1 (i.e., downstream neighbors of node k ). Area gABCDin Figs. 6a and 6b is where upstream neighbors anddownstream neighbors of node k are located, respectively.

If an adversary wants to broadcast a malicious packet tok in our scheme successfully, it will have to compromise allthe upstream neighbors of k. Otherwise, the compromisednode will not have enough time to forge a malicious packetto circumvent our scheme (see analysis in Section 5.2).Similarly, we can further estimate the number of nodes (i.e.,downstream neighbors) that might be affected by node k ifnode k is compromised.

If we assume that the sensor nodes are uniformlydistributed, the estimated number of upstream neighborsof node k(KupðrkÞ) is

KupðrkÞ ¼ ni�1 �Areað gABCDÞAreaðGi�1Þ

:

Using (9) and the geometry shown in Fig. 6a, the aboveequation becomes

KupðrkÞ ¼Nðði� 1Þ2R�ðrkÞ þR�ðrkÞ � rkði� 1Þ sinð�ðrkÞÞÞ

�RS2;

ð10Þ

where

�ðrkÞ ¼ arccosiði� 2ÞR2 þ r2

k

2ði� 1ÞRrk

� �;

and

�ðrkÞ ¼ arccosið2� iÞR2 þ r2

k

2Rrk

� �;

where �ðrkÞ and �ðrkÞ are the functions of � and � in Fig. 6ain terms of rk, respectively.

Similarly, the estimated number of downstream neigh-bors of node k(KdownðrkÞ) in Fig. 6b is

KdownðrkÞ ¼Nðð�� ðrkÞÞRþ irksinð�ðrkÞÞ � i2R�ðrkÞÞ

�RS2;

ð11Þ

where

�ðrkÞ ¼ arccosði2 � 1ÞR2 þ r2

k

2iRrk

� �;

and

�ðrkÞ ¼ arccosð1� i2ÞR2 þ r2

k

2Rrk

� �:

Figs. 7a and 7b illustrate the result given by (10), (11),respectively, when N ¼ 1;000, S ¼ 4, and R ¼ 100 [28]. Anadversary will need to compromise 10-15 upstream neigh-bors to “contaminate” node k if it resides in the middle of thehop group (i.e., rk ¼ ði� 1=2ÞRÞ). The greater i is, the moredifficult it is for an adversary to cause network partitions andinject broadcast packets for nodes in Gi since there are moreupstream neighbors it needs to compromise (see Fig. 7a). Onthe other hand, although an adversary could affect moredownstream neighbors by compromising nodes closer to thebase station (e.g., i ¼ 1 in Fig. 7b), it may be more difficult for


Fig. 6. Connectivity analysis: gABCD is the area where the neighbor nodes receive/forward program updates from node k. (a) Upstream neighbors ofnode k; ðk 2 GiÞ. (b) Downstream neighbors of node k; ðk 2 GiÞ.

an adversary to get physical access to them because it iseasier for the base station to keep them under protectivesurveillance due to their shorter distance away.

5.4 Tunnel (Wormhole) Attack

The tunnel attack was initially proposed in [18]. In thisattack, an adversary establishes a low-latency unidirectionaltunnel, such as a long-range wireless link or wired link,between two compromised nodes in the network that arenot within communication range of each other (see Fig. 5b).One of the compromised nodes (A1) records one or morepackets and tunnels them via the link to the other end oftunnel (A2). The other compromised node (A2) can replaythem into the network in an appropriate manner. In thecontext of network programming, a tunnel can assist anadversary to inject malicious program updates to circum-vent the detection by security schemes which do not requiretime synchronization or asymmetric cryptography in WSNs.

In our scheme, the compromised node (A2 in Fig. 5b) willrequest its collaborator (A1 in Fig. 5b) to transmit the packet(P 0i ) via the tunnel whenever P 0i is available. Since the tunnelis a shortcut from A1 to A2, A2 will get P 0i much earlier thanits neighbors in the same group. Consequently, A2 canlaunch a Sybil attack before its neighbors receive P 0i .

In order to counter this attack, let us briefly review thepacket verification process in Algorithm 1. After a nodesuccessfully updates the key and authenticates a packet, it

will remove the respective segments for further propagation(lines 9 and 11 in Algorithm 1). Since A2 receives this packetfrom the tunnel, the key update segment and packetauthentication segment for the intermediate nodes(B1; B2 . . .Bk in Fig. 5b) will still be attached to P 0i sincethese segments have not been verified by the intermediatenodes. As a result, A2 will need to remove all thesesegments before it can forge Pi0

bad.

In computer networks, a security designer can usecomputational “client puzzles” that the attackers will haveto solve before they can mount an attack. One such exampleis that a server can distribute small cryptographic puzzles toits clients to solve so that an attacker, disguised as alegitimate client, cannot send unlimited redundant requeststo deplete the server’s resources [30]. We have designed anew puzzle for A2 (i.e., the attacker) to solve before it canremove these segments correctly, instead of employing timesynchronization as in [18]. In the base station, segments areattached as shown in Fig. 8. On receiving P 0i , each node willretrieve 8 bytes from the end of P 0i for key update segmentand another k bytes for the packet authentication segment,where k denotes the size of packet authentication segment.If k is fixed to 4 bytes as discussed in Section 5.1, A2 willknow that it needs to remove 12j bytes to retrieve Ki;jþ1,where j is the number of nodes the tunnel has skipped over.In order to increase the difficulty for A2 to retrieve Ki;jþ1,instead of k being a constant, k is now assigned a random


Fig. 7. Expected number of neighbors distribution for node k in Gi. (a) Number of upstream neighbors of k. (b) Number of downstream neighbors of k.

Fig. 8. Puzzle to counter a tunnel attack: the size of the packet authentication segment (cross-hatched) is randomized. Ti;j and Ui;j are defined in (1)and (2), respectively. A2 will need to “guess” (i.e., search for by brute force) the correct number of bytes it needs to remove.

value selected from a set of numbers. Because k israndomized by the base station for nodes in each group,A2 needs to guess

Pjl¼1ð8þ klÞ before it can retrieve Ki;jþ1.

For the intermediate nodes (B1; B2 . . . ), there is nosignificant overhead incurred when the size of the packetauthentication segment is randomized, since they only haveto make several more comparisons on line 10 in Algorithm 1.However, the randomization forces A2 to try to removeevery possible value of

Pjl¼1ð8þ klÞ from P 0i so that it can

retrieve Ki;jþ1. As to the number of possible values inPjl¼1ð8þ klÞ, we have the following lemma when k is

randomized for each hop group:

Lemma 1. Assume that the set of values for kl (i.e., size of packetauthentication segment for P 0l ) is T , jT j ¼ n, and j is thenumber of nodes the tunnel has skipped over. fðj; nÞ denotesthe number of distinct values for

Pjl¼1ð8þ klÞ given j and n.

If the following condition6 is met:

8T1; T2 � T; jT1j ¼ jT2j; T1 6¼ T2;X

T1 6¼X

T2:

We have

fðj; nÞ ¼Pj

i¼0 fði; n� 1Þ; n > 1;1; n ¼ 1:

�ð12Þ

Proof. When jT j ¼ 1, it is equivalent to the case where kl isfixed. Hence,

Pjl¼1ð8þ klÞ has only one result (i.e.,

fðj; nÞ ¼ 1; n ¼ 1).When jT j > 1, fðj; nÞ is equal to the number of

combinations in the following bin-and-ball problem.There are j bins (number of nodes a tunnel has

skipped over) and n balls (number of possible values forthe size of the packet authentication segment). Each binis randomly assigned one ball (the base station willrandomly choose the size of packet authenticationsegment for each group). This bin-and-ball problemmust satisfy the following conditions:

. Each bin can only contain one ball, i.e., there canbe only one value for the size of each packetauthentication segment.

. One ball can be placed into multiple bins, i.e.,multiple packet authentication segments fornodes in different groups can be of the same size.

. The order in which the balls are placed into binsdoes not make any difference as long as the samesubset of balls is used. For example, if T ¼f2; 5; 7g; j ¼ 3,f277g; f772g; f727g are all countedas one combination because

Pjl¼1ð8þ klÞ is

independent to the order of kl when they aresummed. In addition, if 8T1; T2 � T; jT1j ¼ jT2j;T1 6¼ T2;

PT1 6¼

PT2, fðj; nÞ is not subject to the

specific elements in T but jT j and j.

When jT j is incremented from n� 1 to n, fðj; nÞ willhave the relationship with fði; n� 1Þð0 � i � jÞ as shownin the following table: The ith row represents the casewhen j� iþ 1 bins contain the first ball (i.e., Ball1), andthe other n� 1 balls are placed in the remaining i� 1 bins.

The total number of combinations (fðj; nÞ) is thesummation of all rows in the above table. In theðiþ 1Þth row, there are combinations for n� 1 ballsinto i bins, which is fði; n� 1Þ. So, we sum up all rows:

fðj; nÞ ¼ fð0; n� 1Þ þ fð1; n� 1Þ þ � � � þ fðj; n� 1Þ|fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl}jþ1 terms

¼Xji¼0

fði; n� 1Þ:

ut

Based on Lemma 1, we have the following theorem for

fðj; nÞ:Theorem 1. If Lemma 1 holds,

fðj; nÞ ¼ Cjjþn�1; ð13Þ

where

Cba ¼

a!

b!ða� bÞ! :

Proof. We prove this theorem through mathematical induc-

tion. When n ¼ 1; 8j 2 ZZþ, fðj; nÞ ¼ Cjj ¼ 1 as in (12).

When n > 1, we assume that there exists a kðk 2 ZZþ;k � nÞ, so that 8s 2 ZZþ; s � k,

fðj; sÞ ¼ Cjjþs�1: ð14Þ

According to (12), we can simplify fðj; kþ 1Þwith (14)and 8a; b 2 ZZþ; a � b; Cb�1

a þ Cba ¼ Cb

aþ1,

fðj; kþ 1Þ ¼Xji¼0

Ciiþk�1

¼ C0k�1 þ C1

k þ C2kþ1 þ � � � þ C

jjþk�1

¼�C0k þ C1

k

þ C2

kþ1 þ � � � þ Cjjþk�1

¼�C1kþ1 þ C2

kþ1

þ C3

kþ2 þ � � � þ Cjjþk�1

¼�C2kþ2 þ C3

kþ2

þ � � � þ Cj

jþk�1

¼ � � �¼ Cj�1

jþk�1 þ Cjjþk�1 ¼ C

jjþðkþ1Þ�1:

ð15Þ

The above induction can start from k ¼ 1 until

k ¼ nð8j 2 ZZþÞ.


6. For example, T ¼ f3; 5; 7g is not the set meeting this condition sincewhen T1 ¼ f3; 7g; T2 ¼ f5; 5g, jT1j ¼ jT2j; T1 6¼ T2;

PT1 ¼

PT2 ¼ 10. T ¼

f2; 5; 7g is the set meeting this condition.

When j ¼ 1, according to (12), we have

fð1; nÞ ¼ fð0; n� 1Þ þ fð1; n� 1Þ¼ fð0; n� 2Þ þ ðfð0; n� 2Þ þ fð1; n� 2ÞÞ¼ � � �¼ fð0; 1Þ þ fð0; 1Þ þ � � � þ fð0; 1Þ|fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl}

n terms

¼ n ¼ C1n:

This is equal to the respective value in (13) whenj ¼ 1; 8n 2 ZZþ.

When j > 1, we assume that there exists kðk 2 ZZþ; k �jÞ so that 8n 2 ZZþ

fðk; nÞ ¼ Ckkþn�1: ð16Þ

According to (12), we can simplify fðkþ 1; nÞ with(16) and (15):

fðkþ 1; nÞ ¼ fðkþ 1; n� 1Þ þ fðk; nÞ¼ fðkþ 1; n� 2Þ þ fðk; n� 1Þ þ fðk; nÞ¼ � � �

¼ fðkþ 1; 1Þ þXni¼2

fðk; iÞ

¼ Ckk þ

Xni¼2

Ckkþi�1

¼Xni¼1

Ckkþi�1 ¼

Xni¼1

Ci�1kþi�1

¼ Cn�1kþn ¼ Ckþ1

ðkþ1Þþn�1:

The above induction can start from k ¼ 1 until

k ¼ jð8n 2 ZZþÞ.So, Theorem 1 holds with respect to n and j. tu

Obviously, the expected number of guesses A2 needs to

make (i.e., bfðj;nÞ2 c) is exponential in n. Because n is

determined in our scheme while j is determined by the

adversary, we can make n large enough so that A2 incurs a

high latency due to brute-force cost onPj

l¼1ð8þ klÞ even if

the adversary reduces the length of tunnel (i.e., j) in an

attempt to shorten the latency. Assume that the latency via

the tunnel is 0, A1 2 G1, and A2 2 Gjþ1, we can estimate the

total time (in milliseconds) taken for A2 to launch a Sybil

attack with the assistance of the tunnel:7

TtunnelðjÞ ¼ 21:2Cjjþn�1

2

$ %þ 43:4: ð17Þ

The estimated time (in milliseconds) for P 0i to reach nodes

that will be affected by A2 is

TauthenticationðjÞ ¼ 43:4jþ 29:4 ms: ð18Þ

Fig. 9 shows the values in (17) and (18) in terms of tunnel

length (j). When n � 4, the tunnel cannot accelerate a Sybil

attack in Section 5.2 but incur higher significant latency on

brute force solving our puzzle.

The adversary could also utilize a PC-class device toattempt to accelerate the cryptographic operations on eitherend of the tunnel before the correct data packet arrived. In thatcase, jT j (i.e., the number of possible authentication segmentlengths) could be increased to introduce longer delay.

5.5 Additional Implementation Issues

5.5.1 Deployment of New Sensor Nodes

We use a circular model to represent the deployment ofsensor nodes in our scheme. The base station has informa-tion about which key will be used for authentication in eachgroup. We can adopt MIB [24] to predeploy the shared keysfrom the base station to a new node.

5.5.2 Length of Key Chains

The length of the key chains required depends on the numberof program updates the base station needs to broadcast. InDeluge, one page has 48 packets [2] and there are 24 pagesfor one program image in our scheme. So, the total numberof packets we need to send for one program image is1,152 packets. Since the base station is assumed to haveunlimited resource compared to sensor nodes, the length ofkey chains could be sufficiently long to cover the life time ofsensor nodes (e.g., L ¼ 2 � 105). Alternatively, we can adoptmultilevel key chains to update the committed values of keychains securely [31]. We leave this to our future work.

6 IMPLEMENTATION AND PERFORMANCE

EVALUATION

We implemented our scheme as an extension to the Delugenetwork programming protocol that is distributed withTinyOS. In Deluge, the base station programs are written inJava and run on a PC. These Java programs are used toconstruct and broadcast the new code disseminationpackets into the WSN. The programs for the sensor nodesare nesc [32] programs. They are used to receive the packetsof broadcast program images and update the appropriatenode program image slots.

On the base station side, we use the JCE provider in theBouncy Castle Crypto APIs [33] for hash function (SHA-1),key generation, and packet encryption (RC5). On the sensornode side, we employed the hashing operation fromTinyECC [34] and packet decryption from Tinysec [35]. Thecommitted values of the key chains are generated in the basestation and predistributed on the nodes in the correspondinghop group before deployment. The operations of packet


Fig. 9. Latency comparison between legitimate broadcast programupdates and tunnel attack in our scheme.

7. The operations required to make one guess are one hash operation andone RC5 decryption in line 7 of Algorithm 1.

preprocessing are implemented in ImageInjector.java, whilethe operations of packet verification are implemented inDelugePageTransferM.nc. The reference codes for the basestations and sensor nodes are available in [36] and [37],respectively.

Our evaluation consists of two parts. We first evaluatedour scheme using the TOSSIM [38] simulator in Section 6.1.Then, we tested our scheme in a network of Tmotes [6] inSection 6.2.

6.1 Simulation Results

In Section 6.1.1, we compare our scheme with the originalDeluge [2] and Sluice [11] in terms of end-to-end latency.Then, in Section 6.1.2, we evaluate the power consumptionin our scheme through PowerTossim [19], which is a plug-in module for TOSSIM.

Since our work builds on topology knowledge, we havethe following simulation settings in Table 3.

6.1.1 End-to-End Latency

In [11], the authors carried out their experiment for one-hopimage propagation. Given the data from [11], we compareour scheme with Deluge [2] and Sluice [11] in Fig. 10a forone-hop program update.

Sluice and our scheme both have linear scalability withrespect to update size, as shown in Fig. 10a. At thebeginning of program updates, our scheme has much lowerlatency than Sluice because in Sluice, a sensor node has toverify the digital signature for the first page of programimage. In our scheme, no asymmetric cryptographicprimitives are needed. As the number of transmitted pages

increases, the latency of Sluice increases more slowly thanour scheme since it authenticates the program image in agranularity of pages rather than packets. The number ofsymmetric cryptographic operations is significantly re-duced, with the price that a single tampered packet canlead to the failure of the entire page authentication. Despitethe decrease in the number of cryptographic operations,sluice cannot completely make up for the significant delaydue to verification of the digital signature compared withmultiple key-chain methods for the first 30-page update.

Figs. 10b and 10c show the end-to-end latency in ourscheme for multihop program updates compared to Deluge[2]. As number of nodes increases, the gap between Delugeand our scheme increases due to the number of cryptographicoperations in our scheme (Fig. 10b). The single-page latencygap is smaller as the latency effect in the multiple-key chainmethod is accumulative when all the pages are transmitted.

6.1.2 Power Consumption

The authors in [19] provided an energy model for the Mica2only. Without an energy model available for other sensorplatform, we only analyzed our scheme for the Mica2 inthis section.

Figs. 11a, 11b, and 11c show the average power con-sumption for CPU, radio, and EEPROM, respectively, tocomplete a program update. The CPU power consumptionmainly depends on the design of verification process in eachsensor node (i.e., Algorithm 1). Hence, the scalability of thenetwork has least impact on it (see Fig. 11a) since theverification process is independent of the number of nodes inthe WSN. The radio power consumption is proportional tothe number of hops in which the program update ispropagated, as analyzed in Section 5.1 (see (4)). As a result,the respective curve for our scheme in Fig. 11b is roughlylinear in terms of number of nodes in the WSN. ForEEPROM, in addition to dissemination of the receivedprogram image data, a sensor node needs to store authenti-cation segments for downstream peers. So, the respectivepower consumption depends on not only the number ofhops but also the hop distance of the sensor nodes. Hence,there is a larger variance in power consumption by EEPROMthan by CPU or radio. Moreover, the power consumption ofEEPROM is highly dependent on network size.

6.2 Experimental Results

We installed our scheme in Tmote [6] nodes and comparedDeluge [2] and Sluice [11] with our scheme in terms of


Fig. 10. End-to-end latency evaluation on single hop and multihop scenario in our scheme (Simulation). (a) One-hop program update. (b) Multihopprogram update. (c) Page latency in multihop program update.

TABLE 3Simulation Parameters

memory usage for TinyOS applications. We also conducteda survivability test to evaluate the robustness of our schemein the presence of a malicious code injector. Finally, we alsomeasured the code dissemination rate on two types ofrepresentative nodes in our scheme and compared it toDeluge [2].

6.2.1 Memory Overhead

DelugeBasic in the TinyOS distribution is the simplestapplication of Deluge as it only contains the Deluge module.The more hops our scheme supports for network program-ming, the more memory overhead there will be, as more keyupdates and packet authentications for downstream nodesare required. Most practical wireless networks will berestricted to fewer hops than four since the throughputsignificantly degrades for larger hop counts. In addition,large deployments will be likely to form some kind ofhierarchy [26]. Hence, we measured the utilizations of ROMand RAM in our scheme for up to four hops. The measure-ment results for Deluge [2], Sluice [11], and our scheme (withdifferent hop version) are illustrated in Figs. 12a and 12b,respectively. Since digital signature is not used in ourscheme, the memory overhead is less than that of Sluicealthough there is a linear increase on the ROM/RAM usage asthe number of hops increases. Compared to Deluge, there isup to a 6 and 1.5 KB increase in ROM and RAM usage,respectively. In the Tmote platform, the ROM (i.e., programflash memory) and RAM available are 48K and 10K,respectively, [28]. As a result, our scheme will occupy up to

54 percent of ROM and 25 percent of RAM in TMoteplatforms. As described in Section 2, Sluice [11] has lowermemory overhead than the Berkeley method [10] and theColorado method [12] as it has a similar security structure atthe page level rather than at packet level. Thus, our schemewould have significantly less memory overhead than boththe Berkeley method and Colorado method since our schemecosts slightly less than Sluice.

In order to evaluate the memory usage of our scheme fordifferent applications, the programs Blink, SenseToLeds,Oscilloscope, and TinyECC [34] were chosen for experimentas they vary from the simplest application (i.e., Blink) tofundamental sensing applications (i.e., SenseToLeds andOscilloscope) and even one of the most complex applicationsin TinyOS published recently (i.e., TinyECC8). Figs. 13a and13b show the memory usage of Deluge, Sluice, and ourscheme on these selected applications. The experimentshows that our scheme will incur up to 5 KB of ROM and1.5 KB of RAM more than that required by Deluge. In thesimple applications, our scheme has a slightly less memoryoverhead than Sluice, while in the more complex applica-tions, our scheme can have more significant memory savingsthan Sluice by around 0.5 KB because our scheme does notemploy any asymmetric cryptography. The reason whythere is variation of the RAM usage in different applications


Fig. 12. Memory overhead in Deluge [2], Sluice [11], and our scheme in DelugeBasic with respect to number of hops (experimental). (a) ROM usage.(b) RAM usage.

8. TinyECC is a software package providing ECC-based digital signaturethat can be flexibly configured and integrated into sensor networkapplications. There are two types of operations in TinyECC: signer andverifier.

Fig. 11. Power consumption for Deluge [2] and our scheme (simulation). (a) CPU. (b) Radio. (c) EEPROM.

is that in TinyOS, Deluge is wired into the application codeas a component [2]. Consequently, the differences on RAMusage in different applications are due to the design of theapplications themselves.

6.2.2 Survivability Test

We conducted the survivability test to confirm that ourscheme works as expected (i.e., a single malicious nodecannot inject arbitrary updates to its neighbors and cannottamper with the content of an authorized update, and then,inject this modified update to other nodes). We simulated amalicious node by placing a base station running Deluge toinject code with the unprocessed key update or with theunprocessed packet authentication. The Tmotes runningour scheme can detect a wrong key update or a mismatchbetween the packet content and the packet authenticationfield. As a result, the packets from this base station will bedropped. Although the malicious base station in ourexperiment can mount a battery drain attack by injectingfalse packets to deplete the power of its neighbors, we haveleft this kind of DOS attack to our future work.

6.2.3 Code Dissemination Rate

In addition to the one-hop latency evaluated with respect tothe network size in Section 6.1.1, we also investigated howcode updates are propagated by individual nodes. Weselected two types of nodes: the one-hop neighbors of thebase station (the first hop) and the nodes four-hops away fromthe base station (the last hop). These two type of nodes areexpected to have a different latency for code dissemination.We next show the network programming rate with respect topropagation time, using a code image of DelugeBasic.

Fig. 14 depicts the times at which these two type of nodesfinished disseminating a certain percentage of the programimage under both our scheme and Deluge [2]. As time goeson, both types of nodes gradually receive the programimage from their upstream neighbors. Due to the hopdistances to the base station, the nodes four-hops away frombase station receive some of the pages when the neighborsof the base station have already received the completeprogram image. In our scheme, as nodes in each hop groupneed to perform key updates and packet authentications,the delays due to security operations are accumulated as the

program image propagates further in the network. InDeluge, the propagation delay between these two types ofnodes is smaller since security operations are not carried outin the intermediate nodes.

7 CONCLUSION

In this work, we proposed an authentication scheme tosecure multihop network programming with multiple one-way hash chains. Instead of the expensive asymmetriccryptographic primitives used in much prior work, ourscheme employs only symmetric cryptographic primitives,in a circular geographic node deployment model. Wediscussed possible attacks an adversary could mount onour scheme and provided simple and effective countermeasures against them. Finally, we provided a comprehen-sive performance evaluation of our scheme in terms of end-to-end latency and power consumption, which we believe isthe first power consumption evaluation of a securityscheme for network programming protocols. We also testedour scheme on Tmote nodes in terms of the memory usageand code dissemination rate. Our future work will includethe design of security models for network programming


Fig. 13. Memory overhead among Deluge [2], Sluice [11], and our scheme in different applications (experiment). (a) ROM usage. (b) RAM usage.

Fig. 14. Code dissemination progress over time in selected nodes.

using our scheme in hierarchical topologies for improvedscalability, secure update of multiple one-way key chainswhen all the elements of the key chains have beenconsumed, and also the design of countermeasures againstDOS attack.

ACKNOWLEDGMENTS

This paper is an extended version of the conference paper,“Secure Multihop Network Programming with MultipleOne-Way Key Chains,” published in the Proceedings of theACM Wisec Conference, 31 Mar.-2 Apr. 2008, Alexandria,Virginia.

REFERENCES

[1] I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “ASurvey on Sensor Networks,” IEEE Comm. Magazine, vol. 40, no. 8,pp. 102-114, Aug. 2002.

[2] J.W. Hui and D. Culler, “The Dynamic Behavior of a DataDissemination Protocol for Network Programming at Scale,” Proc.Int’l Source Conf. Embedded Networked Sensor Systems (SenSys ’04),pp. 81-94, 2004.

[3] T. Stathopoulos, J. Heidemann, and D. Estrin, “A Remote CodeUpdate Mechanism for Wireless Sensor Networks,” technicalreport, Univ. of California, Los Angeles, 2003.

[4] L. Wang, “MNP: Multihop Network Reprogramming Service forSensor Networks,” Proc. Int’l Source Conf. Embedded NetworkedSensor Systems (SenSys ’04), pp. 285-286, 2004.

[5] J. Jeong and D. Culler, “Incremental Network Programming forWireless Sensors,” Proc. IEEE Conf. Sensor and Ad Hoc Comm. andNetworks (SECON ’04), pp. 25-33, 2004.

[6] Tmote Sky, “Ultra Low Power IEEE 802.15.4 Compliant WirelessSensor Module Humidity, Light, and Temperature Sensors withUSB,” http://www.moteiv.com/products/docs/tmote-sky-datasheet.pdf, Aug. 2007.

[7] R.L. Rivest, A. Shamir, and L.M. Adelman, “A Method forObtaining Digital Signatures and Public-Key Cryptosystems,”Technical Report MIT/LCS/TM-82, 1977.

[8] W. Diffie and M.E. Hellman, “New Directions in Cryptography,”IEEE Trans. Information Theory, vol. 22, no. 6, pp. 644-654, Nov.1976.

[9] A. Tridgell, “Efficient Algorithms for Sorting and Synchroniza-tion,” PhD thesis, 1999.

[10] P.K. Dutta, J.W. Hui, D.C. Chu, and D.E. Culler, “Securing theDeluge Network Programming System,” Proc. Int’l Conf. Informa-tion Processing in Sensor Networks (IPSN ’06), pp. 326-333, 2006.

[11] P.E. Lanigan, R. Gandhi, and P. Narasimhan, “Sluice: SecureDissemination of Code Updates in Sensor Networks,” Proc. IEEEInt’l Conf. Distributed Computing Systems (ICDCS ’06), pp. 53-63,2006.

[12] J. Deng, R. Han, and S. Mishra, “Secure Code Distribution inDynamically Programmable Wireless Sensor Networks,” Proc.Int’l Conf. Information Processing in Sensor Networks (IPSN ’06),pp. 292-300, 2006.

[13] J. Shaheen, D. Ostry, V. Sivaraman, and S. Jha, “Confidential andSecure Broadcast in Wireless Sensor Networks,” Proc. IEEE Int’lSymp. Personal, Indoor and Mobile Radio Comm. (PIMRC ’07), 2007.

[14] D.H. Kim, R. Gandhi, and P. Narasimhan, “Exploring Sym-metric Cryptography for Secure Network Reprogramming,”Proc. Int’l Conf. Distributed Computing Systems Workshops(ICDCSW ’07), p. 17, 2007.

[15] P.E. Lanigan, P. Narasimhan, and R. Gandhi, “Tradeoffs inConfiguring Secure Data Dissemination in Sensor Networks: AnEmpirical Outlook,” Technical Report 006, Carnegie Mellon Univ.,May 2007.

[16] S. Hyun, P. Ning, A. Liu, and W. Du, “Seluge: Secure and Dos-Resistant Code Dissemination in Wireless Sensor Networks,” Proc.Int’l Conf. Information Processing in Sensor Networks (IPSN ’08),pp. 445-456, 2008.

[17] A. Perrig, R. Szewczyk, V. Wen, D.E. Culler, and J.D. Tygar,“Spins: Security Protocols for Sensor Netowrks,” Proc. Int’l Conf.Mobile Computing and Networking (Mobilecom ’01), pp. 189-199,2001.

[18] Y.C. Hu, A. Perrig, and D.B Johnson, “Packet Leashes: A Defenseagainst Wormhole Attacks in Wireless Networks,” Proc. IEEEINFOCOM, vol. 3, pp. 1976-1986, 2003.

[19] V. Shnayder, M. Hempstead, B.-R. Chen, G.W. Allen, and M.Welsh, “Simulating the Power Consumption of Large-Scale SensorNetwork Applications,” Proc. Int’l Source Conf. Embedded Net-worked Sensor Systems (SenSys ’04), pp. 188-200, 2004.

[20] M. Luk, A. Perrig, and B. Whillock, “Seven Cardinal Properties ofSensor Network Broadcast Authentication,” Proc. WorkshopSecurity of Ad Hoc and Sensor Networks (SASN ’06), pp. 147-156,2006.

[21] A.D. Wood, J.A. Stankovic, and S.H. Son, “Jam: A Jammed-AreaMapping Service for Sensor Networks,” Proc. IEEE Int’l Real-TimeSystems Symp. (RTSS ’03), pp. 286-297, 2003.

[22] W. Xu, W. Trappe, and Y. Zhang, “Channel Surfing: DefendingWireless Sensor Networks from Interference,” Proc. Int’l Conf.Information Processing in Sensor Networks (IPSN ’07), pp. 499-508,2007.

[23] L. Lamport, “Password Authentication with Insecure Commu-nication,” Comm. ACM, vol. 24, no. 11, pp. 770-772, Nov. 1981.

[24] C. Kuo, M. Luk, R. Negi, and A. Perrig, “Message-in-a-Bottle: User-Friendly and Secure Key Deployment for Sensor Nodes,” Proc. Int’lSource Conf. Embedded Networked Sensor Systems (SenSys ’07), 2007.

[25] D. Eastlake and P. Jones, “US Secure Hash Algorithm 1 (SHA1),”RFC 3174 (Experimental), Sept. 2001.

[26] W. Hu, C.T. Chou, S. Jha, and N. Bulusu, “Deploying Long-Livedand Cost-Effective Hybrid Sensor Networks,” Ad Hoc Networks,vol. 4, no. 6, pp. 749-767, Nov. 2006.

[27] J.R. Douceur, “The Sybil Attack,” Proc. Int’l Workshop Peer-to-PeerSystems (IPTPS ’01): Revised Papers, pp. 251-260, 2002.

[28] “Telosb-Telosb Mote Platform,” http://www.willow.co.uk/TelosB_Datasheet.pdf, Sept. 2010.

[29] R. Clayton, “Brute Force Attacks on Cryptographic Keys,” http://www.cl.cam.ac.uk/rnc1/brute.html, Oct. 2001.

[30] A. Juels and J. Brainard, “Client Puzzles: A CryptographicCountermeasure against Connection Depletion Attacks,” Proc.Network and Distributed System Security Symp. (NDSS ’99), pp. 151-165, 1999.

[31] D. Liu and P. Ning, Security for Wireless Sensor Networks. Springer,Nov. 2006.

[32] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D.Culler, “The nesC Language: A Holistic Approach to NetworkedEmbedded Systems,” Proc. ACM SIGPLAN, 2003.

[33] Bouncy Castle Crypto Apis, http://www.bouncycastle.org, 2010.[34] A. Liu and P. Ning, “TinyECC: A Configurable Library for Elliptic

Curve Cryptography in Wireless Sensor Networks,” Proc. Int’lConf. Information Processing in Sensor Networks (IPSN ’08), Apr.2008.

[35] C. Karlof, N. Sastry, and D. Wagner, “Tinysec: A Link LayerSecurity Architecture for Wireless Sensor Networks,” Proc. Int’lSourceConf. Embedded Networked Sensor Systems (SenSys ’04),pp. 162-175, 2004.

[36] Java Source Code for Deluge, http://tinyos.cvs.sourceforge.net/tinyos/tinyos-1.x/tools/java/net/tinyos/deluge, 2010.

[37] Nesc Source Code for Deluge, http://tinyos.cvs.sourceforge.net/tinyos/tinyos-1.x/tos/lib/Deluge, 2010.

[38] P. Levis, N. Lee, M. Welsh, and D. Culler, “Tossim: Accurateand Scalable Simulation of Entire Tinyos Applications,” Proc.Int’l Source Conf. Embedded Networked Sensor Systems (SenSys ’03),pp. 126-137, 2003.


Hailun Tan received the MS degrees in tele-communication engineering and informationtechnology from the Australian National Univer-sity in 2004 and 2005, respectively, and the PhDdegree from the University of New South Wales(UNSW) with financial support from the Informa-tion Communication Technology (ICT) Center,Commonwealth Scientific Industrial ResearchOrganization (CSIRO), Australia, in 2009. From2004 to 2005, he worked as a part-time software

engineer for the joint hardware demonstrator project of the ICT Centre,CSIRO, and Energy Technology, CSIRO. From 2005 to 2006, heworked as a research assistant for Smart Road and Traffic (STaRproject) in National Information Communication Technology for Ex-cellence (NICTA), Australia. His main research interests are in securityprotocol design in wireless mesh networks and wireless sensornetworks. He is a student member of the IEEE.

John Zic is currently the research team andscience leader for Trusted Systems within theNetworking Technologies Laboratory, ICTCentre, CSIRO, and holds a visiting associateprofessor position at the University of NewSouth Wales (UNSW). Prior to this position,he acted as the research director for theLaboratory for a period of two years, duringwhich time he oversaw the second Center forNetworking Technologies for the Information

Economy project (CeNTIE 2) funded by the Australian Governmentthrough the Department of Communications, Information Technolo-gies, and the Arts (DCITA) that brought in some $3M p.a. into theICT Centre. He has previously held research positions at Motorola’sAustralian Research Center from 1999 to 2003, and has taughtnetworking, advanced networking, and concurrent computing atundergraduate and postgraduate levels from 1982 to 1999 as alecturer in charge and tutor. He has been involved in networkingprotocol research for more than 29 years, from ALOHA experimentdays, through the development of the first diffuse infrared wirelessLAN and onto IPv6 and home networking research, including thedevelopment of novel extensions to Hoare’s Communicating Sequen-tial Processes algebra allowing compact expression of timingconstraints in real-time systems and their protocols. His currentresearch interest is in the application formal modeling techniques andtools to security and trust protocol analysis, and is a coinventor ofthe Trust Extension Device that is currently in commercialization. Heis a member of the IEEE.

Sanjay K. Jha received the PhD degree fromthe University of Technology, Sydney, Australia.He is a professor and the head of the NetworkGroup in the School of Computer Science andEngineering at the University of New SouthWales. His research activities cover a widerange of topics in networking, including wirelesssensor networks, ad hoc/community wirelessnetworks, resilience/Quality of Service (QoS) inIP networks, and active/programmable net-

works. He has published more than 100 articles in high-quality journalsand conferences. He is the principal author of the book EngineeringInternet QoS and a coeditor of the book Wireless Sensor Networks: ASystems Perspective. He was a member-at-large of Technical Commit-tee on Computer Communications (TCCC) and IEEE Computer Societyfor a number of years. He has served on program committees of severalconferences. He was the technical program committee member of theIEEE Local Computer Networks (LCN) 2004 and ATNAC 2004conferences, and the cochair and general chair of the Emnets-1 andEmnets-II workshop, respectively. He was also the general chair of ACMSensys 2007 Symposium. He is a senior member of the IEEE.

Diethelm Ostry is a research scientist in theNetwork Technologies Laboratory, Informationand Communication Technology Center, CSIRO,Australia. His recent research interests havebeen in the areas of network traffic characteriza-tion, optical packet networks, and security inwireless sensor networks. He is a member ofthe IEEE.

. For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


secure multihop network programming

Documents