Locating Compromised Sensor Nodes Through Incremental Hashing Authentication.

Full text

Page 1

Locating Compromised Sensor Nodes through
Incremental Hashing Authentication
Youtao Zhang1, Jun Yang2, LinglingJin2, and Weijia Li1
1Computer Science Department, University of Pittsburgh, Pittsburgh, PA 15260
2Computer Science and Engineering Department, University of California at Riverside,
Riverside, CA 92507
Abstract. While sensor networks have recently emerged as a promising com-
puting model, they are vulnerable to various node compromising attacks. In this
paper, we propose COOL, a COmpromised nOde Locating protocol for detect-
ing and locating compromisednodesoncethey misbehavein the sensornetwork.
We exploit a proven collision-resilient incrementalhashingalgorithm and design
secure steps to confidently locate compromised nodes. The scheme can also be
combined with existing en-route false report filtering schemes to achieve both
early false report dropping and accurate compromised nodesisolation.
1 Introduction
The sensornetworkhasrecentlyemerged as a promisingcomputingmodel formany
applications e.g. patient status monitoring in a hospital, and target tracking in a battle-
fi eld. However, its unattended nature makes the network vulnerable to varyingforms of
security attacks such as a compromised node droppingtrue data reports [9] or injecting
falsereports[18,22]. Withoutbeingdetected, compromised nodes may prevent thesink
fromreaching a correct or optimal decision. Inaddition,routingfalse reportswastes the
energy of relay nodes, which reduces the lifetime of the network.
Thepreviousworkproposedeithertolocatecompromisednodesthroughen-network
detection [12,15] or to fi lter false reports early in routing [18,22]. While they are ef-
fective in many cases, both approaches have limitations— the former suffers from low
accuracy due to possible collusion attacks and the latter cannot exclude the compro-
mised nodes. In thispaper we propose COOL, a COmpromised nOde Locator for locat-
ing malicious nodes if they send out false data reports or drop real reports. Our design
is based on an intuitive observation — for any well-behaved node in the sensor net-
work, the set of outgoing messages should be equal to the set of incoming and locally
generated or dropped messages3. We exploit a proven collision-resilient incremental
hashing scheme — AdHASH [1] and show how to securely collect the AdHASH val-
ues and confi dently locate compromised nodes. We incrementally extend the testing so
as to capture an inconsistency when a bad link is included. A bad linkis a hop between
3Somemessagesmaybelost duetoweakconnectioninthe sensornetwork.It is alsoconsidered
as one type of fault. We detect such links and let the sink decide if the involved nodes should
be excluded.

Page 2

two nodes in which at least one is compromised. For such links, we drop both nodes
achieving an upper bound of 2m excluded nodes if there are m malicious ones.
The remainder of the paper is organized as follows. We describe the problem, and
the network and attack models in Section 2. The COOL protocol is then presented in
Section3withoptimizationspresented inSection4. We evaluate proposedschemes and
show the results in Section 5. Section 6 discusses the related work. Section 7 concludes
the paper.
2
2.1
Problem Statement
The network model
We assume that the sink assign a unique ID and a unique secret key to each sensor
before deployment. Sensors are left unattended after deployment and monitor events
of interests. While some may be compromised, we assume that the majority of sensing
nodes for any single event are trustworthy.
We adopt a cluster-based multi-hop routing scheme due to its energy effi ciency [6,
19]. Sensing readings (including the timestamps [18]) are fi rst sent to the cluster head
(CH)at whichtheare aggregated toa datareport.Bytakingthemajorityofthereadings,
theCH includes the selected sensing node IDs and theirMACs (message authentication
code, discussed next) in the content of the aggregated report. The CH also appends
its own ID and MAC to the report. After generating the report, the CH forwards it
along the routing path to the sink. Messages from the sink are fi rst sent to CH and then
broadcasted within the cluster.
At the cluster head level, the routinggraph is built using directed diffusionprotocol
[2]. Paths are set up to monitor different interests. We assume reports are forwarded
according to the routing path in one epoch. Each node checks the received report and
drops it if not for a cached interest.
2.2 The attack model
After compromising a sensor node, the adversary can retrieve all security informa-
tionincludingthe secret key. (S)He can theninject false reports ([22,18]), or dropsome
of its received reports ([9]). The adversary knows the COOL or other security enhance-
ment algorithms, and may strive to send back data targeting at defeating the protection.
The injection attack or the droppingattack may occur at a sensing node; at a source
CH; or at a relay CH. In this paper we address all these types except the dropping
attack at a source CH node. Dropping at a source CH is more diffi cult to defend since
a compromised CH may refuse to form a report even after receiving several sensing
readings. On the other hand, a CH is usually granted the power to legally drop some
readings when constructing the report (to shield random erroneous readings). If it is a
concern, then each sensing reading could be sent to more than one source CH nodes
resultingin increased routingoverhead as we will discuss later.
A compromised node is located if and only if its node id is known to the sink who
can then securely notify other sensors (using broadcast authentication [13]). Without
being located, the compromised node can be elected as a CH node and continuously
inject or drop reports. After being located, the network is free from its injection and

