2008 Second International Conference on Future Generation Communication and Networking

Trust-based LEACH Protocol for Wireless Sensor Networks

Fei Song1,3 , and Baohua Zhao1,2,3

1
Dept. of Computer Science, University of Science and Technology of China, Hefei, 230027, China
2
State Key Laboratory of Networking and Switching Technology, Beijing, 100876, China
3
Province Key Laboratory of Software in Computing and Communication, Hefei, 230027, China
flysongfly@gmail.com, bhzhao@ustc.edu.cn

Abstract Trust is currently a hot issue in computer networks such

The traditional security solution based on cryptography
and authentication is not sufficient for wireless sensor net-
works, which encounters new challenges from internal at-
tackers, and trust is recognized as a novel approach to
defend against such attacks. In this paper, we propose a
trust-based LEACH(Low Energy Adaptive Clustering Hier-
archy) protocol to provide secure routing, while preserving
the essential functionalities of the original protocol. The
decision-making of our scheme is based on the decision
trust, evaluated separately and dynamically for different de-
cisions by basic situational trust. The situational trust is
maintained by a trust management module integrated with a
trust-based routing module, having novel techniques in trust
update model and cluster-head-assisted monitoring control.
The simulation results demonstrate the effectiveness of our
proposed scheme.
1. Introduction
Wireless sensor networks(WSNs) are self-organized
wireless network systems which consist of many low-cost
and resource-constraint sensor nodes. As sensor networks
are often deployed in adversarial and unattended environ-
ments for critical applications such as battlefield recon-
naissance and medical monitoring, the security solution
for WSNs is a challenging issue. Note that sensor nodes
are low-cost which makes them unfeasible to be equipped
with tamper-resistant devices, and an adversary can eas-
ily capture them and reveal all their private information in
an unattended environment, then the compromised nodes
can launch many misbehavior attacks such as black hole,
selective forwarding and so on[6]. The traditional mech-
anisms based on cryptography and authentication can not
prevent internal attacks launched by compromised nodes
which have valid cryptographic keys and post as authen-
ticated nodes in the network.
as e-commerce[8] and p2p networks[11], which can solve
secure problems caused by malicious members, so building
trust relationships among sensor nodes has been recognized
as a novel approach to improve security in WSNs. However,
it is not easy to build an effective trust management system
within WSNs, given resource-constraint and inexistence of
trusted third parties.
We propose a Trust-based LEACH(TLEACH) protocol
to enhance the security of LEACH protocol, while preserv-
ing the essential functionalities of original protocol such as
head-election algorithm and working phases. A trust man-
agement module is built in our scheme to maintain the basic
neighbors’ situational trust by direct observations or second
hand information, with a novel trust update model and sec-
ond hand information exchange mechanism. Then a trust-
based routing module is implemented, adding trust slots to
provide better support for trust evaluation, while making de-
cisions by the decision trust, which is evaluated separately
and dynamically for different decisions by basic situational
trust. Moreover, we propose a cluster-head-assisted moni-
toring control scheme to reduce energy consumption effec-
tively. The simulation results demonstrate the effectiveness
of our scheme.
This paper is organized as follows: related work is sum-
marized in Section 2. The description of our proposed pro-
tocol is given in Section 3. Simulation results are shown in
Section 4, followed by conclusions in Section 5.
2. Related Work
The first step to provide security solutions for
WSNs[1][5] is to propose schemes based on establishing
and management of sensor cryptographic keys. Note that
these proposed schemes are not sufficient for the novel in-
ternal attacks launched by compromised nodes as explained
before, and the goal of secure mechanisms in presence of
internal attackers is graceful degradation of WSNs.
Ganeriwal and Srivastava propose a reputation-based

978-0-7695-3431-2/08 $25.00 © 2008 IEEE 202

