Source Location Privacy Using Fake Source and

Phantom Routing in Wireless Sensor Network

By
Mrityunjay Jha

UNDER GUIDANCE OF

Mr. Ujjal Chanda

Submitted to the
NEW HORIZON COMPUTER LEARNING CENTRE

In partial fulfillment of the requirements

for the degree of

MCA
1
 INDEX
1. Abstract..3
2. Introduction 4
3. Objective. 5
4. Requirement and analysis 6
4.1 Problem Definition.6
4.2 Planning and Schedule ...7
4.3 Software hardware description....8
5. Software description about technology.9
5.1 Architecture of Omnet++.10
5.2 Privacy in Wireless Network.13
5.3 Previous Related Work.15
6. System Analysis 17
6.1 SRS17
6.2 Work with Omnet++ flow chart19
6.3 Topology 20
7. Testing..23
8. Limitation. ...26
9. Future Sco..26
10. Bibliography.27

2
1. Abstract
Wireless sensor networks (WSNs) consist of
numbers of small nodes that can sense, collect, and
disseminate information for many different types of
applications. One of these applications is subject tracking and
monitoring, in which the monitored subjects often need
protection. For instance, a WSN can be deployed to monitor
the movement of a panda in a large park. The panda needs
protection from different adversaries. An adversary might
trace the messages in the WSNs to find the source node that
sensed the panda, with the final aim of killing the panda.
Hence the question is: how do we hide the location of the
source node from the adversary? In other words, the problem
is to provide privacy to the source node: Providings our
location privacy(SLP)is complicated by the fact that there are
many factors that influence the effectiveness of a solution.
The problem with most of the existing solutions is that they
only provide SLP in a few specific scenarios. Therefore, we
introduce our adaptive and distributed solution: the Fake
source and Phantom routing (FSAPR) protocol, which provide
the source location privacy in different situation. Our solution
is based on a survey of the state in source location privacy
with a rigorous analysis of the existing fake source routing and
phantom routing protocol.

3
 2. Introduction
Wireless sensor networks (WSNs) are a network,
which consists large number of sensor nodes, which are
communicated through the wireless link. Sensor nodes are basically
small in size, low cost radio devices. They have limited processing
capabilities and life time. WSNs enable several classes of
application, such as automatic data collection, habitat monitoring,
military surveillance, disaster relief operations, etc. One of these
applications is subject tracking and monitoring, in which the
monitored subjects often need protection. For instance, a WSN can
be deployed to monitor the movement of a panda in a large park.
The panda needs protection from different adversaries. An
adversary might trace the messages in the WSNs to find the source
node that sensed the panda, with the final aim of killing the panda.

4
 3. Objective

Our objective for this project is to protect the

location privacy of the source location. In order to that we are
misleading the adversary by using some technique like fake source,
phantom routing and so on. So, in this project we are trying to
evaluate the application of fake source, phantom routing and
similar techniques in preserving the real source location.

5
 4. REQUIREMENTS AND ANALYSIS

4.1 PROBLEM DEFINITIONS

When our enemy wants to attack on me and we dont

have any idea of that attack, suddenly we know about that attack
that time we have only one option for our enemy to pervert them.
For handle this type of situation I thought make a
wireless sensor network application like Source Location Privacy
Using Fake Source and Phantom Routing in Wireless Sensor
Network, by this application we can create many fake
locations, so in situation enemy will be confuse and they cant
be access our actual location.

6
4.2 PLANNING AND SCHEDULE:

Gant Chart with PERT for Source Location Privacy Using

Fake Source and Phantom Routing in Wireless Sensor
Network

Task Dependencies duration 1.1.17 to 30.6.17

1 Start

1 Previous Task 1 15 days

2 Requirement 1 20 days

3 Analysis 1 30 days

4 Designing 2 35 days

5 Coding 2 40 days

6 Testing 3 35 days

7 Implementation 3 20 days

8 Finish

7
4.3 SOFTWARE/HARDWARE REQUIREMENTS

SOFTWARE REQUIREMENTS
Operating system: Windows 8
Front-end tool: Omnet++
Editing tool: Microsoft office 2007
Language: c++
Platform: JDK

HARDWARE REQUIREMENTS
Processor: Intel dual core
RAM: 4.00 GB(Min 256 MB)
Hard-disk: 500 GB(Min 160GB)
Monitor: Any type
Mouse: Optical mouse
Keyboard: General 98 keys keyboard
Remote sensing device:MacroMote

8
 5. SOFTWARE DESCRIPTION ABOUT TECHNOLOGY
