Calculating trust in sensor networks

Calculating trust in sensor networks
Ari Karjalainen
Helsinki September 22, 2009
Pro gradu thesis
UNIVERSITY OF HELSINKI
Department of Computer Science
Date of acceptance Grade
Instructor

HELSINGIN YLIOPISTO — HELSINGFORS UNIVERSITET — UNIVERSITY OF HELSINKI
Tiedekunta — Fakultet — Faculty Laitos — Institution — Department
Faculty of science Department of computer science
Tekijä — Författare — Author
Ari Karjalainen
Työn nimi — Arbetets titel — Title
Calculating trust in sensor networks
Oppiaine — Läroämne — Subject
Computer science
Työn laji — Arbetets art — Level Aika — Datum — Month and year Sivumäärä — Sidoantal — Number of pages
Pro gradu thesis September 22, 2009 66 pages
Tiivistelmä — Referat — Abstract
Sensor networks can benefit from a trust management scheme. A sensor network can become
more resilient against node capture if every node in the network monitors their neighbours. The
information of how one node trusts another can also be used in routing. Trust-based routing tries
to forward traffic through more trustworthy nodes, so that malicious nodes could interfere with the
operation of the network. The route through which a packet traverses then forms a chain of trust
from one node to another. This chain can further be used to measure the trustworthiness of distant
nodes. This thesis evaluates how a trust management solution behaves in a sensor network, and
what kinds of trust chains the solution creates when malicious nodes are introduced to the network.
Results show that, given some inaccuracies, such a scheme can be used to identify untrustworthy
nodes from far away.
ACM Computing Classification System (CCS):
C.2 [Computer-Communication Networks: Security and protection],
C.2.3 [Network Operations: Network management],
C.2.2 [Network Protocols: Routing protocols]
Avainsanat — Nyckelord — Keywords
sensor network, trust management, routing, trust-based routing, network simulation
Säilytyspaikka — Förvaringsställe — Where deposited
Kumpula Science Library, series C-2009-
Muita tietoja — övriga uppgifter — Additional information

Contents
1 Introduction 1
2 Sensor networks 3
2.1 Realworld nodes and networks . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Service discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Security considerations in sensor networks . . . . . . . . . . . . . . . . . . . 13
2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Trust management 18
3.1 Trust-based routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Confidant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 CORE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 A Secure Routing Protocol for wireless ad hoc networks . . . . . . . . . . . 23
3.5 TARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6 Trusted Greedy Perimeter Stateless Routing . . . . . . . . . . . . . . . . . . 25
3.7 A Trust-Based Geographical Routing Scheme . . . . . . . . . . . . . . . . . 26
3.8 WSNodeRater and GESAR . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.9 Trust-based LEACH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.10 Dynamic trusted routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.11 Overview of trust-based routing protocols . . . . . . . . . . . . . . . . . . . 33
4 Analysis of trusted service discovery 37
4.1 Simulating network-protocols in JSIM . . . . . . . . . . . . . . . . . . . . . 38
4.2 The trust-based routing protocol . . . . . . . . . . . . . . . . . . . . . . . . 39
ii

4.3 Calculating a chain of trust . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5 Results 45
5.1 Scenario 1: A cloud of nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Scenario 2: Two islands with one bridge . . . . . . . . . . . . . . . . . . . . 50
5.3 Scenario 3: Two islands with two bridges . . . . . . . . . . . . . . . . . . . 52
5.4 Comparing different trust-metrics . . . . . . . . . . . . . . . . . . . . . . . . 55
5.5 Identifying malicious nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.6 Summary of tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6 Conclusions and future work 61
References 62
iii

1 Introduction
Wireless sensor networks are networks of autonomous sensing gadgets, or ”nodes”. These
nodes leverage the small size and low price of modern short range wireless communication
technologies and integrated circuits to report sensed data. A sensor network may consist
of a large number of sensors scattered across difficult terrain. These sensors will form an
ad hoc network amongst themselves and send their sensed data hop-by-hop to a specific
gateway node, called a sink. This sink-node will act as a gateway to other networks and
will allow a remote user to monitor and administer the sensor network from outside the
network.
Nodes contain an integrated programmable circuit, that will be used to control the node
and its operation. The nodes are typically battery-powered, relying on small low-energy
batteries to power their lifetime. The nodes contain a radio and communicate with each
other through some short range wireless communications protocol. The node is equipped
with an array of sensing equipment such as light, temperature or motion sensors.
An important part the operation of individual nodes and the whole network is that the
nodes can be programmed to aggregate, disseminate or filter the data they sense. This can
have a positive effect on the lifetime of the energy-scarce network as well as allow more
intelligent sensory fields to be built.
A sensor network will most likely operate on the same networking protocols that modern
computers do, so a sensor network may be reachable from other networks, for example
the Internet. This will ease deployment as the available network infrastructure (cell-phone
networks, WLANs, satellite hookups) can be used control the sensor network.
Sensor networks face many challenges, as they by their design, are very hard to protect
from tampering. An attacker would have very little trouble in getting their hands on a
deployed sensor. Experiments have shown that capturing a node is possible and would
up open huge vulnerabilities in a sensor network. A captured node may try to attack
the network from within. Ways to avert this scenario have been introduced, wherein a
distributed trust management system will be built into the nodes. In this system, all nodes
1

monitor their neighbouring nodes for any deviations or signs of malicious intent.
To gain more from this trust management system, it can be incorporated into the routing
protocol of the network. An untrustworthy malicious node will not be allowed to par-
ticipate in routing decisions or packet transmission. This allows malicious nodes to be
excluded from the network, thus resulting in a more resilient and fault tolerant network.
If nodes in a distributed trust management system monitor and gather trust-information
about their neighbours, this information could be used to define a chain of trust from one
node to another. This chain of trust can then provide the user with important information
about the network, the node at the other side of the chain and the nodes in between.
One such example would be service discovery where this chain of trust could be used to
differentiate different service providers. The provider with the best chain chain of trust
should be chosen in such an event.
This thesis will seek to evaluate how trust information can be propagated to a chain of
trust. This work will include discussions of how to best represent individual opinions into
one single metric that will define this chain of trust. In addition to this, the metric must
also be tested in various sorts of networks. The aim of this thesis is to give an estimate
of how accurately this chain of trust would work in a sensor network that is populated
with malicious nodes. The results will show that a chain of trust will work, but with some
irregularities owning to performance of the underlying routing protocol.
Chapter 2 will explain what sensor networks are, how they network and what sort of
security threats they face. To combat these security threats, a number of trust-based
routing protocols have been introduced, which will be highlighted in Chapter 3. In Chapter
4 a test is performed with one trust-based routing protocol to see how it could be used to
describe a node over a chain of other nodes. A network simulator is used to chart different
sorts of networks and results are presented in Chapter 5.
2

2 Sensor networks
Advances in integrated circuits and wireless communications have enabled the development
of wireless integrated sensors. These sensors can be formed to create sensor networks,
that can monitor or even interact with their environment. These multifunctional, low-
power, low-cost nodes are small in size and communicate with each other wirelessly. These
intelligent sensors are fitted with an onboard processor that allows data-processing and
aggregation of sensing data.
Applications for sensor networks have been suggested in for example the transportation-
and health care-industries, environmental oversight, security and safety applications and
the military [PK00] [ASSC02]. All of these industries would benefit from the sensor net-
works ease of deployment, dynamic topology and intelligent sensing and data-processing
capabilities.
A sensor network has the advantage of being a rapidly deployable, low cost, flexible and
fault tolerant way of setting up a sensory field. It has been postulated that a field of
distributed sensors may be used to monitor numerous phenomena inside or around the
field more effectively, instead of one or few central sensors (for example radars or cameras)
[PK00]. As a self-organizing network of autonomous sensors it is easy to set up in remote
locations, since the sensors can be scattered on the field in numerous ways without much
regard to the field’s topology. The sensors can be manually deployed in the are or scattered
from a helicopter or a similar apparatus.
The nodes in a sensor network employ dynamic multi-hop routing protocols that allow the
topology of the field to change without any affect on the networks operation. A sensor
can be moved inside a field, and the routing protocol will adapt to its new neighbours.
Neighbouring nodes can provide a failing sensor’s routing services and possibly continue
its sensing services. If the sensors are low-cost and easily deployable, a field can thus be
refreshed with new sensors that can take over, supplement, or expand the existing field.
A dedicated sink-node is assigned inside a sensor network. It has the responsibility of
operating as a gateway between the sensor network and other networks such as the Internet.
3

Connection to the outside networks is not necessary, but will allow remote monitoring and
control of the sensors. The sink node typically operates on different network protocols
towards the Internet and the sensor network. A sink node is usually also responsible for
automatically gathering sensory information from the field and thus operating as a cache
of sensing data for the network.
Design and security challenges in sensor networks derive from their low processing- and
communication-capabilities and their environment [ASSC02]. A sensor network may con-
tain numerous nodes that operate on a very limited power supply. It will be more than
likely that at some time a sensor will run out of power and disappear from the network.
This is a challenge as packets have to be re-routed or a new sensor must be located to
continue sensing the same area.
A sensor network may contain hundreds or thousands (or even millions!) of sensor nodes,
so production costs will have to be considered when deploying sensor networks. Besides the
challenge this proposes on the organization of the network, price must also be considered.
If the cost of a sensor network is higher than traditional sensors, a sensor network will
most likely not be chosen. This pressure may keep the price of nodes as low as possible. It
will be likely that sensor nodes will follow Moore’s law by introducing even cheaper nodes
with a fixed performance-level instead of even more powerful nodes with the same price
[KW03].
As the sensors are placed inside or very near the observed area or phenomenon, they must
endure unattended operation in possibly extreme conditions. Possible locations include
the ocean, large industrial structures or inside a biologically or chemically contaminated
area. A node must be able to endure these environments, or in case it doesn’t, a redundant
or adjacent node should take over its duties.
Environmental- , size- and price-considerations will most likely dictate that a node must
operate on a very limited power supply. A node’s power supply could be something like
a common AA-battery or similar. Some method of replenishing the battery may exist,
for example solar panels, but this depends largely on where and how the sensor network
is deployed. Protocols and components of the node must be optimized to operate at
4

low power. A good guideline for designing sensor nodes is that it is more economical to
compute thousands of operations instead of sending just one bit [KW03].
Security challenges arise from the fact that sensor nodes are unattended and scattered
across a large area. So, unlike a normal networked computer, a sensor node can very
easily be attacked physically. Besides acts of vandalism, a skilled attacker could ”hack”
the node and intrude the network from within. This scenario and others are detailed in
Chapter 2.4.
The following chapters will detail real world nodes that have been produced and an ex-
ample of an experiment where a sensor network was deployed. To give an idea about
networking sensors, different routing protocols for sensor networks will be detailed along
with discussion about service discovery. Finally, several security challenges will be high-
lighted.
2.1 Realworld nodes and networks
An integral part of making sensor networks more feasible and tempting is developing
small and affordable hardware. Many companies now produce sensor nodes. Much of
the current development focuses on making smaller sensors. This section highlights a few
different commercially available sensor nodes and one realworld scenario where a sensor
network was deployed to research bird habitats.
The MICAz node (also called a ”mote”) by Crossbow Technology is a low-power wireless
sensor node [MICAZ]. It is a 58 mm x 32 mm x 7 mm device that weighs 18 grams (with-
out batteries). A picture of the node can be seen in Figure 1. It runs on 2 AA-batteries.
Wireless communication-capabilities are provided by an IEEE 802.15.4, Zigbee compliant
2.4 GHz radio. Its processor/radio board, which is based on the Atmel ATMega128L mi-
crocontroller, houses a 10-bit analog-to-digital converter, 128 kilobytes of program memory
and 512 kilobytes of memory for measurements.
A very small single-chip sensor node was developed at the University of California at
Berkeley in 2003. This SPEC [SPEC] [SPEC2] mote was the size of a grain of sand at 2
5