DOI 10.1109/FGCN.2008.41
framework for high integrity sensor networks[9] where
nodes maintain reputation for other nodes and use it to eval-
uate their trustworthiness, employing a beta reputation sys-
tem for reputation representation, updates and integration.
The watchdog and pathrater[7] can be regarded as an
early work in trust-based routing in ad hoc networks, which
uses a watchdog that identifies misbehaving nodes and a
pathrater that helps routing protocol avoid these nodes.
CONFIDANT[2] is proposed with a trust manager and
a reputation system which evaluates the events reported by
the watchdog, then aiming at detecting and isolating misbe-
having nodes.
All these solutions do not take the characteristic of
cluster-based routing protocols into account, which may
break the key-properties of original protocols, while making
all decisions by fixed trust. LEACH relies on cluster-heads
for routing and data aggregation, if an intruder attempts to
become a cluster-head, it can drop the messages through
itself totally or selectively, or inject bogus data when data
aggregating, the attacks to cluster-heads are the most dam-
aging to the functionalities of the LEACH, so our work fo-
cuses on preventing compromised nodes becoming cluster-
heads, while making different decisions by dynamic deci-
sion trust.
3. Trust-based LEACH Protocol
3.1. Overall System
Advertisement
Trust-based Routing Module
Trust Management Module
which is composed of two sub-modules: monitoring mod-
ule and trust evaluation module, the former one is responsi-
ble for monitoring neighbors’ behaviors and reporting mis-
behavior, while the latter one is responsible for trust store
and evaluation. The trust-based routing module is a mod-
ified version of basic LEACH protocol, which exploits the
trust management module to provide secure routing.
3.2. Trust Management Module
3.2.1. Monitoring Module The monitoring module is re-
sponsible for observing the neighbors’ behaviors and re-
porting the misbehavior to the upper module(trust evalua-
tion module). When monitoring module working, the nodes
may work in the promiscuous mode periodically or proba-
bilistically in order to save energy. In our scheme, the work-
ing scheduling of monitoring module is controlled by the
trust-based routing module, which will be detailed in Sec-
tion 3.3.2.
A sensor node usually performs various types of opera-
tions such as routing, data sensing and localization, so the
monitoring module need record different operations sepa-
rately, each of which is called situational operation. The
misbehavior detect strategy of each situational operation is
determined by the features of the situational operation and
application-dependent.
After situational misbehavior has been generated, it will
be reported to the trust evaluation module. It is not neces-
sary to report it whenever new one is generated, it can be
reported in fixed period, called trust update period. The sit-
Cluster Joining
uational misbehavior report is defined as a 4-tuples:
r
u
s
t
< Nm , No , OA , j >
n
T

io
is
c
e
D
Where OA represents the index of the situational operation
Monitoring Misbehavior Trust Evaluation and j represents the node ID of the neighbor concerned to
Module Report Module
the report. Nm and No represent the number of misbehavior
and normal-behaviors of the situational operation OA in the
ation
form
l

nd In
o
tr
o
n
Ha trust update period separately.
nd
Seco
C
g

head
n

it
o
ri

ster-
3.2.2. Trust Evaluation Module The trust evaluation mod-
o
n
t: Clu
t Slo ule is responsible for evaluating neighbors’ situational trust
M

Trus
Steady State
Figure 1. System architecture of TLEACH.
Our proposed system consists of two main modules:
trust management module and trust-based routing module.
Figure 1 illustrates the overall system architecture of pro-
posed TLEACH protocol and the inter-modules’ relation-
ships. The trust management module is responsible for
providing infrastructural trust support for routing decisions,
for situational operations and decision trust for making de-
Confirmation
cisions by the situational misbehavior reports.
Each node maintains a data structure, called NSTT
(Neighbor Situational Trust Table), in which each table en-
try contains neighbor’s ID and situational trust for situa-
tional operations, TS .
1)Direct Trust When the trust evaluation module receives a
situational misbehavior report from its monitoring module,
it evaluates the new direct trust of concerned node.
We employ the beta distribution[4] to model the node’s
situational behaviors as in[9] because of its simplicity and
strong foundation on statistical theory.

203
 For situational operation OA , upon receiving a situa-
