[please note before refering the report format] i) this is

[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



7


4.3 SENDING REFERENCE MESSAGE




4.3.4 Data Structure Used 22

4.4 SENDING AUTHENTICATION TICKET




4.5 FORWARDING AUTHENTICATION TICKET




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.

[please note before refering the report format] i) this is

Documents