4. Chapter 1
Keywords List
Wireless Sensor Networks - A series of small sensor nodes working in collabora-
tion.
Prism - A probabilistic model checking tool.
Network Privacy Algorithm - An algorithm designed to ensure privacy within a
network.
Source Location Privacy - The issue of keeping the location of a sensed target
private in a wireless sensor network.
Probabilistic Model Checking - Building the entire state space of a model that
incorporates probability, in order to test several key features of the model.
Guard Based Language - A language based upon a series of conditions that must
be satisfied in order for an action to be executed.
3
5. Chapter 2
Introduction
Within this chapter, the project undertaken and the key notions the project builds
upon will be introduced to the reader.
2.1 Abstract
This paper will analyse the security and energy efficiency performance of a source
location privacy algorithm within a wireless sensor network through the use of prob-
abilistic model checking. The model will be built using the Prism model checker tool,
and analysed by three key scores. These will be the probability of source location
capture, the number of messages expected within the system and finally the expected
time of source location capture. Further to this, the paper will introduce potential
further works into the study of source location privacy and wireless sensor networks
as a whole.
2.2 Introduction to Wireless Sensor Networks
Recent advances in micro-electrical-mechanical systems (MEMS) technology, wireless
communications, and digital electronics have enabled the development of low-cost,
low-power, multifunctional sensor nodes that are small in size and communicate wire-
lessly over short distances.[1] This has led to the development of sensor networks: a
large number of small sensor nodes working in collaboration to communicate infor-
4
6. mation to a main location. These sensors consist of one or more sensing capabilities,
as well as data processing and communication capabilities. Sensors can vary in na-
ture, obtaining information on anything from temperature and humidity to radio
waves present in the area. Such networks have gained popularity and have generated
excitement with the potential improvements they could provide within medicine,
transportation, agriculture, industrial process control, and the military. This is as
well as creating new revolutionary systems in areas such as global-scale environmen-
tal monitoring, precision agriculture, home and assisted living medical care, smart
buildings and cities, and numerous future military applications.[2] Further to this,
wireless sensor networks (WSNs) provide further functionality as the positions of
sensors need not be engineered or predetermined, allowing random deployment in
inaccessible terrains or disaster relief operations.[3] In spite of these numerous po-
tential uses, the development of WSNs has been hindered by a few issues. Firstly,
privacy in a WSN consists of not only the privacy of the message content but also
the privacy of the source locations. A source is considered to be a key node of par-
ticular interest or sensitivity within the network. A real world example may be the
last node to sense the location of an endangered animal within a tracking network.
Therefore if an attacker within the network, in this case a potential poacher, could
determine the direction of messages at a node, they could trace these back to the
source location and compromise the safety of the animal. It is for examples such as
this that source location privacy is integral within wireless sensor networks. Mecha-
nisms such as encryption can protect the confidentiality of the message content, but
even then a well-equipped attacker may still be able to determine the location of
the source by monitoring the traffic patterns and routing paths.[4] Further to this,
energy use is a key issue within WSNs, as these small sensor nodes are often battery
operated and hence must optimise power consumption. Therefore, through increas-
ing the energy optimisation of a WSN, we can increase the lifetime of the network
and hence its functionality. With this in mind, several techniques have been stud-
ied to improve this energy efficiency, such as sleep mode controls and energy efficient
routing algorithms.[5] In this paper, a contextual algorithm will be considered within
the context of these issues, analysing both the source location privacy and energy
efficiency of the algorithm. Furthermore, this paper will aim to optimise the values
5
7. of a series of key variables within the algorithm, identifying any potential trends
between the values the variables are assigned and the security and energy efficiency
scores they herald.
2.3 Motivation
The strongest point of motivation for any form of research into WSNs is, in my
opinion, the high potential of their future uses. During initial project discussions,
such uses did become the deciding factor in undertaking this project. In particular,
the military use of tracking infantry movements and conservationist use of tracking
endangered species’ movements alerted me to the vital importance of security in such
networks.
2.4 Problem
This paper covers the two key areas of interest for WSNs. It will cover the issue
of source location privacy. That is, given that a particular node in our network is
considered to be the source, how can the location of this key node be kept secure
from any potential threat in the network. The issue of energy efficiency will also be
considered, although this shall be seen as secondary to the source location privacy
results. Given that data transmission and all forms of processing will consume power
from nodes within the network, how can the network perform in such a way to reduce
this usage and hence optimise the lifetime of the network?
2.4.1 Areas Considered
As the algorithm considered is a source location privacy algorithm, not a crypto-
graphic algorithm, this paper will only consider the contextual security of the net-
work as opposed to the much studied content-oriented security of the network. That
is, it is assumed any attacker within the network can interpret incoming messages
well enough to ascertain the direction they came from. Within this scenario the
strength of security will be measured as the likelihood of the attacker capturing the
6
9. Chapter 3
Algorithm
This paper will focus upon analysis of the performance of one particular algorithm, as
developed by Arshad Jhumka.[6] Although significant further details on the adaptive
algorithm can be found in [6], a brief summary of the running of the simplistic
algorithm used will be given below. Firstly, the key behaviour of the algorithm must
be discussed.
Figure 3.1: A brief graphic showing the algorithm behaviour during attacker move-
ment
As shown in figure 3.1, the key behaviour of the algorithm is based around attacker
movement. When the attacker receives a message, it is assumed he will move in the
direction of that message. As this happens, the algorithm dictates that the attacker
node will then send a ’choose’ message to each of the neighbours that the attacker
8
10. does not move to. Each of these nodes, upon receiving the choose message, will
become either a permanent or temporary fake source. These types of node will then
simulate some behaviours of the true source node by transmitting messages across
the network in an attempt to draw the attacker back in the incorrect direction and
away from the real source.
3.1 Variables
The remaining key components of the algorithm are based around the selection of
key variables. Firstly, the notion of a permanent chance variable must be introduced.
This is defined to be the probability that a normal node will become a permanent
fake source upon receiving a choose message, otherwise becoming a temporary fake
source node. Another key variable is the period of the source node; defined to be
the time between message transmissions from the source node. Further to this, the
algorithm allows a separate variable for the period of fake source nodes, again set
to be the time between message transmissions but this time for fake source nodes in
the network. Finally, the lifetime of temporary fake sources is also set to be a key
variable. This is defined to be the time between activation of a temporary fake source
(changing from a normal node to a fake source node) to the point of deactivation
(returning to a normal node).
3.2 Key Algorithmic Steps to Build
The Algorithm can be divided into key steps for the building of a model:
1 Attacker moves within the network
2 Choose messages are sent to the former neighbouring nodes of the attacker
3 These nodes turn into fake source nodes, being permanent or temporary with a
probabilistic nature
4 Sources and fake sources transmit messages through the network at a predeter-
mined rate
5 Temporary fake source nodes must return to a normal node type once they have
completed their lifetime
9
11. 6 Messages flood through the network node by node, being removed once the net-
work has been covered
7 Each node transmits the last message it received to its neighbours
It is of vital importance that the model built implements all of these components in
order to provide a reasonable representation of the performance of the algorithm.
3.3 Objective
The key objective of this paper is to, through manipulation of the aforementioned
variables, optimise the running of the algorithm under consideration. That is, with
different network topologies and initial node structures, which values for each of
the variables will provide the best running of the algorithm. Optimisation of the
algorithm is considered to be the values which create the maximal source location
privacy whilst providing the minimal message traffic and hence energy consumption.
In short, it should aim to use the least energy possible to maximise the source location
privacy.
10
12. Chapter 4
Project Management
The management of the project has been a vital component of the progress made.
The development and testing of the model being built was an ongoing process. Al-
though development of the model was often sporadic, whilst knowledge and expe-
rience were gained, the work towards these stages of steep progress was constant.
Often the largest developments in the workings of the model would follow some of
the largest time periods spent with no progress of note. However through careful
testing and change being introduced at a steady rate, the source of the error was
found and corrected to allow further progress. By the nature of the tool used the
only possible testing method available was that of simulation. This involved, assum-
ing the version of the model being tested was successfully parsed, running several
automated simulations to ensure the model did not enter a state of deadlock. If
the model was found to reach the expected end state of all tested simulations, a
series of manual simulations would be undertaken. This process was often a case
of attempting to find the most difficult to implement path for the model, choosing
the state by state development of the model and ensuring heavy involvement in the
areas of the model most recently developed. Assuming the model was seen to be-
have correctly during manual runs, a larger volume of automated simulations would
then be tested. The property results of these simulations would be analysed, seeing
if the results given were a feasible representation of what was expected of the sys-
tem. Assuming this was the case, the next stage of development would then begin.
The largest issue with running a simulation based testing system for the model was
11
13. that subsystems could not be checked individually, the entire model had to be in a
working order to allow any testing to take place. This meant early testing of the
components built was not possible, only when the full model had been implemented
was testing available. However, such an issue was unavoidable by the nature of the
tool used, so early development was hastened in order to allow test led progress.
Development was split into a series of targets. Initially, the targets revolved around
levels of understanding to be obtained by a deadline. Once this had been completed,
the deadlines revolved around development of subsystems. A working model of the
network, although a simple one, was required by the new year. Progress was mon-
itored each week through meetings and update reports with my supervisor. After
achieving the new year deadline, development was planned on a week by week ba-
sis, aiming to increase the functionality of the model each time through guidelines
outlined by continued supervisor meetings. However, as discussed later on, certain
issues faced could not be surpassed and in spite of early development being ahead of
schedule, the model has failed to overcome these in the time available. A final key
aspect of the management of the project has been the back up system used. Back
ups of every save point were kept in a cloud storage system, however the organisa-
tion of these save files was key to the development of the model. The latest tested
and working version of the model was stored and backed up. In addition to this,
’idea’ files were stored separately, extending from the latest model file but allowing
errors to be made. If an ’ideas’ file failed to herald any progress, it would be left and
backed up but not developed any further. A new ’ideas’ file would instead be started
from the latest model file, in order to reattempt development. Once an ’ideas’ file
had made sufficient progress and had been extensively tested, it would replace the
model file in both local and cloud storage. A new series of ’ideas’ files would then be
built from this one. This process continued until the currently held model files were
developed.
4.1 Starting Point
Initial progress in this project was slow. As previously stated, initial targets set were
based around knowledge development. These included two distinct components of
12
14. knowledge required. Firstly, gaining knowledge about wireless sensor networks and
more specifically the behaviour of the algorithm within these was key to building a
representative model. Further to this was knowledge of the nature of issues faced
in these networks, such as energy management and source location privacy. Having
undertaken no previous study in any of the above topics, the learning curve for these
had to be steep. Secondly, and perhaps most importantly, was the ability to code
in Prism. Having no previous experience with this tool, or anything of its nature,
basic principles had to be quickly developed into the ability to create full models.
Assigning myself two weeks to build both knowledge bases to a serviceable level from
no prior study allowed additional time for implementation. This target was met and
led to the development of the initial model in time for the new year.
13
15. Chapter 5
Implementation
In this section, the creation of a probabilistic model built upon the basis of the studied
algorithm will be discussed, as well as the tools and techniques used to achieve this.
5.1 Creation of Model
Firstly, it was key to create a logically sound model of the WSN and the algorithm
running within it. Initially, a key decision to be made was the nature with which
the model should be viewed. Although this is a continuous time system in the real
world, it was quickly decided that it can in fact be simplified to a discrete time sys-
tem. By viewing each round of transmissions and movements as a single time-step,
the entire system can be viewed as a series of discrete time-steps without losing its
resemblance to real world networks. This allowed the creation of a much simpler
discrete time model, with each individual time-step including any movements and
transmissions that would be enacted at that time in a continuous model. With this
in mind, it was then realised that each time-step can in fact be simplified further.
As this system incorporates several distinct steps, notably movements, source trans-
missions and message flooding, it was noted that the full system could be further
divided into a series of smaller subsystems. Further to this, through manipulation of
the ordering of the subsystems running during each time-step, a continuous system
can in fact be fully simulated through a series of discrete time subsystems. The key
ordering imparted is as follows:
14
16. Movement System → Message Flood System → Source Transmission System → Additional Systems
Figure 5.1: The ordering of subsystems within the model
This ordering is the key component to the simplification of the system, as it
ensures the model performs as the full system would. This is because, by taking
the movement first, the attacker can only respond to messages received during the
previous round of transmissions, as required in the real world system. Further to
this, placing the source transmission system after the message flood system gives
preference to the new source messages, especially at nodes one hop from any form
of source. This is again as we would want the system to perform, to ensure new
messages from source nodes are not lost during collision with old messages. The use
of the additional subsystems at the end of the time-step will be discussed later on, as
these subsystems were only introduced as a solution to issues found during creation
of the model.
A final key issue to consider for the model was the nature of message collision for
the message flood system. In a WSN it is common for messages to collide and become
junk messages. For this reason, message systems will often have collision detection
in place or priority queues to ensure that each node only receives one message at a
time. As the system being created will be a discrete time system, it was decided
that each node will therefore only hold one message at the end of each time-step. In
order to ensure that message success was randomised, a transmission queue would
be formed, with each node taking a turn to transmit during each time-step, but this
queue would be randomised at each step to ensure that no node gets set preference
over its neighbours. This random queue system ensured fairness in the system, but
did create a further probabilistic element to the model, meaning it became key that a
probabilistic model must be the one built. Further probabilistic nature of the model
can be seen with the permanent chance clause of the algorithm, and the nature of
the movement of the attacker.
15
17. 5.2 Prism Model Checker
For this reason, in order to model check the system it was vital to obtain a proba-
bilistic model checking tool. It was therefore decided that the model would be built
using the Prism model checker software. This tool will build the full state space of
a probabilistic model in order to check a series of predetermined properties. Further
to this it allows simulation, enabling users to run a set number of paths as opposed
to building the full state space, allowing further testing and functionality. This sim-
ulation tool was seen as a key component for checking the model created during all
stages of development.
5.2.1 Prism Basics
Prism uses a guard based language for model creation. That is, it follows this format
:
[] guard → action
Figure 5.2: A simple prism line structure
This is to say that if all conditions in the guard are met, then we are free to
perform all changes in the action. If multiple clauses have their guard satisfied, then
Prism will randomly select one of the possible actions to perform from these. This
guard based nature allows strict and complex systems to be built up from a series of
possible scenarios.
Further to this nature, Prism uses only a series of variables and constants to
build these guards and actions upon. However, additional functionality is provided
in the nature of variables, as these can be either global or local. Global means that
the variable can be changed throughout the entire model and local means that the
variable is read only outside of the module it is declared within. Each declaration
follows this structure:
16
18. global? var name : var type [var min..var max] init?
const const type const name = ?
Figure 5.3: All possible listed options for variable and constant declaration
In variable declaration, it is first stated if the variable will be global. This requires
the keyword ’global’ if it is to be, leaving this option blank if it is to be local. It is then
assigned a variable name before being declared to be the type required. This type
can either be a Boolean variable, or an int variable. If the variable is to be a Boolean,
then the [var min..var max] is not required and the variable can be set to either true
or false. If the variable is to be a int, then it can be left unbounded by removing the
[var min..var max] option and instead only initialising this to a value. Otherwise,
the variable can be bounded by setting a maximum and minimum possible value
within the relevant option. The declaration of constants is more limited allowing the
same types again, Boolean and int, before being declared to the value required.
Another key component of Prism structure is the use of modules, which separate
the model into smaller components. Each module can only have one guard satisfied
at any one time, else the model is seen to contain errors. Each module contains its
local variables, as well as read access to all external local variables and full access
to all constants and global variables. Every module is built as a series of guards,
based around all variables, and actions; which can only change the modules’ local
variables and any global variables. Although this helps to logically divide the model
being built, the key functionality the module structure of Prism provides is module
renaming. This is, if a module is logically the same as another previous module up to
variable renaming, then the new module can be built from the old module as follows:
module M01 = M00 [x = y]
Figure 5.4: A simple example of Prism module renaming
This would declare a new module M01, that is logically identical to module
M00, with only variable y from module M00 becoming a new variable x for module
17
19. M01. That is, every constant and variable and each guard and relevant action from
module M00 will be exactly copied into module M01, with the only change being the
renaming of any instance of variable y to be an instance of variable x. This becomes
of great use in models with several similar but distinct components, as it removes
the need to repeat previously done work, instead allowing a simple renaming.
Further to this, the notion of guard naming and synchronisation can also be
introduced. This allows a particular guard to be named, synchronising all of those
with the same guard name. That is, all guards with the same name must make
transitions simultaneously, otherwise the system is seen to be in a state of error.
This again allows further control over the guards within the model being built. In
addition to this guards of a particular name can be assigned distinct reward values
during property testing, however this will be further discussed later on. Guards are
named in the following way:
[guard name] guard → action
Figure 5.5: An example guard naming line in Prism
Figure 5.5 will assign the guard the name ’guard name’. This will mean that all
guards assigned this name will be synchronised within the model.
A further component of note for Prism is the idea of multiple initial states.
This system removes any initialisation in the main body of the model code, instead
creating a series of initialisations at the end of the code in the following structure:
init x+y=1 endinit
Figure 5.6: A simple example of multiple start state initialisation
If we have only these two variables in our model, then this initialisation code
will create two initial states; x=0 and y=1 / x=1 and y=0. When model checking,
Prism will now build and check the full state space from each initial start state in
18
20. turn, allowing users to build multiple state spaces from a single model with multiple
potential initial states.
Further functionality is provided through the naming of formulas. This allows
longer or more complex formulae to be named in order to simplify their uses in a
guard. For example:
formula active = a00 + a01 + a02 + a03 + a04;
Figure 5.7: A simple example of formula declaration
This allows any instance of (a00 + a01 + a02 + a03 + a04) within the body of the
code to be replaced by the keyword ’active’.
A vital component of the Prism tool for the model being considered is the ability
to assign probabilities to the execution of different actions from a single guard. This
follows the structure given in figure 5.8:
[] guard → 0.2 : action1 + 0.8 : action2;
Figure 5.8: Example code for probabilistic actions within Prism
This allows us to initiate multiple potential actions from a single guard with a
probabilistic nature. Figure 5.8 effectively reads as, given that the guard is satisfied,
execute action1 with probability 0.2 or execute action2 with probability 0.8. The
probabilities on the action line of a guard must sum to 1, but this functionality is
key for the building of a probabilistic model.
Another tool built into Prism is the availability of a cost and reward system.
This allows the user to assign a particular cost or reward value to certain conditions
being satisfied. These can be set to be a fixed cost or reward being added under
certain conditions, alternatively allowing the value of an int variable to be added.
This feature is further embellished by the ability to assign distinct rewards to named
guards, as seen in figure 5.9:
19
21. rewards ”time”
[] guard1 → 4;
[name] guard2 → x;
Figure 5.9: An example of reward declaration, with variable value accumulation
Figure 5.9 creates a reward structure named ’time’. Prism will then increment
the time value by 4 every time guard1 is satisfied by an unnamed guard. It will
also increment the time value by the value of variable x, each time a ’name’ guard
satisfies the conditions in guard2. This allows a cost and reward structure to be built
up, allowing particular actions to herald several costs or rewards, aiding our analysis
of the model.
The final key component of the Prism tool to be introduced is that of property
testing. This is vital for all analysis of the model built, as it allows us to test
both expected reward values and conditional probabilities. In the first instance, as
previously discussed, rewards and costs are accumulated in the model. Using these,
Prism can calculate the expected value of this reward once a certain condition has
been met, either instantaneous at this point or accumulated up to this point. Further
to this, there are two key types of probability testing. Firstly the probability of a
condition being met can be calculated. Alternatively, a bound can be tested on the
probability, returning either true or false if the probability calculated satisfies the
stated bound. Within this system, Prism also allows several operators to be applied
to the condition during property testing. These include an ’until’ operator, ensuring
a condition remains true until a second condition is satisfied, and an ’eventually’
operator, testing the probability that a condition is eventually met within the model.
These in particular will be demonstrated in figure 5.10:
20
22. P=? [capture=false U complete=true]
P<=0.1 [F capture=true]
R{Messages}=? [complete=true]
R{”Cost”}=? [I=300]
Figure 5.10: Sample property code to illustrate the key functions available within
Prism property declaration
Each of the properties, as described in figure 5.10, will be discussed in turn.
The first property instructs Prism to find the probability that capture remains false
at each moment until complete becomes true. The second property will return a
Boolean response, stating if the probability that capture eventually becomes true
in the model is less than or equal to 0.1. The third property is a reward property,
this will return the expected accumulated value of the ”Messages” reward up until
the point that complete becomes true. The final property will return the value
of the ”Cost” reward at the instant of the 300th time-step. The customisability
available within Prism property testing allows more complex systems to be analysed
and multiple properties to be ascertained within a single Prism model.
5.3 My Model in Prism
This section seeks to bring together the two previous sections, providing the link
between the initial model design and the creation of the model in Prism. The system
incorporates many of the features discussed in section 5.2 and is built upon the
model discussed in section 5.1, with changes made to overcome issues faced during
implementation. Further to this, limitations in the functionality of Prism have lead
to a small change between the simulation file and the full model file, but this will be
discussed at the end of the chapter. It is first worth considering the general structure
of the built model. The first key decision to make was how to simulate the idea of a
’node’. To make the most of the Prism tool, it was easy to decide that this was best
incorporated as setting each module to represent a node. This allows easy extension
21
23. of the network being considered, as nodes can easily be divided into 9 types for the
networks under consideration:
Figure 5.11: A graphic showing the 9 types of node found in the model
Each node has to be considered unique due to their respective neighbourhoods.
This allows us to break node types down into the following; each corner node will
have a unique neighbourhood structure to be analysed, each edge node shares neigh-
bourhood structure only with those along the same edge, meaning each edge must
represent its own node type. All other nodes then have a complete neighbourhood,
and so can all be classified under the central node type. Therefore, creating one
module for each of these node types will allow us to build any size of network simply
through module renaming.
Another key decision to make was how to represent direction within the model.
For this purpose each module was given a directional variable that would be changed
as a message was received, in accordance with the direction the message came from,
as represented in figure 5.12:
22
24. Figure 5.12: A graphic showing the value of the directional variable based on the
direction a message is received from
Figure 5.12 shows the value that the directional variable will take as a message
comes in, based on the direction that the message has come from. This allows the
attacker to gain this knowledge and thus direct his movement accordingly.
A decision was also undertaken about the nature of the variables to be used.
Although the model was initially designed to be based around heavy use of global
variables, this blocked the ability to name guards, a feature which at the stage this
decision was made could not be sacrificed. Therefore, it was decided that the model
would instead be based around a system of local variables. Although this enabled the
use of guard naming, this did remove the ability to push messages or to enforce node
changes to neighbours. To replace this, it was decided the model would instead pull
messages from neighbours, using read-only indicators to signal when this should be
done and a similar indicator system for node changes. This ensured no functionality
was lost in the model in spite of the added complications this did initially create.
Another initial decision to be made was the nature of representing node and
message types. There are 5 types of node to be represented within the model, and
4 types of message to be represented also. As both of these are limited, and can
only have one value at any moment at each node, it was easy to decide that these
should be represented by a local variable within each module. The variables would
then follow the system shown in figure 5.13 to dictate how they are seen within the
network:
23
25. NODE = 0 (Normal), 1 (Temporary Fake Source), 2 (Permanent
Fake Source), 3 (Attacker), 4 (Source Node);
MESSAGE = 0 (No Message), 1 (Normal Message), 2 (Away
Message), 3 (Fake Message), 4 (Choose Message);
Figure 5.13: The listings of available values for the node and message variables, and
their equivalent meanings
This allowed all possible set-ups and eventualities to be encoded within the model
and translated the node and message types into Prism.
5.3.1 Assumptions of Model
Firstly, it is important to state all assumptions the model makes in its creation. Al-
though most assumptions were made to simplify the model to aid the development
of Prism code, none of these should affect the real world applications of the work
undertaken. The first assumption of note is that each node has an equal chance of
message success when it transmits a message through the network. This will be rep-
resented by an activation clause ensuring only one node can be active in the model
at any moment, with each having an equal probability of becoming active. Further
to this, the model assumes that all networks considered will have a grid structure.
This ensures that the 9 node types previously discussed will cover the requirements
of any network placed into the model. Also, the model assumes that each node has
only a single unit of memory. This is to satisfy the nature of Prism, as no array
of messages can be held, we instead assume only one message can be held at any
moment meaning a variable will satisfy the needs of the model. Further to this, the
model assumes that each message has a limited lifespan of 2β hops within the net-
work. That is, after 2β message passes the message will be taken out of the network,
where β is the length of the side of the grid. This ensures every message has the
capability of passing all the way through the network assuming it isn’t blocked en
route through message collision, as well as ensuring messages are removed and do
not continually flood through the network. Another assumption of the model is that
24
26. of an attacker success. Attacker success is deemed to be source capture within twice
the number of time-steps the source would have been captured if no algorithm was
in place in the model. Or, alternatively, the algorithm is deemed to be successful
if it manages to delay the attacker for twice the number of time-steps of a blank
WSN. A final assumption of the model is that of attacker behaviour. The model
assumes that the attacker behaves naively, that is, the attacker will always move in
the direction the last message was received from, regardless of if the destination node
has been previously visited. This enables a simpler attacker movement system to be
developed for model checking.
All code examples used from this point on will be taken from the source code; specif-
ically node 0 of the 5x5 grid system.
5.3.2 Attacker System
In this first section, I shall discuss the creation of the first system to run during
each time-step, the attacker system. This system performs several checks at each
time-step:
’[] (n00 = 3) & (m00 = 1|m00 = 3) & (r00 =
1) & (n01 = 4) & (movecomplete = 0) & (capture =
false) & (reset = false) → (capture =
true) & (capture time = timer + 1);’
Figure 5.14: Implementation of code to represent source capture
25
27. Figure 5.15: A graphic to show the first state check at the attacker node
Figures 5.14 & 5.15 are both the coded version of the scenario under consideration
and the graphical representation of it. In this situation, and the first check for the
attacker system, the attacker node will consider if it has a source message held in
memory. If so, it will then consider the node this has come from and the attacker
will therefore be moving to. If this node is the source node, then we know that the
attacker will capture the source with their next move, meaning that we set the node
to be captured and the time of capture to be the next time-step, when the move
would be completed.
The next consideration of the attacker system is, assuming the above scenario
has been discounted, whether an attacker move is necessary during this time-step:
’[] (n00 = 3) & (m00 = 1|m00 = 3) & (a00 =
0) & (active = 0) & (movecomplete = 0) & (n10! =
3) & (n01! = 3) & (capture! = true) & (reset =
false) → (a00 = 1);’
Figure 5.16: Implemented code to represent the beginning of attacker movement
26
28. Figure 5.17: A graphic to show the second state check at the attacker node
Figures 5.16 & 5.17 demonstrates the next check of the attacker system. For the
attacker node only, if no node is active in the network and there is a message present
at the attacker node, then the attacker will move this time-step and hence this node
must become active.
The next check in the attacker system is in fact for nodes within the neighbour-
hood of an active attacker node, however this check is split into two distinct parts:
’[] (n00! = 4) & (n00! = 3) & (n01 = 3) & (m01 =
1|m01 = 3) & (r01 = 3) & (a01 = 1) & (movecomplete =
0) & (capture = false) & (reset = false) → (n00 =
3) & (m00 = 0);’
Figure 5.18: Implemented code to show the node type change to signify an attacker
movement
27
29. Figure 5.19: A graphic to show the first state check at nodes neighbouring an active
attacker node
This shows the first check for the neighbours of an active attacker node. In this
state, the neighbour will read the directional clause of the active node to ascertain
if the attacker will be moving to the node in this time-step. If the direction does
point to the node, then the node will become an attacker node in preparation for
completion of the move.
’[] ((m00! = 4)|(r00! = 1)) & (n01 = 3) & (m01 = 1|m01 =
3) & (r01! = 3) & (a01 = 1) & (movecomplete =
0) & (messages < (4∗num nodes∗max time)) & (capture =
false) & (reset = false) → (m00 = 4) & (r00 =
1) & (messages = messages + 1);’
Figure 5.20: Code designed to represent the absorption of a choose message
28
30. Figure 5.21: A graphic to show the second state check at nodes neighbouring an
active attacker node
Otherwise, the neighbouring node must be in the scenario described in figures
5.20 & 5.21. That is, the node neighbours an active attacker node but is not set to
be the next destination for the attacker. In this scenario, the node must absorb a
choose message in order to become a fake source. This fully represents step 2 of the
algorithm.
The final system component for an active node is to complete the move and signal
for the next subsystem to initiate. This is done as follows:
’[] (n00 = 3) & (n01 = 3) & (m10 = 4) & (a00 =
1) & (movecomplete = 0) & (reset = false) → (n00 =
0) & (m00 = 0) & (a00 = 0) & (c00 = 1);’
Figure 5.22: Code to represent the completion of the attacker move
29
31. Figure 5.23: A graphic to show the final state check of an active attacker node
This final check applies only to the active ’attacker’ node. As this node has
become active, we know it must be moving away from the current location, sending
choose messages to all other neighbours. Therefore, once we detect a single neighbour
has become an attacker and all other neighbours have absorbed a choose message,
we can deactivate this node and return it to the ’normal’ node state. In addition to
this, we mark the c-variable to be 1. This tells the model that the attacker movement
system is complete for this round, and therefore the next subsystem, in this case the
message flood system, can become active. The completion of this move signifies that
the attacker movement system now covers step 1 of the algorithm.
The only other possibility is for the attacker node to enact no move:
’[] (n00 = 3) & (m00 = 0) & (n10! = 3) & (n01! =
3) & (active = 0) & (movecomplete = 0) & (capture =
false) & (reset = false) → (c00 = 1);’
Figure 5.24: Code used to recognise completion of a time-step with no attacker
movement
However, this a simple state to discuss. If the attacker node holds no source
30
32. message, then it will not be moving this time-step, and so the c-clause is set to 1 to
signify the completion of the system for this step.
5.3.3 Message Flood System
The next subsystem to activate is the message flood system. The purpose of this
system is to transmit any message currently held in storage for a node to its neigh-
bours, therefore flooding a message through the network. It is worth noting that each
guard within this system will test that ’movecomplete=1’, this is the models way of
ensuring that the attacker move system is complete for this round before activating
this subsystem. With that in mind, there remains several states to consider within
this subsystem:
’[] (n00 = 0) & (m00 = 4) & (d00 =
0) & (movecomplete = 1) & (reset = false) →
permchance : (n00 = 2) & (m00 = 0) & (p00 =
0) & (d00 = 1) + (1 − permchance) : (n00 =
1) & (m00 = 0) & (t00 = 0) & (l00 = 0) & (d00 =
1);’
Figure 5.25: The implementation of fake source creation in the model
31
33. Figure 5.26: A graphic to show a nodes behaviour when a choose message is held in
memory
The first check for this subsystem is if the message held in memory is a choose
message. If a choose message is held, the algorithm dictates that the node must be-
come either a temporary fake source or a permanent fake source, at a set probability.
Defining this probability to be ’permchance’, this subsystem then sets the nodes to
be either of the fake source types as defined by the algorithm. Further to this, it
sets the relevant local timers to be zero so as to ensure the new source transmits
at the correct period, however this will be further discussed later on. Finally, the
system sets the d-clause to be 1, to show that the node has completed the message
flood system for this time-step. This code represents step 3 of the algorithm in its
entirety.
32
34. The next consideration for this subsystem is a simple clause, but is key to ensuring
that the model behaves correctly:
’[] (n00! = 0) & (m00 = 4) & (d00 =
0) & (movecomplete = 1) & (reset = false) → (m00 =
0) & (d00 = 1);’
Figure 5.27: Code used to remove the choose message if no action is needed from it
This action will be used if a choose message is received at a non-normal node.
In this case, the node under consideration is already a special form of node and
so clearly cannot be ’overwritten’. For this reason, the node discards the message
without further action and completes its message flood for this round.
Another algorithmic step is then considered by the system, however this only
applies to the real source node:
’[] (n00 = 4) & (d00 = 0) & (movecomplete =
1) & (reset = false) → (d00 = 1);’
Figure 5.28: Code used to prevent the source node from passing messages, as defined
in the algorithm
This clause tests if the current node is the source node, setting the message flood
system as complete for this node if so. This is to ensure that the source node does not
flood messages through the network at a more frequent rate than its period defines,
as this would draw the attacker closer towards it.
Another simple case to consider is that of a node containing no message:
33
35. ’[] (n00! = 4) & (m00 = 0) & (movecomplete =
1) & (d00 = 0) & (reset = false) → (d00 = 1);’
Figure 5.29: Code used to read when a node does not need to flood a message this
round
In this scenario, the node has no message to transmit to its neighbours and so
must simply declare itself to be complete for this round.
Now moving into the higher functionality aspects of the message flood system,
we must introduce the notion of message ageing and the message ageing clause. The
x-clause of each module contains the age of the message currently held in storage;
defined to be the number of times this message has been transmitted in the network.
Further to this, a constant delta is used, which is set to be twice the side length
of the grid. As stated in the assumptions, a message should be discarded from the
network after delta hops, as at this point we know it must have covered the network.
With this in mind, the system performs the following:
’[] (n00! = 4) & (x00 >= delta) & (d00 =
0) & (movecomplete = 1) & (reset = false) → (m00 =
0) & (x00 = 0) & (d00 = 1);’
Figure 5.30: The implementation of the removal of expired messages in the network
Figure 5.30 is used to detect when the held message has hit its ’delta’ age limit.
If this is found to be the case, then we no longer need to transmit the message as
it is guaranteed to have covered the entire network. For this reason, the message is
instead discarded without further action and the node is set to be complete for this
round. This process covers the requirements of step 6 of the algorithm.
If a message is held that is within its expiry time, then an activation system
similar to that used in the attacker movement system is used:
34
36. ’[] (n00! = 4) & (x00 < delta) & (m00! = 0) & (m00! =
4) & (a00 = 0) & (active = 0) & (movecomplete =
1) & (d00 = 0) & (reset = false) → (a00 = 1);’
Figure 5.31: Code used to recognise a node that requires message flooding during
this time-step
Figure 5.32: A graphic to show a nodes behaviour when a message is held in memory
This is where the random queue nature of the message system is incorporated.
Figure 5.31 states that, if a message is held in storage at this node and the node
should transmit the message to its neighbours by nature of the algorithm, then it
will check if any node is active. If no node is active, then this node will ’bid’ to
become the active node. Prism will randomly select one node from all of those that
can activate. As each is assigned an equal probability of successfully becoming an
active node, the ordering of this activity is random every time this bidding process
occurs. Once a node is selected, it becomes the active node, blocking any further
’bids’ for activity from other nodes until it deactivates, at which point the selection
process occurs again. This repeats until all nodes that initially bid to become active
have activated and completed.
Once a node successfully becomes the active node of the network, then we again
35
37. must consider the actions of its neighbours. However, in this system, each neighbour
has only one simple action to perform:
’[] ((s00! = m01)|(r00! = 1)|(y00! = x01 + 1)) & (a01 =
1) & (d01 = 0) & (messages <
(4 ∗ num nodes ∗ max time)) & (movecomplete =
1) & (reset = false) → (s00 = m01) & (r00 =
1) & (y00 = x01 + 1) & (messages = messages + 1);’
Figure 5.33: The implementation of message pulling in the message flood system
Figure 5.34: A graphic to represent a message pull from the neighbour of an active
node
Figures 5.33 & 5.34 represent the behaviour of a node neighbouring an active
node in the message flood system. This node should ’pull’ the message from the
active node, copying the message across as well as ensuring to set the directional
variable and increment the absorbed age variable by one.
The final part of the message flood system again resembles the deactivation of
the attacker movement system:
36
38. ’[] (a00 = 1) & (movecomplete = 1) & (d00 =
0) & (s01 = m00) & (s10 = m00) & (r01 =
3) & (r10 = 0) & (y01 = x00 + 1) & (y10 =
x00 + 1) & (reset = false) → (a00 = 0) & (d00 = 1);’
Figure 5.35: Code used to complete the message flood system for a node
Figure 5.36: A graphic to show the deactivation of an active node in the message
flood system
The active node will continually sense for successful transmission of messages to
its neighbours. Once all neighbours’ message, age and directional variables match
what is expected from this transmission, the node knows its transmission for this
round has been successful. This means it can deactivate, allowing other nodes to
become active if required, and it can also set the d-clause to 1, marking its completion
of the message flood system for this time-step. The completion of this message pass
shows the implementation of step 7 of the algorithm.
5.3.4 Source Transmission System
The final main subsystem defined by the initial model is that of source transmission.
Each of the actions is guarded by a check to floodcomplete. The system checks that
37
39. floodcomplete = num nodes before it becomes the active system, ensuring all nodes
have completed the message flood system before the source transmission system
begins. This is the largest subsystem, giving us the most cases to consider:
’[] ((n00 = 0)|(n00 = 3)) & (e00 = 0) & (floodcomplete =
num nodes) → (e00 = 1);’
Figure 5.37: The implementation of a non-source node taking no source transmission
action
The simplest component of this system is the one shown in figure 5.37. If the
node is a normal node or the attacker node, then clearly it is not concerned with the
source transmission system and so can declare itself complete in this system for this
round.
Next the system deals with the real source node type:
’[] (n00 = 4) & (source timer! = 0) & (e00 =
0) & (floodcomplete = num nodes) & (reset = false) →
(e00 = 1);’
Figure 5.38: Code to show non-action for a source that has not completed its trans-
mission period
The first consideration for the real source, is the scenario where the global source
timer is non-zero. In this case, the source should not transmit this round and so the
system can be declared complete at this node for this round.
Now we must consider the actions for the real source when the source timer is at
zero:
38
40. ’[] (n00 = 4) & (source timer = 0) & (active =
0) & (e00 = 0) & (floodcomplete =
num nodes) & (reset = false) → (a00 = 1);’
Figure 5.39: Code to detect the requirement of transmission for the real source
Figure 5.40: A graphic to show the real source activation process
Figures 5.39 & 5.40 show the process undertaken when the source timer is at
zero. This defines that the node should transmit this time-step and so, in a manner
similar to the message flood system, if no node in the network is active, the source
will ’bid’ to become the active node.
Assuming the source becomes the active node, the system will once again deal
with the neighbours of the active node:
’[] (n01 = 4) & ((s00! = 1)|(r00! = 1)|(y00! = 1)) & (a01 =
1) & (e01 = 0) & (messages <
(4 ∗ num nodes ∗ max time)) & (floodcomplete =
num nodes) & (reset = false) → (s00 = 1) & (r00 =
1) & (y00 = 1) & (messages = messages + 1);’
Figure 5.41: Implementation of the message pull from the source node
39
41. Figure 5.42: A figure to show the message pull of a node neighbouring an active
source
Figures 5.41 & 5.42 show the model’s behaviour when dealing with an active
source. When the source becomes successfully active, all neighbours will pull the
source message from it, ensuring to set the directional variable and setting the age
variable to be 1, to signify the new message entering the network.
The final component of the system for the source again resembles the activity
nature of the previous systems discussed:
’[] (n00 = 4) & (source timer = 0) & (a00 =
1) & (e00 = 0) & (s01 = 1) & (s10 = 1) & (r01 =
3) & (r10 = 0) & (y01 = 1) & (y10 =
1) & (floodcomplete = num nodes) & (reset = false) →
(e00 = 1) & (a00 = 0);’
Figure 5.43: Code to detect completion of transmission for the source
40
42. Figure 5.44: A graphic to show the final stage of the source transmission system for
the real source
This final point of consideration for the source node is the deactivation process,
similar to those considered before. The active source node will sense for successful
message transmission to all neighbours, once this has been confirmed and the source
has sensed that all variables are as expected with neighbours, it will deactivate and
declare itself complete for this time-step. The completion of this part of the system
shows the implementation of the first part of step 4 of the algorithm, with the
source transmitting at a predetermined rate.
Due to the similar nature of the model’s behaviour for the temporary and perma-
nent fake source nodes within the system, these will be analysed side by side. Each
contains a system similar to that of the source timer, if the local timer is non-zero,
we must increment it and declare the node complete for this round:
41
43. ’[] (n00 = 1) & (l00 < temp life counter) & (t00! =
temp rate counter) & (t00! = 0) & (floodcomplete =
num nodes) & (e00 = 0) & (reset = false) → (t00 =
t00 + 1) & (l00 = l00 + 1) & (e00 = 1);’
’[] (n00 = 2) & (p00! = perm rate counter) & (p00! =
0) & (floodcomplete = num nodes) & (e00 =
0) & (reset = false) → (p00 = p00 + 1) & (e00 = 1);’
Figure 5.45: Implementation of local timers ticking over with no transmission occur-
ring
In this scenario, we have a fake source node with the local timers non-zero and
not at the maximum. The system will then increment the timers and complete the
system for this round, as required by the algorithm.
Another similar consideration for each node type is the scenario in which the
timer has reached the maximum value, the value of the fake source period defined
by the algorithm:
’[] (n00 = 1) & (l00 < temp life counter) & (t00 =
temp rate counter) & (e00 = 0) & (floodcomplete =
num nodes) & (reset = false) → (t00 = 0) & (l00 =
l00 + 1) & (e00 = 1);’
’[] (n00 = 2) & (p00 = perm rate counter) & (e00 =
0) & (floodcomplete = num nodes) & (reset = false) →
(p00 = 0) & (e00 = 1);’
Figure 5.46: Implementation of local timers resetting once the required time period
has been reached
With this the counter has reached the time period for re-transmission, so the
system sets the counters back to zero ready for source transmission the following
round.
42
44. The active transmission process within this system bares strong resemblance to
those previously analysed, so they will again be briefly discussed as an entire process:
’[] (n00 = 1) & (l00 < temp life counter) & (t00 =
0) & (a00 = 0) & (active = 0) & (e00 =
0) & (floodcomplete = num nodes) & (reset = false) →
(a00 = 1);
[] (n01 = 1) & ((s00! = 3)|(r00! = 1)|(y00! = 1)) & (a01 =
1) & (e01 = 0) & (messages <
(4 ∗ num nodes ∗ max time)) & (floodcomplete =
num nodes) & (reset = false) → (s00 = 3) & (r00 =
1) & (y00 = 1) & (messages = messages + 1);
[](n00 = 1) & (l00 < temp life counter) & (t00 =
0) & (a00 = 1) & (s01 = 3) & (s10 = 3) & (r01 =
3)v& (r10 = 0) & (y01 = 1) & (y10 =
1) & (floodcomplete = num nodes) & (reset = false) →
(a00 = 0) & (e00 = 1) & (t00 = 1) & (l00 = l00 + 1);’
Figure 5.47: Code used to implement the full activation, transmission and deactiva-
tion system for temporary fake source nodes
Figure 5.48: A graphic to show the full system for a temporary fake source trans-
mission
43
45. ’[] (n00 = 2) & (p00 = 0) & (a00 = 0) & (active =
0) & (e00 = 0) & (floodcomplete =
num nodes) & (reset = false) → (a00 = 1);
[](n01 = 2) & ((s00! = 3)|(r00! = 1)|(y00! = 1)) & (a01 =
1) & (e01 = 0) & (messages <
(4 ∗ num nodes ∗ max time)) & (floodcomplete =
num nodes) & (reset = false) → (s00 = 3) & (r00 =
1) & (y00 = 1) & (messages = messages + 1);
[](n00 = 2) & (p00 = 0) & (a00 = 1) & (s01 =
3) & (s10 = 3) & (r01 = 3) & (r10 = 0) & (y01 =
1) & (y10 = 1) & (floodcomplete =
num nodes) & (reset = false) → (a00 = 0) & (e00 =
1) & (p00 = 1);’
Figure 5.49: Code used to implement the full activation, transmission and deactiva-
tion system for permanent fake source nodes
Figure 5.50: A graphic to show the full system for a permanent fake source trans-
mission
As can be seen in figures 5.47-50, both processes are incredibly similar and do
resemble those seen before. As in previous systems, if local timers are found to be
at zero then it is clear that a source transmission should occur this round. Once
this has been established, the node will bid to become the active node if no other
44
46. node is currently active. Prism will again randomly select a single node to become
active in the system at this point. Once the node becomes the active node, all
neighbouring nodes will pull the message and all other required information from the
active node. Once the active node has detected that this process has been completed
by all neighbours, it will deactivate and return to its previous state, incrementing
the relevant timers in the process. Deactivation frees up the network again for a
new node to become active if necessary. This part of the system completes the
requirements of step 4 of the algorithm.
The only key difference between the model’s handling of temporary and perma-
nent fake sources is in the nature of lifetime. Obviously, the permanent fake source
has an infinite lifetime whereas temporary fake sources should expire at a time de-
fined by the algorithm. It is for this reason, the final part of the source transmission
system was needed:
’[] (n00 = 1) & (l00 = temp life counter) & (e00 =
0) & (floodcomplete = num nodes) & (reset = false) →
(n00 = 0) & (l00 = 0) & (t00 = 0) & (e00 = 1);’
Figure 5.51: The code used to distinguish temporary and permanent fake sources,
with temporary fake source deactivation
Figure 5.52: A graphic to show the change as a temporary fake source expires
45
47. Figures 5.51 & 5.52 show the simplistic process undertaken by the model when
a temporary fake source reaches the end of its lifespan. The node is returned to
a normal node, with all counters being reset to zero for future use and the node
completing its turn in this system for this round. This final component of the system
completes step 5 of the algorithm, and ensures the model implements all key stages
of the algorithm being represented.
5.3.5 Save System
The final subsystems to be considered were not in the initial planned design for
the model, but were instead created to overcome issues that were encountered dur-
ing the implementation of the design. This system is guarded by the value of the
timecomplete formula, requiring timecomplete=num nodes. That is, once all nodes
have completed the source transmission system, this system will become active. In
the original design, as a message came into a node with a single unit of storage, it
would overwrite any message held within the storage unit of the receiving node at
that time. Therefore, if two neighbouring nodes should each transmit in the message
flood system during the same time-step, then whichever activated first would over-
write the message of its neighbour. This meant that when the second of these nodes
activated, it was in fact transmitting the message it had received from its neighbour
that time-step, not the message it received the previous time-step (and hence should
be transmitting this time-step). It was for this reason an additional subsystem was
created, with a few new variables being introduced. Each node was given an addi-
tional memory slot for age and message. All incoming messages for that round would
then be saved into the additional slots, to ensure that they could not interfere with
the messages due to be transmitted from memory by nodes in that round. These
would then be copied into the original memory slots, ready for transmission in the
following time-step:
46
48. ’[] (f00 = 0) & (timecomplete = num nodes) & (y00 <=
(delta)) & (reset = false) → (f00 = 1) & (m00 =
s00) & (x00 = y00) & (s00 = 0) & (y00 = 0);’
Figure 5.53: The code used to save received messages into the regular storage slots
in preparation for transmission next round
Figure 5.53 gives the code used to define the entire save system. It is a very
simple system that copies the ’received’ data on message and age into the original
memory slots, ensuring they will be transmitted in the message flood system the
following round. It also resets the ’received’ data slots to ensure they remain blank
if no message is received in the following round. The system again has a completion
counter, the f-variable, which is set to 1.
Although technically two messages are held at a node in a single moment, only
one message is ever active within that node at any time. This means the system does
not compromise the assumptions of the model, it abides by only holding one active
message at any moment whilst ensuring the correct message is always the one being
transmitted.
5.3.6 Reset System
Another key subsystem to be created for the running of the model is the reset system.
This system is again guarded by a completion clause, requiring saved=num nodes.
That is, once all nodes have completed the save system for this round, this final
subsystem can begin. Initially, the entire model is placed into a state of reset:
’[] (source timer! = source rate counter) & (saved =
num nodes) & (reset = false) & (timer < (max time +
1)) → (source timer = source timer + 1) & (timer =
timer + 1) & (reset = true) & (start = false);’
Figure 5.54: The implementation of the global timer incrementation within the model
47
49. This action is a global action, placing the entire system into a reset mode. Further
to this, the model ensures to increment the global timers too, both the source timer
and the generic timer. Every action considered within this paper so far is guarded by
reset=false, meaning that no other action can be performed until reset is completed.
Each module, however, is started by a single possible action within reset:
’[] (reset = true) & (f00 = 1) → (a00 = 0) & (c00 =
0) & (d00 = 0) & (e00 = 0) & (f00 = 0);’
Figure 5.55: The ’reset’ code present to prepare each node for the next time-step
This performs a simple but vital action in order to reset the system, if the save
system is still set to be complete and the system is still in a state of reset, then
all completion variables must be reset to zero in preparation for the running of all
subsystems during the next time-step.
’[] (saved = 0) & (start = false) & (reset = true) →
(reset = false);’
Figure 5.56: The final code used in a time-step, beginning the process for the next
round
Once the system detects that saved is now equal to zero, it is clear that all nodes
must have been reset (as it was previously known to be equal to num nodes). This
means the system can be taken out of reset mode in order for the next time-step to
begin with the attacker movement system.
5.3.7 Detecting Completion and Collecting Results
The only aspect of the model left to be considered is detecting the completion of a
run. This can happen in two ways, both of which require us to obtain key pieces of
data:
48
50. ’[] (capture = true) & (complete = false) → (capture =
true) & (complete = true);’
Figure 5.57: The implementation of code to represent system completion under
source capture
The first scenario to consider is when a capture is detected. In this case the
system is simply placed into a state of completion by setting the complete variable
to be true.
’[safe] (saved = num nodes) & (timer = (max time +
1)) → (timer = (max time + 2)) & (complete = true);’
Figure 5.58: Code used to implement system completion under time expiration
The other potential scenario is if the model has run out of time for attacker
success, and hence the source is considered to be safe. In this case, we again place
the model into a state of completion with the complete variable and increment the
timer further.
’[] (capture = true) & (complete = true) → (capture =
true) & (complete = true);’
’[safe] (saved = num nodes) & (timer = max time + 2) →
(timer = max time + 2);’
Figure 5.59: Code used to trap the model in an infinite loop upon completion
The model is then held in the state of completion by creating a loop, an action
that affects no real change to the state of the model. Once Prism detects a loop
like this, the path is no longer extended and hence that run is completed. This
ensures that only the initial changes are implemented, but the above looping actions
49
51. shown in figure 5.59 only serve to stop the model, never actually extending the path
explored.
This leads to the ability of the model to collect the key data required using a
reward structure:
’rewards ”Total time”
[] (capture = true) : timer + 1;
[safe] (timer = max time + 1) : timer;
endrewards
rewards ”Messages”
[] (capture = true) : messages;
[safe] true : messages;
endrewards’
Figure 5.60: The reward structure used to obtain the key information from the model
This structure ensures that the data is collected only at the initial actions of this
section, those where the model is first set to be complete. As the rewards either
require complete to be true or the ’safe’ guard name, they can only apply to those
discussed in this section. However, as Prism does not extend the looping actions,
they in fact are only counted once, during the initial completion. The total time
reward structure is assigned the value of the timer as the model completes, with
the messages reward structure being assigned the value of the messages variable.
The messages variable was incremented by one throughout the model whenever a
message was pulled from an active node, meaning this will contain the total number
of messages transmitted in the model as required. These pieces of data are key to
the analysis of the model.
5.3.8 Division Between Simulation File and Model File
Through the current version of the Prism tool available, separate files had to be cre-
ated for use during simulation and model building. This is down to the initialisation
of variables, in this case used to define the structure of the network, including the
50
52. locations of the attacker and source nodes. The simulation option in Prism allows
the user to select an initial state, meaning no variables need be initialised for any
initial node structure to be available. However, such an option is not available for
model building in Prism, and so the variables must all be initialised before the model
can be built. This caused an issue as, when modules are created from renaming of
previously defined modules, no variable can be initialised to a different value. This
meant each ’central’ node had to be initialised to the same node type.
A solution for this has been found, but requires the use of a feature currently
not supported for simulations. Through use of the multi-start state tool built into
Prism, the model code uses the ’init ... endinit’ structure to initialise each variable
separately, building a fully customised starting structure. Using this to initialise
every variable used in the model also ensures that multiple-models are not built, but
a single model with a customised starting node structure can be.
5.3.9 Properties Tested for Model
The final file built for model checking was the properties file. This contained the
key properties to be analysed for the model in order to evaluate the success of the
algorithm:
P =? [ capture = false U complete = true ]
R{”Messages”} =? [F complete = true]
R{”Total time”} =? [F complete = true]
Figure 5.61: The properties file used to collect results on the model
The three properties shown in figure 5.61 give all of the information necessary
to analyse the model. The first property will return the probability that the node
reaches a safe state, or in other words that the source is not captured by the attacker.
The property reads as ’What is the probability that capture remains false until com-
plete becomes true’. However, we know complete will only become true if the source
is captured or the source becomes safe. Therefore if capture is false as the model
completes then the source must be safe. The second property finds the expected
51
53. value of the messages reward as the model completes. As discussed previously, the
messages reward is assigned the value of the number of messages transmitted as the
model completes. Therefore this property will return the expected number of mes-
sages sent in the model as it completes. The final property is similar, returning the
expected value of the total time reward as the model completes its run. This reward
is assigned the value of the timer as the model completes, meaning the expected
value of this reward is the expected completion time of the model.
These properties give us key details about the model. The first property will
tell us how the algorithm has performed in terms of source location privacy. If the
capture rate is low, then it is clear that the algorithm is performing well in keeping the
source secure. The second property will analyse the algorithms performance in terms
of energy efficiency. If a lot of messages are transmitted in the model, then clearly
this will use more energy than an algorithm that requires fewer transmissions. The
final property gives an additional idea on the algorithms success with source location
privacy. A low value for this property would signify that the source is captured
quickly whenever it is captured. This may be an issue with some WSNs and so gives
another aspect of the source location privacy to analyse.
52
54. Chapter 6
Results
This project aimed to test the aforementioned properties in order to ascertain the
success of the algorithm as the values of each variable was changed. It was hoped this
could be done in a model checking scenario, where the entire state space would be
built and tested for these particular values. Once all reasonable value combinations
had been tested for the algorithmic variables, trends within the data would be sought
in order to find the values that gave the strongest combined performance of security
and efficiency. In this chapter, the attempts and issues faced with obtaining results
will be discussed, as well as the partial result obtained.
6.1 Blank Model
A key component of obtaining the required result was to stringently define attacker
success. It was decided that the algorithm should be seen as successful if it takes
an attacker twice the time to capture the source as they would with no algorithm
in place. However, in order to ensure the model runs for the correct amount of time
before being declared safe, it became clear that a blank model had to be set up to
obtain the number of time-steps an attacker would be expected to need to capture
the source with no algorithm in place. A new Prism model was therefore set up,
identical to the original model but with all algorithmic aspects removed from the
file. This ensured that the only difference between the model built by this file and
the model built by the original file would be the algorithm being tested. The value
53
55. of ’time for capture with no algorithm’ was set to be the time required to ensure a
90% capture rate for the attacker in this blank model.
6.2 Issues Found
In spite of numerous solutions being found for issues encountered, the project still
failed to return the results hoped for. This was down to numerous problems, but
ultimately the limitations of the machines available caused the diminished return.
Despite attempts being made to overcome this, including communication with the
developers of Prism in the hopes that they may have a better insight into finding a
resolution, no solution has been found. However, it did become clear the issue lay
with the memory limitations of the machine being used rather than with the code
itself. As Prism will exhaustively search every possible combination of decisions it has
to make, the random queue nature of the algorithm meant each time-step heralded
huge volumes of potential combinations which, although logically equivalent, would
all be searched by Prism in order to build the full model. This meant that, as Prism
attempted to build the full model, the system ran out of memory and crashed before
it could complete it. Although attempts were then made to obtain cluster system
access, in hopes that the use of high-powered computing would solve the issue, this
was unfortunately not possible within a time-scale that allowed the return of results.
6.3 Partial Results
Despite these issues, a small number of results have been obtained. Whilst trying to
solve the memory issues encountered, the decision was made to begin obtaining some
results through the use of Prism simulation. However, as the no algorithm model
couldn’t be built, the true number of time-steps the model was required to run for
could not be obtained, meaning that each test was just ran for a consistent number
of steps. In order to improve the reliability of results, a large number of samples were
taken, however this heavily limited the number of results obtained as each simulation
test took approximately 72 hours to run on the machine available. The following was
obtained through running 100,000 simulations on a 5x5 grid structured network. The
54
56. model was set to run for 20 time-steps, with a confidence interval of 0.01 being put
in place:
Attacker
Start
Posi-
tion
Source
Posi-
tion
Grid
Size
Capture
Proba-
bility
Message
Aver-
age
Expected
Number
of Time-
Steps
Source
Rate
Perm
Rate
Temp
Rate
Temp
Life
Perm
chance
Centre Top
Left
5x5 0.41005 918.82097 15.83906 2 2 2 8 0.0
Centre Top
Left
5x5 0.41147 920.53285 15.81340 2 2 2 8 0.1
Centre Top
Left
5x5 0.41225 923.8306 15.80996 2 2 2 8 0.2
Centre Top
Left
5x5 0.41298 925.84521 15.80154 2 2 2 8 0.3
Figure 6.1: The full table of simulation results obtained
In spite of these results being obtained, and seemingly a trend beginning to
emerge, the results ultimately have a highly limited use. As they are based purely
on simulation as opposed to model checking, they may miss key cases that could
dramatically effect the results. Further to this, the model is unlikely to have run for
the correct amount of time to declare safety as the no algorithm model was not able
to be used to give the correct value. Likewise, despite a trend seemingly emerging,
too few results have been taken in order for this to be nearing proven. Although the
results are interesting to look at to begin to build a picture of the model behaviour,
they cannot be used to create anything beyond speculation due to their limited
nature.
55
57. Chapter 7
Future Work
In this chapter potential future works based upon this project will be discussed. They
will be numerous, due to the issues faced with this project as well as the interesting
and high potential nature of the topic being researched. There are several potentially
in depth and challenging extensions to this project that may be considered.
7.1 Implementation of Multiple Algorithms
Firstly, the idea of incorporating multiple algorithms into this model based analysis
is an interesting as well as potentially high value concept. This would allow side by
side comparison of the performance of the algorithms, set within the same model
environment to ensure total fairness in the comparisons. Such work could lead to
a standard algorithm to be defined for maximal source location privacy, maximal
energy efficiency, maximal confirmed delay and the strongest algorithm for combining
all of these. If this work could be undertaken, it could be a key component for defining
a standard for WSNs in the future.
7.2 Expansion of Grid Sizes Considered
A simpler, but equally as vital, potential extension to the current project would be
to extend the range of grid sizes being tested. At the current moment, only the 3x3
and 5x5 Prism models have been created. However, due to their module based design
56
58. and the module renaming tool built into Prism, extensions of these would be easy to
create, allowing a wide range of grid sizes to be modelled.
7.3 New Network Structures
A further extension to the above would be to consider new network structures. At
the current moment, the project focusses only on grid based networks. Clearly, in the
real world WSNs are made up of varying structures, their ability to do this is a large
part of their practicality. For this reason, it would be important to further analyse
performance across a range of network structure types. Potential starting points
may be the circular and ring structures commonly found in WSNs, however further
structure creations may be possible. If nodes are divided into node types, as used to
a limited extent for this project with 9 node types being created, then by defining a
module for each node type and through module renaming for any repetition in the
network, entirely customisable network structures should be creatable.
7.4 Design of Message Efficiency Algorithm
This idea could in fact be an important component of strengthening the models
basis to a real world representation. Although the energy efficiency of the algorithm
is measured with this project, the message system behaves very naively, in a way
that is unlikely to be used in real WSNs. Instead, further energy saving would be
implemented through the use of message efficiency algorithms in conjunction with
source location privacy algorithms. Therefore, through incorporating such a message
efficiency algorithm into the model, a more realistic result on the energy efficiency of
the source location privacy algorithm could be obtained. This may, in fact, become
key to analysing the energy efficiency of the algorithm as it is unclear if the algorithms
will interfere with each other’s performance until such testing happens.
57
59. 7.5 Use of High Powered Computing to Build Full
Models
An obvious extension of the work is to build the models, in order to model check
the full state space. Although this has not been possible within the bounds of this
project, through the use of high powered computing it is believed that the building
and analysis of such models would be trivial, with the foundations already being
in place. Therefore, although this work should not require much beyond access to
high-powered computing, it is still a vital future work that must be undertaken for
any further progress to be made with analysis of this algorithm.
7.6 System Inclusive of Content-Oriented Secu-
rity
The final potential future work that could be built from this project is the incor-
poration of content-oriented security within the model. This would again provide a
stronger real world model to analyse, as any WSNs will make use of both forms of
security available. This may drastically affect the performance of the model, as any
attacker may have to break the content-oriented security to an extent before being
able to challenge the contextual security of the system. This would allow a stronger
analysis of the security based performance of the algorithm, as well as providing a
tool for fully simulating attacks upon WSNs. One of the main issues would lie with
the selection of the best content-oriented security algorithm to optimise performance
when used in conjunction with the contextual security algorithm, although several
of the strongest security algorithms could be created and tested to ensure the best
possible combined security and efficiency results.
58
60. Chapter 8
Related Work
There are few related contextual security studies of note, due to the heavy focus
upon content-based security. However, one of the main works of mention would
be that of Phantom Routing. This is another source location privacy algorithm to
rival the one under consideration in this project. This algorithm is again based
upon the idea of fake sources, but the key difference lies in the selection of the fake
sources. Whereas the algorithm used in this paper takes fake source based upon the
attacker location, the Phantom Routing algorithm will instead choose fake sources
by selecting a random path, of at most a predefined length h, from the source. Once
a phantom fake source is encountered along this path, the fake source will flood the
network with the source message in order to draw the attacker away. However, a
phantom fake source is often encountered within h/5 hops of the source, meaning
that the optimal level of security is not achieved. Although other routing algorithms
have been suggested to find a phantom fake source further from the true source, no
standard has been set that ensures an increased source location privacy.[4]
Another potential area of relation lies within the creating of communication proto-
cols for the message flood system. These studies are again sparse, although clustered
message sending systems, where the WSN is split into clusters each with a head
node, should reduce the energy required to flood a message through a network.[7]
The other strongest related works are those into content-oriented security, as
they would be used in partnership with any contextual security algorithm. However,
there are a vast number of studies into this topic, meaning a full scope of the field
59
61. is difficult to summarise here. It is my belief that the most interesting of these
currently being researched is that of quantum security. This is based around the
idea of using quantum computing for both the key distribution and cryptographic
process of any communication. Although quantum computers are currently little
more than an idea, should they be achieved, it is argued that this form of security
may in fact be unbreakable.[8]
60
62. Chapter 9
Acknowledgements
This project has been possible due only to the help and support of Arshad Jhumka,
without whom the level of understanding achieved and progress made would not
have been feasible. Also with special thanks to Matthew Bradbury for his initial
work giving rise to this project, as well as for his frequent help during meetings.
Finally, thanks must be given to the developers of Prism, both for the use of their
superb Model Checking tool and for their help in analysis of the issues faced with
model building.
61
63. Bibliography
[1] Akyildiz, I.F. et al., 2001. Wireless sensor networks: a survey. Atlanta, USA:
Georgia Institute of Technology.
[2] Stankovic, J et al., 2008. Realistic Applications for Wireless Sensor Networks.
Charlottesville, VA, USA: University of Virginia.
[3] Akyildiz, I et al., 2002. A Survey on Sensor Networks. Atlanta, USA: Georgia
Institute of Technology
[4] Zeng, Z et al., 2010. Source-Location Privacy Protection in Wireless Sensor Net-
works using AZR Routing. Changsha, Hunan, China: Central South University.
[5] Cardei, M et al., 1976. Energy -Efficient Target Coverage in Wireless Sensor
Networks. Boca Raton, FL, USA: Florida Atlantic University.
[6] Jhumka, A et al., 2010, Fake Source-based Source Location Privacy in Wireless
Sensor Networks, Coventry, United Kingdom: University of Warwick.
[7] Heinzelman, W. R. et al., 2000. Energy-Efficient Communication Protocol for
Wireless Microsensor Networks. Cambridge, MA, USA: Massachusetts Institute
of Technology.
[8] Gisin, N et al., 2008. Quantum cryptography. Geneva, Switzerland: University
of Geneva.
62