Omnet++:-
The OMNET++ IDE is based on the Eclipse platform
which is an extensible, Java based framework. While it started as
an IDE framework only, its main goal is to be a generic integration
platform. Extensions (called plug-ins) can be written in Java
language. Plug-ins can be simply added to an existing Eclipse
installation, extending it with new functionality by contributing
various user interface elements into the platform user interface.

The OMNET++ feature which contains all OMNET++ specific tools

we use:- the NED, MSG and INI file editor, simulation launcher,
result analysis tools, sequence char view, documentation generator
etc.
CDT (C/C++ Development Tooling - eclipse.org/cdt) - for C++
development and debugging. This feature integrates with the
standard gcc toolchain and the gdb debugger.
Version control integration plug-ins for Git and Subversion.
To keep the size of OMNET++ distribution small, the OMNET++ IDE
does not contain the tools required for Java development. If you
would like to develop your own plugins for the IDE, you will need to
install some additional components manually:
JDT (Java Development Tools) - for generic Java development. JDT
contains a Java compiler and all the editors debuggers and tools
used during Java development.
PDE (Plug-in Development Environment) - this component
contains additional tools, API definitions and documentation for
developing plug-ins. PDE requires the presence of JDT.

9
5.1 Architecture of Omnet++:-

CMDENV
Or
Executing TKENV
ENVIR Or
Model SIM
Main()

Model
Component
Library

Fig:-1

1. Executing Model:-
An execution model specifies how work
takes place. Every programming language has an execution
model, which is specified as part of the language specification,
and is implemented as part of the language implementation.

2. SIM:-
Simulation is the imitation of the operation of a real-
world process or system over time. The act of simulating
something first requires that a model be developed; this model
represents the key characteristics, behaviors and functions of
the selected physical or abstract system or process

10
 3. TKENV:-
Tkenv is a graphical runtime interface for
simulations. Tkenv supports interactive simulation execution,
animation, inspection, tracing and debugging. In addition to
model development and verification, Tkenv is also useful for
presentation and educational purposes, since it allows the
user to get a detailed picture of the state and history of the
simulation at any point of its execution.

Features of the Omnet++:-

Simulator designed for fixed, wired, distributed systems(Such

as: computer, networks, multiporecssor systems
Discrete time simulator.
It is compatible with: DOS, UNIX, WINDOWS.
Several graphical interfaces allows easy debugging and
variables inspection
Offers support for parallel execution.

11
C++:-

C++ (pronounced cee plus plus) is a general-

purpose programming language. It has imperative, object-
oriented and generic programming features, while also providing
facilities for low-level memory manipulation.
C++ introduces object-oriented programming (OOP) features to
C. It offers classes, which provide the four features commonly
present in OOP (and some non-OOP)
languages: abstraction, encapsulation, inheritance,
and polymorphism.

JDK:-
The java development kit(JDK) is an implementation of
either one of the java platform, standard edition; java platform,
enterprise edition; java platform enterprise Edition or java
platform, Micro Edition platform released by oracle corporation in
the form of a binary product aimed at java developers on Solaris,
Linux, Mac OS X or widows.
The JDK includes a private JVM and a few
other resources to finish the development of a java Application.

12
 Privacy in Wireless sensor network

Privacy in WSN

Data Privacy
Context Privacy

Data Aggregation Data Query Location Privacy Temporal Privacy

Source Location Sink Location

Privacy Privacy

Fig:-2
Since wireless sensor network are deployed in an open
environment so the privacy is one of the major concerns in
randomly deployed sensor networks. Privacy in WSNs are basically
categorized in two parts.
i) Data privacy
ii) context privacy.
Privacy in WSNs is shown

13
in Fig. In randomly deployed sensor network there is an adversary
is present to breach the privacy of the network and trying to find
out the source of the incoming message. How do we protect the
location of a source from adversaries? We basically need to hide
the subject from the adversary. In fact, we have to hide the
location of the source that senses the subject. Hence, we aim at the
source location privacy(SLP). SLP requires more than confidentiality
of the messages exchanged between node. SLP requires that the
flow of the messages does not give away the location of a source
node. The confidentiality of a message is part of another privacy
category, called content privacy. Content privacy focuses on,
amongst others, providing integrity, non-repudiation, and
confidentiality of the messages exchanged in a WSN. SLP is part of
context privacy, which focuses on hiding the contextual
information of a WSN. Context privacy comprises, for instance,
hiding the identity and the location of

14
Related Works
The Privacy in Wireless Sensor Networks (WSNs) is mainly categorized
in two parts.

Content - based privacy and

Context -based privacy

Context-based privacy are taking care of the different type of

cryptographic techniques.