Page 3

dropping attacks since others know it is excluded. Of course additional mechanism
might be needed to prevent it from malicious signal collisionor changing its id.
Reports may be lost due to weak connections. This is one type of faults that should
also be identifi ed. Identifyinga weak connectionis benefi cial since it gives the accurate
location where a problem occurs. Based on the frequency of a faulty link, the sink can
always make the decision whether or not to exclude the involved nodes. Since it is
straightforward to detect/eliminate such links, we will focus on the report loss due to
security attacks in the rest of the paper.
2.3The design objectives
For a sensor network with above settings and models, our design goal is to effec-
tively identifythose compromised nodes and then exclude them from the network. The
proposed algorithm meets the followingrequirements.
– The sink has the ability to discriminate the false reports;
– The scheme can defend both true report dropping at the relay nodes and all types
of injection attacks;
– The algorithm can locate compromised nodes;
– The algorithmis effective withsmall overhead introducedtoexistingclusteringand
routingalgorithms.
3 The COOL Protocol
In this section we present the basic design of the COOL protocol. We fi rst discuss
the incremental hash function, and then describe the high-level idea of malicious node
detection using a simple example. The details of the systematic protocol operations are
then discussed, followed by security analyses of the protocol.
3.1 The incremental hash function
Fig. 1 illustrates the concept of the incremental hash [1]. It computes a crypto-
graphic hash value for a fi nite set of elements. Each element is fi rst concatenated witha
uniqueid and then hashed by a standard cryptographichash functione.g. MD5 or SHA
[14]. Those intermediate hash values are then combined by a combining operator to get
the incremental hash value.
In this paper, we use the AdHASH introduced in [1] (abbreviated as AH(...)):
AHh
where h is a standard cryptographic hash function and M is a very large integer value
withk bits.The ?i?isanid assignedtoeach message such thattheconcatenationofthem
is unique in the entire set. When we apply the AdHASH in our sensor network, each
report is assigned with the sensor’s ID and a local report sequence number. Therefore,
each report received by the forwarding cluster head is unique. As we can see, the AH
computed by the cluster head is independent of the order at which reports are received.
Thisincremental hashfunctionhasthefollowingpropertiesthatare usefulinourdesign.
M(x1,x2,..,xn) =∑n
i=1h(?i?.xi) mod M
– Compression. It compresses inputs of larger size into k bits such that each incre-
mental hash value can be stored using small number of bits in each node.

Page 4

– Incrementality. The AH of a larger set can be computed incrementally from the
AH of its subset. In particular, when a new item is inserted to the set, the new
AH can be computed from the old value and the h() value of the new item. i.e.
AHh
– Effi ciency. The computation of an AH hash value just needs several additions and
one modulation in addition to the standard hashing. Particularly, for the insertion
of a new item, the computation overhead is one addition and one modulation only
(the width of the h and AH is of the same order). This is important as most hash
values are to be maintained by resource constrained relay nodes in our design.
– Proven collision-resilience. It is computationally infeasible to forge another set of
items that can result in a same hash value [1]. This gives us a solid security ground
for designing security enhancement schemes for sensor networks.
M(x1,...,xn+1) = (AHh
M(x1,..,xn)+h(?n+1?.xn+1)) mod M
We selected h to be MD5 [14] and k to be 128 in the design. The selection of MD5
is independent and can be substitutedif for example security is a concern [17,16]. The
security of AdHASH requires that the number of reports should be greater than k [1].
This is generally not a restriction — the protocol can start after the network has been
warmed up.
?????? ??????
?
??????
??
?
?
??????????
???????????
???????????????????
?????
??????????????????????
Fig.1. An incremental hash function.
?
?
??
?
?
????????
?
?
?
?
??
?
??
??
?
????????
?????????
?
?
Fig.2. Locatecompromisednodesusing
incremental hashing.
3.2The basic design — a simple example
We next show how an incremental hash function can be applied to authenticate
messages and in particular how to locate malicious nodes in a sensor network.
The design is based on an intuitiveobservation, i.e. the set of outgoing(forwarded)
messages of a well-behaved node equals the set of the incoming (received) and locally
generated/dropped messages. Unfortunately, these message sets are maintained on dif-
ferent sensor nodes across the network making it impractical to pass them around and
compare. Luckily with the incremental hash function, we only need to compare the
hash values of different sets whilekeeping suffi cient confi dence toclaim that their hash
values match indicates that the message sets also match, i.e. Fig. 2(a).
No node being compromised
⇔
{msgout} = {msgin} ∪ {msglocal}
⇔ (with sufficient confidence)
AH({msgout}) = (AH({msgin}) + AH({msglocal})) mod M