Figure 1: MICAz sensor node by Crossbow Technology. Image source [XBOW]
mm x 2.5 mm (see Figure 2). This small chip houses among other things an ”AVR-like
RISC-processor”, 3 kilobytes of memory, an 8-bit analog-to-digital converter and a micro-
radio operating at a wavelength of 900 MHz. Spec runs on TinyOS [TINYOS]. Successful
communications tests have been performed where the node was able to transmit a distance
of about 12 meters (40 feet) with a throughput of 19 200 bits per second.
A Finnish company called Sensinode has produced a node called NanoSensor [SENSI]. The
product is mainly targeted at development and research use, as the company is pushing
the IPv6 6LowPAN (IETF RFC 4944) protocol stack that it helped produce. The node
itself (see Figure 3) is equipped with a Zigbee-compatible 2.4 GHz radio, 128 kB of Flash
memory and 8 kB of RAM and houses a light sensor and a 3-axis accelerometer for sensing
duties. The node runs on two AA-batteries.
A working prototype has been built of a sensor node that is fabricated by printing silver
ink on paper [VRYT08]. The circuit layout and radio antenna were printed on a piece of
paper (see Figure 4) and the rest of the node assembly, which included battery, temperature
sensor, an intergrated controller including the radio controller, were added to the paper.
6

Figure 2: The SPEC mote and the tip of a ballpoint pen for reference. Image source
[SPEC]
Figure 3: A cased NanoSensor development node. Image source [SENSI]
7

3#.-!!!!!!!!!!!"#$!>&!,#41*93)0!?-3)--9!()31(-!@.++&!
D)++&! ! !!!!!!"#$! E&!"#-9*!7(.3.327)!?++)48*2&!
!
!
Figure 4: A prototype of a sensor ”printed on paper”. Image source [VRYT08]
The overall size of the node measured at under 10 cm x 10 cm. A working but crude
prototype, the radio was tested to be functional and transmitting at small distances.
An example of a realworld sensor network is a network built on the Great Duck Island
in Maine, United States [MCP + 02]. Research into the disturbances to bird habitats had
concluded that even a small human presence can have a large impact on the life of a bird
colony by increasing stress, reducing breeding success and even forcing birds to migrate
to more unsuitable habitats. A method of reducing human interference and footprint on
the observable bird population and breeding places was needed. In 2002 a network of 32
sensor nodes were deployed on a small island of the coast of Maine to monitor the habitats
of the Leach’s Storm Petrel. A sink node (called a base-station) was installed on the island
which connected the sensor network to the Internet via a satellite link.
)9+1()0!!!!!!!!!!!!!!!!!!!!!!!"#$!G&!HB,?!4)9+1()0!7.C)(!*)I)*!
.-+&!!!!!!!!!!!!!!!!!!!!!!!!!!!!!)4#33)0!82!C#()*)++!+)-+.(!4.01*)&!
A UC Berkeley MICA node (a predecessor of the MICAz node) was equipped with tem-
perature, pressure, photoresistor, humidity and passive infrared sensing capabilities (for a
picture of the node see Figure 5). A pair of AA batteries was enough to power the nodes
over the fall and winter. The nodes were placed in and around the burrows where the
birds were living. This allowed the researchers to collect and monitor the comings and
goings of the birds during the test period without affecting the birds natural habitat in
any way.
ded on March 4, 2009 at 09:10 from IEEE Xplore. Restrictions apply.
8