The cryptographic technique does not take care about context based
privacy and this privacy need major concern in source location privacy.
To achieve the source location privacy in WSNs various techniques is
provided by the different authors. The concept of source location
privacy (SLP) in relation to Context privacy was first described by Ozturk
based on the panda hunter game. The essence of the panda hunter
game is that the hunter can only use the traffic flow to track the panda.
Were the first to formalize the source location problem based on the
panda hunter game. Both Ozturket . and Kamatetal. Argue that it is up
to the routing strategy to hide the location of the subject, with respect
to an adversary that only traces packets through the WSN. Kamatetal.
Use two metrics to quantify the privacy delivered by the routing
algorithms. The first metric, shared by Ozturk. the safety period of a
routing protocol. The safety period is the number of messages a source
node sends out before the adversary locates the subject, given the
movement strategy of the adversary. The second metric is the capture
15
likelihood ofa routing protocol, which is the probability that the hunter
can capture the subject within a specified time period, given the
adversaries moving strategy. Jhumka. claim that the safety period ends
either when the adversary finds the subject or when the subject has
moved away from the source node. SLP is breached when an adversary
finds the subject, while it is at the source. To preserve the Source
location privacy in

WSNs various techniques are described in the sections below:

1 Random Walk.

2 Geographic Routing.

3 Delay

4 Using Dummy Data Sources.

5 Cyclic Entrapment.

6 In Network location anonymization.

7 Cross layer routing.

8 Separate path routing.

9 Network coding. etc.

16
 6. SYSTEM Analysis
SRS (Software Requirement Specification)
1. Introduction
1.1. Purpose: - The main purpose of the wsn is the One of
these applications is subject tracking and monitoring, in
which the monitored subjects often need protection .
1.2 Scope: - One of the scope of this applications is subject
tracking and monitoring, in which the monitored subjects often need
protection. For instance, a WSN can be deployed to monitor the
movement of a panda in a large park. The panda needs protection from
different adversaries. An adversary might trace the messages in the
WSNs to find the source node that sensed the panda, with the final aim
of killing the panda.
Definition and Acronyms General Description
Our objective for this project is to protect the location
privacy of the source location. In order to that we are misleading
the adversary by using some technique like fake source, phantom
routing and so on. So, in this project we are trying to evaluate the
application of fake source, phantom routing and similar techniques
in preserving the real source location.

2.1. Product Perspective: - The application mainly consists

for hide the actual information and create the fake location.

17
 2.2. Product Function: -this application will be provide:-
1 hide the information
2 create the fake location
3 Provide the security



2.2. User Characteristics:-
The has to perform the
task gently, user have to full idea for this application ,
how to handle the application, and how this application
is worked.
2.3. Constraints:-
The receiver has to be ensured that it has
received the original data with no alter. Data authentication may
also provide data integrity in some cases
3. Specific Requirement
3.1. User Interface:- The proposed system contain the
following
User interfaces:-
1. Check the movement of path.
2. Find the source of the path.
3. Provide the privacy from the source node.

18
 Working with Omnet++:Flow Chart
1. An omnet++ model is build from components(modules) which communicate by exchanging messages.
Modules can be nested, that is, several modules can be grouped together to from a compound
module.

2. Define the model structure in the NED languet. You can edit NED in a text editor or in the graphical editor
of the Eclipse-based Omnet++ simulation IDE.

3. The active components of the model (simple modules) have to be programmed in ++, using the simulation
kernel and class library.

4. Provide a suitable omnetpp.ini to hold omnet++ configuration and parameters to your model a config file
can describe several simulation runs with different parameters.

5. Build the simulation program and run it. Youll link the code with the Omnet++ simulation kernel and one of
the user interfaces omnet++ provides. There are command line(batch) and interactive, graphical user
interface.

6.Simulation results are written into output vector and output scalar files. You can use the analysis tool in the
simulation IDE to visualize them. Result file are text-base, so you can also process them with R, Matlab or
19
other tools.
Mesh Topology:-
Mesh topologies involve message can take any of
several paths from source to destination. (Recall that even in a ring,
although two paths exist, messages can only travel in one direction.) A
mesh network in which every node connects to every other is called a
full mesh and there is partial mesh networks also exist in which some
devices (nodes) connect only indirectly to others.

Sink

Sensor NOde

Fig:-3

20
 7. TESTING
Software testing is a process of executing a program or application with
the intent of finding the software bugs.

It can also be stated as the process of validating and verifying that a

software program or application or product:

Meets the business and technical requirements that guided its design
and development

Works as expected can be implemented with the same characteristic.

6.1. TESTING APPROACH

UNIT TESTING
Unit testing, also known as component testing refers to tests that verify the
functionality of a specific section of code, usually at the function level. In an
object-oriented environment, this is usually at the class level, and the minimal
unit tests include the constructors and destructors.