tional misbehavior report, < Nm , No , OA , j >, the direct
trust of node i on node j, DT (i, j, OA ), is defined as fol-
lows according to the beta distribution:
No + 1
DT (i, j, OA ) = (1)
No + N m + 2
Without any direct observations, Nm = No = 0, and
DT (i, j, OA ) is equal to 0.5, so the initial value of neigh-
bor’s situational trust is 0.5, which stands for neutral trust.
2)Indirect Trust If a node only evaluates trust by the di-
rect observations, it keeps monitoring module working to
get more precise values, and then the energy consumption
will be too large for WSNs. The sensor nodes may exchange
trust values between them to make use of the neighbors’
observations as SHT(Second Hand Trust), however, over
depending on SHT will lead to high communication over-
head, thus our scheme only gets SHT from cluster-heads as
a trade-off, which play a crucial role in LEACH and are usu-
ally more trustworthy. Upon receiving SHT, ST (k, j, OA ),
the trust value from node k to node i on node j, node i com-
putes indirect trust on node j, IDT (i, j, OA ) , according to
the following formula:
IDT (i, j, OA ) = T S(i, k, OA ) × ST (k, j, OA )
(2)
+(1 − T S(i, k, OA )) × T S(i, j, OA )
Where T S(i, k, OA ) and T S(i, j, OA ) are the situational
trust of node i on node k and node j. It is a weighted
sum which takes the trust value of node k and j into ac-
count. Without the weighted factor, the indirect trust may
be computed incorrectly as the SHT may be sent by ma-
licious nodes. If the trust on the sender is too little, the
result of the formula is approximate to the old trust value
T S(i, j, OA ), so the malicious SHT will make little impact
on the trust evaluation.
3)Trust Update After new direct misbehavior reports or
SHT is received, new direct trust or indirect trust, Tnew , is
calculated, which needs to be integrated with the old value,
Told , stored in the NSTT, then Told is updated to the new
integrated trust value, TI . It is intuitive to assume that Tnew
and Told should carry different weights in the integrated
trust, so the integrated trust value, TI , is calculated as fol-
lows:
TI = (1 − w) × Told + w × Tnew (3)
Where w is the updating factor reflecting the weight of the
Tnew , whose value ranges from 0 to 1. Trust update is a
periodical action, which can be exploited by sophisticated
malicious nodes to do time-domain inconsistent behaviors
and break the functioning of the trust management system.
For example, a malicious node may do normal behaviors at
the start in order to obtain high trust, then perform attack
actions without being detected, and then go on to do normal
204
behaviors to regain its trust. If the value of w is large, then
the malicious node can regain its trust by performing nor-
mal behaviors for a while after doing much misbehavior; on
the other hand, if the value of w is small, the attacker can do
vandalism without being detected after acquiring high trust.
To address this problem, the value of w should be chosen
carefully. A phenomenon should be noticed that the trust
should not be reduced in an idealized system. As the realis-
tic system may have system failure because of environment
changes or emergent events, it is reasonable to assume that
the trust should not be reduced sharply under normal cir-
cumstances, and if a node wants to regain its trust after some
misbehavior, it needs to do more normal behaviors, after all
bad behaviors are always remembered easily in trust sys-
tem. So we do not choose fixed w, and set w as a function
of the difference between Tnew and Told . For example, we
can choose:
w = wo f or Told − Tnew ≥ β;
(4)
w = w1 f or Told − Tnew < β
Where 0 < w1 ≤ w0 ≤ 1, 0 < β < 1. w0 can choose
a bigger value, then the trust drops rapidly after an excep-
tional trust reduction, and w1 can choose a smaller value,
then the trust grows slowly for normal behaviors. β is the
predefined threshold which indicates the max permissible
trust decrement depending on the system circumstances and
requirements.
4)Decision Trust Compute In a trust-based system, when
a node wants to cooperate with one neighbor for an opera-
tion, it makes decision based on the neighbor’s instant trust,
called decision trust. Different situational operations may
perform consistently for malicious nodes, in other words,
if a node misbehaves in one operation, it is very likely un-
trustworthy in others, however, each situational trust should
have different weight in final decisions, so the decision trust
about operation O of node i on node j, Tdecision (i, j, O), is
defined as:
Tdecision (i, j, O) = θOA × T S(i, j, OA ) + θOB ×
(5)
T S(i, j, OB ) + θOC × T S(i, j, OC ) + . . .
Where θOx (x = A, B, C . . .) is the association factor for
each situational trust, which takes values in range (0, 1),
and the total sum of θOx is 1. For decision trust calculation
on different situational operations, the values of θOx should
be different, as the more interrelated situational operations
of the final decision should have bigger association factors.
3.3. Trust-based Routing Module
Our trust-based routing module preserves the core of the
original protocol with the same cluster-head election al-
gorithm and working phases as shown in Figure 1, while
adding trust slots and trust-based decision-making.
3.3.1. Set-up Phase
1) Advertisement The operation is the same as the original
protocol. After this phase is completed, each non-cluster-
head node will have a list of the cluster-head candidates.
2) Cluster Joining In this phase, the non-cluster-head
nodes decide which cluster-head to join for this round. The
decision of the original protocol is based on the received
signal strength of the advertisement, which can be illegally
used by attackers[6]. Our cluster-head selection is based on
the decision trust about cluster-head selection operation on
the cluster-head candidates. The selection procedure is as
follows:
Firstly, for each cluster-head candidate, we compute the
decision trust about cluster-head selection operation by the
formula (5), then we get a trust list of cluster-head candi-
dates.
Secondly, the final cluster-head is chosen by the trust
list. The simple way is to choose the candidate whose trust
is maximal. However, all the cluster-head candidates may
be malicious in some cases, so we define a trust threshold,
Tmin , and only choose the candidate of maximal trust be-
yond the threshold. If there are no candidates whose trust
values are beyond the threshold, the nodes reset the cluster-
head selection procedure.
Lastly, the non-cluster-head nodes send cluster-join mes-
sages to their chosen cluster-heads.
3) Confirmation After a cluster-head receives all the
cluster-join messages, it begins to create a TDMA sched-
ule. Our scheme adjusts the original time schedule to pro-
vide better support for trust evaluation, adding trust slots.
As shown in Figure 2, the whole steady-state time period
is divided into some frames, each of which consists of data
slots for data sending and a trust slot for trust evaluation,
update and exchange, then the trust update period of our
scheme is frame time.
Steady state phase
Data slot Trust slot
…
i j k … i j k … from their cluster-heads with formula (2), then update the
Frame
Figure 2. TDMA Schedule.
3.3.2. Steady-state Phase In this phase, the non-cluster-
head nodes begin to send data to their cluster-heads in their
data slots and control monitoring module to observe neigh-
bors’ behaviors, while the cluster-heads keep their receivers
on to receive the data, and all nodes perform trust evaluation
during the trust slots.
205
1) Data slots For cluster-heads, they keep their receivers on
to receive data. In the last data slot, they detect the data
misbehavior, then do data aggregation based on the deci-
sion trust about data aggregation operation, excluding the
untrustworthy nodes. Then they send the aggregated data to
the sink.
For non-cluster-head nodes, they send data to their
cluster-heads during their time slots, with the monitoring
modules turned off, and when not in their time slots, they
turn on the monitoring modules to observe the neighbors’
behaviors. In order to reduce energy consumption, we turn
on the monitoring module with a monitoring probability,
Pm , for each data slot. Notice that the cluster-heads keep
observing the cluster-members’ behaviors, while holding
the most comprehensive information about clusters, and the
non-cluster-head nodes get SHT from their cluster-heads,
so our work control of monitoring module is cluster-head-
assisted, with the monitoring probability determined by de-
cision trust about monitoring operation on the cluster-heads,
for example, we set the monitoring probability of node i,
Pm (i), as:
Pm (i) = 1 − Tdecision (i, CH, OM ) (6)
Where Tdecision (i, CH, OM ) is the decision trust about
monitoring operation on the node’s cluster-head. If the
cluster-heads have high trust, the cluster-members can turn
off their monitoring modules in most time, as they can
get trustworthy information about neighbors from cluster-
heads; if the cluster-heads have low trust, the cluster-
member need to get precise trust by direct observations with
high monitoring probability, as the SHT from cluster-heads
is untrustworthy.
2) Trust slot For cluster-heads, they perform trust evalua-
tion and update their NSTTs, then they share their observa-
tions, with broadcasting their situational trust values to their
cluster-members.
For non-cluster-head nodes, they evaluate the new direct
trust by the misbehavior reports from their monitoring mod-
ules with formula (1), and indirect trust by the SHT received
NSTT by the new trust calculated by formula (3).
After one frame ends, the next frame begins as the same,
and when the steady-ready state ends, the next round begins
with the advertisement phase.
4. Simulations
In this section, we use simulations to study the perfor-
mance of our scheme. We have implemented TLEACH and
original LEACH in OMNET++[10], a discrete event sim-
ulator. The parameter settings are the same as [3] when-
ever possible. We evaluate TLEACH using the following
metrics: trust evolution, the runtime trust value of a node; evolution of our scheme. First we consider the effectiveness
packet deliver ratio, the percentage of sent packets received of different updating factor settings under different attack
by the sink. modes. Figure 3 shows the trust evolution of a malicious
We consider a network where 100 sensor nodes are ran- node, with three updating factor settings:(I)fixed w = 0.8,
domly scattered in a rectangular space of size 1000m by (II) fixed w = 0.05, (III)tunable w, with wo = 0.95, w1 =
1000m. The sensor nodes send the sensory data and state 0.1, and β = 0.05. Figure 3(a) shows the trust evolution
packets reporting their state information to their cluster- under uninterrupted attack. The trust value falls rapidly to
heads in their data slots. The cluster-heads aggregate the range from 0.2 to 0.3 in setting (I) and (III), and then keeps
sensory data, while forwarding state packets to the sink in the range, while taking more time to fall in the range
without aggregation. In our simulation,we assume that the in setting (II). Figure 3(b) shows the trust evolution under
malicious nodes inject 70%-80% bogus data for data situa- probabilistic attack, with probability of 0.6, from which we
tional operation and drop 70%-80% state packets for rout- can see that even for more sophisticated attacks, the trust
ing situational operation. value maintains low below 0.35 in setting (III) , while keep-
ing beyond 0.5 in setting (II) and varying fiercely in set-
4.1. Trust Evolution ting (I). It is shown that the tunable updating factor of our
scheme can detect more sophisticated attacks.
Next we consider the impact of cluster-head-assisted
1
monitoring on trust evolution. For monitoring operation,
0.9
we set θOR = 0.5, association factor of routing situational
trust, θOD = 0.5, association factor of data situational trust.
Fixed w=0.8
Fixed w=0.05
0.8
Tunable w The nodes choose the candidates whose trust are maximal
0.7
Data Situational Trust