Page 5

To see how this principle is applied in our sensor network, let us look at a simple
example (Fig. 2). Here we show four cluster head sensors (s1-s4) and one sink (s0).
The messages are labeled in letter a,b etc. Suppose the compromised node s2 injects a
false message X and pretends that X is sent by s4 (in this section, we will also discuss
what ifX is forged as if it is sent by s2). All messages are forwardedto the sink, but the
AH values are calculated and kept locally. Specifi cally, s4/s3 calculates outgoingAHs
for (a,b)/(d,e); s1 calculates two incoming AHs for (d,e) and (a,b,X) respectively,
and one outgoing AH for (a,b,c,d,e,X); s2, as a compromised node, can fake the
incoming or outgoing AHs for either (a,b) or (a,b,X). Note that s2 will not produce
another incoming AH for X as s2 tries to hide itself from being detected immediately
(X is“originated”froms4).As we willelaboratelater thattheAHs forlocallygenerated
legitimate messages are computed at the sink.
The sink receives all messages including X. It can immediately identify that X is
false since s2 does not have the secret key of s4 and cannot generate the consistent
MAC for X. Next, the sink tries to locate the sender of X, i.e., the node that has been
compromised. At this time, the sink collects all the AHs. We can assume that they all
arrive correctly as simple endorsement using secret keys can assure this, and there are
fi xed number of them for a given routing so that no AHs are dropped. The sink then
starts to check the “node consistency”, i.e., if
AH(incoming∪generated)= AH(outgoing∪dropped)
holdsforevery node.Note that due totheadditivityofthe AHfunction,AH(incoming∪
generated) = (AH(incoming)+AH(generated))mod M (and the same for the right
hand side). It is easy to see those conditions for s1, s3 and s4 satisfy. For s2, as we
mentioned, there are two options —AH(a,b) or AH(a,b,X)— for both the incoming
and outgoing AH values, forming four possibilities. If s2 choses the different values
for incoming and outgoing AHs, it would immediately be identifi ed as compromised
as equality (1) would not satisfy. Let us assume s2 is intelligent enough not to expose
itself too easily, and thus chose a consistent incoming and outgoing AH pair. Thus, it
will pass at least the “node consistency” check.
Next the sink starts a “link consistency” check in which the AH of the outgoing
message on a linkshould equal the AH of the upstream incoming message. This can be
easily checked for links without the node s2. Let us assume that the s2’s incoming and
outgoinghashes are both AH(a,b,X). Then, as an outgoingAH, AH(a,b,X) is consis-
tent with one of the incoming AHs for s1. However, as an incoming AH, AH(a,b,X) is
inconsistent with the outgoing AH for s4 which is AH(a,b). In other words, s2 chose
that value to lie that s4 had given it a false incoming message. The sink now cannot
distinguish who is the real compromised node, but can at least conclude that one of
them is flawed. A new routing graph will be generated excluding both s4 and s2 after
detecting the link inconsistency.
Notice that node s2 can destroy s1 in the same way by producing AH(a,b) for link
consistency checking, or even destroy all the adjacent nodes by forging an arbitrary
AH making none of the links consistent. It would be unnecessarily conservative if all
involvednodes insuch a scenario are eliminatedsince thefaultsare due toonlyone evil
axial node. Instead, our protocol removes one linkat a time, removing the axial node in
the fi rst place and saving the other nodes being circumvented.
(1)