These types of tests are usually written by developers as they work on code
(white-box style), to ensure that the specific function is working as expected. One
function might have multiple tests, to catch corner cases or other branches in the
code. Unit testing alone cannot verify the functionality of a piece of software, but
21
rather is used to ensure that the building blocks of the software work
independently from each other.

Unit testing is a software development process that involves synchronized

application of a broad spectrum of defect prevention and detection strategies in
order to reduce software development risks, time, and costs. It is performed by
the software developer or engineer during the construction phase of the software
development lifecycle. Rather than replace traditional QA focuses, it augments it.
Unit testing aims to eliminate construction errors before code is promoted to QA;
this strategy is intended to increase the quality of the resulting software as well as
the efficiency of the overall development and QA process.

Depending on the organization's expectations for software development, unit

testing might include static code analysis, data flow analysis, metrics analysis,
peer code reviews, code coverage analysis and other software verification
practices.

INTEGRATED TESTING
Integration testing is any type of software testing that seeks to verify the
interfaces between components against a software design. Software components
may be integrated in an iterative way or all together ("big bang"). Normally the
former is considered a better practice since it allows interface issues to be located
more quickly and fixed.

Integration testing works to expose defects in the interfaces and interaction

between integrated components (modules). Progressively larger groups of tested
software components corresponding to elements of the architectural design are
integrated and tested until the software works as a system.

BLACK BOX TESTING

Black-box testing is a method of testing that examines the functionality of an
application without peering into its internal structures or workings. This method

22
of test can be applied to virtually every level of software
testing: unit, integration, system and acceptance. It typically comprises most if

not all higher level testing, but can also dominate unit testing as well.

Test procedures
Specific knowledge of the application's code/internal structure and
programming knowledge in general is not required. The tester is aware
of what the software is supposed to do but is not aware of how it does
it. For instance, the tester is aware that a particular input returns a
certain, invariable output but is not aware of how the software
produces the output in the first place.

Test cases
Test cases are built around specifications and requirements, i.e., what
the application is supposed to do. Test cases are generally derived from
external descriptions of the software, including specifications,
requirements and design parameters. Although the tests used are
primarily functional in nature, non-functional tests may also be used.
The test designer selects both valid and invalid inputs and determines
the correct output, often with the help of an oracle or a previous result
that is known to be good, without any knowledge of the test object's
internal structure.

WHITE BOX TESTING

23
White-box testing (also known as clear box testing, glass box
testing, transparent box testing, and structural testing) is a method of
testing software that tests internal structures or workings of an
application, as opposed to its functionality (i.e. black-box testing). In
white-box testing an internal perspective of the system, as well as
programming skills, are used to design test cases. The tester chooses
inputs to exercise paths through the code and determine the
appropriate outputs. This is analogous to testing nodes in a circuit,
e.g. in-circuit testing (ICT).
White-box testing can be applied at
the unit, integration and system levels of the software testing process.
Although traditional testers tended to think of white-box testing as
being done at the unit level, it is used for integration and system testing
more frequently today. It can test paths within a unit, paths between
units during integration, and between subsystems during a system
level test. Though this method of test design can uncover many errors
or problems, it has the potential to miss unimplemented parts of the
specification or missing requirements.

TESTING PROCEDURE
White-box testing's basic procedures involves the tester having a deep
level of understanding of the source code being tested. The
programmer must have a deep understanding of the application to
know what kinds of test cases to create so that every visible path is
exercised for testing. Once the source code is understood then the
source code can be analyzed for test cases to be created. These are the
three basic steps that white-box testing takes in order to create test
cases:

24
1. Input involves different types of requirements, functional
specifications, detailed designing of documents, proper source
code, security specifications. This is the preparation stage of
white-box testing to layout all of the basic information.
2. Processing involves performing risk analysis to guide whole
testing process, proper test plan, execute test cases and
communicate results. This is the phase of building test cases to
make sure they thoroughly test the application the given results
are recorded accordingly.
3. Output involves preparing final report that encompasses all of the
above preparations and results.

25
9.1. Limitations
We assume that an adversary has only local views. They only able to see a
part of the whole network.
There exist only one Source node at a time in the whole network.
There exist a single non-movable base station in the network.

5 Future scope
To maximize the life time of sensor nodes.
To provide efficient energy harvesting techniques.
To provide more secure way of data transmission.

26
 10. BIBLIOGRAPHY
www.wekepedia.com

A. JHUMKA, M. L., AND SHRESTHA, S. On the use of fake sources for source
location privacy: trade-offs between energy and privacy. vol. 54, pp. 860874.

27
28