as cluster-heads, and when the cluster-heads are malicious,

0.6 they share incorrect SHT. Figure 4 shows the trust evolution
0.5 of a normal and malicious node with and without cluster-
0.4 head-assisted monitoring, which is continuing monitoring.
0.3 With cluster-head-assisted monitoring, the trust evolution of
0.2
the malicious node is almost the same as that with continu-
ing monitoring, and the trust of the normal node is slightly
0.1
less than that with continuing monitoring, but still main-
0
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 tains high value, then the normal and malicious nodes can
Time 4
x 10 be distinguished for decision-making. Meanwhile, the mon-
(a) uninterrupted attack itoring node only monitors about 25% data slots in our ex-
periment, so the energy-consumption can be reduced signif-
1 icantly.
0.9

0.8
4.2. Packet Deliver Ratio
0.7
Data Situational Trust

0.6

0.5 For cluster-head selection decision, we set θOR = 0.6

0.4
and θOD = 0.4, and for data-aggregation decision, we set
0.3
θOR = 0.1 and θOD = 0.9. Figure 5 shows the packet de-
liver ratio versus the number of malicious nodes in different
0.2
Fixed w=0.8 trust strategies. LEACH is the original protocol, TLEACH-
0.1 Fixed w=0.05
Tunable w 0 means choosing the candidate whose trust value is maxi-
0
0 0.5 1 1.5 2 2.5 3 mal as cluster-head without trust threshold, and TLEACH-
Time 4
x 10 0.5 means setting trust threshold, Tmin , as 0.5.
(b) probabilistic attack As expected, TLEACH-0.5 performs the best as the ma-
licious nodes are prevented from being chosen as cluster-
Figure 3. Trust Evolution of a malicious node heads with the trust threshold, increasing the packet deliver
in different updating factor settings ratio by up to 60% compared to the origin protocol, and
TLEACH-0 performs worse than TLEACH-0.5, as all the
cluster-head candidates may be malicious in some cases, but
We take data situational trust as an example to study trust still better than the original protocol.