n neither use every drop of enthe
batteries manufactured with
tch to batch or from manufacmake
a conservative estimate
e to supply 2200 mAh at 3 volts.
operate uniformly over the dehas
8.148 mAh per day available
oses how to allocate this energy
, sensing, local calculations and
hat since different nodes in the
tions, they also may have very
s. For example, nodes near the
rd all messages from a patch,
y need to merely report its own
here will be some set of power
odes exhaust their supplies, the
inoperable. Consequently, we
ith respect to the energy bottle- Figure 3: Acrylic enclosure used for deploying the
Figure 5: A picture
an estimate of what is possible Mica
of
mote.
the MICA node and its casing that was used in monitoring the
of AA batteries, weLeach’s tabulated Storm Petrels on the Great Duck Island in 2002. Image source [MCP
erations in Table 2.
mounting holes for securing the sensor boards. To provide
nAh
weather-proofing, we coat the entire sensor package with a
20.000
10 micron parylene sealant, which protects exposed electri-
8.000
cal contacts from water. The sensors remain exposed to
illisecond 1.250
protect their sensitivity. Each coated node is then enclosed
sample (analog) 1.080
in a transparent acrylic enclosure. The enclosure is venti-
sample (digital) 0.347
lated to not distort the sensor readings; its primary func-
the ADC 0.011
tion is to provide additional protection against mechanical
1.111
failures and to raise the sensor off the ground. Acrylic pack-
ta 83.333
aging was chosen because it is infrared and radio frequency
transparent, which won’t obstruct sensor readings or wireless
communication.
by various Mica operations. The acrylic enclosure shown in Figure 3 is used for deploying
nodes above the ground on Great Duck Island. The
e node is determined by the cur- size of the Mica mote itself was almost too large to fit in pe-
Minimizing power in sleep mode trel burrows; therefore we placed the parylene sealed motes
ors, the radio, and putting the into the burrows without enclosures. Not using the enclo-
ode. Additionally, I/O pins on sure is less robust; we’ve noticed expansion and contraction
be put in a pull-up state when- of connectors over the course of four weeks leading to faulty
ntribute as much as 100 µA of electrical connections. We advocate the future use of sol-
ecture uses a DC booster to prodered connections to solve this problem.
rading alkaline batteries. With
etween 200 and 300 µA, depend- 4.5 Patch Gateways
hile this functionality is crucial Using different gateway nodes directly affects the underly-
gs and communications, it is not ing transit network available. We implemented two designs:
Furthermore, the current draw an 802.11b single hop with an embedded linux system and
portional to the supply voltage. a single hop mote-to-mote network.
ith a Schottky diode, which al- Initially, we chose CerfCube [1], a small, StrongArm-based
the DC booster while reducing embedded system, to act as the sensor patch gateway. Each
odes. The modification allows gateway is equipped with a CompactFlash 802.11b adapter.
d 50 µA current draw (battery Porting functionality to CerfCubes is fairly easy; they run
he energy available for tasks to an embedded version of Linux operating system. Permanent
storage is plentiful – the gateway can use the IBM
MicroDrive which provides up to 1 GB of storage. Sup-
nt
plying adequate power for this device is a challenge, with-
nsor network using Mica motes out power management features this device consumes about
in July 2002. The network con- 2.5W (two orders of magnitude more than the motes). To
itecture described in Section 3. satisfy the CerfCube power requirements, we considered a
weather conditions on GDI, we solar panel providing between 60 and 120 Watts in full sun-
ective packaging that minimally light connected to a rechargeable battery with capacity be-
ty. Mica motes by their design tween 50 and 100 Watt-hours (e.g., sealed lead-acid). Re-
ly, with the battery case firmly searchers from Intel Research and JPL have demonstrated
ocessing and sensor boards, and delay-tolerant networking using CerfCubes and motes [10]
+ 02]
2.2 Routing protocols
Networking sensors brings up different challenges and requires new approaches to routing
protocols. The nodes in a sensor network cannot operate with the same resorces or rules
of any ad hoc network. The role and usage of sensor networks and therefore the kind of
relayed data also differentiates it from other ad hoc networks.
A big concern with sensor networks is the node itself. The size of the nodes requires weaker
transmission ranges and smaller batteries to be used. This means that an efficient routing
protocol must take into account the limited resources of the nodes.
Another consern is the difficulty of building a global naming scheme for a huge number
of nodes. Nodes will most likely not have a global identifier. Also, contrary to other
networks, the flow of infomation in a sensor network will most likely be from multiple
areas (sensors) to one address (the sink). The flow of sensed information will most likely
also be largely redundant, as many nodes may sense the same phenomenon.
A number of routing protocols have been designed for routing data in sensor networks
[AY05]. They differ in 5 respects as some protocols are data-centric, some hierarchical
and others location-based, and there are also a few that are designed with network-flow or
9

quality of service in mind. The rest of this chapter will highlight some examples of these
protocols.
Data-centric routing protocols, such as SPIN and Directed Diffusion work by discarding
the typical addressing of normal networks in favor of queries that are sent to the network.
SPIN [HKB99] uses high-level meta-data to describe and advertise data that the nodes
gather. This meta-data is then advertised to other nodes which then flood the meta-data
onwards. A request-mechanism is also implemented to retrieve advertised data. SPIN
cannot guarantee the delivery of the data as some nodes may not retrieve the wanted
data, although the protocol has been shown to operate better than pure flooding.
Directed Diffusion [IGE00] is a breakthrough [AY05] in data-centric routing and has since
spawned many modifications. It works by building paths based on routes and intrested
parties of data. A sink will notify the network of what kind of data it is interested in. The
nodes will cache this interest and then respond, if they or their neigbours have data that
corresponds to this interest. The replies (called gradients) are then used to determine the
fastest route from the sink to the source of the data. Nodes in Directed Diffusion may
contribute only by caching and relying data if they themselves are not the source of the
interesting data, thus leaving sensing to only the important nodes. Directed Diffusion is
query-driven and as such will not operate efficiently when a constant steady stream of
information is required.
Hierarchical protocols try to divide the network into clusters in order to build more scalable
networks. The aim of hierarchical protocols is to minimize energy consumption of nodes
by minimizing transmissions to the sink. The nodes form clusters, and transmit their data
to elected cluster-heads that then aggregate, fuse or compress the data before sending it
to the sink.
Leach (Low Energy Adaptive Clustering Hierarchy) [HCB00] is one of the most popular
hierarchical protocols. In Leach about 5% of the nodes will be elected as cluster-heads,
with the nomination changing every now and then to conserve energy. Cluster-heads then
gather data from the nodes in their cluster, disseminate and aggregate this data, and
then forward it to the sink. Leach works only if the cluster-heads are indeed capable
10

of transmitting directly to the sink, so it does not scale well to vast networks. A more
efficient modification of Leach is Pegasis (Power Efficient GAthering in Sensor Information
Systems) which operates by forming chains of neighbouring nodes that gather information
from each other, then elect a leader to transmit that data to the sink.
Location-based protocols take advantage of the fact that nodes usually provide some sort
of location information. This can be used to determine the shortest route between the
node and the sink. Location-information can also be used to address nodes in a particular
area instead of the nodes’ actual addresses.
GPSR (Greedy Perimeter Stateless Routing) [KK00] is one of the earliest works in location-
based routing protocols. It was originally designed for ad hoc networks, where each hop
is chosen according to its distance to the final destination. Beacon-messages are used to
determine the locations of other nodes. GPSR is stateless, as each node just selects the
most suitable hop from its neighbours until the packet finds its final recipient. GPSR is as
its name suggests, greedy, in that it may always forward packets to a specific node until
that node runs out of energy.
GEAR (Geographic and Energy-Aware Routing) [GE01] is a location-based modification
of Directed Diffusion. It works by constraining the interests to certain regions instead of
the whole network. GEAR works by dividing the network into separate areas, where data
can be sent. Forwarding to these areas is done by specific nodes, called holes. A hole is
a node very near the target area. GEAR employs a distributed learning algorithm that
weighs transmission times and used energy to decide the optimal node on the other side
of the hole. After a packet reaches the specified area, it is simply flooded to every node in
the area. Leach, GPSR and GEAR will be covered in more detail in the following sections.
An example of a QoS-based (quality of service) routing protocol is SPEED [SA03] that
provides soft real-time end-to-end guarantees for packet delivery. With SPEED, applica-
tions can estimate an end-to-end delay for a packet by dividing the distance to the recipient
by the transmission time. The stateless routing protocol estimates transmission times by
measuring the time it takes to receive an ACK from a neighbour. This information is
then used to decide the fastest neighbour. If the fastest neighbour is not fast enough
11

for the desired speed, the packet is dropped according to random chance. This random
punishement is used to force the routing protocol to try and find a faster or alternative
route.
A routing algorithm called Maximum residual energy path [CT04] offers an energy-conserving
approach to routing packets in sensor networks. It considers the cost of a path to be the
amount of energy a node is left with after transmitting a packet. This favors nodes that
have high energy or can forward a packet with the least strain on their battery. The
Bellman-Ford shortest path-algorithm is used to select the cheapest path, which would
be the path whose residual energy is the largest of possible paths. Simulations made by
the authors suggest that maximizing residual energy prolongs the lifetime of the network
more than minimizing energy-consumption when transmitting.
Research into sensor networks has spawned numerous new routing protocols [AY05]. These
protocols try to best match the demands of a sensor network by
2.3 Service discovery
Service discovery allows a more dynamic way of leveraging different networked entities.
Service discovery in a sensor network may include the discovery of a specific service in
a network from either inside or outside the sensor network. A user may want to query
a deployed sensor network from a mobile terminal (for instance a PDA) while strolling
around the area of the network. Another scenario could be a user, that uses a remote
computer to monitor and maintain several different sensor networks remotely. A user may
be interested in only the aggregated data from the network, such as the latest readings
gathered straight from the sink-node, or a user may want to find the nearest sensor that
will provide it with the sensing capability that the user wants.
Different service discovery protocols already exist such as the SLP [SLP], UPnP [UPNP]
or the Bluetooth Service Discovery Protocol (SDP) [BT]. None of these protocols are
specifically designed for sensor networks.
A protocol called SensorML [SML] exists that aims to provide service discovery specifically
12

for sensor networks. SensorML contains an information model and XML encodings for
discovering, querying and controlling sensors that may be connected to the rest of the
Internet.
SensorML contains intricate ways for describing the type and properties of a sensor in
XML, such as what kind of data it can provide, how long the data will be valid, what
the sensor is attached to or who operates the sensor. SensorML does not itself define how
services should be found; for instance should the service provider actively advertise itself
to the network and how and who keeps track of the different services in the network.
An open question is whether the same service discovery protocol should be used inside and
outside the sensor network. Could a sink-node perhaps translate service requests from one
protocol to another when querying the sensors? Or should the sink even query the sensors?
A sink could work as a gateway for the sensors and exclude direct communications with
the sensors from the outside.
2.4 Security considerations in sensor networks
Sensor networks can pose unique security challenges. Traditional security techniques, that
are used in more common networks, may not be directly applied to sensor networks. For
one, sensor nodes have very limited communication and computational capacities and must
operate on very low power levels. This limits both transmission range and intervals and
may also rule out public-key cryptography.
By their design sensor networks may require that end-to-end security be discarded. [KW03]
In traditional networks the intermediary routers do not need to have access to the messages
contents, but a sensor network may some form employ data aggregation or in-network
processing to promote the lifespan of the network. This requires that intermediary nodes
have access to the data they are forwarding. Nodes may refuse to forward repeated or
redundant data to the data collector. They may also choose to aggregate and bundle
larger amounts of sensing data that will be sent at a later time.
Setting up cryptographic keys in sensor networks may be harder than in other networks
13

[PSW04]. A shared network-wide key would create a single point of failure, where a
compromised node may leak the key. Public-key cryptography (such as Diffie-Hellman
key establishment) can prove to be computationally beyond the capabilities of sensor
nodes. Other approaches, such as using the sink-node or a distributed pool of random
keys to authenticate other nodes, have been proposed but they still are vulnerable to one
or several captured nodes.
Another aspect to consider is the ease of access an attacker may have to a node. A sensor
network will most likely consist of many unattended nodes scattered across a large area
so gaining access to a node will most likely be easy. Because of financial considerations,
a node may not have a very tamper-proof exterior. Thus, one possible attack on a sensor
network is node capture, where an attacker can capture and reprogram a node [BBD06]. If
this attack goes unnoticed it may result in a node that behaves in an arbitrarily malicious
way.
If an attacker captures a node, he may extract code and keys from the node and use this
information to launch an attack from more powerful computers. An off-the-shelf laptop
will have hugely more powerful processors, more sensitive antennas and higher-powered
radio transmitters than any node. A laptop computer can more efficiently eavesdrop or
disrupt the sensor network. Several laptops may also be connected by a faster low-latency
network that allows an attacker to mount coordinated assaults from different parts of the
network.
There are several ways an attacker may take advantage of a node upon gaining physical
access [BBD06]. An attacker may change the sensing unit of a node and thus inject
erroneous data to the network. Some nodes are designed as modular units and changing
the sensing component could be as easy as unplugging the old one and replacing it with a
new one. This operation could only take a couple of seconds. If the sensing component is
soldered into the node it may be harder to change, but a skilled attacker could still do it
in a matter of minutes.
An attacker may also be interested in reading or writing the external memory of the node
if it is possible that sensitive information is stored in it. The simplest way to do this
14

would be to eavesdrop on the wires of the memory-chip. This passive attack could go on
for a long period of time without anyone noticing. Another way would be to use a second
micro-controller to effectively hijack the I/O of the memory-chip, thus replacing the nodes
external memory with the attackers.
A more serious method would be to attack the micro-controller of the node. This may be
possible through the node bootloader or a possible debugging port found on some node-
types. Both of these attacks allow the attacker to obtain the contents of the nodes memory.
A realistic method of attacking the bootloader requires the source code of the node to be
known in advance. The attacker may also take advantage of the standard IEEE 1149.1
JTAG test access port found on many types of nodes. If the test port is not disabled, an
attacker may read the contents of the nodes memory.
All of the physical attacks presented above require special instruments and can most likely
be committed on the field. The most damaging ones will most likely take the node off the
network for a while. This absence could be used to detect captured nodes [BBD06].
A working method of remote code injection and node capture on Crossbow Technologies
MICAz-nodes has been demonstrated [FC08]. The attack exploits software vulnerabilities
and permanently injects code into the program memory of an Atmel AVR-based sensor.
The attack requires that the version of the node operating system (TinyOS) and the
program memory content is known in advance and the running code has at least one
expoitable buffer overflow vulnerability. A fake stack is injected into the node’s data
memory by using instructions already present in the node (also called ”gadgets”). The
injected code can then be written onto the permanent flash memory thus permanently
infecting the node. The attack can be used to install malware on the sensor node and
spread the malware onto other nodes. No permanent and foolproof solution is given to
protect a MICAz node from this type of attack.
Routing protocols are highly susceptible to node capture. A captured node may be used
to spoof, alter or replay routing data. This allows the attacker to manipulate the network
by disrupting the networks routing. A malicious node may commit several different kinds
of attacks to a network and disrupt its routing [KW03].
15

A malicious node may refuse to forward all or some packets that it receives. This is known
as a blackhole or a greyhole-attack. These attacks work if the attacker is able to inject
itself into a route.
A sinkhole is a node that tries to lure all possible routes to itself by advertising itself as a
very high-quality candidate to other nodes. A laptop that disguises itself as a node may
use a high-powered radio to advertise itself to the whole network. As most communications
from the network are towards the sink-node, a sinkhole can effectively take over the network
by advertising itself as the best candidate for routing packets to the sink. A malicious
node may also launch a sybil-attack, in which it disguises itself as several nodes.
An attacker may also launch a wormhole-attack on the network. A wormhole occurs when
the traffic of one part of the network is relayed by a low-latency link to another part of
the network. This can effectively create a sinkhole since the attacker is able to create a
shorter connection to the sink from a distant part of the network.
An attacker can also spoof link layer acknowledgements for overheard packets. This can
be used to advertise a weak link as a strong link, or a dead node as a live node.
A method of combating some of these attacks is using link-layer encryption. This effectively
eliminates all but the wormhole-attack [KW03]. Wormholes may be detected by some
methods, for instance geographic routing protocols can notice if a route advertised through
a wormhole is well above their normal transmission ranges.
Eventually, if a node is compromised and the attacker gets around any possible encryption
or authentication mechanisms, there exists no possible way to counter any of the attacks
described above. The following chapter will give one possible solution to the problem of
compromised nodes, distributed trust management.
2.5 Summary
Sensor networks are ad hoc wireless networks formed by very small autonomous sensing
devices. These sensors typically contain a radio, a CPU, a small amount of memory and
run some sort of an embedded operating system complete with their on network stacks.
16

Development of these sensors leans towards making sensors smaller while lowering their
price. It could be possible, that in the future we will see sensor networks comprised of
thousands or millions of small disposable sensors. Some research has focused on identifying
different methods of disrupting these networks or attacking the nodes directly. Node
capture is a possible method of attack that could have a significant impact on the operation
of any kind of sensor network.
17

3 Trust management
Research done in mobile ad hoc networks has shown that network performance is severely
reduced if nodes in the network misbehave [MM02b]. Misbehaving nodes usually refuse to
participate in network activity because of selfish or malicious intents. A selfish node may
refuse to forward packets because it is trying to save energy. A selfish node will use the
network but will not cooperate. A malicious node will go beyond that and do anything to
disrupt the network.
A sensor network organizes and operates very similarly to any ad hoc network. The
network topology is not known beforehand, and nodes may not have complete trust about
their neighbour’s intent. Nodes in a sensor network are often unattended, so gaining
physical access to them would be easy for an attacker. Research has suggested [BBD06]
[FC08] that nodes can be compromised on the field with only a minimal lapse in the
nodes presence. A general assumption about sensors is that they can be captured and
reprogrammed for malicious purposes.
One countermeasure against such an attack would be that each node in a network collects
trust information about its neighbours. This would be called distributed trust manage-
ment.
A node may gather subjective observations about its neighbouring nodes to determine
how much it may trust them. This is called direct trust. This approach would require no
central node or server to determine who should be trusted, and who should not. Such a
distributed trust management system could be more resilient towards attacks where large
parts of the network could be taken over.
Gathering data (or ”evidence”) for trust evaluation can be a cumbersome process. Some
relevant behaviour that a trust management scheme could look for include momentary
absence from the network (see node capture in Chapter 2.4), answering to non-existing
queries, weird or invalid sensor readings or reluctance to co-operate in routing or packet
forwarding [FGRL07].
Nodes may also engage in sharing their trust-information. This sort of behavior could be
18

called recommending or gossiping about other nodes. A node may request another node
how much it trusts a third node. Another way to share this information is warning others
about malicious behavior. This sort of information is called indirect trust.
The following chapters detail several different trust management systems along with rout-
ing protocols that takes advantage of the trust information. The systems differ in how
they calculate trust and what types of behavior they monitor from other nodes.
3.1 Trust-based routing
Many proposals for trust-based routing for sensor- or ad hoc networks have emerged.
Trust-based routing generally defines a routing scheme that tries to avoid uncooperative
or malicious nodes. This behaviour requires that other nodes must constantly be monitored
and rated. The following chapter describes wireless sensor network routing protocols that
share these characteristics.
Trust-based routing decisions are based on the node’s perception of its neighbours. This
has the added benefit that network efficiency can be maximized by redirecting traffic to
properly behaving nodes. Security can also be maximized by redirecting traffic away from
malicious or misbehaving nodes. Network lifetime can also be maximized by redirecting
traffic to nodes that have fuller batteries.
In order to define how trustworthy a node is, all of the nodes must actively monitor their
neighbours for malicious behavior. All of the solutions described below depend on this
kind of functionality. When monitoring other nodes, a node uses its radio to listen to
other activity. A radio is then said to be in a promiscuous-mode. This allows the node to
detect all activities around it, but is unfortunately power consuming.
A trust-based routing protocol must define what sort of behaviour it expects from other
nodes. The most common trait of a well behaving node is that it forwards every packet
that is sent to it. Further qualifications can be added, such as whether the packet was
sent without modifications or whether the node also transmits packets from every other
node. Every type of attack against a sensor network has its own characteristics and a
19

more detailed monitoring scheme will more likely detect different kinds of attacks.
A trust-based routing-algorithm might only use first-hand observations (direct trust) about
it neighbours or it might gather third-hand observations (indirect trust) from other nodes.
Indirect trust adds another layer of complications as the observations can also be from
untrusted nodes. Some protocols do not employ indirect trust at all, while some weigh
recommendations against what is known about the recommender. Some protocols also
use active notifications in situations where they discover an untrustworthy node. These
notifications usually warn other nodes about a bad node.
The following details different trust-based routing protocols, their components, how they
define trust and how they monitor their surroundings along with details about how trust
is used in routing decisions.
3.2 Confidant
Confidant [BB02] is a distributed trust manager that cooperates with the routing layer.
Confidant is based on the Dynamic Source Routing protocol (DSR). Confidant consists
of 4 components: the monitor, the trust monitor, the reputation system and the path
manager.
The monitor is in charge of noticing unwanted behaviour in neighbouring nodes and it
reports deviations to the reputation system. The reputation system maintains a list of
nodes and their reputations. The system changes a nodes reputation only when the moni-
tor notices significant bad behaviour that occurs for a long period of time. The reputation
system then modifies the reputation for the node depending on the type of bad behaviour
that was monitored.
The trust manager component sends out and deals with ALARM-messages. These mes-
sages are used by nodes to notify about untrustworthy nodes. An ALARM-message defines
the type of misbehaviour that was noticed, how long this has occured and which node is
in question. A node will send out and ALARM when it observes or is alarmed by an
untrustworthy node. To deal with false messages, Confidant uses a sort of friends list
20

of trustworthy nodes. These are nodes that a node trusts and is willing to share trust
information. Confidant identifies friends on four levels from no information to complete
trust and uses this information to weigh received ALARM-messages.
The path manager keeps a list of known routes. These routes are established according to
the DSR protocol by sending route requests and route replies. Normally DSR chooses the
route that receives the fastest or the shortest replies. Confidant adds trust considerations
to the decision, although the article doesn’t [BB02] define how. If the reputations system
notices enough bad behaviour about a node to raise suspicion, the path manager deletes all
the routes that have this node. If the path manager receives route requests from malicious
nodes, it may drop the requests. The path manager also re-arranges routes according to
the ALARM-messages the trust manager receives.
3.3 CORE
CORE [MM02a] defines itself as a generic method that aims to enforce node co-operation
in ad hoc networks. It incorporates a monitoring scheme to gather trust-information
about neighbouring nodes. This trust-information can in turn be used to weigh packet
forwarding, route discovery, network management or any other decisions in regards to
node co-operation. The article defines a way in which the DSR routing protocol can use
this trust-information in route discovery.
CORE defines trust as a product of direct-, indirect- and what it calls functional reputa-
tion. It calculates direct- and indirect trusts according to different functions, or observable
traits of nodes and then combines these values to a single trust-value with functional trust.
Direct trust (or what the article calls subjective reputation) is defined as a product of
past actions, where more relevance is given to past observations. This is so that sporadic
misbehaviour will have less of an impact than long term behaviour. Direct trust is defined
as:
directreputation t si (sj | f) = � ρ(t, tk)σk
Where directreputation t si (sj | f) is the direct reputation value calculated at time t by
21

node si about node sj while monitoring the function f. σk is the success of observation
k, a negative observation would have a value −1 and a positive observation would have a
value of 1 with a scale of anything in between for partially successful actions. ρ(t, tk) is a
time dependent function that gives higher relevance to past values of σk.
Indirect trust in CORE works by neighbours sharing only their positive observations about
other nodes. This approach is chosen as a means to combat denial of service-attacks from
malicious nodes that could otherwise badmouth good nodes.
Functional reputation in CORE means a combined metric of both direct- and indirect
reputations according to function f. All of the functional reputations of a node can then
be combined into one global reputation-value that different weights to different functional
reputations. Each node must maintain a Reputation table where it stores the direct- and
indirect reputations of each observable function for every neighbouring node.
The final trust-value is defined as such:
reputation t si = � wk ∗ (directreputation t si (sj | fk) + indirectreputation t si (sj | fk)
Where wk is the weight associated to the functional reputation of function fk.
The article does not specifically define which sort of behaviour (or functions) nodes should
monitor about their neighbours. It does suggest however, that packet forwarding and
routing functions should be monitored to ensure efficient operation of the network, with
more weight given to packet forwarding.
Instead of a proprietary monitoring scheme, each node in CORE uses the Watchdog-
mechanism [MGLB00] to validate other nodes behaviour. Watchdog is summoned every
time the correct execution of a function by another node must be verified. It does this by
storing all expected behaviour to a buffer. It then compares the observered behaviour to
this buffer and removes the entry in case the expected and observed behaviours match.
This is also marked as positive behaviour and the reputation table is updated accordingly.
If an entry stays in the buffer for too long, it is marked as a negative observation and also
marked in the reputation table.
An entry is stored in the reputation table for each observed function of other nodes. A
22

node uses this table to determine if it will co-operate with other nodes regarding different
functions. Therefore nodes will deny co-operation to nodes that have not have misbehaved
previously, thus excluding them from the network. CORE also maintains that nodes with
positive reputations should gradually lose their reputations if they idle. This is required
to enforce constant node co-operation by rewarding non-idling nodes.
Two applications for the CORE trust management scheme were presented in the paper
[MM02a]. The first one was an extension to the DSR-protocols route discovery phase and
the seconds on to packet forwarding. Watchdog is able to detect any node in the vicinity
that does not reply to route requests or does not forward successfully forward packets that
are sent to it. This will cause the uncooperative nodes to be labelled with bad reputation
values. According to CORE principle of exclusion these nodes will then be denied any
route requests. The same principle can be used to exclude nodes from packet forwarding.
If a misbehaving node drops packets it will soon discover that no one will forward its
packets.
3.4 A Secure Routing Protocol for wireless ad hoc networks
Trust management is based on a distributed authentication model [LS05]. The model
includes both direct and indirect trust. Direct trust is based on monitoring neighbouring
nodes and their transmissions. Indirect trust is based on exchanging trust-values between
other nodes.
Each node maintains a trust table that contains the calculated trust-values of every node
it knows. Trust is as a number between -1 to 4. Nodes that have a trust-value below 2
are considered untrustworthy.
The model defines trust as a series of trusted and authenticated nodes. If a node wants to
know if another node is trustworthy, it will ask for recommendation from every trustworthy
node. These nodes will then send back their trust of the unknown node. The original
asking node will then weigh these recommendations according to how much it trusts the
recommenders and uses this information to calculate the initial trust for an unknown node.
23

The model also includes a way to punish false recommendations. If a node falsely recom-
mends a node to another, the distributed authentication model might lower both nodes’
trusts unless one of the nodes starts badmouthing the other.
The model monitors the neighbouring nodes for any malicious activity and decreases their
trust if it finds any. If a node begins to consider another node as untrustworthy, it broad-
casts a WARNING-message to other nodes. Upon receiving a WARNING-message, a
node determines if it is from a trustworthy node. If so it adds the detected malicious to a
blacklist.
The routing uses HELLO messages to find and locate new neighbours. The distributed
authentication model is then used to identify these nodes. When sending a packet, a node
forms a route request to determine the route to the destination. Route requests from
untrustworthy nodes are dropped.
3.5 TARP
TARP [AKG06] (Trust-Aware Routing Protocol) is a trust-based routing scheme that con-
sists of two concurrent components: reputation assessment and path reliability evaluation.
TARP keeps track of several kinds of successful transmissions to a node in order to calculate
trust-values. What TARP looks for is:
• Number of unicast messages it has sent to a node and node has reported to have
forwarded.
• Number of unicast messages it has received from a node.
• Number of broadcast messages it has sent to a node and node has reported to have
forwarded.
• Number of broadcast messages it has received from a node.
• Number of messages it has actually overheard that the node has forwarded.
TARP sees direct trust as a product of the two-way link between itself and the node,
24

and the nodes willingness (or maliciousness) to forward the messages. TARP re-evaluates
a nodes trust at specific intervals, where it looks at the collected statistics derived from
communications with the node. Trust is defined in TARP as a number between 0 and 1.
TARP also handles indirect trust by allowing nodes to send reputation reports either as a
reply to a previous reputation request or if a trust of a node drop below a certain threshold.
When a node receives a reputation report about another node, it recalculates the nodes
trust, while weighing in how much it prefers direct trust over indirect trust.
Path reliability evaluation in TARP is a routing protocol that uses trust-information to
find the most reliable route from a node to the sink. It works by finding the most trusted
route from the sink over on to every node in the cloud. Each node receives multiple
possible routes from the sink, and selects the most trusted one as its primary route. Each
messages from that point on is transmitted to the sink via the primary route.
3.6 Trusted Greedy Perimeter Stateless Routing
T-GPSR [PM07] is an improved variant of GPSR (see Chapter 2.2). An integral part
of GPSR is that every node know its position on a common grid. GPSR uses location
information to select the next hop, and beacon messages to gather the locations of other
nodes. When sending a message, the routing layer must know the address as well as the
final position of the recipient.
Routing decisions are based on transmitting the packet to the node that is nearest to the
final recipient. GPSR is a stateless protocol. Every hop has a simple choice to make and
the route is not known or established at the beginning of transmission.
T-GPSR adds trust to the decision making. In normal GPSR, the node that is closest to
the final recipient is chosen. In T-GPSR, the node that is the closest and has the highest
trust is chosen as the next hop.
Trust in T-GPSR is based on first-hand observations about neighbours. After a packet
is forwarded, a node begins to eavesdrop on nearby communications to see whether the
packet is forwarded intact. Trust is thus described as.
25

T rusti(n) = W (PA) ∗ PA + W (PP ) ∗ PP
Where T rusti(node) is how much node i trusts node n, PA is the number of successfully
forwarded packet by node n, PP is the number of times node n has forwarded a packet
without tampering with its contents and W (PA) and W (PP ) are the designated weights
for PP and PA.
This protocol does not implement indirect trust. The authors conclude that using indirect
trust is vulnerable to deception where a malicious node may transmit false information
about itself or others.
3.7 A Trust-Based Geographical Routing Scheme
Trust-based geographical routing scheme [HLK07] is a routing protocol where each node
monitors its neighbours and tries to build routes that are as trustworthy and short as
possible. Trust-based geographical routing requires that all nodes know their position in
common coordinates. It also employes a kind of quality of service-scheme by defining a
minimum trust for a route that a packet must travel.
In trust-based geographical routing, every packet can individually be defined with a packet
trust requirement which is a number between 0 and 1. This value defines the minimum
trust of each hop that the packet should pass.
Trust is based in direct observations of neighbouring nodes. After a packet is sent the node
eavesdrops on its neighbours to find out whether the packet is forwarded. This information
is then used to calculate the trust for the forwarding node as such.
T rusti,j =
� NK=1 P i j,k ∗ Si j,k
� NK=1 P i j,k
Where P i j,k is the packet trust requirement for packet Pk, S i j,k
26
is 0 if the node j did not
forward the packet Pk and 1 if it did. So if a malicious node drops many packets that
have a high packet trust requirement, its reputation will drop faster than if it dropped less
important packets.

Trust-based geographical routing does not use indirect observations from other nodes.
Each packet also has a filter-distance which defines the minimum distance this packet
should travel with each hop. The filter-distance is initially set as an approximate of the
overall distance divided by the transmission range of the nodes. This filter is used to avoid
the situation where a packet is sent to a trusted but close node. The main point is to
guarantee an average hop-distance for the route and minimize hop count.
Routing decisions are made as the node that is the closest to the target out of all the
nodes that fulfill the minimum trust and filter-distance of the packet.
3.8 WSNodeRater and GESAR
WSNodeRater [MN07] (Wireless Sensor Node Rater) is an application-layer protocol that
interacts directly with the network layer, built on top of the a new routing protocol called
GESAR. It consists of three independent components for node monitoring, node rating
and event responses. GESAR (Geographic, Energy and Security Aware Routing protocol)
is an enhanced version of the GEAR routing protocol (see Chapter 2.2), that interacts
directly with the response component of WSNodeRater.
The routing protocol GESAR works by simply expanding the GEAR routing protocol
with the trust-information WSNodeRater provides. The distributed learning algorithm of
GEAR considers energy and distance when learning new routes to different areas of the
network. GESAR expands this by also considering the risk associated with a node. The
information from WSNodeRater is thus used to find the most trustworthy and energy-
efficient route.
WSNodeRater uses both direct- and indirect observations to determine trust-values for
other nodes. The monitoring component of WSNodeRater handles monitoring activities
around the node and supplies the rating component with first-hand information about
other nodes. It uses a technique called Energy Efficient Monitoring Procedure (EEMP)
to minimize power usage. EEMP tries to minimize the amount of time the monitoring
component must listen to other nodes in promiscuous mode. EEMP works by sharing the
monitoring workload between several nodes. EEMP assumes that a relationship can be
27

uilt between two or several nodes that agree to share the monitoring work for their area.
EEMP does not define strict timeslots for each node to do the monitoring. The individual
monitoring timeslots for each node are instead determined randomly and independently.
EEMP works by dividing each timeslot into two parts, the ON- and OFF-parts. Each
node then decides probabilities that it will start monitoring during the ON-slot, and a
probability that it will stop monitoring during the OFF-slot. Shared monitoring is random,
with the off chance that at some point, no node is monitoring the area.
The rating component draws information from the monitoring component and gathers
indirect observations from other nodes. First hand observations define the trust of a node
by a number between 0 and 1. Trust is calculated as:
riski = frequencyi
frequencymax
Where frequencymax is the maximum amount of bad behaviour that is tolerated per time
and frequencyi is defined as:
frequencyi = badbehaviouri
timei
Where badbehaviouri is the amount of bad behaviour noticed about node i and timei is
the amount of time spent monitoring node i.
The scheme then works by assigning untrustworthy nodes a high number, indicating high
risk. Trustworthy nodes receive a low number, indicating low risk.
Nodes may notify other nodes about node i by transmitting their risk for node i. These
indirect observations are added to the overall risk by.
riski = W ∗ riskdirect,i + (1 − W ) ∗ riskindirect,i
Where W is a weighing factor that is used to define how much emphasis direct observa-
tions are given over indirect observations. What is notable here is that WSNodeRater
automatically trusts indirect observations and does not consider or weight the source of
the information.
28

The rating component also employs a strategy of recalculating the risk of node i only when
node i is seen behaving well. If a node does not misbehave for a certain amount of time,
the rating component will begin to lower the risk of node i.
The rating component finally weighs the trust of a node by:
trusti = 1 − ri
rmax
Where rmax is the maximum risk that is tolerated of another node. So trustworthy nodes
will receive a high number near 1 and risky, untrustworthy nodes will receive a low number
near 0.
The article does not define what sort of behaviour is monitored of the nodes nor how nodes
actually share the monitoring work.
The response component of WSNodeRater can take action toward untrustworthy nodes
or work with the GESAR routing layer to avoid bad nodes. These actions include noti-
fying other nodes about a misbehaving node or shutting off all communications with the
misbehaving node.
3.9 Trust-based LEACH
A new trust-based version of the LEACH [HCB00] has been introduced [SZ08] that simply
called Trusted-LEACH or TLEACH. Trust management in TLEACH uses both direct and
indirect trust. TLEACH, like LEACH, works in tight intervals, dividing the operation of
the network to a well orchestrated and synchronized beat of data retrieval and monitoring.
TLEACH begins by electing nodes for cluster-heads. The cluster heads are in charge of
gathering and forwarding data from the nodes in their cluster to the sink. The size of the
clusters is determined so that about 5% of the nodes are cluster-heads. In normal LEACH,
the cluster head is chosen randomly and changed every now and again. In TLEACH every
node chooses the most trustworthy node to be the cluster head. To avoid malicious nodes
from becoming cluster heads, a minimal trust value is chosen that a cluster head must
fullfill.
29

After a cluster head is chosen, it segments time to periods of data sending and monitoring.
Each node in a cluster gets a small window of time to send data to the cluster head. During
other times a node may randomly monitor its neighbours to gather trust information.
The cluster head constantly keeps listening and monitoring its nodes and gathers trust-
information. After every node has sent data to the cluster head the cluster head forwards
this data to the sink. During this time the other nodes may or may not eavesdrop on the
cluster head according to how much they trust the cluster head. After this is done a new
cycle begins and the nodes transmit new data.
Indirect trust about other nodes is provided only by the cluster-heads to the nodes in
its cluster. Every node weighs this information to how much it trusts the cluster-head
according to the formula:
indirecttrust(i, j) = trust(i, head) ∗ rec(head, j) + (1 − trust(i, head)) ∗ trust(i, j)
Where i is the receiving node, head is the cluster head and j is the node that is being
talked about. trust(i, j) is how much node i trusts node j before and rec(head, j) is the
indirect trust-packet (recommendation) that the cluster head sends about node j. The
formula guarantees that if the recommender is not trusted, then the recommendation will
have little impact on the final opinion.
Direct trust in TLEACH is a multistep process where a node monitors either direct events
about a nodes behavior or receives recommendations from other nodes.
A node keeps track of how another node performs by calculating the number of good and
bad behaviours using beta distribution:
directtrust(i, j, O) =
Ngood + 1
Ngood + Nbad + 2
Where O is the type of operation that is monitored and Ngood and Nbad are the amounts
of good and bad behaviour that was detected about the operation. The result will be a
number between 0 and 1, with an unknown node having a trust value of 0,5.
The overall trust of a node is calculated whenever the direct or indirect trusts are updated.
The new observation about a node is added to the overall trust according to the formula:
30

trust = (1 − w) ∗ trustold + w ∗ newobservation
Where trustold is the previous trust, newobservation is the result from the new observation
(direct- or indirect trust) and w is a weighing factor that determines how much weight
should be given to new observation against the old trust value. The authors propose
a variable weighing factor w that is constantly adjusted to reward good behavior and
discourage bad.
3.10 Dynamic trusted routing
A secure routing mechanism is proposed in [DYN] that uses trust information to find the
safest route between nodes in a sensor network. The protocol utilizes a distributed trust
management scheme that gathers trust information about other nodes, then combines this
with a geographical routing protocol. A thorough list of monitored behaviour is used to
define direct trust, that is then combined with indirect trust from other nodes.
The scheme proposes that the following traits of other nodes are monitored and tabulated,
which include:
1. Packet forwarding.
2. The network-layer acks that are received.
3. Packet integrity, which means that no forwarded packets should be tampered with.
4. Authentication and Crypthography/Confidentiality which mean that the use of se-
curity measures must also be monitored for correct behaviour.
5. Reputation responses and correct reputation sharing, which means that a node will
be monitored that it participates in distributing reputation information and that the
information is correct.
6. Remaining energy, which means that nodes will share their energy-levels with neigh-
bouring nodes.
31

7. The distance to the sink node, because nodes closer to the sink will be seen as more
favourable.
The scheme also proposes that a log of previous interactions should be kept to combat
on-off -types of attacks, where malicious nodes may try to confuse other nodes by selec-
tively co-operating with them. This log would contain a history of previous interactions
accounted by whether they were successful or unsuccessful. In addition to this log the over-
all number of interactions with a node will also be recorded. The number of interactions
will be used to define a confidence factor for a node.
Six of these traits are directly calculated as direct trust. Trust of node B by node A
concerning trait i is then calculated as:
T A,B
i
= aiS A,B
i
aiS A,B
i
A,B
− biFi A,B
+ biF
Where ai and bi are the weight given to successful and unsuccessful occurrences of trait i.
S A,B
i
is the number of successful occurrences of trait i and F A,B
i
occurrences of trait i.
i
32
are the number of failed
The confidence factor of a node will be calculated according to the total number of inter-
actions with a node. This factor is defined as:
C A,B = 1 −
1
nB + wc
Where nB is the number of interactions with node B and wc is a baseline factor that is
used to weigh the initial confidence of newly discovered nodes.
Finally a direct trust value will be calculated as:
DT A,B = C A,B 6�
(
i=1
Wi ∗ T A,B
i )
Where Wi is a weighing factor for the six previous trusts concerning trait i.
Indirect trust is used in the scheme when for example a new, previously unknown node is
found or when there is a neutral opinion about a node. In these cases a node will request

that nodes around it send in their trust-information about the node in question, and uses
these values to calculate indirect trust as:
IT A,B n�
= W (DT
j=1
A,Nj Nj,B
)DT
Where Nj is node j of the neighbouring nodes, W (DT A,Nj ) is a weight given to the nodes
recommendation that is dependent on the direct trust of node Nj and finally DT Nj,B is
the node Nj:s opinion about node B. Recommendations from an untrusted node will then
be given less significance than recommendations from a trustworthy node.
Finally the trust-value of node B will be calculated as:
T T A,B = WDT ∗ DT A,B + WIT ∗ IT A,B
Where WDT and WIT are use to weigh the significance of direct trust-values to indirect
trust-values. As firsthand information should be given a higher significance, the article
recommends WDT be higher.
The weighing factors will be defined so that the overall trust-value of node B will be a
number between 0 and 1, with 0 noting a completely untrustworthy node and 1 noting a
completely trustworthy node.
Routing in this scheme works by a utilizing a stateless routing protocol that weighs the
next hop of a packet according to the trust-values of the neighbours. A decision will be
based on both the distance of the node to the final destination as well as the nodes’ trust-
value. In this regard the routing works very similarly to the Trusted Greedy Perimeter
Stateless-routing that was previously presented.
3.11 Overview of trust-based routing protocols
The last sections detailed several different approaches to routing in ad hoc- and especially
sensor networks. The oldest examples were from 2002 and the latest from 2009. What they
all had in common was a trust management system that used passive monitoring to spy
on their neighbours. This information was then used to base routing or other decisions.
33

Figure 6 summarizes some of the most common characteristics of the previous routing
protocols.
Some approaches detailed what should be monitored about other nodes, some did not. The
most common trait to look for was whether the other node forwarded packets. The most
complete list of monitored traits was used in Dynamic Trusted Routing. WSNodeRater
used a shared monitoring mechanism to minimize energy consumption, by sharing the
monitoring load amongst many nodes. Several different ways of detecting and identifying
malicious or suspicious activity have been identified [FGRL07], but the previously detailed
trust management approaches implemented only a subset of these.
Not every approach used indirect trust, these were TGPSR and the Trust-Based Geo-
graphical Routing Scheme. Indirect trust is when nodes share their trust-information
about other nodes. Some approaches used indirect trust, but did not consider whether the
information itself should be trusted. This kind of behavior could be used to spread false
rumors about other nodes. In TLEACH, only the elected cluster-head is allowed to spread
indirect trust-information about other nodes. In CORE, only positive observations about
other nodes is spread as indirect trust-information.
Routing was based on the idea that less trustworthy nodes should be cut off from routing-
duties and thus excluded from the network. In some approaches other services were also
denied from untrustworthy nodes, such as packet forwarding or route discovery. In the
Trust-based Geographical Routing Scheme, a sender could define a minimum trust for
every packet that it sends. The packet is then forwarded to nodes whose trust is atleast
the required minimum trust of the packet.
A clear distinction should be made about trust and reliability. A node should be trusted
when it is seen as friendly. A node should be seen as reliable when it is friendly and
participating in the network. This raises the question, how do we separate the intruders
from the faulty nodes, and should both be handled the same way?
Something that should be taken into consideration is how a potential attack is seen through
trust management. If an attacker manages to insert a malicious node to the network, can
this be detected by these different monitoring schemes? Is it likely that they report false
34

positives, nodes that seem to be fine but in reality damage the network? Is a trust
management system needed or would link layer encryption be enough to exclude attackers
from the network? And how much energy is a node wasting while it is monitoring its
neighbours versus how much it saves by avoiding bad nodes? One article [SLL09] tries to
measure how much sharing trust information impacts a nodes energy consumption. The
results simply showed that some trust management protocols consumed more energy than
others. Unfortunately these results could not answer our previous question, as the article
did not take monitoring into consideration.
It is difficult to decide which of these trust-based routing protocols would be best suited for
their purpose, as the none seem to address the previous questions and most importantly;
can they actually detect and isolate captured nodes from a network?
35

Name Direct- Indirect-trust Warning mechanism Monitored behaviour* Routing protocol
Confidant X X X ? DSR
CORE X X X (1,8) DSR
SRP X X X 1 not specified
TARP X X X 1 not specified
T-GPSR X 1,2 GPSR
TGRS X 1 not specified
WSNodeRater X X X ? GESAR (GEAR)
TLEACH X X ? LEACH
Teihal X X 1,2,3,4,5,6,7 not specified
* Monitored behaviour:
1: Packet forwarding
2: Network ACK
3: Packet integrity
4: Authentication
5: Cryptography
6: Corrent reputation sharing
7: Remaining energy
8: Routing functions
36
? : Not exactly specified in the article
Figure 6: Comparison of different trust-based routing schemes.

4 Analysis of trusted service discovery
The previous sections have included comparisons of different routing protocols for service
discovery, including trust-based ones. A major motivation for defining and monitoring
trust in sensor networks is that an individual node may be subject to node capture. A
malicious node could then try to damage the network by sending false sensing data or
by disrupting the routing. But all of the proposed trust-based routing protocols only
consider the neighbouring nodes. As such, a node will have no way of knowing anything
about nodes far away from them.
Another thing to consider is how the trust information could be leveraged for other appli-
cations? If the trust management system could give an accurate guess about which nodes
are malicious and which are not, would the user like to know about it? Consider a scenario
where a user has used service discovery to locate two sensors from the network and now
cannot decide which of them is more suitable? Discarding such information as location
(maybe the nodes are right next to each other) or power levels, should we ask which of
the nodes is more trustworthy?
The following chapters detail a way with which the individual trust-values of other nodes
can be used to describe the trustworthiness of a single node. Consider the previous scenario
where a user has received a reply from one of the potential service providers: What if the
trustworthiness of the provider could be defined as the product of the route through which
a packet must traverse. If the service provider is not trusted by its neighbours, the overall
trustworthiness should go down. If the packet traverses a route of highly trusted nodes,
the trustworthiness should be high. If the packet goes through a couple of untrustworthy
nodes, the trustworthiness should go down.
We define the trustworthiness of a service or a node as the chain of individual reputations,
or trusts from the service provider to the service seeker. As a node receives a packet for
forwarding, it must alter the trustworthiness field of the packet according to how much it
trusts the node from which it received the packet.
A series of simulations were prepared to test how this type of a scheme would behave
37

in a network that uses trust-based routing. The Dynamic trusted routing-protocol from
Chapter 3.10 was used in a network simulator called JSIM. Several ways of calculating the
overall trustworthiness are proposed and discussed. Finally a series of different networks
are built in the JSIM simulator to chart the trustworthiness of nodes in a network that
is infested with malicious nodes. The focus will be in presenting how given parts in a
network will be seen from different parts of the network.
4.1 Simulating network-protocols in JSIM
JSIM [JSIM] is a network simulation platform developed in Java. It is built around a
component-based architecture. Every entity is defined as an autonomous component that
is then connected to other components by strict contracts (or interfaces). For instance a
802.11 MAC-layer can be defined as a component that is then connected to a network-layer
component and a physical-medium component (a radio-antenna). JSIM also makes sure
that discreet events in the simulator occur in the correct order and on the right time.
JSIM is built as a comprehensive framework of protocols and components that can be con-
nected amongst each other to simulate different networked entities. Creating and defining
the simulator environment is done using a Tcl script language interpreter integrated into
JSIM, that allows rapid development and runtime creation and modification of the simu-
lator environment.
Simulating sensor networks is possible with JSIM as the software contains an existing
framework of several ad hoc routing protocols, a generic sensor application layer, a 802.11
MAC layer along with different kinds of radio-antennas, batteries and even processors.
The nodes in the simulator can be spread across a field in three dimensions and they can
be moved freely within this field. This allows the user to simulate for instance how nodes
network when randomly scattered, how the network performs and what kind of an impact
different scenarios have on the network or node lifetime.
An immobile prototype sensor was built with JSIM that used an 802.11 MAC-layer for
communications, no mobility-models and the implemented routing protocol that was based
on the Dynamic trusted routing scheme described in sections 3.10 and 4.2. A representa-
38

To other sensors...
Simulated Sensor
ID
Address
resolution
The "airwaves"
Keeps track of
battery and
energy
Queue
Wireless Channel
Sensor
application
WirelessAgent
Routing
protocol
Link layer
Mac 802.11
Wireless
Physical
Initiates
communications
Keeps track of
the position of
all the sensors
Determines
how a node
moves in the
area
Mobility
Model
Physical Node Tracker
Figure 7: A diagram of the components of a sensor and their connections in JSIM. A simu-
lated sensor in JSIM is broken down into several loosely coupled autonomous components.
The components are then connected with each other through ports.
tion of the components of the implemented sensor can be seen in Figure 7.
4.2 The trust-based routing protocol
A version of the Dynamic Truster Routing -protocol for JSIM was used to gather results.
Curiosly, the implementation was built on the regular GPSR routing protocol but a trust
management and calculation routine was added to its routine of routing decisions. Where
normally GPSR chooses the next hop by sending the packet as close to the final recipient as
possible, Dynamic Truster Routing combines forwarding- and integrity checks and energy-
awareness to the decision.
A node that must forward a packet chooses the next hop amongst its neighbours by
considering their distance to the final recipient and other weighting factors. This decision
39

is calculated as a sole number, a node’s reputation. The node with the highest reputation
is chosen as the next hop. Reputation for node x towards node i is defined as:
Where:
And:
reputationi(x) = distancei(x) + energyi(x) + forwardi(x) + integrityi(x)
distancei(x) = Wd ∗
1 − � distance(x, target)
� distance(allneighbours, target)
energyi(x) = We ∗ remainingenergy(x)
forwardi(x) = Wf ∗ succesfullyforwarded
packetssent
intergrityi(x) = Wi ∗ intergitymaintained
packetssent
Wd + We + Wf + Wi = 1
In this case the weighing factors were Wd = 0.5, We = 0.1, Wf = 0.2 and Wi = 0.2.
4.3 Calculating a chain of trust
Defining service trustworthiness or the chain of trust is based on gathering different opin-
ions about nodes into one estimate. We need to define a way to gather individual repu-
tations of nodes into one metric. This chapter details four different ways of defining this
metric.
Since all reputations are presented as a numeric value between 0 and 1, we try to find the
most representive way of defining a queue of numbers into one number that would give
the best estimate of the nature of the queue. This queue is the individual reputations of
nodes comprising a route from node x to node y.
40

A simple way of defining this metric would be to simply multiply the metric with the
reputation of the last hop. We will call this the aggregated-metric:
n�
trustworthiness(x, y) = reputationi(i − 1)
i=1
Where reputationi(i − 1) is the trust of node i about the last node i − 1 in the path.
This will ensure that the result will stay between 0 and 1. If the route contains untrusted
nodes (nodes with a low reputation), the results would drastically fall. Longer routes
will inevitably appear more untrustworthy as each hop decreases the total trustworthiness
of the node. This metric does have the advantage of needing only one field in the data
transimission packet, as every hop only needs to look at the trustworthiness-field and
multiply it with the reputation of the last hop.
Another space-conscious approach would be to calculate a square root of the multiplied
number. We will call this the square root -method:
trustworthiness(x, y) =
�
trustworthiness(i − 1, i − 2) ∗ reputationi(i − 1)
This method requires the same information as the previous multiply-method. It works
by multiplying the previous information with the reputation of the previous hop, but also
calculates a square root of the result. This has the added benefit of giving an estimate
of the average reputation of all the nodes in the route. Unfortunately this method also
places too much emphasis on the last hop and so tends to ’lose history’.
A critical piece of information would be the number of hops a route comprises off. This
information can easily be transmitted from the routing layer.
One way this allows us to calculate the chain of trust is by a simple arithmetic average of
all of the reputations of the route:
�ni=1 reputationi(i − 1)
trustworthiness(x, y) =
n
The average of reputations gives us a good estimate of the overall nature of the route while
giving equal weight to each hop of the route.
41

Another method of using the hop count of a route would be to count the multiplied
reputations of the route with the hop count:th root:
trustworthiness(x, y) = n
�
�
�
� n �
reputationi(i − 1)
One major benefit of this approach is that lower reputations will have a larger impact on
the total trustworthiness of the route.
To test the different metrics described above, we define three test scenarios and calculate
the trustworthiness with three of the four metrics, route average, hop count:th root and
square root. We will omit the aggregated-metric, as it is not easily compared to the other
three metrics. The most we can answer about the aggregated method is that the result
will lower with every hop, finally resulting in very low numbers.
Figure 8: Different methods of calculating chains of trust in a route consisting of good,
then bad, then good nodes.
Figure 8 shows the trust calculations of the three metrics when a packet traverses 11 nodes.
The reputations of the nodes decrease steadily from 0,9 to 0,1 as the packet moves from
hop to hop and then rise steadily back to 0,9. The average and hop:th root-methods each
react similarly to the reputations with the hot:th root-method returning more pessimistic
i=1
42

esults. The square root-method reacts heavily to the sinking and rising reputations of
the hops, and ends up with the most optimistic results.
Figure 9: Different methods of calculating chains of trust in a route consisting of bad
nodes, then good nodes.
Figure 9 has a route where the first half of hops have a bad reputation of 0,3 and 0,2, while
the second half has hops with good reputations of 0,8 and 0,9. Again, the average and
the hop:th root react similarly with hop:th root being more pessimistic again. The square
root-method reacts to the changes very optimistically ending with a very high result of
0,85. This high a number would suggest that the route is very trustworthy, though in
reality it is not. This is a good example of how the square root-method forgets its history.
Figure 10 shows a route with alternating bad (0,1) and good (0,9) hops. It shows what a
sobering effect the hop:th root-method has on the results. With a route that has a high
contrast between each hop, the average-method gives results suggesting neither good nor
bad hops. The square root-method is less optimistic but reacts erratically to each hop.
The hop:th root-method gives a bigger weight to the history of the route and so gives the
most pessimistic and steady results.
From these figures we see that both the arithmetic average- and hop:th root-method return
similar results, with the hop:th root-method in general returning the most pessimistic
43

Figure 10: Different methods of calculating chains of trust in a route consisting of alter-
nating bad and good nodes.
results, so both of them would be good candidates for defining a chain of trust out of
individual reputations.
4.4 Summary
If a sensor network uses a trust management scheme, or in our case: uses a trust-based
routing protocol, the nodes could aggregate individual trusts to form chains of trust from
one node to another. This would allow nodes to identify packets from less trustworthy
nodes near of far away. All this requires is a way of calculating individual opinions into one
representative number. The previous chapter has proposed and compared some methods.
One of these methods will be later simulated in the JSIM network simulator using the
ATSR routing protocol described in Chapter 3.10.
44

5 Results
The JSIM network simulator was used to test how a chain of trust scheme would work
in a sensor network. The JSIM simulator was used mainly because it had support for
simulating both sensor networks and the Dynamic Trusted Routing-protocol. A basic
service discovery-protocol was then implemented on top of the Dynamic Truster Routing
protocol-layer. The simulation was setup as a grid of sensor nodes.
The simulations were divided into 3 scenarios. Each scenario had a different number of
nodes in different kinds of locations. Each scenario was divided into 2 tests. One test
included no malicious nodes and one had a number of malicious nodes, implementing a
black hole-attack. These two tests could then be compared to see how the network behaves
when attacking nodes are inside the network.
Three metrics were calculated from each of these tests: average reputations of all the nodes
and chains of trust towards two different nodes.
An average reputation is derived as the arithmetic average of every nodes opinion of a node
(excluding the ones that don’t have an opinion). When presenting the average reputation
of nodes, the grid is populated with blue boxes that represent nodes, and black boxes that
represent malicious black hole -nodes. The size of a box indicates the average reputation
of a node with a larger box meaning a more reputable node. An example of this kind of
graph can be found in Figure 11.
A chain of trust is calculated for two asking nodes. This test is dependent on the position
of the asking node in the grid and the average reputations of other nodes. The test reveals
how trustworthy a service would be from any other node in the network for the asking
node. When representing chain of trust from one to to another, a different kind of graph
is used. One node is designated as the asking node, represented as a yellow box. Every
other non-malicious node is represented as blue box, with the size of the box representing
the trustworthiness of a route to the asking node. Malicious nodes are presented as black
boxes. An unknown node that could not be reached by the asking node is presented as a
question mark (?). An example of this kind of graph can be found in Figure 12 on page
45

Figure 11: A graph of average reputations in a grid of nodes. The grid contains 17 normal
nodes and 3 black hole -nodes.
47.
This way each scenario would produce 6 different results that could be used to assess how
a trusted routing protocol and a chain of trust -scheme will operate in a sensor network.
Since a trusted routing protocol requires information about its neighbours before it will
operate normally, the network was primed by transmitting random data between the
nodes. This was implemented by two nodes on the opposite corners of the grid each
downloading roughly 2 kB of data from each non-malicious node. In a 5x5 grid of nodes
with 23 transmitting nodes and a 256 byte payload this would amount to around 170
packets transmitted. At that point, every node will have a pretty good opinion about its
neighbours.
5.1 Scenario 1: A cloud of nodes
Scenario number 1 consists of 25 nodes aligned in a 5x5 grid. When malicious nodes are
added to the grid, they are spaced as a cluster of 7 nodes near one side of the grid. Nodes
in the opposite left lower- and right upper-corners function as the service asking nodes.
46

Figure 12: A graph describing chains of trust of other nodes for node in position 0,0 (the
yellow box). The larger the box, the more trustworthy a route to a node is. This graph
contains 13 normal nodes (one unreachable) and 3 black hole -nodes.
The addition of the black hole -nodes does not completely cut off the two corner nodes,
but only a few friendly nodes connect the two nodes.
The results from the scenario shows that at least when no malicious nodes are in the grid,
both the average reputations and chains of trust are as predicted. Findings from these
graphs are:
• In Figure 13c there seems to be number of nodes scattered randomly in the grid
that are less trustworthy (under 0.7) than the rest of the nodes (above 0.75). This is
because all of their service replies have taken a route through either nodes coordinates
0,100 or 100. This is because the node on 0,0 happens to have less trust for these
two nodes. It appers that although all of the nodes have dropped packets, these two
nodes have done it a bit more than their neighbours. So it is more a fault of why
these two nodes have misbehaved, there is nothing particularly wrong with the other
47

nodes.
• In Figure 13e the trustworthiness of nodes seems to drop linearly in the node’s
distance from the asking node. The different gradients of both Figures 13c and 13e
are odd and have most likely something to do with the simulator. Basically the
situations should be identical but for some reason node 0 sees the network as less
trustworthy than node 24. We conjectured that this is because the initiation routine
in the beginning favors node 0, but inverting the order in the initiation routine had
no effect on the results.
The results from the tests with black hole nodes show that the routing protocol is able to
circumvent the malicious nodes. The malicious nodes also seem to have an effect on the
reputations of the nodes that they almost completely surround. Outliers in the graphs
include:
• All the black hole -nodes suffer a reputation of around 0.57. The number should
be lower. This is due to the fact that position of node to the destination is given
a weighting factor of 0.5, so their reputations will not decrease until the position is
given less weight.
• In Figure 13b normal nodes in the left lower-corner of the grid have substantially
lower reputations than the other normal nodes. This is due to the fact that the node
in position 0,100 does not trust the node in position 0,0 (the asking node in this case),
so it routes the packets through nodes 200,0 and 100,0. Upon close inspection the
node in position 0,0 is not trusted amongst its neighbours. Some of the nodes have
sent a packet to the node and unfortunately the one and only packet that they sent
was dropped, so they thought the node was a black hole. Here we see how dependent
the trustworthiness metric is on the proper operation of the routing layer.
The previous measurements were done by comparing two nodes on different corners of
the grid. A different set of tests was committed to describe how neighbouring nodes view
the grid. The tests were done with the same parametres as scenario 1, using 7 blackhole-
48

(a) Average reputations with no malicious
nodes
(c) Chains of trust for node 0, no malicious
nodes
(e) Chains of trust for node 24, no malicious
nodes
Figure 13: Results for scenario 1
(b) Average reputations with 7 blackholes
49
(d) Chains of trust for node 0, with blackholes
(f) Chains of trust for node 24, with blackholes

nodes. A row of 5 nodes were chosen to query for services from the grid and record the
trustworthiness-results they received. The results of these tests can be seen in Figure 14.
The tests reveal that nodes on the right side of the grid, furthest away from the blackhole-
nodes view most of the grid as more reliable than nodes behind the malicious cloud. This
is because packets travelling to these nodes do not have to circumvent the blackholes
and as the hop count is smaller, the overall trustworthiness of the route is higher. For
instance: a packet travelling from node 400,400 (the node in the top-right corner) to node
0,0 (bottom-left corner) have to traverse 4 hops of very reliable nodes resulting with a total
trust-value of 0.765. When the same information is sent to node 400,0 in the bottom-right
corner, the packets only traverse 2 reliable hops resulting with a trust-value of 0.927.
5.2 Scenario 2: Two islands with one bridge
Scenario 2 consists of two 3x5 grids of nodes connected by a ’bridge’ of 3 nodes. In the test
that include hostile nodes, the 3 connecting nodes are designated as black hole -nodes, to
see if they can cut off communication from the two grids. The two nodes that are asking
for services are placed in opposite corners of the two grids, so that they are as far away
from each other as possible.
The tests without malicious nodes (Figure 15) show that the routing protocol is able to
find its way through the bridge and the two grids are able to communicate with each other.
Some more findings from the graph:
• In the average reputations, two nodes inside the clusters have a somewhat lower
reputations than the others. This is because a few nodes have chosen to believe that
the nodes are black holes. This is the same kind of behaviour that was seen in the
previous scenario. The nodes that do not trust the nodes with lower reputations
have tried to send only one packet before giving up and labeling the malfunctioning
node as a black hole.
• In both the tests that measure trustworthiness, the same malfunction can be seen.
For example in Figure 15c the node in position 0,200 has a significantly lower trust-
50

(a) Chains of trust for node 0, with blackholes (b) Chains of trust for node 5, with blackholes
(c) Chains of trust for node 10, with blackholes (d) Chains of trust for node 15, with blackholes
(e) Chains of trust for node 24, with blackholes
Figure 14: Comparison of how different positions affect trustworthiness-results.
51

worthiness as its neighbours. This is because it sent the transmission packet to a
node that doesn’t trust it, hence resulting in a low trustworthiness in the end. This
happens, because two nodes may have totally different opinions about each other
and these opinions have no correlation between themselves.
From the tests that include malicious nodes, we see that the 3 black hole -nodes that
connect the two grids effectively disrupt communications. The nodes asking for services
in the different grids are unable to get a response from the opposite side, as marked by
the question marks in graphs 16b and 16c. Other findings include:
• Some nodes in the right grid have no reputation. Reputation among other normal
nodes seems to be consistent.
• There is a large variance in how trustworthy nodes appear inside their own grid.
Some nodes have a trustwothiness under 0.3 and the highest seem to have trustwor-
thiness of over 0.9. There also seems to be no apparent reason other than a larger
hop count on some paths.
5.3 Scenario 3: Two islands with two bridges
The scenario consists of 2 3x5 grids of nodes connected by 2 5-node bridges. The tests
that have malicious nodes, one of the bridges is designated as 5 black hole -nodes. This
will show whether the routing protocol is able to find a functioning route between the two
grids. The two nodes that ask for services are again designated in opposite corners, so
that they are as far away from each other as possible.
In the tests that have no attacking nodes, it can be seen that the average reputation of
nodes is spread out between the whole area. The highest reputations are over 0.9 and the
lowest are just over 0.5. For some reason the left side of the area is seen as less reputable
than the right side. The nodes in the middle of the bridges also have a lower reputation
than the other nodes inside the bridges. Other findings include:
52

(a) Average reputations with no malicious nodes
(b) Chains of trust for node 0, no malicious nodes
(c) Chains of trust for node 26, no malicious nodes
Figure 15: Results for scenario 2, without malicious nodes.
53

(a) Average reputations with blacholes
(b) Service trustworthiness for node 0, no malicious nodes
(c) Service trustworthiness for node 26, no malicious nodes
Figure 16: Results for scenario 2, with blachole-nodes.
54

• The trustworthiness of nodes decreases rapidly the farther they are from the asking
node. This is directly related to the amount of nodes a packet must hop, but for
some reason is more apparent in this scenario that the previous.
• The same behaviour that was seen in the previous scenario, nodes inside the asking
nodes grid seem to have randomly high or low trustworthiness.
• Some nodes are unreachable.
The tests that include malicious nodes showed more consistent results. The routing proto-
col was able to establish routes using the proper bridge despite the bridge made entirely of
black holes. The average reputations of the nodes are evenly spread out among the map.
The middle node in the ’faulty’ bridge seems to have never received any contact because
no normal node has knowledge if it. Other findings include:
• The trustworthiness of nodes is spread just as unevenly as in the previous test.
The nodes that are in the same grid with the asking node seem to have random
trustworthiness. This again is because the routing has trouble finding the shortest
path to the recipient. Some nodes in the island are not trusted by the other nodes
so they reroute packets through unnecessary hops.
• All the nodes in the adjacent island seem to have around the same trustworthiness
numbers, suggesting the routing operates more consistently when fetching packets
from there.
5.4 Comparing different trust-metrics
All of the previous tests were done using the aggregated trust-metric, where every hop
multiplies the trustworthiness of the packet with the trust of the previous hop. This
results in a gradual reduction of the overall trustworthiness with every hop. As can be
seen in every previous test, the further a node is, the lower the trustworthiness of that
node is. This happens in spite of the fact that usually every hop of the route is very
reliable.
55

(a) Average reputations without malicious nodes
(b) Chains of trust for node 0, no malicious nodes
(c) Chains of trust for node 28, no malicious nodes
Figure 17: Results for scenario 3, without malicious nodes.
56

(a) Average reputations with blackhole-nodes
(b) Chains of trust for node 0, with blackhole-nodes
(c) Chains of trust for node 28, with blackhole-nodes
Figure 18: Results for scenario 3, with blachole-nodes.
57

In Chapter 4.3 two other trust-metrics were proposed: the arithmetic average and the hop
count:th root. These two metrics differ from the simple aggregated metric by describing
the overall trustworthiness of a route not by the length of the route but by the reputations
of the hops. This chapter introduces and compares results from these two metrics.
Scenario 3 (two clouds of nodes connected by two bridges) was used to gather results
for both the average and hop counth root-methods. The parameters for the experiment
were the same as in Figures 18b and 18c. One of the connecting bridges was filled with
malicious blackhole-nodes. Two nodes on the opposite corners of the grid then measured
the trustworthiness of every non-malicious node in the grid. The results of these tests can
be seen in Figure 19.
The tests revealed very similar results between the two metrics, infering that the differences
are not as stark as proposed in Chapter 4.3. Although scenario 3 is probably not a very
realistic scenario, it does hint that when traversing even long routes of equally reputable
nodes both metrics behave very similarly. Closer inspection of the results reveals that
when the packets travel the same routes, the average-method does return slightly more
optimistic results but these differences are miniscule. The actual routing of the packets
has a much larger impact on the results in Figures 19a to 19d.
So instead of recommending which method would be best suited in real life use, these
tests reveal that when given a large grid of nodes with parametres somewhat close to what
they will be in reality, both methods can be expected to behave almost similarly. The
differences in all of the tests were so small that choosing between the two should yield to
technical considerations instead.
5.5 Identifying malicious nodes
To test whether the chain of trust could be used to detect malicious nodes from friendly
nodes, a new scenario was prepared. 100 nodes were placed in a 10 x 10 grid, with a
4x4 box of 16 blackhole nodes near the center of the field. This time the blackholes were
programmed to reply to service requests, so that it could be seen whether their chain of
trust could separate them from the friendly nodes. The test was the same as the previous
58

(a) Chains of trust for node 28 with blackhole-nodes, using the hop count:th root metric
(b) Chains of trust for node 28 with blackhole-nodes, using the arithmetic average of reputa-
tions
(c) Chains of trust for node 28, with blackhole-nodes, using the hop count:th root metric
(d) Chains of trust for node 28 with blackhole-nodes, using the arithmetic average of reputa-
tions
Figure 19: Comparing the arithmetic average and hop count:th root trust-metrics in sce-
nario 3.
59

scenarios in every other sense, the trust-values of individual nodes were multiplied together
to form the same aggregated trustworthiness-value. The larger network was primed by
4 nodes in each opposite corner of the field downloading some 10 packets from each and
every other node. This allowed every node to form a good opinion about their neighbouring
nodes. The results of this test can be seen in Figure 20. The node that asked the service
was located in the upper-left corner of the field.
The test was largely successful, because every malicious blackhole node has a substantially
smaller trust than their neigbours. This means the scheme avoided giving out false-
positives. Instead we see a lot of false-negatives also. This is mainly a fault of the routing
protocol, and the same kind of behaviour could be seen in the previous tests also. Nodes
further away from the asking node have a lower trustworthiness-value.
5.6 Summary of tests
The results from the all the simulations showed that a chain of trust can be used to measure
the trustworthiness of a sensor network. Much of the accuracy of such a scheme stems
from the underlying trust management solution. The way an individual node monitors its
neighbours has the biggest influence on the results of a long chain of reputations in a chain
of trust. In fact, discrepancies in the routing protocol was the only source of false negatives
in our tests. The rest of the smaller questions fall back to how the chain of individual
reputations is calculated into a single number. This equation determines for example: the
limit where a good node is considered a bad node, how much an individual opinion affects
the whole chain and how the final result should be interpreted. The methods given here
are by no means perfect; they all have their faults. But what we can learn here is that
given a map of nodes and some trust management solution, an chain of trust calculated
from individual opinions can be used to extract interesting and possibly useful information
from the network.
60

Figure 20: Identifying malicious nodes from a large field of nodes. For clarity, this picture
only presents a nodes trust as boxes without text. Friendly nodes are colored blue, and
blackhole nodes are black.
6 Conclusions and future work
This thesis has dealt with routing in sensor networks. A number of different routing pro-
tocols were highlighted along with some that incorporated distributed trust management
systems. Distributed trust management systems have been proposed as a way of combat-
ing an event of node capture. A capture can occur when an attacker gains physical access
to a node and reprograms it to attack or disrupt the network.
The trust-based routing protocols defined different ways of detecting these malicious nodes
and all used this information to base some of their routing decisions. The line between
61

friendly and malicious was never seen as a clear line, but instead a gradual transition from
one end to another.
A open question is whether any of these trust management systems are effective in de-
tecting a realworld attack though captured nodes. Many of the systems focused on packet
forwarding or routing duties to detect malicious nodes. No real data was shown about
what would be the most realistic way to detect an attacker from a sensor network.
Regardless of the fact how a malicious node will be detected, the trust information could
be used further define the network. A chain of trust could be used to describe one node to
another. Ways of calculating this chain were introduced and simulation results on small
sensor networks were presented. The results showed that such a scheme can work if the
routing protocol works well.
Future work could be directed towards proving the feasibility of trust management and
further; trust-based routing in sensor networks. Node capture is a grave threat to a sensor
network, and a working trust management solution should be able to identify and isolate
compromised nodes from a network. If a trust management solution fails to do this, it
can only give a blind estimate about node reliability, which is a whole other matter. A
working trust management solution could then be used as input for other services that a
sensor network depends on, such as service discovery.
References
AKG06 Abusalah, L., Khokhar, A. and Guizani, M., Nis01-4: Trust-aware routing in
mobile ad hoc networks. IEEE Global Telecommunications Conference, 2006.
GLOBECOM ’06.
ASSC02 Akyildiz, I., Su, W., Sankarasubramaniam, Y. and Cayirci, E., A survey on
sensor networks. Communications Magazine, IEEE, 40,8(2002), pages 102 –
114.
AY05 Akkaya, K. and Younis, M., A survey on routing protocols for wireless sensor
networks. Elsevier Ad Hoc Networks Journal, 3,3(2005), pages 325–349.
62

BB02 Buchegger, S. and Boudec, J.-Y., Performance analysis of the confidant pro-
tocol. Proceedings of the 3rd ACM international symposium on Mobile ad hoc
networking & computing, MobiHoc, pages 226 – 236.
BBD06 Becher, A., Benenson, Z. and Dornseif, M., Tampering with motes: Real-
world physical attacks on wireless sensor networks. Security in Pervasive
Computing, Lecture Notes in Computer Science, 3934, pages 104 – 118.
BT Bluetooth technology info site. http://www.bluetooth.com. [7.4.2009]
CT04 Chang, J.-H. and Tassiulas, L., Maximum lifetime routing in wireless sensor
networks. IEEE/ACM Transactions on Networking, 12, pages 609 – 619.
FC08 Francillon, A. and Castelluccia, C., Code injection attacks on harvard-
architecture devices. CCS ’08: Proceedings of the 15th ACM conference on
Computer and communications security, pages 15 – 26.
FGRL07 Fernandez-Gago, M., Roman, R. and Lopez, J., A survey on the applicability
of trust management systems for wireless sensor networks. Third Interna-
tional Workshop on Security, Privacy and Trust in Pervasive and Ubiquitous
Computing, 2007. SECPerU 2007, pages 25 – 30.
GE01 Govindan, R. and Estrin, D., Geographical and energy aware routing: a re-
cursive data dissemination protocol for wireless sensor networks. UCLA Com-
puter Science Department Technical Report UCLA/CSD-TR-01-0023.
SLP Guttman, E., Perkins, C., Veizades, J. and Day, M., Service Location Proto-
col, version 2. Request for Comments (Standards Track) 2608, 1999. URL
http://tools.ietf.org/html/rfc2608.
HCB00 Heinzelman, W. R., Chandrakasan, A. and Balakrishnan, H., Energy-efficient
communication protocol for wireless microsensor networks. Proceedings of the
33rd Hawaii International Conference on System Sciences.
HKB99 Heinzelman, W., Kulik, J. and Balakrishnan, H., Adaptive protocols for infor-
mation dissemination in wireless sensor networks. MobiCom ’99: Proceedings
63

of the 5th annual ACM/IEEE international conference on Mobile computing
and networking, pages 174 – 185.
HLK07 Hung, K.-S., Lui, K.-S. and Kwok;, Y.-K., A trust-based geographical rout-
ing scheme in sensor networks. Wireless Communications and Networking
Conference, 2007, IEEE WCNC 2007, pages 3123 – 3127.
IGE00 Intanagonwiwat, C., Govindan, R. and Estrin, D., Directed diffusion: a scal-
able and robust communication paradigm for sensor networks. MobiCom ’00:
Proceedings of the 6th annual international conference on Mobile computing
and networking, pages 56–67.
JSIM The JSIM homepage. http://www.j-sim.org/. [7.4.2009]
KK00 Karp, B. and Kung, H., Gpsr: greedy perimeter stateless routing for wire-
less networks. MobiCom ’00: Proceedings of the 6th annual international
conference on Mobile computing and networking, pages 243 – 254.
KW03 Karlof, C. and Wagner, D., Secure routing in wireless sensor networks: attacks
and countermeasures. Proceedings of the First IEEE International Workshop
on Sensor Network Protocols and Applications, pages 113 – 127.
LS05 Li, H. and Singhal, M., A secure routing protocol for wireless ad hoc networks.
Proceedings of the 39th Annual Hawaii International Conference on System
Sciences, 2006. HICSS ’06., 9, pages 225a – 225a.
MCP + 02 Mainwaring, A., Culler, D., Polastre, J., Szewczyk, R. and Anderson, J.,
Wireless sensor networks for habitat monitoring. WSNA ’02: Proceedings of
the 1st ACM international workshop on Wireless sensor networks and appli-
cations, pages 88 – 97.
MGLB00 Marti, S., Giuli, T. J., Lai, K. and Baker, M., Mitigating routing misbehav-
ior in mobile ad hoc networks. Proceedings of the 6th annual international
conference on Mobile computing and networking, pages 255 – 265.
64

MICAZ The MicaZ datasheet. http://www.xbow.com/Products/Product_pdf_
files/Wireless_pdf/MICAz_Datasheet.pdf. [7.4.2009]
MM02a Michiardi, P. and Molva, R., Core: A collaborative reputation mechanism
to enforce node cooperation. Proceedings of the IFIP TC6/TC11 Sixth Joint
Working Conference on Communications and Multimedia Security: Advanced
Communications and Multimedia Security, pages 107 – 121.
MM02b Michiardi, P. and Molva, R., Simulation-based analysis of security exposures
in mobile ad hoc networks. European Wireless Conference 2002, Next Gener-
ation Wireless Networks: Technologies, Protocols, Services and Applications,
Florence Italy, Jan 2002.
MN07 Maarouf, I. and Naseer, A., Wsnoderater - an optimized reputation system
framework for security aware energy efficient geographic routing in wsns.
Computer Systems and Applications, 2007. AICCSA ’07. IEEE/ACS Inter-
national Conference on, pages 258 – 265.
PK00 Pottie, G. and Kaiser, W., Wireless integrated network sensors. Communica-
tions of the ACM, 43,5(2000), pages 51–58.
PM07 Pirzada, A. and McDonald, C., Trusted greedy perimeter stateless routing.
Networks, 2007. ICON 2007. 15th IEEE International Conference on, pages
206 – 211.
PSW04 Perrig, A., Stankovic, J. and Wagner, D., Security in wireless sensor networks.
Communications of the ACM, 47,6(2004), pages 53 – 57.
SA03 Stankovic, J. A. and Abdelzaher, T., SPEED: A stateless protocol for real-
time communication in sensor networks. Proceedings of the 23rd International
Conference on Distributed Computing Systems, 2003.
SML Introduction to SensorML. http://vast.uah.edu/SensorML. [7.4.2009]
SENSI Sensinode homepage. http://www.sensinode.com. [7.4.2009]
65

SLL09 Shaikh, R., Lee, Y.-K. and Lee, S., Energy consumption analysis of
reputation-based trust management schemes of wireless sensor networks.
ICUIMC ’09: Proceedings of the 3rd International Conference on Ubiquitous
Information Management and Communication.
SPEC2 Researchers create wireless sensor chip the size of glitter. http://www.
universityofcalifornia.edu/news/article/5456. [7.4.2009]
SPEC Spec takes the next step toward the vision of true smart dust. http://www.
jlhlabs.com/jhill_cs/spec/. [7.4.2009]
SZ08 Song, F. and Zhao, B., Trust-based leach protocol for wireless sensor networks.
Second International Conference on Future Generation Communication and
Networking, 2008. FGCN ’08., 1, pages 202 – 207.
TINYOS The TinyOS homepage. http://www.tinyos.net. [7.4.2009]
UPNP The UPNP forum. http://www.upnp.org. [7.4.2009]
VRYT08 Vyas, R., Rida, A., Yang, L. and Tentzeris, M., Design and development of the
first entirely paper-based wireless sensor module. Antennas and Propagation
Society International Symposium, 2008. AP-S 2008. IEEE.
XBOW Crossbow technology. http://www.xbow.com/. [7.4.2009]
DYN Zahariadis, T., Trakadas, P., Leligou, H., Papadopoylos, K., Ladis, E., Tse-
likis, C., Vangelatos, C., Besson, L., Manner, J., Loupis, M., Alvarez, F.
and Papaefstathiou, Y., Securing wireless sensor networks towards a trusted
”internet of things”. Future of the Internet Conference 2009, Prague.
66