[Please Note before refering the Report Format]
i) This is a Sample Copy for Preparing Final Year Project.
ii) Follow the Instructions given by the respective Project Committee
Members for the content organization.
2
DISTRIBUTED AUTHENTICATION OF PROGRAM INTEGRITY VERIFICATION
IN WIRELESS SENSOR NETWORKS
A PROJECT REPORT
Submitted by
[Roll No]
[Name of the Student]
for the fulfillment of the award of the degree
of
Master of Technology
in
INFORMATION TECHNOLOGY
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
COLLEGE OF ENGINEERING,
ANNA UNIVERSITY, CHENNAI
CHENNAI-600 025.
APRIL 2009
3
CERTIFICATE
Certified that this project report titled “Distributed Authentication of Program
Integrity Verification in Wireless Sensor Networks” is the bonafide work of
who carried out the project under my supervision. Certified further, that to the best of my
knowledge the work reported herein does not form part of any other thesis or dissertations on
the basis of which a degree or award was conferred on an earlier occasion on these or any other
candidates.
4
ABSTRACT
Security in Wireless Sensor Networks has become important as sensors are usually
deployed hostile and unattended environments and hence are susceptible to various attacks,
including node capture, physical tampering, and manipulation of the sensor program a soft
tamper-proofing scheme that verifies the integrity of the program in each sensor device, called the
program integrity verification (PIV), in which sensors authenticate PIV servers (PIVSs) using
centralized and trusted third-party entities, such as authentication servers (ASs).
Requiring a centralized service such as AS is inconsistent with the distributed structure of
sensor networks. Moreover, sensors that are deployed near the AS will consume more energy to
route messages for other sensors and will exhaust their batteries before others. Therefore, having a
centralized AS will not scale well to a large sensor network.
DAPP is the distributed authentication protocol of PIVSs (DAPP) without requiring the
commonly used ASs. DAPP enables sensors to first check the authenticity of server before
communicating with them.
Implementation of DAPP shows that DAPP reduces the sensors’ communication traffic in
the network by more than 90% and the energy consumption on each sensor by up to 85%, as
compared to the case of using a centralized AS for authenticating PIVSs.
5
TABLE OF CONTENTS
CHAPTER NO TITLE PAGE NO
ABSTRACT iv
LIST OF FIGURES x
LIST OF ABBREVATIONS xi
1. INTRODUCTION
1.1 OBJECTIVE 1
1.2 SCOPE 1
1.3 METHODOLOGY 2
1.4 DEFINITIONS 2
1.5 CHALLENGES 2
1.6 OVERVIEW OF THE PROJECT 3
1.7 OVERVIEW OF THE REPORT 4
2. LITERATURE SURVEY 5
2.1 PIV PROTOCOL
2.2 AUTHENTICATION SERVERS (AS)
2.3 PIV SERVERS (PIVSS)
6
2.4 BLUNDO SCHEME
3. DESIGN
3.1 OVERALL DESIGN 9
3.1.1 System Architecture 9
3.1.2 Sensor 9
3.1.3 PIV Server 10
3.1.4 Reference PIVS. 11
3.2 DETAILED DESIGN
3.2.1 Sensor 12
3.2.2 PIV Server 12
3.2.3 Reference PIVS 14
3.3 DESIGN DIAGRAMS
4 IMPLEMENTATION
4.1 SENDING BEACON SIGNAL
4.1.1 Message Creation 17
4.1.2 Implemented Classes 17
4.1.3 Message Structure 18
4.1.4 Data Structure Used 18
4.2 SENDING AUTHENTICATION REQUEST
4.2.1 Message Creation 19
4.2.2 Implemented Classes 19
7
4.2.3 Message Structure 20
4.3 SENDING REFERENCE MESSAGE
4.3.1 Message Creation 20
4.3.2 Implemented Classes 21
4.3.3 Message Structure 21
4.3.4 Data Structure Used 22
4.4 SENDING AUTHENTICATION TICKET
4.4.1 Message Creation 22
4.4.2 Implemented Classes 23
4.4.3 Message Structure 23
4.5 FORWARDING AUTHENTICATION TICKET
4.5.1 Message Creation 23
4.5.2 Implemented Classes 24
4.5.3 Message Structure 24
5. TOOLS DESCRIPTION
5.1 INTRODUCTION 25
5.2 NED EDITOR 26
5.2.1 Graphical Mode 26
5.2.2 Text Mode 27
5.3 VIEWS 28
5.3.1 Outline View 28
5.3.2 Problem View 28
8
5.3.3 Progress View 28
5.3.4 Debug View 28
5.3.5 Console View 28
6. TEST CASES AND RESULTS 30
6.1 TEST PLATFORM 30
6.2 TEST CASE SPECIFICATION 30
6.3 TEST CASES 33
6.4 PERFORMANCE ANALYSIS 36
7. CONCLUSION AND FUTURE WORK 39
REFERENCES 40
9
LIST OF FIGURES
Figure No TITLE Page No
2.1 Architecture of PIV PROTOCOL. 6
3.1 Architecture of DAPP PROTOCOL. 10
3.2 Detailed Design of DAPP PROTOCOL 11
3.3 Activity Diagram of Sensor 12
3.4 Activity Diagram of PIVS 13
3.5 Activity Diagram of Reference PIVS 14
3.6 Sequence Diagram of DAPP PROTOCOL 15
3.7 Collaboration Diagram of DAPP 15
3.8 Activity Diagram of DAPP PROTOCOL 16
4.1 Broadcasting Beacon Message. 18
4.2 Authentication Request Message from Sensor 19
4.3 Sending PIVS Reference Message 21
4.4 Authentication Ticket from Reference PIVS 23
4.5 Forwarding Authentication Ticket 24
5.1 OMNET++ IDE 26
5.2 NED EDITOR (Graphical Mode) 27
5.3 Building Project 29
5.4 Running Project 29
10
LIST OF TABLES
TABLE NO TITLE PAGE NO
6.1 Energy Consumption in PIV Protocol 37
6.2 Energy Consumption in DAPP Protocol 38
11
LIST OF ABBREVATIONS
PIV- Program Integrity Verification
DAPP- Distributed authentication protocol of PIVSs
PIVS- PIV Server
AS-Authentication Server
RHF-Randomized Hash Function
MAC-Message Authentication Code.
CHAPTER 1
12
INTRODUCTION
1.1 OBJECTIVE
In recent years, security has become a primary concern to the communications between
mobile nodes. Unlike wired networks, security in wireless networks is difficult to achieve due to
the broadcast nature of internodes communications. In sensor and ad hoc networks, it is even
easier for attackers to circumvent the underlying intrusion detection system because a malicious
user can join the network at one point, hide inside the network for a while, and then mount
attacks.
To protect the sensors from physical attacks, including physical tampering and
manipulation of the sensor programs, we implemented a soft tamper-proofing scheme that verifies
the integrity of the program in each sensor device in a distributed manner, called the Distributed
Authentication of program integrity verification protocol (DAPP).
1.2 SCOPE OF THE PROJECT
Wireless Sensor Networks are becoming important for many emerging applications such as
Military Surveillance, earthquake, volcano emergency System. The security of sensor networks
used for such application is of utmost importance
We implemented a distributed authentication protocol of PIVSs (DAPP) for sensors to securely
communicate with PIVSs without the authentication server (AS) infrastructure assumed in PIV.
DAPP is a solution to the problem of authenticating PIVSs in a fully distributed manner and acts
as the first line of defense for the network by enabling each sensor node to prove the identity of a
server before communicating with it. The DAPP is to enable sensors to validate a PIVS before
using it for their verification.
1.3 METHODOLOGY
13
The methodology behind implementation of the DAPP is to verify the integrity of program in
sensor by one of the PIVSs in the sensor network. All the PIVS broadcast the beacon message.
The PIVS with greater signal strength is chosen for the authentication process.
1.4 DEFINITIONS
1. Beacon message – The beacon message is broadcasted by the PIVS to the sensor and the
reference PIVSs. Beacon message consists of id of the PIVS and the signal strength associated
with it.
2. Nonce – It is a randomly generated number that is unpredictable and used to achieve
freshness. It is also used to avoid outside attacks.
3. Authentication Ticket – The authentication ticket is granted by the reference PIVSs to
the PIVS that is about to authenticate the sensor. The authentication ticket ensures that PIVS is
secure and not compromised.
4. Authentication Message – After receiving beacon messages from various PIVSs,
Authentication message is sent by the sensor to the PIVS with the greater signal strength. The
authentication message consists of Nonce, MAC value and the length of the generated MAC.
5. Reference Message – Reference Message is sent by the PIVS to the reference PIVSs for
the authentication of the PIVS. If authentication succeeds then authentication ticket is granted by
the reference PIVSs to the PIVS. Reference Message consists of Nonce, MAC value and the
sensor id.
1.5 CHALLENGES
The Challenges in implementing the protocol are
a) MAC Generation and Verification
We used HMAC-SHA for MAC generation and verification in DAPP. HMAC does not
rely on encryption but instead uses a cryptographic hash function in combination with a secret
key. Carman and colleagues analyzed the impact of security algorithms on energy consumption
for sensor nodes, showing that the computation of HMAC-SHA for a 1024-bit message is
energy-cost-effective for sensor networks.
14
b) Communication Cost
The communication overhead of DAPP is associated with a PIVS’s authentication
request to its neighbor PIVSs. For a PIVS to authenticate another PIVS, two messages need to
be transmitted. First, a PIVS has to authenticate itself with N neighbor PIVSs to pass the
authentication; then the neighbors reply. Therefore, there will be 2N messages transmitted to
authenticate a PIVS. However, DAPP is used only before a sensor runs PIV and wants to
authenticate a PIVS. Because a sensor runs the PIV protocol only infrequently, the
communication overhead is not high. Also, because PIVSs have dual radio interfaces, the
communications between PIVSs do not interfere with sensor communications.
1.6 OVERVIEW OF THE PROJECT
We implement the PIV protocol in a distributed manner to protect the integrity of sensor
programs. To remove the need for a centralized AS from the PIV infrastructure, we use PIVSs to
perform the AS functions and Authenticate one another to achieve the distributed authentication
of PIVSs.
PIVSs interact with one another to be authenticated without the need for a centralized AS in the
network.
PIVSs need to share some secrets with one another to authenticate one another. Before
deployment, PIVSs and sensors are loaded with functions to establish pair wise keys. After
deployment, PIVSs and sensors can use the loaded functions to establish pair wise keys with any
node in the network. In the original PIV design, protection of a sensor from a malicious
server/code disguised as a PIVS/PIVC is achieved by using the AS that acts as a trusted third
party. The AS can help a sensor ensure that the PIVS is authentic, and the PIVC it receives from
the PIVS is thus safe to execute. Here, we propose a distributed protocol, DAPP, for sensors to
authenticate PIVSs without using such a centralized AS.
DAPP has two more objectives in addition to the distribution of the AS function to PIVSs:
Reduce (1) the total number of sensor communication messages exchanged in the network and (2)
the energy consumed by each sensor by using DAPP for authentication.
15
1.7 OVERVIEW OF THE REPORT
The outline of the report is as follows.
Chapter 2 discusses about the literature survey
Chapter 3 discusses the System Design
Chapter 4 explains the Implementation Details.
Chapter 5 provides Tools Description
Chapter 6 explains Test Cases and Results.
Chapter 7 summarizes the report and presents directions for future work.
CHAPTER 2
16
LITERATURE SURVEY
2.1 Program Integrity Verification (PIV) Protocol
In PIV protocol, the sensors rely on PIV Servers to verify the integrity of the sensor
program. The sensors authenticate PIVSs with centralized and trusted third-party entities, such as
Authentication Servers in the network.
The PIV [2] protocol verifies the integrity of the program and data stored in a sensor
device. It is purely software-based protection from physical attacks in sensor networks. This
protocol supports the tamper proofing of sensors and makes it difficult for attackers to modify the
sensor programs without changing or adding the sensor hardware.
This protocol supports the tamper proofing of sensor program and makes it difficult for
attackers to modify the sensor program without changing or adding the sensor hardware.
The PIV protocol performs three tasks:
(1) Authentication of each PIVS via the centralized AS;
(2) Transmission and execution of the PIV code [2]
(3) Program verification by the PIVC and the PIVS.
2.2 Authentication Servers (AS)
Sensors authenticate PIVSs with a conventional Authentication Server (AS) [2], to ensure
that PIVSs are authentic and safe to communicate with and the sensors can safely execute the
code received from PIVSs.
17
Figure 2.1 Architecture of PIV PROTOCOL.
2.3 Program Integrity Verification Servers (PIVSs)
The network is composed of sensors and PIV servers (PIVSs). PIVSs verify the integrity of
the sensors programs and maintain a database of the digests of the original sensor programs. The
security of sensors is accomplished by authenticating PIVSs before communicating with them, to
protect sensors from malicious or compromised PIV servers. In PIV protocol, Sensors
authenticate PIVSs with a conventional authentication server (AS), to ensure that the PIVSs are
authentic and safe to communicate with and that the sensors can safely execute the codes received
from the PIVSs.
Authentication
Server 1. Request
Authentication of
PIVS
SENSOR
2. Success/Fail
3. Request
Verification
Program Integrity
Verification Server
4. PIVC
5. Hash Value
6. Register or
Delete Sensor ID.
PIV_DB
18
CHAPTER 3
SYSTEM DESIGN
This chapter discusses the design methodology adopted to implement the DAPP. First the
overall methodology adopted is explained followed by the detailed design of the components.
DESIGN REQUIREMENTS
Hardware: A system with 512 MB RAM or above, with Intel Pentium IV processor
Tool: OMNET++ 4.0, Java 2 (Version 1.5 and above )
Operating System: Our system is platform independent.
3.1 OVERALL DESIGN
3.1.1 SYSTEM ARCHITECTURE
DAPP consists of three main Components:
Sensor.
Program Integrity Verification Server (PIVS).
Reference PIVS.
3.1.2 SENSOR
Each sensor in the network should verify their program using PIV servers which are
deployed in the same network. The security of sensors is accomplished by authenticating PIVSs
before communicating with them, to protect sensors from malicious or compromised PIV servers.
Sensors must first select a PIVS to verify its program. The selection is based on the
signal strength received from the beacon message. The server with highest signal strength is
selected for authentication.
19
Figure 3.1 Architecture of DAPP PROTOCOL.
3.1.3 PIV SERVER
PIVSs verify the integrity of the sensors’ programs and maintain a database of the
digests of the original sensor programs. Each PIVS broadcasts a beacon message to all the nodes
in the network. The beacon message consists of ID of PIVS and the signal strength.
If a PIVS is selected by the sensor to verify its program, the server should prove its
authenticity to the sensor before verifying the sensor program. Each PIVS maintains a Reference
list which consists of IDs of its neighbor PIVS.
PIVS prove its authenticity by sending a Reference Message to the neighbor servers.
PIVS will receive an Authentication Ticket from its neighbors. PIVS will then forward the
authentication ticket to the sensor to prove its authenticity.
PIVS A PI PIVS B B
SENSOR
E
1. PIVS Auth Message
2. PIVS Ref Message
3. E,Auth Ticket
4. Auth Ticket
20
3.1.4 REFERENCE PIVS
Reference PIVS will receive a PIVS Reference Message from the PIVS selected for
authentication. Reference PIVS will check the authenticity of the message received. If the
message is authentic, the Reference PIVS will generate the authentication ticket.
Reference PIVS will send the authentication ticket to PIVS which is then forwarded to
the sensor whose program is to be verified.
3.2 DETAILED DESIGN
Figure 3.2 Detailed Design of DAPP PROTOCOL
PIVS A
Sensor E
PIVS B
2.PIVS Ref
Message(E,NE,MAC(KAB,E|NE)
3. E, AuthTicket(B,MAC(KBE,NE)),
MAC(KAB,E|AuthTicket(B,MAC(KBE,NE)
1. PIVS Auth Message
(NE, MAC (KAE,NE))
4. AuthTicket
(B,MAC(KBE,NE))….,MAC(KAE,NE+1)
.
List of Reference PIVS
21
3.2.1 SENSOR
Each sensor must verify its program periodically with the server. Sensor receives
beacon message from the servers in the network. Beacon message contains ID of the server and
the signal strength. Sensor then selects the server with highest signal strength to verify the
program.
Sensor then creates an Authentication message which contains the ID of the sensor
and the MAC value of the pair wise keys and Nonce.
Figure 3.3 Activity Diagram of Sensor
3.2.2 PIV SERVER
Each PIV server broadcasts a beacon message to reference PIVS and all the sensor
nodes in the network. Each PIV server contains the program of each sensor in the network
Sensor waits for signal Receives Beacon
message from various
PIVS
Selects server with
maximum signal strength
Sends Authentication
request message to the
selected server
22
and the program’s hash value. The selected PIV server will receive an authentication
message from the sensor. The PIV server then verifies the authenticity of the received
message. If the message is authentic then the server sends a PIVS reference message to its
neighbor PIVS.
The PIVS will receive an authentication ticket from its reference PIVS. PIVS checks
the authenticity of the received message and if the message is authentic then the ticket is
forwarded to the sensor.
Figure 3.4 Activity Diagram of PIVS
Broadcasts Beacon
Message to reference
PIVS and sensor
Receives Authentication
request message
(Verifies MAC Value)
Sends reference messages
to reference PIVS
Receives authentication
ticket from reference
PIVS
(Verifies MAC Value)
Forwards authentication ticket
to sensor
23
3.2.3 REFERENCE PIVS
The purpose of Reference PIV servers is to prove the authenticity of the server selected
to verify sensor’s program. Reference PIVS will receive an PIVS Reference Message from the
selected PIV server.
Reference PIVS then checks the authentication of the message received by checking
the MAC values. If the message is authentic, then the reference PIVS generates an authentication
ticket.
The created authentication ticket is then sent to the selected PIVS. PIVS receives a
authentication ticket from the Reference PIVS.
Figure 3.5 Activity Diagram of Reference PIVS
3.3 DESIGN DIAGRAMS
Each PIV server broadcasts a beacon message to all the nodes in the network. Sensor
selects a server to verify its program. Sensor sends Authentication Request Message to the server
with maximum signal strength.
Server receives the authentication message and checks the authenticity of the message by
calculating the MAC value for the pair wise keys. If MAC value matches then Server sends
Reference messages to PIVs in the Reference List. Each Reference PIV server will check the
authenticity of the Reference message by calculating the MAC value. If message is authentic then
the authentication ticket is send to PIVS
Receives Reference
Message
Calculates MAC and
Verifies the Received
Message
Send Authentication Ticket
24
PIVS forwards Authentication ticket to sensor to prove its authenticity.
Reference PIVSSENSOR E PIVS A
. PIVS AUTH MESSAGE (NE, MAC (KAE, NE))
AuthTicket(B,MAC(KBE,NE)),..,MAC(KAE,NE+1)
E, AUTH TICKET (B, MAC (KBE, NE)),MAC(KAB,E|AUTHTICKET(B,MAC(KBE,NE)))
. PIVS REF MESSAGE (E,NE, MAC (KAB, E,NE))
Figure 3.6 Sequence Diagram Of OVERALL DAPP PROTOCOL.
Figure 3.8 Activity Diagram of OVERALL DAPP PROTOCOL
.
25
CHAPTER 4
IMPLEMENTATION
This chapter discusses the detailed implementation of DAPP protocol. The steps involved
in implementation and the classes used are explained in detail.
4.1 BROADCASTING BEACON SIGNAL
4.1.1 MESSAGE CREATION
Each PIV server must broadcast a beacon message to all the nodes in the network to share
its Identity. PIV server creates a beacon message with following attributes
ID of server
Signal strength
After creating beacon message structure create beacon message object and assign the
value for signal strength and ID. The beacon message is then broadcasted to all nodes in the
network using send ( ) function. The beacon message is broadcasted to all nodes in the network
by creating a duplicate copy of the beacon message. The duplicate copy of the message is created
using dup ( ) function.
4.1.2 IMPLEMENTED CLASSES
Class server --- invokes function for creating beacon message.
FUNCTIONS USED
beacon(" message name") -- used to create object for beacon message and name for the
message.
Send (cMessage object, type of gate, index) – used to send message to the particular server
using gate index
setSigstr (int value) – assigns the value of signal strength.
26
4.1.3 MESSAGE STRUCTURE
message beacon
{
int id;
int sigstr;
int ind;
}
4.1.4 DATA STRUCTURE USED
int refid [] -- contains IDs of reference PIVS to which beacon message will be
broadcasted.
input in [] -- contains indexes of in gate.
output out [] -- contains indexes of out gate.
Figure 4.1: Broadcasting Beacon Message.
.
27
If MAC matches, then the reference servers will creates Authentication Ticket with
following fields
Nonce
MAC
Reference Server id
The object for Authentication ticket is created and values for Nonce and MAC and
the server ID is assigned to it. The pair wise keys are generated using ID of Reference PIVS and
server. The MAC value is generated using the pair wise keys and the Nonce value. The
authentication is then sent to the server selected for authentication.
Figure 4.4: Authentication Ticket from Reference PIVS
28
Figure 4.5 Forwarding Authentication Ticket
4.5.3 MESSAGE STRUCTURE
message AuthTick
{
char Mac[200];
char Mac1[200];
int refid;
int len;
}
29
CHAPTER 5
TOOL DESCRIPTION
5.1 INTRODUCTION
The OMNeT++ 4.0 Integrated Development Environment is based on the Eclipse platform,
and extends it with new editors, views, wizards and other functionality.
OMNeT++ adds functionality for creating and configuring models (NED and ini files),
performing batch executions and analyzing the simulation results, while Eclipse provides C++
editing, and optionally other features (UML modeling, bugtracker integration, database access,
etc) via various open-source and commercial plug-ins.
5.3 VIEWS
5.3.1 OUTLINE VIEW
The Outline View shows the structure of NED files in both graphical and text editing
mode, and allows navigation as well.
5.3.2PROBLEMS VIEW
The Problems View presents errors, warnings and info messages in NED files, ini
files and other source files in a unified manner. Double-clicking on an item opens the
corresponding file and goes the error's location. The view's contents can be filtered in various
ways (current file, current project, all projects, by severity, etc).
5.3.3 PROGRESS VIEW
The Progress View reports the status of simulation execution when you have a
long- running simulation, or you are executing several runs in a batch. It is possible to cancel the
30
whole batch operation with a single click if it is necessary. Simulation runs are running in
different processes that do not block the IDE, so the user can keep working while her simulations
are running in the background.
5.3.4 DEBUG VIEW
The Debug View is another one of Eclipse's standard Views, but it is not only
useful for debugging. While the Progress View only shows currently executing processes, the
Debug View displays the ones already terminated as well, together with their exit codes.
Processes are marked with the run number and launch time for easier identification. Double-
clicking an item reveals the process' output in the Console View.
5.3.5 CONSOLE VIEW
Each running process sends its output to a separate console buffer within the Console View,
so the user can review the output after the simulation(s) have finished. One can switch between
console buffers using the Console View's menu or toolbar, or by double-clicking on a process in
the Debug View.
5.4 BUILDING THE PROJECT
Once we have created your source files and configured your project settings, you can build
your executable. Before doing this, check if the active build configuration is correctly set for your
project. Select Build Configurations | Set Active from the project context menu and choose which
configuration should be built.
Once the correct configuration is active select Build Project from the Project menu or from the
project context menu. This should start the build process. First a makefile will be created in each
source folder (according to the project properties Makemake page) and then the primary makefile
will be called to start the build process. You should switch to the console view to see the actual
progress of the build.
31
5.5 RUNNING OR DEBUGGING THE PROJECT
To run or debug the simulations open the Run menu and choose the Run/Debug
Configurations...
Figure 5.3: Building Project Figure 5.4: Running Project
32
CHAPTER 6
TEST CASES AND RESULTS
6.1 TEST ENVIRONMENT
• Front-End:
– .ned File(Network topology)
– .ini File(configuration file)
Back-End:
-- C++
• Tools:
– Omnet++ (version 4.0)
• Operating System:
– Windows XP / VISTA
6.2 TEST CASE SPECIFICATION
Test Case
1
Selecting Server to
authenticate
Use Case
flow
Main Success Scenario and Alternate Flows
Objectives
(Post conditions)
Verify that the server with maximum signal strength is selected.
Verify that the authentication message is sent to the selected server.
Preconditions Input Expected Results
Test Case
2
Generating pair wise
keys
Use Case
flow
Main Success Scenario and Alternate Flows
33
1. 2.
34
1.
6.3 TEST CASES
Test case Id: 1
Input: Signal strength of servers
Server 1: 5 Server 2: 7 Server 3: 5 Server 4: 6 Server 5: 8
Output: Server with Maximum Signal Strength is selected.(Server 5)
Result: Pass.
Output: Server with Maximum Signal Strength is not selected.(Server 3)
Result: Fail.
Test case Id: 4
Input: Vector containing the ID of Reference Servers.
REFID{2,3,4,5,6}
Output: Authentication Ticket received from all reference servers.
Result: pass.
Input: Vector containing the ID of Reference Servers.
35
REFID {2, 3, 4, 5, 6, 10} (containing Invalid ID)
Output: Authentication Ticket not received from all reference servers.
Result: Fail.
6.4 PERFORMANCE ANALYSIS
In PIV protocol, requiring a centralized service such as AS is inconsistent with the
distributed structure of sensor networks. Moreover, sensors that are deployed near the AS will
consume more energy to route messages for other sensors and will exhaust their batteries before
others. Therefore, having a centralized AS will not scale well to a large sensor network.
Implementation of DAPP shows that DAPP reduces the sensors’ communication traffic in the
network and the energy consumption on each sensor by up to 85%, as compared to the case of
using a centralized AS for authenticating PIVSs. The following charts shows the difference
between the amount of energy consumed in PIV and DAPP protocol .
6.4.1 ENERGY CONSUMPTION IN PIV PROTOCOL
Figure 6.1: Energy Level in nodes after the implementation of PIV protocol
36
Table 6.1 Energy Consumption in PIV Protocol
NODE INITIAL ENERGY LEVEL FINAL ENERGY
LEVEL
Sensor1 100 99
Server2 100 55
Server3 100 99
Server4 100 99
Server5 100 99
Server6 100 99
6.4.1 ENERGY CONSUMPTION IN DAPP PROTOCOL
Figure 6.2: Energy Level in nodes after the implementation of DAPP protocol
37
CHAPTER 7
CONCLUSION AND FUTURE WORK
7.1 Conclusion
The implementation of DAPP is to achieve the authentication of PIVSs in a distributed
manner without requiring a dedicated and trusted authentication server (AS), an important
departure from PIV.
DAPP maintains the distributed nature of sensor networks and reduces the sensor
communication traffic in the network by more than 90% and the energy consumption on each
sensor by up to 85%, compared to using a centralized trusted AS for authentication. We also show
that DAPP is robust and secure against various attacks in sensor networks.
7.2 Future Enhancements
Future Enhancement of DAPP is to implement Intrusion Detection System (IDS). IDS
for sensor networks is needed to initiate PIV on suspicious sensors after their initial admission and
is needed to detect malicious PIVSs in the network. Once the IDS identify any malicious or
malfunctioning sensors, it can collaborate with the PIV protocol to request the sensor to reverify
with the PIVS. Once a malicious PIVS is detected in the network, other PIVSs can collaborate to
revoke it.
38
REFERENCES
[1] KATHARINE CHANG and KANG G.SHIN, 2008. “Distributed Authentication of
Program Integrity Verification in Wireless Sensor Networks”. ACM Transactions on
Information and Systems Security, pp. 8-16, March 2008.
[2] PARK, T. AND SHIN, K. G., 2005. “Soft tamper-proofing via program integrity
verification in wireless sensor networks”. IEEE Transactions on Mobile Computing, pp.
297–309, 2005
[3] SESHADRI, A., PERRIG, A., VAN DOORN, L., AND KHOSLA, P. 2004. “Swatt:
Software-based attestation for embedded devices”. In Proceedings of the IEEE Symposium on
Security and Privacy, pp 45-72, 2004
[4] BAUER, K. AND LEE, H. 2005. “A distributed authentication scheme for a wireless
sensing system”. In Proceedings of the 2nd International Workshop on Networked Sensing
Systems (INSS05), pp. 33- 45, 2005.
[5] BLUNDO, C., SANTIS, A. D., HERZBERG, A., KUTTEN, S., VACCARO, U., AND
YUNG, M. 1992. “Perfectly-secure key distribution for dynamic conferences”. In Proceedings
on Advances in Cryptology (CRYPTO92), pp. 73-77, 1992.
[6] CASTELLUCCIA, C., SAXENA, N., AND YI, J. H. 2005. Self-configurable key pre-
distribution in mobile ad hoc networks. In The 4th International IFIP-TC6 Networking
Conference, pp. 41-77, 2005.