206
 1 1

0.9 0.9

0.8 0.8

0.7 0.7
Data Situational Trust

Packet Deliver Ratio

0.6 0.6
Normal Node With CH−Assisted
0.5 Normal Node Without CH−Assisted 0.5
Malicious Node With CH−Assisted
0.4 Malicious Node Without CH−Assisted 0.4

0.3 0.3

0.2 0.2
LEACH
TLEACH−0
0.1 0.1 TLEACH−0.5

0 0
0 1 2 3 4 5 6 0 10 20 30 40 50 60 70 80 90 100
Time x 10
4
Number of Malicious Nodes

Figure 4. Trust Evolution with and without Figure 5. Packet Deliver Ratio versus the
cluster-head-assisted monitoring number of malicious nodes

5. Conclusions [2] S. Buchegger and J.L.Boudec. Performance analysis of the

In this paper, we propose a trust-based LEACH pro-
tocol to provide secure routing, which is an integration
of a trust management module with a trust-based routing
module. The trust management module is responsible for
building trust relationships among sensor nodes with novel
methodologies to provide efficient monitoring, trust ex-
change and evaluation. The trust-based routing module is
a modified version of original protocol with the same head-
election algorithm and working phases, while having trust-
based decision-making. Simulation results demonstrate that
our scheme can detect more sophisticated malicious nodes
and increase packet deliver ratio significantly with efficient
monitoring. We plan on designing more suitable trust eval-
uation model and doing further experiments to study the en-
ergy and communication overhead of our scheme.
Acknowledgment
This work is supported in part by the National Natural
Science Foundation of China under Grant No.60872009 and
60602016, the National Grand Fundamental Research 973
Program of China under Grant No.2003CB314801, the Hi-
Tech Research and Development Program of China 863 un-
der Grant No.2007AA01Z428.
References
confidant protocol: Cooperation of nodes fairness in dy-
namic ad-hoc networks. Proceedings of ACM Mobihoc,
2002.
[3] W. R. Heinzelman, A. Chandrakasan, and H. Bakajrusgbab.
Energy-efficient communication protocol for wireless mi-
crosensor networks. Proceedings of the 33rd Hawaii Inter-
national Conference on System Sciences, January 2000.
[4] A. Jøsang and R. Ismail. The beta reputation system. 15th
Bled Electronic Commerce Conference, 2002.
[5] C. Karlof, N. Sastry, and D. Wagner. Tinysec: A link layer
security architecture for wireless sensor networks. ACM
SenSys04, pages 162–175, November 2004.
[6] C. Karlof and D. Wagner. Secure routing in sensor net-
works: attacks and countermeasures. Elsevier AdHoc Net-
works journal, May 2003.
[7] S. Marti, T. Giuli, K. Lai, and M. Baker. Mitigating routing
misbehavior in mobile ad hoc networks. ACM MOBICOM,
2000.
[8] P. Resnick and R. Zeckhauser. Trust among stranger in in-
ternet transactions: Empirical analysis of ebays reputation
system. Proceedings of NBER workshop on empirical stud-
ies if electronic commerce, 2000.
[9] S.Ganeriwal and M. Srivastava. Reputation-based frame-
work for high integrity sensor networks. Proceeding of the
2nd ACM workshop on Security of ad hoc and sensor net-
works, 2004.
[10] A. Varga. The OMNeT++ discrete event simulation system.
Proceedings of the European Simulation Multiconference,
2001.
[11] L. Xiong and L. Liu. A reputation-based trust model for
peer-to-peer ecommerce communities. IEEE conference on
ecommerce, 2003.

[1] A.Perrig, R. Szewczyk, V. Wen, D. Culler, and D. Tygar.

Spins: Security protocols for sensor networks. Wireless Net-
works Journal, September 2002.

207