Secure Multihop Network Programming

with 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
AbstractCurrent 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 TermsNetwork programming protocols, broadcast authentication, code dissemination, sensor network security.

1 INTRODUCTION
N
ETWORK programming is becoming necessary for
wireless sensor networks (WSNs) because there is
always a need to fix bugs in program images or insert new
functionalities after WSN is deployed in an evolving,
dynamic environment [1].
Early network programming protocols [2], [3], [4], [5]
concentrated on reliable program image dissemination and
minimal end-to-end update latency using distribution
methods having epidemic-like characteristics. However,
they provided no authentication or security mechanisms.
The absence of authentication of the broadcast of program
image means that a malicious node could install arbitrary
program images in the sensor nodes. An adversary could
just capture one sensor node, inject malicious program
images into the network, and thereby take control of the
entire WSN.
The goal of this paper is to present a design and
implementation for a new scheme to verify the authenticity
and integrity of program updates in network programming
protocols. Our workis motivatedbythe followingchallenges.
First, as a significant class of WSN sensor nodes is
resource-impoverished, traditional cryptographic schemes
are impractical. For example, the Tmote [6] has 10 KB RAM,
48 KB flash memory, 1 MB storage, and 250 kbps
communication bandwidth. This is barely sufficient to
execute traditional asymmetric cryptography (e.g., RSA [7]
or Diffie and Hellman [8]). It is important that a security
scheme for WSNs should be low in power consumption and
have low computational overhead.
The second challenge arises from the open wireless
environment in which WSNs are typically deployed. Since
program updates are also broadcast through the wireless
medium, an adversary can readily intercept the program
updates and attempt to forge a malicious program image
while avoiding detection. Another complication arises from
the way that sensor nodes are deployed. Typically, these are
left unattended after deployment, and as such are at risk of
physical or functional capture. It is possible to physically
secure a sensor network node against theft or tampering by
a variety of means, but these physical approaches are
outside the scope of this paper. Our paper presents a
scheme that is resilient against brute-force attack and node
compromise.
The rest of the paper is organizedas follows: Relatedwork
in secure network programming is reviewed and our
contributions in this work are outlined in Section 2. Our
securityrequirements andassumptions aregiveninSection3.
The new scheme itself is briefly described in Section 4, and a
detailed implementation and other related issues are dis-
cussed in Section 5. Finally, the performance of our scheme is
evaluatedinSection6, andthepaper is concludedinSection7.
2 RELATED WORK AND OUR CONTRIBUTIONS
2.1 Review of Network Programming
Deluge [2], currently distributed as part of TinyOS, is one of
the most popular multihop network programming proto-
cols. In Deluge, program updates are divided into fixed-size
pages, with each page further divided into fixed-size packets.
Packets are the basic transmission units. Deluge employs a
three-stage (advertise-request-update) process to propagate
a 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 and
Engineering, 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, CSIRO
ICT 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:
tmc@computer.org, 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 are
allowed to forward the pages that they have completely
received without waiting for the receipt of the whole
program update. However, pages are received sequentially,
i.e., a node cannot forward a page without having received
all previous pages.
Other network programming protocols include MOAP
[3], MNP [4], and incremental programming [5]. MOAP
adopts the publisher-subscriber mechanism to disseminate
program updates among neighbor nodes. It focuses on
simplicity of network programming and does not use a
pipeline to propagate updates, so the nodes in MOAP have
to wait for the entire program update before further
propagation. In MNP, program update propagation is done
by having each node compete with its peers. Nodes that
were unsuccessful in a propagation attempt are put into
sleep for a time period, and compete again when this time
elapses and they wake up. MNP also exploits a pipeline
mechanism to enhance the efficiency. Incremental program-
ming employs the rsync algorithm [9] to reduce the
overhead of program updates by propagating differences
between old and new program images.
Although we have used Deluge for our reference
implementation, our scheme can be extended to other
popular network programming protocols, with the assump-
tions listed in Section 3.2. In the rest of this paper, unless
otherwise specified, we assume that Deluge is used as the
network programming protocol.
2.2 Existing Work on Secure Network Programming
Since the program image is composed of pages, and each
page consists a series of packets, secure network program-
ming protocols have typically computed a hash function of
the last packet [10] or the last page [11], and then, attached
this hash to the previous packet or page. The packet or page
with the hash appended is then itself hashed and this hash
value is attached to the previous packet or page. This
process is continued until the first packet/page is reached.
The first packet or page is signed with the private key of the
base station. Each receiving sensor node verifies the first
packet or page with the base stations public key, then
recursively authenticates each packet or page using the
hashed value from the predecessor packet/page until the
entire 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 for
packet authentication. However, in most cases, whether
they are recursive or a variant such as a Merkle tree, all are
based on the use of a digital signature to sign the first
packet or page. There are three problems associated with
this approach. First, signature verification incurs a compu-
tation overhead, which is a concern given the limited power
resources of sensor nodes. Second, memory usage required
to include the signature is significantly higher, as shown in
Figs. 12 and 13. Third, these approaches require the number
of data packets to be known in advance of the network
programming process, since they construct a hash chain
which starts from the last data packet and works back to the
first. This requirement limits the expansion of these
approaches to other broadcast applications where the
number of broadcast packets is not known in advance.
Jaleel et al. proposed one-way key chain to ensure the
confidentiality of program updates [13] without public-key
cryptography. Their scheme does not, however, support
multihop program propagation. Recently, Lanigan et al.
have proposed an enhancement of Sluice by exploiting
symmetric cryptography [14], [15]. However, the overhead
issues such as power consumption have not been fully
addressed. Hyun et al. [16] employed an architecture
similar to Dengs work [12]. In addition, they proposed a
weak authenticator based on digital signature to counter a
signature-based DOS attack. Their scheme is similar to the
other schemes in [10], [11], [12] in terms of overhead as they
also rely on the digital signature to bootstrap the network
programming process.
Perrig et al. proposed j-TELSA [17] to authenticate
broadcast 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 to
authenticate program updates since the program image is
broadcasted in packets. However, j-TELSA requires loose
time synchronization among sensor nodes, which leads to
more complicated measures to secure synchronization. In
addition, the sensor nodes cannot authenticate packets
immediately, but must wait until the respective keys are
disclosed, resulting in excessive verification latency and a
requirement 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 not
required to bootstrap the network programming
process. Instead, multiple distinct one-way key
chains are distributed to the nodes based on their
hop 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 attack
mechanism in multihop networks. We propose a
simple-to-implement prevention mechanism and
present an initial analysis of the mechanism.
. Power consumption evaluation. Power conservation is
imperative in WSNs. To the best of our knowledge,
we are the first to evaluate power consumption of
secure network programming schemes through the
use of Power Tossim [19].
. Immediate verification. In our scheme, no time
synchronization among sensor nodes is required,
and consequently, the packets of a program update
can be verified immediately as they are received.
. Extensibility to other broadcast application in WSNs. To
our knowledge, all existing methods to securing
network programming [10], [11], [12] are data-
dependent. The implication of this is that the
number of packets in a base station broadcast must
be known beforehand. This information is required
by the base station to insert the initial digital
signature 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 the
number of broadcast packets. The only proviso is
that the base station must generate long enough key
chains to cover the lifetime of the WSN. This
property 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 WSN
authentication [20]. They argued that any broadcast
authentication scheme in WSNs can only provide any six
of them at most. We provide a description of the properties
that our scheme meets.
. Resistance to node compromise: Our scheme is resilient to
node compromise regardless of the number of
compromised nodes, as long as the subset of non-
compromised nodes can still forma connected graph.
. Low computational overhead: Our scheme employs
symmetric cryptography to authenticate broadcast
program updates. As a result, the computational
overhead is relatively low compared to the existing
work in secure network programming [10], [11], [12].
. Low communication overhead: In our scheme, the
communication overhead depends on the number
of hops needed to reach all nodes in the network. The
analysis of this is further discussed in Section 5.1.
. Robustness to packet loss: Our scheme inherits robust-
ness to packet loss from underlying protocol
components. For example, Deluge itself provides
reliable data dissemination.
. Immediate authentication: Time synchronization be-
tween base station and sensor nodes is not required
in our scheme. This allows immediate authentication
of packets as they are received.
. Messages sent at irregular times: Since our method
does not require time synchronization, no assump-
tions are made about the time interval between
consecutive packets.
. High message entropy: Our scheme also makes no
assumptions about the content of the message itself
or its entropy.
3.2 Assumptions
Our scheme is based on the following assumptions:
. The base station cannot be compromised, and is
trusted. In Deluge, the base station is the origin of all
legitimate program updates. If it were not trusted,
nothing else in the WSN could be trusted.
. The base station has unlimited computational power
compared with sensor nodes.
. We assume that the wireless sensor network has a
static topology and the nodes are evenly distributed
within this topology.
. If a node has / disjoint paths to the base station,
then it is protected against / 1 compromised
nodes in our scheme. In other words, given any
healthy node which has / one-hop neighbors, an
adversary can compromise at most / 1 neighbors
without compromising . The value of / depends
on our deployment model, which will be further
discussed in Section 5.3.
. Attacks from an adversary with resources able to
compromise the base station are out of scope of this
paper. Such an adversary could compromise or
replace sensor nodes, allowing the compromised
sensor nodes to alter or delay packets. No security
mechanism in the network programming protocol
could stop such an attack unless tamper-proof
hardware is used.
. In our scheme, we do not consider Denial of Service
(DOS) attacks such as jamming [21], [22] or power
depletion attacks [16].
. We assume that all packets are delivered in correct,
sequential order. Out-of-order packet delivery is not
considered since the network programming service
employed is assumed to buffer and pipeline on page
boundaries and use selective negative acknowledg-
ments to request retransmission of missing packets.
Even though compromised nodes can resequence
forwarded packets, our scheme includes these
sequence 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 network
programming scheme. As described in Section 2.1, Deluge
has a hierarchical organization of program images (pro-
gram images ! pages ! packets). Our scheme works at
the 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 are
provided in Table 1. The two phases of our scheme are
presented 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] to
secure the Deluge protocol. Hash chains
1
are based on a
function H with the property that its computation is easy,
whereas its inverse H
1
is extremely difficult to compute. A
hash chain with length 1 is generated by applying H to an
initial element repeatedly for L times (i.e., 80 i 1. 1
, o. 1
i.,
H1
i1.,
, as shown in Fig. 1). The last value
after H has been applied 1 times is called the committed
value of the hash chain (see Fig. 1).
Before the sensor nodes are deployed, the base station
constructs o hash chains. It generates o distinct random
seed numbers and computes a one-way hash chain with
length of 1 1 starting from each seed, as shown in Fig. 1
(the 1 i 1th output of hash function derived from ,th
random seed number is denoted as 1
i.,
).
Sensor nodes are divided into o groups according to
their hop distance to the base station (see Fig. 2). The
committed value of the ith key chain (1
0.i
in Fig. 1),
corresponding to the hop distance, is predistributed to
nodes in the ith hop group before they are deployed. A
secure method suitable for key distribution before node
18 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 1, JANUARY 2011
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 a
Diffie-Hellman key exchange protocol [8], and
. key agreement between the base station and all
sensor 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 1
0
. 1
1
. . . . 1
11
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 (1
0
). The committed value of the
first key chain (1
0.1
in Fig. 1) is used to encrypt the next key
element in the order of key dissemination (1
1.1
in Fig. 1).
The encrypted result (1
1
0.1
1
1.1
) is the key update segment
for the first hop group. Then, 1
1.1
is concatenated with 1
0
and the result is hashed, yielding the packet authentication
segment (H1
0
k1
1.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 1
0
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
TAN ET AL.: SECURE MULTIHOP NETWORK PROGRAMMING WITH MULTIPLE ONE-WAY KEY CHAINS 19
Fig. 1. Establishment of multiple one-way key chains.
Fig. 2. Grouping of nodes when o 2,
1.2...
are nodes in the one-hop
group, while 1
1.2...
are nodes in the two-hop group.
TABLE 1
The Notations in Section 4 and Section 5
Fig. 3. The packet preprocessing for the first data packet: 1
0
0

1
0
kT
0.o
kl
0.o
k . . . kT
0.1
kl
0.1
, where T
0.,
H1
0
k1
1.,
. l
0.,
1
10.,
1
1.,
.
80 , o.
2. Key agreement protocols in the WSNs are out of the scope of this
paper. Interested readers are recommended to refer to [24].
packet preprocessing result (1
0
i
) for the ith (8i. 0 i < 1)
packet (1
i
) propagated to o hops is
1
0
i
1
i
kT
i.o
kl
i.o
k . . . kT
i.1
kl
i.1
.
where
T
i.,
H1
i
k1
i1.,
. 1
and
l
i.,
1
1
i.,
1
i1.,
. 2
The complete mechanism of packet preprocessing is
illustrated in Fig. 4, while the complete verification of
ith packet in node A ( 2 G
,
) is shown in Algorithm 1.
3
Algorithm 1. The i
t/
1 i 1 packet(1
i
) verification in
node(A) where 2 G
,
1 , o
1: base station: 1cn occtioi i, ( 1
1
i1.,
1
i.,

2: base station: 1
i 1
i.,
( H1
i
k1
i.,

3: base station: 1
i
0
( 1
i
k1
i 1
i.,
k1cn occtioi i,
4: base station ! : 1
i
0
5: 1
i
0
has been propagated by , 1 nodes
6: : receive 1
0
i
8 2 G
,
group
7: if H1
1
i.,
1cn occtioi i, 1
i.,
then
8: : 1
i1.,
( 1
1
i.,
1cn occtioi i,
9: : remove 1cn occtioi i, from 1
0
i
10: if H1
i
k1

1
i 1
i.,
then
11: : remove 1
i 1
i.,
from 1
0
i
12: : accept 1
i
13: : advertise 1
i
14: else
15: : drop 1
0
i
16: end if
17: else
18: : drop 1
0
i
19: endif
20: if 1
i
is requested then
21: ! : 1
0
i
22: 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., 1
0
0
1
0
kT
0.1
kl
0.1
), 1
0
0
is transmitted to
nodes in the first hop group. After retrieving the correct
group information from 1
0
0
(i.e., the sensor node parses the
right fields T
0.1
and l
0.1
), the sensor nodes verify the key
update segment (l
0.1
) and packet authentication (T
0.1
) segments
as follows:
. key update segment: The sensor node decrypts l
0.1
with 1
0.1
, i.e., 1
1
0.1
l
0.1
. The sensor node checks if
H1
1
0.1
l
0.1
is the same as 1
0.1
(line 7 in
Algorithm 1). If it is, the authenticity of l
0.1
is
ensured and 1
0.1
is replaced by 1
1.1
for the next
packet verification (line 8 in Algorithm 1). Otherwise,
this packet is discarded (line 17 in Algorithm 1).
. packet authentication segment: After the sensor node
retrieves the authenticated 1
1.1
from l
0.1
, it per-
forms H1
0
k1
1.1
to see if it matches T
0.1
(line 10 in
Algorithm 1). If it does, the integrity of packet is
assured (line 12 in algorithm 1). Otherwise, this
packet is discarded (line 14 in Algorithm 1).
4.2.3 Justification of Key Update Segment and Packet
Authentication Segment
. Key update segment (l
i.,
in Fig. 4). This segment is
needed for three reasons. First, the key in ,th group
can be dynamically updated by packets (line 8 in
Algorithm 1) without time synchronization between
base station and sensor nodes. With the key
updated, compromised nodes cannot launch a
replay attack (lines 17-19 in Algorithm 1). Second,
since different hop groups of nodes employ different
one-way key chains, attacks on compromised nodes
from different groups can be prevented (especially a
man-in-the-middle attack).
4
Third, the encrypted
part contains the next element of the respective key
in the dissemination order (see Fig. 1), so the
updated key can be verified as a consequence of
20 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 1, JANUARY 2011
Fig. 4. Packet preprocessing in the base station: l
i.,
1
1i.,
1
i1.,
,
T
i.,
H1
i
k1
i1.,
.
3. For clarity, the segments required for other groups of downstream
nodes are not shown.
4. The attack from compromised node in the same group will be
investigated in Section 5.2.
the one-way property of the hash chain (line 7 in
Algorithm 1).
. Packet authentication segment (T
i.,
in Fig. 4). Integrity
of the packet content is ensured with this segment.
Had 1
i
been altered, the verification of this segment
(line 10 in Algorithm 1) would fail (lines 14-16 in
Algorithm 1). This segment serves as a signature
from the base station. However, due to the absence of
nonrepudiation in symmetric cryptography, this
signature could be forged by a compromised node.
However, the difficulty of forging this signature is
made great enough by selecting appropriate design
parameters (e.g., size of this segment) (see Sections
5.1 and 5.4).
5 DISCUSSION
In this section, we analyze potential attacks that an
adversary might launch and the corresponding counter-
measures our scheme employs to maximize the difficulty in
launching such attacks.
5.1 Trade-Off between Brute Force and Costs in Our
Scheme
Brute-force attack is a method to defeat a cryptographic
scheme by trying every possible key to discover the secret
key shared by communicating parties. This is particular
problem in WSNs because sensor nodes are resource-
impoverished and there is a trade-off between security
requirements (in terms of key length and computation) and
resource availability. For example, the maximum packet
size in TinyOS is 128 bytes. Our scheme has two
cryptographic operations: the SHA-1 hash function and
the RC5 encryption/decryption.
. SHA-1 has a default size of 20 bytes [25]. This is
around 16 of the maximum packet size in TinyOS.
On the one hand, we need to truncate / bytes out of
20 for the size of packet authentication segment so
that it would not consume too much resource in the
sensor nodes. On the other hand, we need to ensure
that the hashed value is robust to brute-force attack.
Our scheme truncates the first 8 bytes from the
hashed value in the one-way key chains.
. RC5 encryption/decryption has a key size of 8 bytes due
to the availability of open source in Tinysec [35].
5
For a typical sensor node (the Tmote), the time taken for
these operations are: RC5 encryption/decryption takes
7.2 msec, and the SHA-1 hash operation takes 14 msec
[35], [10].
Assuming that the size of packet authentication segment
is / bytes, the average time taken to discover a key by brute-
force depends on cracking either the key update segment or
the packet authentication segment in Section 4.2. This
means that a compromised node needs to either brute force
decrypt one RC5 encryption and one SHA-1 hash operation
(line 7 in Algorithm 1) or one SHA-1 hash operation (line 10
in Algorithm 1). The time taken to brute force our scheme
(T
1oioc
/ in millisecond) is
T
/intc1oicc
/ iii14 2
8/1
. 21.2 2
63
1 / 20.
3
If the packet is propagated through o hops, the first hop
between the base station and its immediate neighbors will
have the maximum number of bytes to transmit. The
communication overhead (\
Coiiniicotioi
/ in byte) is
\
Coiiniicotioi
/ / 8o. 4
The maximumpacket size inTinyOS is 128 bytes, the payload
of a Deluge packet is 23 bytes, andthe header is 5 bytes [2]. So,
the maximumnumber of hops our scheme can support given
one base station is
o/
100
/ 8
" #
. 5
As to the memory usage, the average number of extra
bytes stored in each node (\
`cioin
/ in byte) in our
scheme is
\
`cioin
/
/ 8o/ 1
2
. 6
Table 2 lists how / affects T
forge
, o, and \
memory
in our
scheme. When / 4, it would take around 347 days for
compromised node to brute force our scheme. In addition,
the minimum memory overhead can be achieved when
/ 4. Most practical wireless networks will be restricted to
fewer hops than 4 since the throughput would be
significantly degraded for larger hop counts. This hop limit
can be ensured without restricting the overall network size
by deploying a hybrid sensor network [26]. Strong crypto-
graphic algorithms such as RSA can be used in the
communications between base stations in an upper tier,
while our scheme could be employed between base station
and sensor nodes or among sensor nodes in the lower tiers.
5.2 Sybil Attack
In order to reduce power consumption and computational
overhead, we do not adopt any asymmetric cryptography in
our scheme. Employing only symmetric cryptographic
primitives comes with the price that nonrepudiation cannot
be fully ensured. One possible attack exploiting this is the
Sybil Attack, which is a falsified identity attack first
proposed in [27]. For example, in Fig. 5a, the compromised
TAN ET AL.: SECURE MULTIHOP NETWORK PROGRAMMING WITH MULTIPLE ONE-WAY KEY CHAINS 21
TABLE 2
Overhead Analysis for Algorithm 1 and
Brute-Force Attack on Our Scheme
5. We adopt this key length from Tinysec in our implementation only as
a proof of concept. Our scheme can be adapted to a required cryptographic
strength by using a much longer key.
node (
1
) in G
,
can exploit the condition that it has the
same key as other nodes in G
,
. Hence, after it receives 1
0
i
from nodes in G
,1
(e.g., 1
1
) and finishes the verification for
key update segment (lines 7-9 in Algorithm 1), it can forge a
malicious packet (1
i
0
/od
) as
1
i
0
/od
1
i
/od
kH1
i
/od
k1
i.,
k1cn occtioi i,.
Then,
1
can broadcast the above malicious packet to its
neighbors in the same group (e.g.,
2
) claiming to be a node
from G
,1
.
However, the above Sybil attack is difficult to launch
since it has a strict timing requirement to be successful.
First,
1
has to wait for the packet from G
,1
so that it can
obtain 1
i.,
. 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 1
i
0
/od
as above. Last, it needs to transmit
1
i
0
/od
to
2
.
Since the time taken for RC5 and SHA-1 is 7.2 ms [35]
and 14 ms [10], respectively, the time for Algorithm 1
(T
algorithm 1
in milliseconds) can be computed as
T
algorithm 1
14 2 7.2 35.2 ms. 7
As to the packet delivery time between 1
2
and
2
, 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 (
100
310
8
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 (T
oic /oj
in milliseconds) is
T
oic /oj
2
128 8
250 10
3
8.2 ms. 8
With the values from (7) and (8), the total time taken for

1
to launch a Sybil attack (T
:n/i|
in milliseconds) is
T
sybil
T
1
1
!:1
0
i
T
algorithm 1
T

1
!:1
i
0
/od
51.6 ms.
According to Section 3.2, there will be at least one
healthy node in G
,1
connected to
2
(1
2
in Fig. 5a). The
time taken for a legitimate update (T
authentication
in milli-
seconds) is
T
authentication
T
1
2
!:1
0
i
T
line 7
8.2 21.2 29.4 ms.
for
2
to update 1

2
(e.g., from 1
2
in Fig. 5a). This is much
shorter than T
on/i|
. In order to make a Sybil attack
successful, an adversary must do the following:
. Launch the jamming attack or produce interference
in order to delay the packet delivery from the
healthy upstream nodes so that the adversary has
sufficient time to discover the session key to
construct a malicious packet forgery. Such an attack
could definitely disrupt not only the network
reprogramming but also other network operations.
However, jamming attacks and network interference
are beyond the scope of this paper. Several effective
approaches have been reported [21], [22] to detect
and defend against them.
. Employ a PC-class device to accelerate malicious
packet forgery so that the malicious packets reach
the downstream neighbors before the correct packets
do. In this case, the length of the symmetric key can
be made sufficiently large to ensure a significant
delay before an adversary could brute force decrypt
the key even with PC-class capability. For example,
the average time required to exploit 60 percent of the
64-bit RC5 key space with a contemporary computer
is 1,470 days [29] certainly long enough for the
correct packets to reach downstream nodes. If node
compromise was available to adversary with a PC-
class device, the adversary could always connect the
sensor nodes via the serial port of his/her pc-class
device and reprogram the nodes physically. This
attack would be much simpler and more powerful
than accelerating malicious packet forgery. More-
over, no security mechanism in network program-
ming protocols could prevent this attack unless a
tamper-proof hardware was used for sensor nodes.
. Completely compromise all upstream neighbors of

2
in G
,1
(i.e., network partition attack). Such an
effort would significantly increase the attack cost for
an adversary if the density of nodes in the WSN is
high. It also makes detection of an adversary easier
by requiring more nodes to be compromised. This
attack will be further discussed quantitatively in
Section 5.3.
22 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 1, JANUARY 2011
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 we
further discuss in Section 5.4.
5.3 Security Analysis of a Network Partition Attack
In Section 3.2, the nodes are assumed to be uniformly
distributed. Thus, the number of nodes in G
i
(i
i
) is
i
i

1
2
i
2
i 1
2
`
o1
2

2i 1`
o
2
1 i o. 9
Given any node / where / 2 G
i
(Fig. 6a), we can assume
i 11 i
/
i1. In our scheme, node / will receive
broadcast packets from nodes in G
i1
(i.e., upstream
neighbors of node /) and relay broadcast packets to nodes
in G
i1
(i.e., downstream neighbors of node / ). Area
g
1C1
in Figs. 6a and 6b is where upstream neighbors and
downstream neighbors of node / are located, respectively.
If an adversary wants to broadcast a malicious packet to
/ in our scheme successfully, it will have to compromise all
the upstream neighbors of /. Otherwise, the compromised
node will not have enough time to forge a malicious packet
to 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 / if
node / is compromised.
If we assume that the sensor nodes are uniformly
distributed, the estimated number of upstream neighbors
of node /(1
nj
i
/
) is
1
nj
i
/
i
i1

ico
g
1C1
icoG
i1

.
Using (9) and the geometry shown in Fig. 6a, the above
equation becomes
1
nj
i
/

`i 1
2
10i
/
1ui
/
i
/
i 1 sin0i
/

1o
2
.
10
where
0i
/
arccos
ii 21
2
i
2
/
2i 11i
/

.
and
ui
/
arccos
i2 i1
2
i
2
/
21i
/

.
where 0i
/
and ui
/
are the functions of 0 and u in Fig. 6a
in terms of i
/
, respectively.
Similarly, the estimated number of downstream neigh-
bors of node /(1
doni
i
/
) in Fig. 6b is
1
doni
i
/

` ui
/
1ii
/
:ii0i
/
i
2
10i
/

1o
2
.
11
where
0i
/
arccos
i
2
11
2
i
2
/
2i1i
/

.
and
ui
/
arccos
1 i
2
1
2
i
2
/
21i
/

.
Figs. 7a and 7b illustrate the result given by (10), (11),
respectively, when ` 1.000, o 4, and 1 100 [28]. An
adversary will need to compromise 10-15 upstream neigh-
bors to contaminate node / if it resides in the middle of the
hop group (i.e., i
/
i 121). The greater i is, the more
difficult it is for an adversary to cause network partitions and
inject broadcast packets for nodes in G
i
since there are more
upstream neighbors it needs to compromise (see Fig. 7a). On
the other hand, although an adversary could affect more
downstream neighbors by compromising nodes closer to the
base station (e.g., i 1 in Fig. 7b), it may be more difficult for
TAN ET AL.: SECURE MULTIHOP NETWORK PROGRAMMING WITH MULTIPLE ONE-WAY KEY CHAINS 23
Fig. 6. Connectivity analysis:
g
1C1 is the area where the neighbor nodes receive/forward program updates from node /. (a) Upstream neighbors of
node /. / 2 G
i
. (b) Downstream neighbors of node /. / 2 G
i
.
an adversary to get physical access to them because it is
easier for the base station to keep them under protective
surveillance due to their shorter distance away.
5.4 Tunnel (Wormhole) Attack
The tunnel attack was initially proposed in [18]. In this
attack, an adversary establishes a low-latency unidirectional
tunnel, such as a long-range wireless link or wired link,
between two compromised nodes in the network that are
not within communication range of each other (see Fig. 5b).
One of the compromised nodes (
1
) records one or more
packets and tunnels them via the link to the other end of
tunnel (
2
). The other compromised node (
2
) can replay
them into the network in an appropriate manner. In the
context of network programming, a tunnel can assist an
adversary to inject malicious program updates to circum-
vent the detection by security schemes which do not require
time synchronization or asymmetric cryptography in WSNs.
In our scheme, the compromised node (
2
in Fig. 5b) will
request its collaborator (
1
in Fig. 5b) to transmit the packet
(1
0
i
) via the tunnel whenever 1
0
i
is available. Since the tunnel
is a shortcut from
1
to
2
,
2
will get 1
0
i
much earlier than
its neighbors in the same group. Consequently,
2
can
launch a Sybil attack before its neighbors receive 1
0
i
.
In order to counter this attack, let us briefly review the
packet verification process in Algorithm 1. After a node
successfully updates the key and authenticates a packet, it
will remove the respective segments for further propagation
(lines 9 and 11 in Algorithm 1). Since
2
receives this packet
from the tunnel, the key update segment and packet
authentication segment for the intermediate nodes
(1
1
. 1
2
. . . 1
/
in Fig. 5b) will still be attached to 1
0
i
since
these segments have not been verified by the intermediate
nodes. As a result,
2
will need to remove all these
segments before it can forge 1
i
0
/od
.
In computer networks, a security designer can use
computational client puzzles that the attackers will have
to solve before they can mount an attack. One such example
is that a server can distribute small cryptographic puzzles to
its clients to solve so that an attacker, disguised as a
legitimate client, cannot send unlimited redundant requests
to deplete the servers resources [30]. We have designed a
new puzzle for
2
(i.e., the attacker) to solve before it can
remove these segments correctly, instead of employing time
synchronization as in [18]. In the base station, segments are
attached as shown in Fig. 8. On receiving 1
0
i
, each node will
retrieve 8 bytes from the end of 1
0
i
for key update segment
and another / bytes for the packet authentication segment,
where / denotes the size of packet authentication segment.
If / is fixed to 4 bytes as discussed in Section 5.1,
2
will
know that it needs to remove 12, bytes to retrieve 1
i.,1
,
where , is the number of nodes the tunnel has skipped over.
In order to increase the difficulty for
2
to retrieve 1
i.,1
,
instead of / being a constant, / is now assigned a random
24 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 1, JANUARY 2011
Fig. 7. Expected number of neighbors distribution for node / in G
i
. (a) Number of upstream neighbors of /. (b) Number of downstream neighbors of /.
Fig. 8. Puzzle to counter a tunnel attack: the size of the packet authentication segment (cross-hatched) is randomized. T
i.,
and l
i.,
are defined in (1)
and (2), respectively.
2
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 / is
randomized by the base station for nodes in each group,

2
needs to guess
P
,
|1
8 /
|
before it can retrieve 1
i.,1
.
For the intermediate nodes (1
1
. 1
2
. . . ), there is no
significant overhead incurred when the size of the packet
authentication segment is randomized, since they only have
to make several more comparisons on line 10 in Algorithm 1.
However, the randomization forces
2
to try to remove
every possible value of
P
,
|1
8 /
|
from 1
0
i
so that it can
retrieve 1
i.,1
. As to the number of possible values in
P
,
|1
8 /
|
, we have the following lemma when / is
randomized for each hop group:
Lemma 1. Assume that the set of values for /
|
(i.e., size of packet
authentication segment for 1
0
|
) is T, jTj i, and , is the
number of nodes the tunnel has skipped over. 1,. i denotes
the number of distinct values for
P
,
|1
8 /
|
given , and i.
If the following condition
6
is met:
8T
1
. T
2
T. jT
1
j jT
2
j. T
1
6 T
2
.
X
T
1
6
X
T
2
.
We have
1,. i
P
,
i0
1i. i 1. i 1.
1. i 1.
&
12
Proof. When jTj 1, it is equivalent to the case where /
|
is
fixed. Hence,
P
,
|1
8 /
|
has only one result (i.e.,
1,. i 1. i 1).
When jTj 1, 1,. i is equal to the number of
combinations in the following bin-and-ball problem.
There are , bins (number of nodes a tunnel has
skipped over) and i balls (number of possible values for
the size of the packet authentication segment). Each bin
is randomly assigned one ball (the base station will
randomly choose the size of packet authentication
segment for each group). This bin-and-ball problem
must satisfy the following conditions:
. Each bin can only contain one ball, i.e., there can
be only one value for the size of each packet
authentication segment.
. One ball can be placed into multiple bins, i.e.,
multiple packet authentication segments for
nodes in different groups can be of the same size.
. The order in which the balls are placed into bins
does not make any difference as long as the same
subset of balls is used. For example, if T
f2. 5. 7g. , 3,f277g. f772g. f727g are all counted
as one combination because
P
,
|1
8 /
|
is
independent to the order of /
|
when they are
summed. In addition, if 8T
1
. T
2
T. jT
1
j jT
2
j.
T
1
6 T
2
.
P
T
1
6
P
T
2
, 1,. i is not subject to the
specific elements in T but jTj and ,.
When jTj is incremented from i 1 to i, 1,. i will
have the relationship with 1i. i 10 i , as shown
in the following table: The ith row represents the case
when , i 1 bins contain the first ball (i.e., Ball
1
), and
the other i 1 balls are placed in the remaining i 1 bins.
The total number of combinations (1,. i) is the
summation of all rows in the above table. In the
i 1th row, there are combinations for i 1 balls
into i bins, which is 1i. i 1. So, we sum up all rows:
1,. i 10. i 1 11. i 1 1,. i 1
|{z}
,1 terms

X
,
i0
1i. i 1.
ut
Based on Lemma 1, we have the following theorem for
1,. i:
Theorem 1. If Lemma 1 holds,
1,. i C
,
,i1
. 13
where
C
/
o

o!
/!o /!
.
Proof. We prove this theorem through mathematical induc-
tion. When i 1. 8, 2 ZZ

, 1,. i C
,
,
1 as in (12).
When i 1, we assume that there exists a // 2 ZZ

.
/ i, so that 8: 2 ZZ

. : /,
1,. : C
,
,:1
. 14
According to (12), we can simplify 1,. / 1 with (14)
and 8o. / 2 ZZ

. o ! /. C
/1
o
C
/
o
C
/
o1
,
1,. / 1
X
,
i0
C
i
i/1
C
0
/1
C
1
/
C
2
/1
C
,
,/1

C
0
/
C
1
/

C
2
/1
C
,
,/1

C
1
/1
C
2
/1

C
3
/2
C
,
,/1

C
2
/2
C
3
/2

C
,
,/1

C
,1
,/1
C
,
,/1
C
,
,/11
.
15
The above induction can start from / 1 until
/ i8, 2 ZZ

.
TAN ET AL.: SECURE MULTIHOP NETWORK PROGRAMMING WITH MULTIPLE ONE-WAY KEY CHAINS 25
6. For example, T f3. 5. 7g is not the set meeting this condition since
when T
1
f3. 7g. T
2
f5. 5g, jT
1
j jT
2
j. T
1
6 T
2
.
P
T
1

P
T
2
10. T
f2. 5. 7g is the set meeting this condition.
When , 1, according to (12), we have
11. i 10. i 1 11. i 1
10. i 2 10. i 2 11. i 2

10. 1 10. 1 10. 1
|{z}
i terms
i C
1
i
.
This is equal to the respective value in (13) when
, 1. 8i 2 ZZ

.
When , 1, we assume that there exists // 2 ZZ

. /
, so that 8i 2 ZZ

1/. i C
/
/i1
. 16
According to (12), we can simplify 1/ 1. i with
(16) and (15):
1/ 1. i 1/ 1. i 1 1/. i
1/ 1. i 2 1/. i 1 1/. i

1/ 1. 1
X
i
i2
1/. i
C
/
/

X
i
i2
C
/
/i1

X
i
i1
C
/
/i1

X
i
i1
C
i1
/i1
C
i1
/i
C
/1
/1i1
.
The above induction can start from / 1 until
/ ,8i 2 ZZ

.
So, Theorem 1 holds with respect to i and ,. tu
Obviously, the expected number of guesses
2
needs to
make (i.e., b
1,.i
2
c) is exponential in i. Because i is
determined in our scheme while , is determined by the
adversary, we can make i large enough so that
2
incurs a
high latency due to brute-force cost on
P
,
|1
8 /
|
even if
the adversary reduces the length of tunnel (i.e., ,) in an
attempt to shorten the latency. Assume that the latency via
the tunnel is 0,
1
2 G
1
, and
2
2 G
,1
, we can estimate the
total time (in milliseconds) taken for
2
to launch a Sybil
attack with the assistance of the tunnel:
7
T
tunnel
, 21.2
C
,
,i1
2
$ %
43.4. 17
The estimated time (in milliseconds) for 1
0
i
to reach nodes
that will be affected by
2
is
T
authentication
, 43.4, 29.4 ms. 18
Fig. 9 shows the values in (17) and (18) in terms of tunnel
length (,). When i ! 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 to
attempt to accelerate the cryptographic operations on either
endof thetunnel before thecorrect datapacket arrived. Inthat
case, jTj (i.e., the number of possible authentication segment
lengths) 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 of
sensor nodes in our scheme. The base station has informa-
tion about which key will be used for authentication in each
group. We can adopt MIB [24] to predeploy the shared keys
from the base station to a new node.
5.5.2 Length of Key Chains
The length of the key chains requireddepends on the number
of program updates the base station needs to broadcast. In
Deluge, one page has 48 packets [2] and there are 24 pages
for one program image in our scheme. So, the total number
of packets we need to send for one program image is
1,152 packets. Since the base station is assumed to have
unlimited resource compared to sensor nodes, the length of
key chains could be sufficiently long to cover the life time of
sensor nodes (e.g., 1 2 10
5
). Alternatively, we can adopt
multilevel key chains to update the committed values of key
chains securely [31]. We leave this to our future work.
6 IMPLEMENTATION AND PERFORMANCE
EVALUATION
We implemented our scheme as an extension to the Deluge
network programming protocol that is distributed with
TinyOS. In Deluge, the base station programs are written in
Java and run on a PC. These Java programs are used to
construct and broadcast the new code dissemination
packets into the WSN. The programs for the sensor nodes
are nesc [32] programs. They are used to receive the packets
of broadcast program images and update the appropriate
node program image slots.
On the base station side, we use the JCE provider in the
Bouncy Castle Crypto APIs [33] for hash function (SHA-1),
key generation, and packet encryption (RC5). On the sensor
node side, we employed the hashing operation from
TinyECC [34] and packet decryption from Tinysec [35]. The
committed values of the key chains are generated in the base
station and predistributed on the nodes in the corresponding
hop group before deployment. The operations of packet
26 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 1, JANUARY 2011
Fig. 9. Latency comparison between legitimate broadcast program
updates and tunnel attack in our scheme.
7. The operations required to make one guess are one hash operation and
one RC5 decryption in line 7 of Algorithm 1.
preprocessing are implemented in ImageInjector.java, while
the operations of packet verification are implemented in
DelugePageTransferM.nc. The reference codes for the base
stations and sensor nodes are available in [36] and [37],
respectively.
Our evaluation consists of two parts. We first evaluated
our scheme using the TOSSIM [38] simulator in Section 6.1.
Then, we tested our scheme in a network of Tmotes [6] in
Section 6.2.
6.1 Simulation Results
In Section 6.1.1, we compare our scheme with the original
Deluge [2] and Sluice [11] in terms of end-to-end latency.
Then, in Section 6.1.2, we evaluate the power consumption
in our scheme through PowerTossim [19], which is a plug-
in module for TOSSIM.
Since our work builds on topology knowledge, we have
the following simulation settings in Table 3.
6.1.1 End-to-End Latency
In [11], the authors carried out their experiment for one-hop
image propagation. Given the data from [11], we compare
our scheme with Deluge [2] and Sluice [11] in Fig. 10a for
one-hop program update.
Sluice and our scheme both have linear scalability with
respect to update size, as shown in Fig. 10a. At the
beginning of program updates, our scheme has much lower
latency than Sluice because in Sluice, a sensor node has to
verify the digital signature for the first page of program
image. In our scheme, no asymmetric cryptographic
primitives are needed. As the number of transmitted pages
increases, the latency of Sluice increases more slowly than
our scheme since it authenticates the program image in a
granularity of pages rather than packets. The number of
symmetric cryptographic operations is significantly re-
duced, with the price that a single tampered packet can
lead to the failure of the entire page authentication. Despite
the decrease in the number of cryptographic operations,
sluice cannot completely make up for the significant delay
due to verification of the digital signature compared with
multiple key-chain methods for the first 30-page update.
Figs. 10b and 10c show the end-to-end latency in our
scheme for multihop program updates compared to Deluge
[2]. As number of nodes increases, the gap between Deluge
andour scheme increases due tothe number of cryptographic
operations in our scheme (Fig. 10b). The single-page latency
gap is smaller as the latency effect in the multiple-key chain
method is accumulative when all the pages are transmitted.
6.1.2 Power Consumption
The authors in [19] provided an energy model for the Mica2
only. Without an energy model available for other sensor
platform, we only analyzed our scheme for the Mica2 in
this section.
Figs. 11a, 11b, and 11c show the average power con-
sumption for CPU, radio, and EEPROM, respectively, to
complete a program update. The CPU power consumption
mainly depends on the design of verification process in each
sensor node (i.e., Algorithm 1). Hence, the scalability of the
network has least impact on it (see Fig. 11a) since the
verification process is independent of the number of nodes in
the WSN. The radio power consumption is proportional to
the number of hops in which the program update is
propagated, as analyzed in Section 5.1 (see (4)). As a result,
the respective curve for our scheme in Fig. 11b is roughly
linear in terms of number of nodes in the WSN. For
EEPROM, in addition to dissemination of the received
program image data, a sensor node needs to store authenti-
cation segments for downstream peers. So, the respective
power consumption depends on not only the number of
hops but also the hop distance of the sensor nodes. Hence,
there is a larger variance in power consumption by EEPROM
than by CPU or radio. Moreover, the power consumption of
EEPROM is highly dependent on network size.
6.2 Experimental Results
We installed our scheme in Tmote [6] nodes and compared
Deluge [2] and Sluice [11] with our scheme in terms of
TAN ET AL.: SECURE MULTIHOP NETWORK PROGRAMMING WITH MULTIPLE ONE-WAY KEY CHAINS 27
Fig. 10. End-to-end latency evaluation on single hop and multihop scenario in our scheme (Simulation). (a) One-hop program update. (b) Multihop
program update. (c) Page latency in multihop program update.
TABLE 3
Simulation Parameters
memory usage for TinyOS applications. We also conducted
a survivability test to evaluate the robustness of our scheme
in the presence of a malicious code injector. Finally, we also
measured the code dissemination rate on two types of
representative nodes in our scheme and compared it to
Deluge [2].
6.2.1 Memory Overhead
DelugeBasic in the TinyOS distribution is the simplest
application 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 key
updates and packet authentications for downstream nodes
are required. Most practical wireless networks will be
restricted to fewer hops than four since the throughput
significantly degrades for larger hop counts. In addition,
large deployments will be likely to form some kind of
hierarchy [26]. Hence, we measured the utilizations of ROM
and RAM in our scheme for up to four hops. The measure-
ment results for Deluge [2], Sluice [11], and our scheme (with
different hop version) are illustrated in Figs. 12a and 12b,
respectively. Since digital signature is not used in our
scheme, the memory overhead is less than that of Sluice
althoughthere is a linear increase onthe ROM/RAMusage as
the number of hops increases. Compared to Deluge, there is
up to a 6 and 1.5 KB increase in ROM and RAM usage,
respectively. In the Tmote platform, the ROM (i.e., program
flash 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 TMote
platforms. As described in Section 2, Sluice [11] has lower
memory overhead than the Berkeley method [10] and the
Colorado method [12] as it has a similar security structure at
the page level rather than at packet level. Thus, our scheme
would have significantly less memory overhead than both
the Berkeley method and Colorado method since our scheme
costs slightly less than Sluice.
In order to evaluate the memory usage of our scheme for
different applications, the programs Blink, SenseToLeds,
Oscilloscope, and TinyECC [34] were chosen for experiment
as they vary from the simplest application (i.e., Blink) to
fundamental sensing applications (i.e., SenseToLeds and
Oscilloscope) and even one of the most complex applications
in TinyOS published recently (i.e., TinyECC
8
). Figs. 13a and
13b show the memory usage of Deluge, Sluice, and our
scheme on these selected applications. The experiment
shows that our scheme will incur up to 5 KB of ROM and
1.5 KB of RAM more than that required by Deluge. In the
simple applications, our scheme has a slightly less memory
overhead than Sluice, while in the more complex applica-
tions, our scheme can have more significant memory savings
than Sluice by around 0.5 KB because our scheme does not
employ any asymmetric cryptography. The reason why
there is variation of the RAM usage in different applications
28 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 1, JANUARY 2011
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 signature
that can be flexibly configured and integrated into sensor network
applications. There are two types of operations in TinyECC: signer and
verifier.
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 code
as a component [2]. Consequently, the differences on RAM
usage in different applications are due to the design of the
applications themselves.
6.2.2 Survivability Test
We conducted the survivability test to confirm that our
scheme works as expected (i.e., a single malicious node
cannot inject arbitrary updates to its neighbors and cannot
tamper with the content of an authorized update, and then,
inject this modified update to other nodes). We simulated a
malicious node by placing a base station running Deluge to
inject code with the unprocessed key update or with the
unprocessed packet authentication. The Tmotes running
our scheme can detect a wrong key update or a mismatch
between the packet content and the packet authentication
field. As a result, the packets from this base station will be
dropped. Although the malicious base station in our
experiment can mount a battery drain attack by injecting
false packets to deplete the power of its neighbors, we have
left 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 to
the network size in Section 6.1.1, we also investigated how
code updates are propagated by individual nodes. We
selected two types of nodes: the one-hop neighbors of the
base station(thefirst hop) andthenodes four-hops awayfrom
the base station (the last hop). These two type of nodes are
expected to have a different latency for code dissemination.
We next showthe network programming rate with respect to
propagation time, using a code image of DelugeBasic.
Fig. 14 depicts the times at which these two type of nodes
finished disseminating a certain percentage of the program
image under both our scheme and Deluge [2]. As time goes
on, both types of nodes gradually receive the program
image from their upstream neighbors. Due to the hop
distances to the base station, the nodes four-hops away from
base station receive some of the pages when the neighbors
of the base station have already received the complete
program image. In our scheme, as nodes in each hop group
need to perform key updates and packet authentications,
the delays due to security operations are accumulated as the
program image propagates further in the network. In
Deluge, the propagation delay between these two types of
nodes is smaller since security operations are not carried out
in the intermediate nodes.
7 CONCLUSION
In this work, we proposed an authentication scheme to
secure multihop network programming with multiple one-
way hash chains. Instead of the expensive asymmetric
cryptographic primitives used in much prior work, our
scheme employs only symmetric cryptographic primitives,
in a circular geographic node deployment model. We
discussed possible attacks an adversary could mount on
our scheme and provided simple and effective counter
measures 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 is
the first power consumption evaluation of a security
scheme for network programming protocols. We also tested
our scheme on Tmote nodes in terms of the memory usage
and code dissemination rate. Our future work will include
the design of security models for network programming
TAN ET AL.: SECURE MULTIHOP NETWORK PROGRAMMING WITH MULTIPLE ONE-WAY KEY CHAINS 29
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 improved
scalability, secure update of multiple one-way key chains
when all the elements of the key chains have been
consumed, and also the design of countermeasures against
DOS attack.
ACKNOWLEDGMENTS
This paper is an extended version of the conference paper,
Secure Multihop Network Programming with Multiple
One-Way Key Chains, published in the Proceedings of the
ACM Wisec Conference, 31 Mar.-2 Apr. 2008, Alexandria,
Virginia.
REFERENCES
[1] I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, A
Survey 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 Data
Dissemination Protocol for Network Programming at Scale, Proc.
Intl Source Conf. Embedded Networked Sensor Systems (SenSys 04),
pp. 81-94, 2004.
[3] T. Stathopoulos, J. Heidemann, and D. Estrin, A Remote Code
Update Mechanism for Wireless Sensor Networks, technical
report, Univ. of California, Los Angeles, 2003.
[4] L. Wang, MNP: Multihop Network Reprogramming Service for
Sensor Networks, Proc. Intl Source Conf. Embedded Networked
Sensor Systems (SenSys 04), pp. 285-286, 2004.
[5] J. Jeong and D. Culler, Incremental Network Programming for
Wireless Sensors, Proc. IEEE Conf. Sensor and Ad Hoc Comm. and
Networks (SECON 04), pp. 25-33, 2004.
[6] Tmote Sky, Ultra Low Power IEEE 802.15.4 Compliant Wireless
Sensor Module Humidity, Light, and Temperature Sensors with
USB, http://www.moteiv.com/products/docs/tmote-sky-data
sheet.pdf, Aug. 2007.
[7] R.L. Rivest, A. Shamir, and L.M. Adelman, A Method for
Obtaining 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 the
Deluge Network Programming System, Proc. Intl Conf. Informa-
tion Processing in Sensor Networks (IPSN 06), pp. 326-333, 2006.
[11] P.E. Lanigan, R. Gandhi, and P. Narasimhan, Sluice: Secure
Dissemination of Code Updates in Sensor Networks, Proc. IEEE
Intl Conf. Distributed Computing Systems (ICDCS 06), pp. 53-63,
2006.
[12] J. Deng, R. Han, and S. Mishra, Secure Code Distribution in
Dynamically Programmable Wireless Sensor Networks, Proc.
Intl Conf. Information Processing in Sensor Networks (IPSN 06),
pp. 292-300, 2006.
[13] J. Shaheen, D. Ostry, V. Sivaraman, and S. Jha, Confidential and
Secure Broadcast in Wireless Sensor Networks, Proc. IEEE Intl
Symp. 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. Intl Conf. Distributed Computing Systems Workshops
(ICDCSW 07), p. 17, 2007.
[15] P.E. Lanigan, P. Narasimhan, and R. Gandhi, Tradeoffs in
Configuring Secure Data Dissemination in Sensor Networks: An
Empirical 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.
Intl 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. Intl Conf.
Mobile Computing and Networking (Mobilecom 01), pp. 189-199,
2001.
[18] Y.C. Hu, A. Perrig, and D.B Johnson, Packet Leashes: A Defense
against Wormhole Attacks in Wireless Networks, Proc. IEEE
INFOCOM, 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 Sensor
Network Applications, Proc. Intl Source Conf. Embedded Net-
worked Sensor Systems (SenSys 04), pp. 188-200, 2004.
[20] M. Luk, A. Perrig, and B. Whillock, Seven Cardinal Properties of
Sensor Network Broadcast Authentication, Proc. Workshop
Security 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-Area
Mapping Service for Sensor Networks, Proc. IEEE Intl Real-Time
Systems Symp. (RTSS 03), pp. 286-297, 2003.
[22] W. Xu, W. Trappe, and Y. Zhang, Channel Surfing: Defending
Wireless Sensor Networks from Interference, Proc. Intl 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. Intl
Source 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-Lived
and 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. Intl Workshop Peer-to-Peer
Systems (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 Cryptographic
Countermeasure 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 Networked
Embedded 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. Intl
Conf. Information Processing in Sensor Networks (IPSN 08), Apr.
2008.
[35] C. Karlof, N. Sastry, and D. Wagner, Tinysec: A Link Layer
Security Architecture for Wireless Sensor Networks, Proc. Intl
SourceConf. 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: Accurate
and Scalable Simulation of Entire Tinyos Applications, Proc.
Intl Source Conf. Embedded Networked Sensor Systems (SenSys 03),
pp. 126-137, 2003.
30 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 1, JANUARY 2011
Hailun Tan received the MS degrees in tele-
communication engineering and information
technology from the Australian National Univer-
sity in 2004 and 2005, respectively, and the PhD
degree from the University of New South Wales
(UNSW) with financial support from the Informa-
tion Communication Technology (ICT) Center,
Commonwealth Scientific Industrial Research
Organization (CSIRO), Australia, in 2009. From
2004 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, he
worked as a research assistant for Smart Road and Traffic (STaR
project) in National Information Communication Technology for Ex-
cellence (NICTA), Australia. His main research interests are in security
protocol design in wireless mesh networks and wireless sensor
networks. He is a student member of the IEEE.
John Zic is currently the research team and
science leader for Trusted Systems within the
Networking Technologies Laboratory, ICT
Centre, CSIRO, and holds a visiting associate
professor position at the University of New
South Wales (UNSW). Prior to this position,
he acted as the research director for the
Laboratory for a period of two years, during
which time he oversaw the second Center for
Networking Technologies for the Information
Economy project (CeNTIE 2) funded by the Australian Government
through the Department of Communications, Information Technolo-
gies, and the Arts (DCITA) that brought in some $3M p.a. into the
ICT Centre. He has previously held research positions at Motorolas
Australian Research Center from 1999 to 2003, and has taught
networking, advanced networking, and concurrent computing at
undergraduate and postgraduate levels from 1982 to 1999 as a
lecturer in charge and tutor. He has been involved in networking
protocol research for more than 29 years, from ALOHA experiment
days, through the development of the first diffuse infrared wireless
LAN and onto IPv6 and home networking research, including the
development of novel extensions to Hoares Communicating Sequen-
tial Processes algebra allowing compact expression of timing
constraints in real-time systems and their protocols. His current
research interest is in the application formal modeling techniques and
tools to security and trust protocol analysis, and is a coinventor of
the Trust Extension Device that is currently in commercialization. He
is a member of the IEEE.
Sanjay K. Jha received the PhD degree from
the University of Technology, Sydney, Australia.
He is a professor and the head of the Network
Group in the School of Computer Science and
Engineering at the University of New South
Wales. His research activities cover a wide
range of topics in networking, including wireless
sensor networks, ad hoc/community wireless
networks, resilience/Quality of Service (QoS) in
IP networks, and active/programmable net-
works. He has published more than 100 articles in high-quality journals
and conferences. He is the principal author of the book Engineering
Internet QoS and a coeditor of the book Wireless Sensor Networks: A
Systems Perspective. He was a member-at-large of Technical Commit-
tee on Computer Communications (TCCC) and IEEE Computer Society
for a number of years. He has served on program committees of several
conferences. He was the technical program committee member of the
IEEE Local Computer Networks (LCN) 2004 and ATNAC 2004
conferences, and the cochair and general chair of the Emnets-1 and
Emnets-II workshop, respectively. He was also the general chair of ACM
Sensys 2007 Symposium. He is a senior member of the IEEE.
Diethelm Ostry is a research scientist in the
Network Technologies Laboratory, Information
and Communication Technology Center, CSIRO,
Australia. His recent research interests have
been in the areas of network traffic characteriza-
tion, optical packet networks, and security in
wireless sensor networks. He is a member of
the IEEE.
> For more information on this or any other computing topic,
please visit our Digital Library at www.computer.org/publications/dlib.
TAN ET AL.: SECURE MULTIHOP NETWORK PROGRAMMING WITH MULTIPLE ONE-WAY KEY CHAINS 31