A

Resilient

Packet-Forwarding

Scheme

against

Maliciously

Packet-Dropping

Nodes

in

Sensor

Networks

This

paper

focuses

on

defending

against

compromised

nodes

dropping

of

legitimate

reports

and

investigates

the

misbehavior

of

a

maliciously

packet-dropping

node

in

sensor

networks

We

present

a

resilient

packet-forwarding

scheme

using

Neighbor

Watch

System

-LRB-

NWS

-RRB-

specifically

designed

for

hop-by-hop

reliable

delivery

in

face

of

malicious

nodes

that

drop

relaying

packets

as

well

as

faulty

nodes

that

fail

to

relay

packets

Unlike

previous

work

with

multipath

data

forwarding

our

scheme

basically

employs

single-path

data

forwarding

which

consumes

less

power

than

multipath

schemes

As

the

packet

is

forwarded

along

the

single-path

toward

the

base

station

our

scheme

however

converts

into

multipath

data

forwarding

at

the

location

where

NWS

detects

relaying

nodes

misbehavior

Simulation

experiments

show

that

with

the

help

of

NWS

our

forwarding

scheme

achieves

a

high

success

ratio

in

face

of

a

large

number

of

packet-dropping

nodes

and

effectively

adjusts

its

forwarding

style

depending

on

the

number

of

packet-dropping

nodes

en-route

to

the

base

station

C.

-LSB-

Computer-Communication

Networks

-RSB-

General-Security

and

protection

Security

Algorithm

Reliability

Wireless

sensor

networks

consist

of

hundreds

or

even

thousands

of

small

devices

each

with

sensing

processing

and

Permission

to

make

digital

or

hard

copies

of

all

or

part

of

this

work

for

personal

or

classroom

use

is

granted

without

fee

provided

that

copies

are

not

made

or

distributed

for

profit

or

commercial

advantage

and

that

copies

bear

this

notice

and

the

full

citation

on

the

first

page

To

copy

otherwise

to

republish

to

post

on

servers

or

to

redistribute

to

lists

requires

prior

specific

permission

and/or

a

fee

SASN

October

Alexandria

Virginia

USA

Copyright

ACM

communicating

capabilities

to

monitor

the

real-world

environment

They

are

envisioned

to

play

an

important

role

in

a

wide

variety

of

areas

ranging

from

critical

military-surveillance

applications

to

forest

fire

monitoring

and

the

building

security

monitoring

in

the

near

future

In

such

a

network

a

large

number

of

sensor

nodes

are

distributed

to

monitor

a

vast

field

where

the

operational

conditions

are

harsh

or

even

hostile

To

operate

in

such

environments

security

is

an

important

aspect

for

sensor

networks

and

security

mechanisms

should

be

provided

against

various

attacks

such

as

node

capture

physical

tampering

eavesdropping

denial

of

service

etc

-LSB-

-RSB-

Previous

research

efforts

against

outsider

attacks

in

key-management

schemes

-LSB-

-RSB-

and

secure

node-to-node

communication

mechanisms

-LSB-

-RSB-

in

sensor

networks

are

well-defined

Those

security

protections

however

break

down

when

even

a

single

legitimate

node

is

compromised

It

turns

out

to

be

relatively

easy

to

compromise

a

legitimate

node

-LSB-

-RSB-

which

is

to

extract

all

the

security

information

from

the

captured

node

and

to

make

malicious

code

running

for

the

attacker

's

purpose

Even

a

small

number

of

compromised

nodes

can

pose

severe

security

threats

on

the

entire

part

of

the

network

launching

several

attacks

such

as

dropping

legitimate

reports

injecting

bogus

sensing

reports

advertising

inconsistent

routing

information

eavesdropping

in-network

communication

using

exposed

keys

etc.

Such

disruption

by

the

insider

attacks

can

be

devastating

unless

proper

security

countermeasures

against

each

type

of

attacks

are

provided

In

reality

detecting

all

of

the

compromised

nodes

in

the

network

is

not

always

possible

so

we

should

pursue

graceful

degradation

-LSB-

-RSB-

with

a

small

number

of

compromised

nodes

The

fundamental

principle

for

defense

against

the

insider

attacks

is

to

restrict

the

security

impact

of

a

node

compromise

as

close

to

the

vicinity

of

the

compromised

node

as

possible

When

the

attacker

compromises

a

legitimate

node

it

may

first

try

to

replicate

the

captured

node

indefinitely

with

the

same

ID

and

spread

them

over

the

network

Against

such

attacks

a

distributed

detection

mechanism

-LRB-

based

on

emergent

properties

-LSB-

-RSB-

-RRB-

has

been

proposed

by

Parno

et

al.

-LSB-

-RSB-

In

addition

Newsome

et

al.

-LSB-

-RSB-

have

presented

the

techniques

that

prevent

the

adversary

from

arbitrarily

creating

new

IDs

for

nodes

Using

cryptographic

information

obtained

from

a

captured

node

attackers

can

establish

pairwise

keys

with

any

legitimate

nodes

in

order

to

eavesdrop

communication

where

in

the

network

Localized

key-establishment

scheme

by

Zhu

et

al.

-LSB-

-RSB-

is

a

good

solution

against

such

an

insider

attack

Since

the

scheme

does

not

allow

a

cloned

node

-LRB-

by

inside-attackers

-RRB-

to

establish

pairwise

keys

with

any

legitimate

nodes

except

the

neighbors

of

the

compromised

nodes

the

cryptographic

keys

extracted

from

the

compromised

node

are

of

no

use

for

attackers

Compromised

nodes

can

also

inject

false

sensing

reports

to

the

network

-LRB-

i.e.

report

fabrication

attacks

-LSB-

-RSB-

-RRB-

which

causes

false

alarms

at

the

base

station

or

the

aggregation

result

to

far

deviate

from

the

true

measurement

Proposed

en-route

filtering

mechanisms

-LSB-

-RSB-

that

detect

and

drop

such

false

reports

effectively

limit

the

impact

of

this

type

of

attacks

Also

proposed

secure

aggregation

protocols

-LSB-

-RSB-

have

addressed

the

problem

of

false

data

injection

and

they

ensure

that

the

aggregated

result

is

a

good

approximation

to

the

true

value

in

the

presence

of

a

small

number

of

compromised

nodes

Advertising

inconsistent

routing

information

by

compromised

nodes

can

disrupt

the

whole

network

topology

Hu

et

al.

-LSB-

-RSB-

have

proposed

SEAD

a

secure

ad-hoc

network

routing

protocol

that

uses

efficient

one-way

hash

functions

to

prevent

any

inside

attackers

from

injecting

inconsistent

route

updates

A

few

secure

routing

protocols

-LSB-

-RSB-

in

sensor

networks

have

been

proposed

to

detect

and

exclude

the

compromised

nodes

injecting

inconsistent

route

updates

Compromised

nodes

also

can

silently

drop

legitimate

reports

-LRB-

i.e.

selective

forwarding

attacks

-LSB-

-RSB-

-RRB-

instead

of

forwarding

them

to

the

next-hop

toward

the

base

station

Since

data

reports

are

delivered

over

multihop

wireless

paths

to

the

base

station

even

a

small

number

of

strategically-placed

packet-dropping

nodes

can

deteriorate

the

network

throughput

significantly

In

order

to

bypass

such

nodes

most

work

on

secure

routing

and

reliable

delivery

in

sensor

networks

relies

on

multipath

forwarding

scheme

-LSB-

-RSB-

or

interleaved-mesh

forwarding

scheme

-LSB-

-RSB-

Among

the

insider

attacks

described

above

this

paper

focuses

on

defense

against

compromised

nodes

dropping

of

legitimate

reports

and

we

present

a

resilient

packet-forwarding

scheme

using

Neighbor

Watch

System

-LRB-

NWS

-RRB-

against

maliciously

packet-dropping

nodes

in

sensor

networks

We

investigate

the

misbehavior

of

a

maliciously

packet-dropping

node

and

show

that

an

acknowledgement

-LRB-

ACK

-RRB-

that

its

packets

were

correctly

received

at

the

next-hop

node

does

not

guarantee

reliable

delivery

from

the

security

perspective

NWS

is

specifically

designed

for

hop-by-hop

reliable

delivery

in

face

of

malicious

nodes

that

drop

relaying

packets

as

well

as

faulty

nodes

that

fail

to

relay

packets

Unlike

previous

work

-LSB-

-RSB-

with

multipath

data

forwarding

our

scheme

basically

employs

single-path

data

forwarding

which

consumes

less

power

than

multipath

schemes

As

the

packet

is

forwarded

along

the

single-path

toward

the

base

station

our

scheme

however

converts

into

multipath

data

forwarding

at

the

location

where

NWS

detects

relaying

nodes

misbehavior

NWS

exploits

the

dense

deployment

of

large-scale

static

sensor

networks

and

the

broadcast

nature

of

communication

pattern

to

overhear

neighbors

communication

for

free

The

contribution

of

this

paper

is

two-fold

First

we

investigate

the

misbehavior

of

a

maliciously

packet-dropping

node

and

propose

a

resilient

packet-forwarding

scheme

which

basically

employs

single-path

data

forwarding

in

face

of

such

nodes

as

well

as

faulty

nodes

Second

our

scheme

can

work

with

any

existing

routing

protocols

Since

it

is

designed

not

for

securing

specific

protocols

but

for

universal

protocols

it

can

be

applied

to

any

existing

routing

protocols

as

a

security

complement

The

rest

of

paper

is

organized

as

follows

Background

is

given

in

Section

We

present

our

resilient

packet-forwarding

scheme

in

Section

An

evaluation

of

the

scheme

is

given

and

discussed

in

Section

We

present

conclusions

and

future

work

in

Section

Sensor

networks

typically

comprise

one

or

multiple

base

stations

and

hundreds

or

thousands

of

inexpensive

small

static

and

resource-constrained

nodes

scattered

over

a

wide

area

An

inexpensive

sensor

node

can

not

afford

tamper-resistant

packaging

We

assume

that

a

large

number

of

sensor

nodes

are

deployed

in

high

density

over

a

vast

field

such

that

the

expected

degree

of

a

node

is

high

each

sensor

has

multiple

neighbors

within

its

communication

range

Sensing

data

or

aggregated

data

are

sent

along

the

multihop

route

to

the

base

station

We

assume

that

each

sensor

node

has

a

constant

transmission

range

and

communication

links

are

bidirectional

Our

sensor

network

model

employs

a

key-establishment

scheme

that

extends

the

one

in

LEAP

-LSB-

-RSB-

where

the

impact

of

a

node

compromise

is

localized

in

the

immediate

neighborhood

of

the

compromised

node

and

our

scheme

is

based

on

it

To

evolve

from

LEAP

we

will

describe

it

briefly

in

Section

Threat

Model

The

attacks

launched

from

outsiders

hardly

cause

much

damage

to

the

network

since

the

rouge

node

which

does

not

possesses

the

legitimate

credentials

-LRB-

e.g.

the

predistributed

key

ring

from

the

key

pool

-LSB-

-RSB-

-RRB-

fails

to

participate

in

the

network

On

the

other

hand

there

may

be

multiple

attacks

from

insiders

-LRB-

e.g.

dropping

legitimate

reports

injecting

false

sensing

reports

advertising

inconsistent

route

information

and

eavesdropping

in-network

communication

using

exposed

keys

etc

-RRB-

and

the

combination

of

such

attacks

can

lead

to

disruption

of

the

whole

network

Thus

proper

security

countermeasures

-LRB-

specifically

designed

to

protect

against

each

type

of

the

attacks

-RRB-

should

be

provided

Among

them

in

this

paper

we

focus

on

defending

against

compromised

nodes

dropping

of

legitimate

reports

Other

attacks

mentioned

above

are

effectively

dealt

with

by

several

proposed

schemes

as

described

in

the

previous

section

We

consider

a

packet-dropping

node

as

not

merely

a

faulty

node

but

also

an

arbitrarily

malicious

node

Some

previous

work

-LSB-

-RSB-

on

reliable

delivery

uses

an

acknowledgement

-LRB-

ACK

-RRB-

that

its

packets

were

correctly

received

at

the

next-hop

node

in

order

to

find

out

unreliable

links

However

in

the

presence

of

maliciously

packet-dropping

nodes

simply

receiving

ACK

from

a

next-hop

node

does

not

guarantee

that

the

packet

will

be

really

forwarded

by

the

next-hop

node

For

example

node

u

forwards

a

packet

to

compromised

node

v

and

node

u

waits

for

ACK

from

node

v.

Node

v

sends

back

ACK

to

node

u

and

then

node

v

silently

drops

the

packet

This

simple

example

shows

that

receiving

ACK

is

not

enough

for

reliable

delivery

in

face

of

maliciously

packet-dropping

nodes

For

more

reliability

we

should

check

whether

the

next-hop

node

really

forwards

the

relaying

packet

to

its

proper

next-hop

node

Fortunately

due

to

the

broadcast

nature

of

communication

pattern

in

sensor

networks

we

can

overhear

neighbors

communication

for

free

-LRB-

for

now

per-link

encryption

is

ignored

-RRB-

After

forwarding

a

packet

to

next-hop

node

v

and

buffering

recently-sent

packets

by

listening

in

on

node

v

's

traffic

we

can

tell

whether

node

v

really

transmits

the

packet

Watchdog

-LSB-

-RSB-

mechanism

-LRB-

extension

to

DSR

-LSB-

-RSB-

-RRB-

implicit

ACK

in

M

RC

-LSB-

-RSB-

and

local

monitoring

in

DICAS

-LSB-

-RSB-

detect

misbehaving

nodes

in

this

way

However

this

kind

of

simple

overhearing

schemes

does

not

guarantee

reliable

delivery

either

With

arbitrarily

malicious

nodes

we

should

be

assured

that

the

node

to

which

the

next-hop

node

forwards

the

relaying

packet

is

really

a

neighbor

of

the

next-hop

node

For

example

node

u

forwards

a

packet

to

compromised

node

v

and

node

u

listens

in

on

node

v

's

traffic

to

compare

each

overheard

packet

with

the

packet

in

the

buffer

Node

v

transmits

the

relaying

packet

whose

intended

next-hop

id

marked

with

any

id

in

the

network

such

as

x

that

is

not

a

neighbor

of

v

Then

node

u

overhears

this

packet

from

node

v

and

considers

it

forwarded

correctly

despite

the

fact

that

actually

receives

the

packet

The

packet

is

eventually

dropped

without

being

detected

We

refer

to

this

attack

as

blind

letter

attack

We

consider

packet-dropping

attacks

to

be

addressed

in

this

paper

as

ones

ranging

from

the

naive

case

-LRB-

e.g.

a

faulty

node

-RRB-

to

the

most

malicious

one

-LRB-

e.g.

a

node

launching

blind

letter

attack

-RRB-

We

focus

on

developing

a

solution

to

such

attacks

Notation

We

use

the

following

notation

throughout

the

paper

u

v

are

principals

such

as

communicating

nodes

R

u

is

a

random

number

generated

by

u.

f

K

is

a

family

of

pseudo-random

function

-LSB-

-RSB-

MAC

-LRB-

K

M

M

-RRB-

denotes

the

message

authentication

code

-LRB-

MAC

-RRB-

of

message

concatenation

of

M

and

M

with

MAC

key

K.

Key-Establishment

Scheme

in

LEAP

LEAP

supports

the

establishment

of

four

types

of

keys

for

each

sensor

node

an

individual

key

shared

with

the

base

station

a

pairwise

key

shared

with

its

neighbor

a

cluster

key

shared

with

its

surrounding

neighbors

and

a

group

key

shared

by

all

the

nodes

in

the

networks

It

assumes

that

the

time

interval

T

est

for

a

newly

deployed

sensor

node

to

complete

the

neighbor

discovery

phase

-LRB-

e.g.

tens

of

seconds

-RRB-

is

smaller

than

the

time

interval

T

min

that

is

necessary

for

the

attacker

to

compromise

a

legitimate

node

-LRB-

i.e.

T

min

T

est

-RRB-

Some

existing

work

-LSB-

-RSB-

has

made

similar

assumptions

which

are

believed

to

be

reasonable

The

four

steps

for

a

newly

added

node

u

to

establish

a

pairwise

key

with

each

of

its

neighbors

are

as

follows

Key

Pre-distribution

Each

node

u

is

loaded

with

a

common

initial

key

K

I

and

derives

its

master

key

K

u

f

K

I

-LRB-

u

-RRB-

Neighbor

Discovery

Once

deployed

node

u

sets

up

a

timer

to

fire

after

time

T

min

broadcasts

its

id

and

waits

for

each

neighbor

v

's

ACK

The

ACK

from

v

is

authenticated

using

the

master

key

K

v

of

node

v

Since

node

u

knows

K

I

it

can

derive

K

v

f

K

I

-LRB-

v

-RRB-

u

u

R

u

v

u

v

M

AC

-LRB-

K

v

R

u

v

-RRB-

Pairwise

Key

Establishment

Node

u

computes

its

pairwise

key

with

v

K

uv

as

K

uv

f

K

v

-LRB-

u

-RRB-

Node

v

also

computes

K

uv

in

the

same

way

K

uv

serves

as

their

pairwise

key

Key

Erasure

When

its

timer

expires

node

u

erases

K

I

and

all

the

master

keys

of

its

neighbors

Every

node

however

keeps

its

own

master

key

in

order

to

establish

pairwise

keys

with

later-deployed

nodes

Once

erasing

K

I

a

node

will

not

be

able

to

establish

a

pairwise

key

with

any

other

nodes

that

have

also

erased

K

I

Without

K

I

a

cloned

node

-LRB-

by

an

attacker

compromising

a

legitimate

node

after

T

min

-RRB-

fails

to

establish

pairwise

keys

with

any

nodes

except

the

neighbors

of

the

compromised

node

In

such

a

way

LEAP

localizes

the

security

impact

of

a

node

compromise

In

this

section

we

present

our

resilient

packet-forwarding

scheme

using

Neighbor

Watch

System

-LRB-

NWS

-RRB-

NWS

works

with

the

information

provided

by

Neighbor

List

Verification

-LRB-

NLV

-RRB-

to

be

described

in

Section

Neighbor

Watch

System

Our

scheme

seeks

to

achieve

hop-by-hop

reliable

delivery

in

face

of

maliciously

packet-dropping

nodes

basically

employing

single-path

forwarding

To

the

best

of

our

knowledge

proposed

works

so

far

rely

on

multipath

forwarding

or

diffusion-based

forwarding

exploiting

a

large

number

of

nodes

in

order

to

deliver

a

single

packet

ACK-based

technique

is

not

a

proper

solution

at

all

as

explained

in

the

previous

section

With

NWS

we

can

check

whether

the

next-hop

node

really

forwards

the

relaying

packet

to

the

actual

neighbor

of

the

next-hop

node

The

basic

idea

of

our

scheme

is

as

follows

Neighbor

List

Verification

After

deployment

during

neighbor

discovery

phase

every

node

u

gets

to

know

of

not

only

its

immediate

neighbors

but

also

the

neighbors

respective

neighbor

lists

-LRB-

i.e.

u

's

neighbors

neighbor

lists

-RRB-

The

lists

are

verified

using

Neighbor

List

Verification

to

be

described

in

Section

Every

node

stores

its

neighbors

neighbor

lists

in

the

neighbor

table

Packet

Forwarding

to

Next-hop

If

node

u

has

a

packet

to

be

relayed

it

buffers

the

packet

and

forwards

the

packet

-LRB-

encrypted

with

cluster

key

of

node

u

so

that

neighbors

of

node

u

can

overhear

it

-RRB-

to

its

next-hop

node

v

As

in

LEAP

a

cluster

key

is

a

key

shared

by

a

node

and

all

its

neighbors

for

passive

participation

u

v

w

y

Figure

Neighbor

Watch

System

Sub-watch

nodes

w

and

y

as

well

as

primary-watch

node

u

listen

in

on

v

's

traffic

Designation

of

Watch

Nodes

Overhearing

the

packet

from

node

u

to

node

v

among

neighbors

of

node

u

the

nodes

that

are

also

neighbors

of

node

v

-LRB-

in

Figure

nodes

w

and

y

-RRB-

are

designated

as

sub-watch

nodes

and

store

the

packet

in

the

buffer

Other

nodes

-LRB-

that

are

not

neighbors

of

node

v

-RRB-

discard

the

packet

Node

u

itself

is

a

primary-watch

node

A

primary-watch

node

knows

which

nodes

are

sub-watch

nodes

since

every

node

has

the

knowledge

of

not

only

its

neighbors

but

also

their

respective

neighbor

lists

Neighbor

Watch

by

Sub-Watch

Node

Sub-watch

nodes

w

and

y

listen

in

on

node

v

's

traffic

to

compare

each

overheard

packet

with

the

packet

in

the

buffer

To

defend

against

blind

letter

attack

each

of

them

also

checks

whether

the

packet

's

intended

next-hop

is

a

verified

neighbor

of

node

v

by

looking

up

the

neighbor

table

If

all

correct

the

packet

in

the

buffer

is

removed

and

the

role

of

the

sub-watch

node

is

over

If

the

packet

has

remained

in

the

buffer

for

longer

than

a

certain

timeout

sub-watch

nodes

w

and

y

forward

the

packet

-LRB-

encrypted

with

their

respective

cluster

keys

-RRB-

to

their

respective

next-hop

nodes

other

than

node

v

Then

the

role

of

a

sub-watch

node

is

over

-LRB-

each

of

them

is

now

designated

as

a

primary-watch

node

for

the

packet

it

has

forwarded

-RRB-

Neighbor

Watch

by

Primary-Watch

Node

Primary-watch

node

u

does

the

same

job

as

sub-watch

nodes

The

only

difference

however

is

that

it

listens

in

on

not

only

node

v

's

traffic

but

also

sub-watch

nodes

w

's

and

y

's

If

the

packet

is

correctly

forwarded

on

by

at

least

one

of

them

-LRB-

nodes

v

w

or

y

-RRB-

primary-watch

node

u

removes

the

packet

in

the

buffer

and

the

role

of

the

primary-watch

node

is

over

Otherwise

after

a

certain

timeout

primary-watch

node

u

forwards

the

packet

-LRB-

encrypted

with

its

cluster

key

-RRB-

to

its

next-hop

other

than

node

v

As

the

packet

is

forwarded

on

this

procedure

-LRB-

except

for

Neighbor

List

Verification

-RRB-

of

NWS

is

performed

at

each

hop

so

that

hop-by-hop

reliable

delivery

can

be

achieved

with

mainly

depending

on

single-path

forwarding

On

the

other

hand

in

the

previous

approaches

-LSB-

-RSB-

when

forwarding

a

packet

a

node

broadcasts

the

packet

with

no

designated

next-hop

and

all

neighbors

with

smaller

costs

The

cost

at

a

node

is

the

minimum

energy

overhead

to

Base

Station

u

v

Figure

An

example

of

our

packet-forwarding

scheme

Only

the

nodes

that

relay

the

packet

are

presented

With

the

help

of

sub-watch

nodes

-LRB-

grey

ones

-RRB-

our

scheme

bypasses

two

packet-dropping

nodes

en-route

to

the

base

station

or

within

a

specific

geographic

region

continue

forwarding

the

packet

anyway

For

example

in

Figure

if

nodes

v

w

and

y

have

smaller

costs

than

node

u

in

the

previous

approaches

they

all

forward

the

packet

from

node

u

In

our

scheme

however

sub-watch

nodes

w

and

y

are

just

on

watch

in

designated

next-hop

node

v

instead

of

uncondi-tionally

forwarding

the

packet

If

no

packet-dropping

occurs

en-route

to

the

base

station

the

packet

may

be

forwarded

along

single-path

all

the

way

through

However

a

packet-dropping

triggers

the

multipath

forwarding

for

the

dropped

packet

If

the

designated

next-hop

node

v

in

Figure

has

not

forwarded

the

relaying

packet

to

its

certified

neighbor

by

a

certain

timeout

sub-watch

nodes

w

and

y

forward

the

packet

to

their

respective

next-hop

At

the

point

the

packet

is

sent

over

multiple

paths

Since

the

location

where

the

packet-dropping

occurs

is

likely

in

an

unreliable

region

this

prompt

reaction

of

the

conversion

to

multipath

forwarding

augments

the

robustness

in

our

scheme

The

degree

of

multipath

depends

on

the

number

of

the

sub-watch

nodes

Figure

shows

an

example

of

our

packet-forwarding

scheme

bypassing

two

packet-dropping

nodes

en-route

to

the

base

station

If

a

node

utilizes

a

cache

-LSB-

-RSB-

for

recently-received

packets

it

can

suppress

the

same

copy

of

previously-received

one

within

a

certain

timeout

as

nodes

u

and

v

in

Figure

Our

scheme

requires

that

a

relaying

packet

should

be

encrypted

with

a

cluster

key

of

a

forwarding

node

in

order

that

all

its

neighbors

can

decrypt

and

overhear

it

In

fact

per-link

encryption

provides

better

robustness

to

a

node

compromise

since

a

compromised

node

can

decrypt

only

the

packets

addressed

to

it

Thus

there

exists

a

tradeoff

between

resiliency

against

packet-dropping

and

robustness

to

a

node

compromise

However

encryption

with

a

cluster

key

provides

an

intermediate

level

of

robustness

to

a

node

compromise

-LSB-

-RSB-

-LRB-

a

compromised

node

can

overhear

only

its

immediate

neighborhood

-RRB-

and

also

supports

local

broadcast

-LRB-

i.e.

resiliency

against

packet-dropping

-RRB-

so

that

we

can

achieve

graceful

degradation

in

face

of

compromised

nodes

forward

a

packet

from

this

node

to

the

base

station

It

is

the

broadcast

transmission

with

no

designated

next-hop

and

if

needed

the

packet

should

be

encrypted

with

a

cluster

key

in

order

for

all

neighbors

to

overhear

it

To

make

our

scheme

work

-LRB-

against

blind

letter

attack

-RRB-

we

must

address

the

problem

of

how

a

node

proves

that

it

really

has

the

claimed

neighbors

It

is

the

identical

problem

of

how

a

node

verifies

the

existence

of

its

neighbors

neighbors

Apparently

a

node

has

the

knowledge

of

its

direct

neighbors

by

neighbor

discovery

and

pairwise

key

establishment

phases

However

in

the

case

of

two-hop

away

neighbors

as

in

Figure

malicious

node

v

can

inform

its

neighbor

u

that

it

also

has

neighbor

node

x

-LRB-

any

possible

id

in

the

network

-RRB-

which

in

fact

is

not

a

neighbor

of

node

v.

Node

u

has

to

believe

it

since

node

x

is

not

a

direct

neighbor

of

node

u

and

only

the

node

v

itself

knows

its

actual

surrounding

neighbors

Then

how

do

we

verify

the

neighbors

neighbors

The

answer

to

this

critical

question

is

described

in

the

next

subsection

Neighbor

List

Verification

To

verify

neighbors

neighbors

we

present

Neighbor

List

Verification

-LRB-

NLV

-RRB-

which

extends

the

pairwise

key

establishment

in

LEAP

During

neighbor

discovery

in

LEAP

two

messages

are

exchanged

between

neighbors

to

identify

each

other

On

the

other

hand

NLV

adopts

three-way

handshaking

neighbor

discovery

in

order

to

identify

not

only

communicating

parties

but

also

their

respective

neighbors

NLV

has

two

cases

of

neighbor

discovery

One

is

that

neighbor

discovery

between

two

nodes

that

are

both

still

within

the

initial

T

-LRB-

referred

as

pure

nodes

-RRB-

The

other

is

that

neighbor

discovery

between

a

newly-deployed

node

within

the

initial

T

min

and

an

existing

node

over

the

initial

T

min

-LRB-

referred

as

an

adult

node

-RRB-

Neighbor

Discovery

between

Pure

Nodes

Neighbor

list

verification

process

between

pure

nodes

is

quite

simple

If

a

pure

node

broadcasts

its

neighbor

list

before

the

elapse

of

its

initial

T

min

we

can

accept

the

list

as

verifiable

Thus

the

key

point

here

is

to

keep

track

of

each

other

's

T

min

and

to

make

sure

that

both

broadcast

their

respective

neighbor

lists

before

their

respective

T

min

The

following

shows

the

three-way

handshaking

neighbor

discovery

between

pure

node

u

and

v

u

u

R

u

v

u

v

T

v

R

v

M

v

M

AC

-LRB-

K

v

R

u

K

u

M

v

-RRB-

u

v

u

T

u

M

u

M

AC

-LRB-

K

uv

R

v

M

u

-RRB-

where

T

v

and

T

u

are

the

amount

of

time

remaining

until

T

min

of

v

and

T

min

of

u

respectively

Once

deployed

node

u

sets

up

a

timer

to

fire

after

time

T

min

Then

it

broadcasts

its

id

and

waits

for

each

neighbor

v

's

ACK

The

ACK

from

every

neighbor

v

is

authenticated

using

the

master

key

K

v

of

node

v

Since

node

u

knows

K

I

it

can

derive

K

v

f

K

I

-LRB-

v

-RRB-

The

ACK

from

node

v

contains

T

v

the

amount

of

time

remaining

until

T

min

of

node

v

If

T

v

is

a

non-zero

value

node

v

claims

to

be

a

pure

node

K

u

in

MAC

proves

node

v

to

be

a

pure

node

since

pure

node

v

should

know

K

I

and

derive

K

u

f

K

I

-LRB-

u

-RRB-

Node

u

records

T

v

-LRB-

T

v

added

T

min

is

the

time

interval

necessary

for

the

attacker

to

compromise

a

legitimate

node

as

in

LEAP

-LSB-

-RSB-

Each

node

u

is

loaded

with

a

common

initial

key

K

I

and

derives

its

master

key

K

u

f

K

I

-LRB-

u

-RRB-

After

time

T

min

node

u

erases

K

I

and

all

the

master

keys

of

its

neighbors

u

v

w

x

t

z

r

q

Figure

Neighbor

Discovery

between

Pure

node

x

and

Adult

node

u.

Grey

and

white

nodes

represent

adult

and

pure

nodes

respectively

to

the

current

time

of

node

u

-RRB-

in

the

entry

for

node

v

in

the

neighbor

table

Node

u

computes

its

pairwise

key

with

v

K

uv

f

K

v

-LRB-

u

-RRB-

Node

u

also

generates

M

AC

-LRB-

K

v

v

u

-RRB-

-LRB-

which

means

that

v

certifies

u

as

an

immediate

neighbor

-RRB-

and

stores

it

as

a

certificate

The

ACK

from

node

u

also

contains

T

u

the

amount

of

time

remaining

until

T

min

of

u

This

ACK

is

authenticated

using

their

pairwise

key

K

uv

which

proves

node

u

a

pure

node

and

u

's

identity

Node

v

then

records

T

u

-LRB-

T

u

added

to

the

current

time

of

v

-RRB-

in

the

entry

for

u

in

the

neighbor

table

It

also

generates

M

AC

-LRB-

K

u

u

v

-RRB-

and

stores

it

as

a

certificate

Then

the

three-way

handshaking

is

done

Every

pure

node

u

broadcasts

its

neighbor

list

just

prior

to

T

min

of

u.

Each

receiving

neighbor

v

checks

whether

the

receiving

time

at

v

is

prior

to

T

u

in

the

neighbor

table

If

yes

the

neighbor

list

of

u

is

now

certified

by

each

neighbor

v.

Neighbor

Discovery

between

A

Pure

Node

and

An

Adult

node

After

most

nodes

have

completed

bootstrapping

phase

new

nodes

can

be

added

in

the

network

Consider

Figure

The

issue

here

is

how

adult

node

u

can

assure

its

existing

neighbors

-LRB-

v

and

w

-RRB-

of

the

existence

of

its

newly-added

neighbor

x

This

is

a

different

situation

from

the

above

neighbor

list

verification

case

between

two

pure

nodes

Thus

the

messages

exchanged

during

the

three-way

handshaking

are

somewhat

different

in

this

case

The

following

shows

the

three-way

handshaking

neighbor

discovery

between

pure

node

x

and

adult

node

u

x

x

R

x

u

x

u

T

u

R

u

v

certif

icate

M

AC

-LRB-

K

v

v

u

-RRB-

w

certif

icate

M

AC

-LRB-

K

w

w

u

-RRB-

M

u

M

AC

-LRB-

K

u

R

x

M

u

-RRB-

x

u

x

T

x

certif

icate

M

AC

-LRB-

K

x

x

u

-RRB-

v

one-time

cert

M

AC

-LRB-

K

v

x

u

-RRB-

w

one-time

cert

M

AC

-LRB-

K

w

x

u

-RRB-

M

x

M

AC

-LRB-

K

xu

R

u

M

x

-RRB-

Newly-added

node

x

sets

up

a

timer

to

fire

after

time

T

min

Then

it

broadcasts

its

id

and

waits

for

each

neighbor

u

's

Node

v

also

computes

K

uv

in

the

same

way

K

uv

serves

as

their

pairwise

key

ACK

The

ACK

from

every

neighbor

u

is

authenticated

using

the

master

key

K

u

of

node

u

Since

node

x

knows

K

I

it

can

derive

K

u

f

K

I

-LRB-

u

-RRB-

The

ACK

from

node

u

contains

T

u

the

amount

of

time

remaining

until

T

min

of

u

If

T

u

is

zero

node

u

is

an

adult

node

that

may

already

have

multiple

neighbors

as

in

Figure

Node

u

reports

its

certified

neighbor

list

-LRB-

v

and

w

-RRB-

to

x

by

including

their

respective

certificates

in

the

ACK

Node

x

verifies

u

's

neighbor

list

by

examining

each

certificate

since

x

can

generate

any

certificate

with

K

I

If

all

correct

x

computes

its

pairwise

key

with

u

K

xu

f

K

u

-LRB-

x

-RRB-

Node

x

also

generates

M

AC

-LRB-

K

u

u

x

-RRB-

and

stores

it

as

a

certificate

The

ACK

from

x

also

contains

T

x

the

amount

of

time

remaining

until

T

min

of

x

This

ACK

is

authenticated

using

their

pairwise

key

K

xu

which

proves

node

x

a

pure

node

and

x

's

identity

Node

u

then

records

T

x

-LRB-

T

x

added

to

the

current

time

of

u

-RRB-

in

the

entry

for

x

in

the

neighbor

table

Since

adult

node

u

can

not

generate

M

AC

-LRB-

K

x

x

u

-RRB-

by

itself

pure

node

x

provides

the

certificate

for

u

in

the

ACK

Node

x

also

provides

one-time

certificates

for

each

of

u

's

certified

neighbors

-LRB-

v

and

w

-RRB-

Then

the

three-way

handshaking

is

done

After

that

adult

node

u

broadcasts

one-time

certificates

-LRB-

from

newly-discovered

pure

node

x

-RRB-

in

order

to

assure

u

's

existing

neighbors

-LRB-

v

and

w

-RRB-

of

the

discovery

of

new

neighbor

x

The

packet

containing

one-time

certificates

is

as

follows

u

u

x

v

one-time

cert

M

AC

-LRB-

K

v

x

u

-RRB-

w

one-time

cert

M

AC

-LRB-

K

w

x

u

-RRB-

K

A

u

M

u

M

AC

-LRB-

K

c

u

M

u

-RRB-

where

x

is

a

new

neighbor

of

u

K

A

u

is

a

local

broadcast

authentication

key

in

u

's

one-way

key

chain

K

c

u

is

the

cluster

key

of

u.

Each

receiving

neighbor

v

of

u

verifies

u

's

new

neighbor

x

by

examining

the

one-time

certificate

designated

for

v

M

AC

-LRB-

K

v

x

u

-RRB-

If

ok

node

x

is

now

certified

by

each

neighbor

v

of

u.

Then

one-time

certificates

can

be

erased

since

they

are

of

no

use

any

more

Broadcast

authentication

only

with

symmetric

keys

such

as

cluster

key

K

c

u

fails

to

prevent

an

impersonation

attack

since

every

neighbor

of

u

shares

the

cluster

key

of

u.

Thus

we

employ

the

reverse

disclosure

of

one-way

key

chain

K

A

u

as

in

LEAP

Just

prior

to

T

min

of

x

pure

node

x

broadcasts

its

neighbor

list

Each

receiving

neighbor

u

of

x

checks

whether

the

receiving

time

at

u

is

prior

to

T

x

in

the

neighbor

table

If

yes

the

neighbor

list

of

x

is

now

certified

by

each

neighbor

u

In

summary

through

the

proposed

three-way

handshaking

neighbor

discovery

process

pure

node

u

identifies

each

immediate

neighbor

v

and

v

's

certified

neighbor

list

-LRB-

if

v

is

an

adult

node

-RRB-

and

keeps

track

of

T

min

of

v.

Just

prior

to

T

min

of

u

node

u

broadcasts

its

direct

neighbor

list

so

that

every

neighbor

of

u

accepts

the

list

as

verifiable

Then

node

u

becomes

an

adult

node

After

that

if

newly-added

node

x

initiates

neighbor

discovery

with

adult

node

u

node

u

identifies

pure

node

x

keeps

track

of

T

min

of

x

provides

u

's

certified

neighbor

list

to

x

and

in

return

takes

one-time

certificates

from

x.

Node

u

then

broadcasts

these

one-time

One-time

certificate

for

instance

M

AC

-LRB-

K

v

x

u

-RRB-

assures

v

that

x

is

an

immediate

neighbor

of

u

It

is

generated

by

pure

node

x

with

master

key

of

v.

Table

An

example

of

the

Neighbor

Table

of

u.

Neighbor

ID

Certificate

Verified

Neighbor

List

v

M

AC

-LRB-

K

v

v

u

-RRB-

u

w

t

w

M

AC

-LRB-

K

w

w

u

-RRB-

u

v

z

x

M

AC

-LRB-

K

x

x

u

-RRB-

u

r

q

certificates

in

order

to

assure

u

's

existing

neighbors

of

the

discovery

of

new

neighbor

x.

Thus

every

time

adult

node

u

discovers

newly-added

node

x

through

three-way

handshaking

node

u

informs

-LRB-

by

broadcasting

-RRB-

its

existing

neighbors

of

the

discovery

of

new

neighbor

x.

Also

whenever

receiving

neighbor

list

information

from

pure

neighbor

x

node

u

checks

whether

the

receiving

time

at

u

is

prior

to

T

x

in

the

neighbor

table

If

yes

u

now

accepts

the

neighbor

list

of

x

as

verifiable

Through

the

above

neighbor

list

verification

in

the

bootstrapping

phase

every

node

gets

the

knowledge

of

its

neighbors

certified

neighbors

Our

Neighbor

Watch

System

makes

use

of

this

information

to

prevent

blind

letter

attack

With

this

knowledge

watch

nodes

are

able

to

check

whether

the

relaying

packet

's

intended

next-hop

is

a

verified

neighbor

of

the

forwarding

node

Neighbor

Table

Maintenance

The

information

obtained

through

neighbor

list

verification

-LRB-

e.g.

its

direct

neighbors

corresponding

certificates

neighbors

neighbor

lists

etc

-RRB-

is

stored

in

the

neighbor

table

of

each

node

Table

shows

an

example

of

the

neighbor

table

of

node

u

In

densely-deployed

sensor

networks

the

expected

degree

of

a

node

is

high

However

in

this

example

for

simplicity

node

u

has

only

three

neighbors

v

w

and

x

as

in

Figure

The

entries

in

the

neighbor

table

are

accessed

and

maintained

with

immediate

neighbor

IDs

For

example

if

node

u

overhears

the

packet

sent

from

w

to

v

node

u

begins

to

listen

in

on

v

's

traffic

as

a

sub-watch

node

-LRB-

since

the

neighbor

table

of

u

has

both

v

's

and

w

's

entries

in

it

-RRB-

Unless

v

forwards

the

packet

to

a

node

of

the

Verified

Neighbor

List

in

v

's

entry

by

a

certain

timeout

sub-watch

node

u

will

forward

the

packet

to

its

next-hop

other

than

v

many

existing

routing

protocols

-LSB-

-RSB-

enable

each

node

to

maintain

multiple

potential

next-hop

Once

forwarding

the

packet

sub-watch

node

u

becomes

a

primary-watch

node

and

begins

to

listen

in

on

its

next-hop

's

traffic

as

described

above

If

newly-added

node

y

initiates

the

three-way

handshaking

with

u

node

u

provides

its

neighbor

list

to

y

by

sending

certificates

in

the

neighbor

table

Node

u

in

return

from

node

y

takes

the

certificate

for

y

and

one-time

certificates

for

u

's

existing

neighbors

Then

node

u

stores

the

certificate

in

the

new

entry

for

y.

However

node

u

does

not

store

the

one-time

certificates

but

broadcasts

them

to

its

neighbors

If

new

neighbor

y

broadcasts

its

neighbor

list

within

T

min

node

u

stores

the

list

in

the

entry

for

y

If

node

u

is

compromised

not

only

cryptographic

key

information

but

also

certificates

in

the

neighbor

table

are

exposed

However

the

attacker

can

not

misuse

these

certificates

for

other

purposes

Since

a

certificate

only

attests

neighborship

between

two

specific

nodes

it

can

not

be

applied

to

any

other

nodes

In

fact

it

can

be

made

even

public

However

colluding

nodes

can

deceive

a

pure

node

anyway

by

fabricating

a

bogus

certificate

We

will

describe

this

limitation

in

Section

In

this

section

we

evaluate

the

communication

and

storage

cost

and

analyze

the

security

of

our

resilient

forwarding

scheme

-LRB-

Neighbor

Watch

System

-RRB-

as

well

as

Neighbor

List

Verification

We

then

present

the

simulation

results

of

our

forwarding

scheme

Communication

Cost

Unlike

the

previously

proposed

diffusion-based

reliable-forwarding

schemes

-LSB-

-RSB-

that

exploit

a

large

number

of

nodes

to

deliver

a

single

packet

our

scheme

requires

only

the

designated

next-hop

node

to

relay

the

packet

under

the

supervision

of

watch

nodes

We

note

that

like

overhearing

by

watch

nodes

in

our

scheme

those

diffusion-based

schemes

require

each

node

to

listen

to

all

its

neighbors

since

they

forward

a

packet

by

broadcasting

with

no

designated

next-hop

With

a

smaller

number

of

relaying

nodes

our

scheme

makes

a

report

successfully

reach

the

base

station

Thus

the

average

communication

cost

of

our

forwarding

scheme

for

delivery

of

a

single

packet

is

smaller

than

those

of

the

previous

schemes

Our

neighbor

list

verification

during

the

bootstrapping

phase

requires

the

three-way

handshaking

neighbor

discovery

Unlike

the

neighbor

discovery

between

two

pure

nodes

the

size

of

the

messages

exchanged

between

a

pure

and

an

adult

node

varies

with

the

degree

of

the

adult

node

A

large

number

of

certificates

caused

by

the

high

degree

can

be

overburdensome

to

a

single

TinyOS

packet

which

provides

bytes

for

data

Considering

certificates

and

a

message

authentication

code

-LRB-

MAC

-RRB-

the

adult

node

is

able

to

include

at

most

two

neighbors

information

in

a

single

TinyOS

packet

Thus

when

the

entire

neighbor

list

can

not

be

accommodated

within

a

single

packet

the

node

should

allot

the

list

to

several

packets

and

send

them

serially

In

a

network

of

size

N

with

the

expected

degree

d

of

each

node

the

average

number

of

packets

invoked

by

a

newly-added

node

per

each

node

is

nearly

-LRB-

d

-RRB-

-LRB-

N

-RRB-

Therefore

as

node

density

d

grows

the

total

number

of

packets

transmitted

from

adult

nodes

to

a

newly-added

node

increases

However

neighbor

discovery

between

a

pure

and

an

adult

node

occurs

much

less

than

between

two

pure

nodes

since

most

neighbor

discoveries

throughout

the

network

are

between

two

pure

nodes

in

the

early

stage

of

the

network

Neighbor

discovery

between

a

pure

and

an

adult

node

occurs

generally

when

a

new

node

is

added

to

the

network

Storage

Overhead

In

LEAP

each

node

keeps

four

types

of

keys

and

a

manageable

length

of

hash

chain

which

is

found

to

be

scalable

In

our

scheme

each

node

needs

to

additionally

store

its

direct

neighbors

certificates

and

their

respective

neighbor

lists

as

in

Table

Thus

for

a

network

of

the

expected

degree

d

and

the

byte

size

l

of

node

ID

the

additional

storage

requirement

for

each

node

is

d

-LRB-

ld

-RRB-

bytes

Although

our

storage

requirement

for

these

neighbor

lists

is

O

-LRB-

d

-RRB-

for

a

reasonable

degree

d

memory

overhead

does

MAC

is

found

to

be

not

detrimental

in

sensor

networks

as

in

TinySec

-LSB-

-RSB-

which

employs

MAC

u

v

u

v

C

C

Figure

Examples

of

critical

area

C

and

C

not

exceed

KB

-LRB-

a

Berkeley

Mote

with

KB

flash

memory

and

KB

SRAM

-RRB-

For

example

when

d

and

l

a

node

needs

bytes

of

memory

to

store

such

information

If

node

density

of

a

network

is

so

high

that

the

required

space

for

those

neighbor

lists

significantly

increases

and

the

storage

utilization

becomes

an

issue

we

can

employ

a

storage-reduction

technique

such

as

Bloom

filter

-LSB-

-RSB-

For

example

when

d

and

l

a

node

requires

bytes

of

additional

space

mainly

for

the

neighbor

lists

Instead

of

storing

neighbors

neighbor

lists

applying

each

of

the

neighbor

lists

-LRB-

bits

-RRB-

to

a

Bloom

filter

-LRB-

of

hash

functions

mapping

to

a

bit

vector

-RRB-

a

node

needs

the

reduced

space

of

bytes

for

such

information

-LRB-

with

the

false

positive

probability

-RRB-

Resilience

to

Packet-Dropping

Attacks

In

face

of

maliciously

packet-dropping

nodes

the

higher

degree

of

multipath

we

provide

the

more

resiliency

our

scheme

achieves

against

such

attacks

The

average

degree

of

multipath

depends

on

the

number

of

sub-watch

nodes

around

a

packet-dropping

node

Sub-watch

nodes

should

be

located

in

the

region

within

the

communication

range

of

both

forwarding

node

u

and

designated

next-hop

v

We

refer

to

such

a

region

as

critical

area

As

in

Figure

if

nodes

u

and

v

are

located

farther

away

the

size

of

critical

area

C

gets

smaller

than

that

of

C

and

the

probability

-LRB-

p

c

-RRB-

that

at

least

one

sub-watch

node

exists

in

the

critical

area

goes

down

The

probability

-LRB-

p

c

-RRB-

is

p

c

-LRB-

c

-RRB-

where

c

is

the

ratio

of

the

critical

area

size

to

the

node

's

communication

range

and

the

expected

degree

d

of

the

node

To

determine

the

appropriate

degree

d

we

set

the

smallest

critical

area

C

in

Figure

as

a

lower

bound

case

-LRB-

c

-RRB-

Figure

shows

that

even

in

the

lower

bound

critical

area

with

d

and

d

probability

p

c

is

above

and

above

respectively

Since

in

a

network

of

degree

d

the

probability

that

there

exist

m

sub-watch

nodes

in

the

critical

area

of

the

ratio

c

is

p

-LRB-

m

-RRB-

d

m

c

m

-LRB-

c

-RRB-

the

expected

number

of

sub-watch

nodes

m

in

the

critical

area

is

given

by

E

-LSB-

m

-RSB-

-LRB-

d

-RRB-

c.

Thus

in

the

lower

bound

-LRB-

c

-RRB-

critical

area

when

d

the

number

of

sub-watch

nodes

-LRB-

i.e.

the

degree

of

multipath

-RRB-

is

on

average

respectively

This

Degree

of

a

node

P

r

ob

ab

i

l

i

t

y

p

c

Figure

Probability

-LRB-

p

c

-RRB-

that

at

least

one

sub-watch

node

exists

in

the

lower

bound

-LRB-

c

-RRB-

critical

area

shows

that

the

higher

degree

of

each

node

has

our

scheme

has

the

higher

degree

of

multipath

and

resiliency

against

packet-dropping

nodes

The

Security

of

Neighbor

List

Verification

Our

Neighbor

List

Verification

-LRB-

NLV

-RRB-

keeps

the

nice

properties

of

LEAP

Adult

nodes

fail

to

establish

pairwise

keys

with

any

adult

nodes

in

arbitrary

locations

so

that

the

impact

of

a

node

compromise

is

localized

NLV

performs

the

three-way

handshaking

neighbor

discovery

instead

of

two-message

exchange

in

LEAP

The

three-way

handshaking

enables

each

node

to

verify

not

only

its

direct

neighbors

but

also

their

respective

neighbor

lists

Moreover

this

this

three-way

handshaking

can

be

a

potential

solution

to

deal

with

irregularity

of

radio

range

-LSB-

-RSB-

In

reality

due

to

the

noise

and

some

environmen-tal

factors

radio

range

of

each

node

is

not

exactly

circular

So

communication

links

among

nodes

are

asymmetric

node

u

can

hear

node

v

which

is

unable

to

hear

u.

With

two-message

exchange

only

the

node

initiating

the

neighbor

discovery

is

assured

of

the

link

's

bidirectionality

By

the

three-way

handshaking

both

of

neighbors

can

be

assured

of

their

symmetric

connectivity

With

NLV

only

the

verified

lists

are

stored

and

utilized

for

our

packet-forwarding

scheme

NLV

verifies

the

neighbor

list

of

an

adult

node

with

certificates

These

certificates

merely

attest

neighborship

between

two

specific

nodes

Even

if

a

node

is

compromised

the

attacker

fails

to

abuse

the

certificates

of

the

captured

node

for

other

purpose

However

collusion

among

compromised

nodes

can

fabricate

bogus

certificates

in

order

to

deceive

a

newly-added

node

For

example

consider

two

colluding

nodes

u

and

v

at

the

different

locations

When

compromised

node

u

discovers

newly-added

node

x

node

u

provides

x

with

u

's

neighbor

list

-LRB-

maliciously

including

v

in

it

-RRB-

Even

though

node

v

is

not

an

actual

neighbor

of

u

colluding

node

v

can

generate

the

bogus

certificate

for

u

M

AC

-LRB-

K

v

v

u

-RRB-

Then

x

falsely

believes

that

v

is

a

direct

neighbor

of

u

This

attack

however

affects

only

the

one

newly-added

node

x.

Thus

when

compromised

node

u

tries

to

launch

the

blind

letter

attack

Compromised

node

u

transmits

the

relaying

packet

with

its

other

surrounding

adult

neighbors

of

u

can

still

detect

it

anyway

The

more

serious

case

is

that

colluding

nodes

exploit

a

newly-added

node

to

generate

bogus

one-time

certificates

For

example

consider

two

colluding

nodes

u

and

v

that

share

all

their

secret

information

as

well

as

all

their

certificates

When

newly-added

node

x

initiates

the

three-way

handshaking

with

u

compromised

node

u

pretends

to

be

v

and

provides

x

with

v

neighbor

list

Then

x

in

return

provides

u

with

one-time

certificates

for

each

neighbor

of

v

these

one-time

certificates

falsely

attest

that

v

has

new

neighbor

x.

Node

u

sends

this

information

to

v

over

the

covert

channel

Then

v

broadcasts

these

one-time

certificates

and

neighbors

of

v

falsely

believe

that

x

is

a

direct

neighbor

of

v.

Unfortunately

we

do

not

provide

a

proper

countermeasure

to

defend

against

this

type

of

man-in-the-middle

attacks

However

we

point

out

that

this

type

of

attacks

has

to

be

launched

in

the

passive

manner

The

adversary

has

to

get

the

chance

of

discovery

of

a

newly-added

node

In

other

words

compromised

nodes

wait

for

the

initiation

of

the

three-way

handshaking

from

a

newly-added

node

Since

the

attacker

does

not

know

where

the

new

nodes

will

be

added

it

has

to

compromise

a

sufficient

number

of

legitimate

nodes

in

order

to

increase

the

probability

of

discovery

of

newly-added

nodes

As

an

active

defense

against

such

man-in-the-middle

attacks

we

can

apply

a

node

replication

detection

mechanism

such

as

Randomized

or

Line-Selected

Multicast

-LSB-

-RSB-

which

revokes

the

same

ID

node

at

the

different

location

claims

To

successfully

launch

such

man-in-the-middle

attacks

two

colluding

nodes

should

pretend

to

be

each

other

so

that

each

of

them

claims

to

be

at

two

different

locations

with

the

same

ID

Location-binding

key-assignment

scheme

by

Yang

et

al.

-LSB-

-RSB-

with

a

little

modification

also

can

be

a

good

solution

to

such

attacks

Since

it

binds

secret

keys

with

nodes

geographic

locations

the

key

bound

to

the

particular

location

can

not

be

used

at

any

arbitrary

locations

Adopting

this

NLV

can

check

whether

the

claimed

neighbors

are

really

located

within

geographically

two

hops

away

Simulations

To

further

evaluate

the

performance

of

our

resilient

forwarding

scheme

we

run

simulations

of

our

scheme

in

the

presence

of

packet-dropping

nodes

on

a

network

simulator

-LSB-

-RSB-

Simulation

Model

In

our

simulations

we

deploy

N

sensor

nodes

uniformly

at

random

within

target

field

with

N

and

Each

sensor

node

has

a

constant

transmission

range

of

so

that

the

degree

of

each

node

is

approximately

-LRB-

N

-RRB-

and

-LRB-

N

-RRB-

on

average

We

position

a

base

station

and

a

source

node

in

opposite

corners

of

the

field

at

a

fixed

point

-LRB-

-RRB-

and

-LRB-

-RRB-

respectively

They

are

located

approximately

hops

away

from

each

other

We

distribute

compromised

nodes

over

an

inner

square

area

with

each

side

-LRB-

from

to

of

each

side

of

the

target

area

-RRB-

Thus

compromised

nodes

are

strategically-placed

in

between

the

base

station

and

the

source

node

In

the

simulations

those

compromised

nodes

drop

all

the

relaying

packets

next-hop

id

as

v

so

that

x

considers

it

forwarded

correctly

-LRB-

nodes

-RRB-

Number

of

Packet-dropping

Nodes

S

u

cc

ess

R

a

t

i

o

Single

Path

Forwarding

with

NWS

-LRB-

a

-RRB-

Success

ratio

-LRB-

N

x

-RRB-

-LRB-

nodes

-RRB-

Number

of

Packet-dropping

Nodes

S

u

cc

ess

R

a

t

i

o

Single

Path

Forwarding

with

NWS

-LRB-

b

-RRB-

Success

ratio

-LRB-

N

x

-RRB-

-LRB-

nodes

-RRB-

Number

of

Packet-Dropping

Nodes

N

u

m

b

e

r

of

R

e

l

a

yi

n

g

N

o

d

e

s

Single

Path

Forwarding

with

NWS

-LRB-

c

-RRB-

The

number

of

relaying

nodes

with

N

-LRB-

nodes

-RRB-

Number

of

Packet-dropping

Nodes

N

u

m

b

e

r

of

R

e

l

a

yi

n

g

N

o

d

e

s

Single

Path

Forwarding

with

NWS

-LRB-

d

-RRB-

The

number

of

relaying

nodes

with

N

Figure

Simulation

Results

-LRB-

averaged

over

runs

-RRB-

We

use

the

typical

TinyOS

beaconing

-LSB-

-RSB-

with

a

little

modification

as

a

base

routing

protocol

in

our

simulations

We

add

a

hop

count

value

in

a

beacon

message

To

have

multiple

potential

next-hops

when

receiving

a

beacon

with

the

same

or

better

hop

count

than

the

parent

node

's

each

node

marks

the

node

sending

the

beacon

as

a

potential

next-hop

Each

simulation

experiment

is

conducted

using

different

network

topologies

and

each

result

is

averaged

over

runs

of

different

network

topologies

Simulation

Results

In

the

presence

of

compromised

node

dropping

all

the

relaying

packets

we

measure

the

success

ratio

-LRB-

i.e.

the

percentage

of

the

packets

that

successfully

reach

the

base

station

from

the

source

-RRB-

and

the

number

of

relaying

nodes

by

the

primitive

single-path

forwarding

and

with

NWS

in

a

network

of

size

N

with

N

and

The

base

station

initiates

the

beacon-broadcasting

which

floods

through

the

network

in

order

to

set

up

a

routing

tree

Figure

-LRB-

a

-RRB-

shows

the

success

ratio

in

face

of

x

packet-dropping

nodes

-LRB-

varying

x

to

-RRB-

in

a

network

with

the

approximate

degree

d

Although

the

success

ratio

gently

decreases

with

x

it

keeps

up

above

even

with

x

with

the

help

of

NWS

This

tendency

of

decreasing

success

ratio

can

be

attributed

to

the

degree

d

-LRB-

sub-watch

nodes

on

average

-RRB-

as

well

as

an

increasing

number

of

packet-dropping

nodes

Due

to

the

strategically-placement

of

compromised

nodes

in

our

simulations

as

x

increases

on

it

is

likely

that

a

forwarding

node

's

all

potential

sub-watch

nodes

themselves

are

packet-dropping

nodes

Figure

-LRB-

c

-RRB-

shows

the

number

of

nodes

that

relay

the

packet

from

the

source

to

the

base

station

in

the

same

experiments

Since

the

source

is

located

about

hops

away

from

the

base

station

the

number

of

relaying

nodes

only

with

the

single-path

forwarding

remains

at

With

NWS

the

number

of

relaying

nodes

increases

with

x

in

order

to

bypass

an

increasing

number

of

packet-dropping

nodes

In

face

of

such

nodes

our

scheme

converts

single-path

forwarding

into

multipath

data

forwarding

with

the

help

of

sub-watch

nodes

around

such

packet-dropping

nodes

Utilizing

a

cache

for

recently-received

packets

can

suppress

the

same

copy

within

a

certain

timeout

which

reduces

the

number

of

relaying

nodes

Figure

-LRB-

b

-RRB-

shows

the

success

ratio

in

a

network

with

the

approximate

degree

d

with

x

packet-dropping

nodes

-LRB-

varying

x

to

-RRB-

Unlike

that

with

N

the

success

ratio

stays

constantly

at

around

even

with

x

with

the

help

of

NWS

This

tendency

of

high

success

ratio

can

be

mainly

attributed

to

the

degree

d

-LRB-

sub-watch

nodes

on

average

in

the

lower

bound

case

-RRB-

which

is

found

to

be

high

enough

to

bypass

a

large

number

of

packet-dropping

nodes

Figure

-LRB-

d

-RRB-

shows

the

number

of

relaying

nodes

from

the

source

to

the

base

station

in

the

same

experiments

With

NWS

the

increase

in

the

number

of

relaying

nodes

with

x

is

more

conspicuous

than

that

with

N

since

more

than

twice

as

many

as

sub-watch

nodes

help

forward

the

packets

so

that

it

can

bypass

a

large

number

of

packet-dropping

nodes

anyway

In

the

simulation

results

we

note

that

our

forwarding

scheme

dynamically

adjusts

its

forwarding

style

depending

on

the

number

of

packet-dropping

nodes

en-route

to

the

base

station

As

in

Figures

-LRB-

c

-RRB-

and

-LRB-

d

-RRB-

while

there

exist

or

a

small

number

of

packet-dropping

nodes

on

the

way

our

scheme

works

almost

like

the

single-path

forwarding

with

the

help

of

a

few

additional

relaying

nodes

On

the

other

hand

when

confronting

a

large

number

of

packet-dropping

nodes

our

scheme

makes

full

use

of

the

help

from

additional

relaying

nodes

in

order

to

successfully

deliver

the

packet

to

the

base

station

at

any

cost

to

the

best

efforts

In

this

paper

we

focus

on

defending

against

compromised

nodes

dropping

of

legitimate

reports

We

have

presented

a

resilient

packet-forwarding

scheme

using

Neighbor

Watch

System

-LRB-

NWS

-RRB-

against

maliciously

packet-dropping

nodes

in

sensor

networks

In

face

of

such

nodes

NWS

is

specifically

designed

for

hop-by-hop

reliable

delivery

and

the

prompt

reaction

of

the

conversion

from

single-path

to

multipath

forwarding

augments

the

robustness

in

our

scheme

so

that

the

packet

successfully

reach

the

base

station

In

future

work

we

plan

on

further

improving

NLV

to

defend

against

the

man-in-the-middle

attacks

collusion

among

compromised

nodes

Such

attacks

can

be

prevented

by

using

a

master

key

derived

with

not

only

a

node

ID

but

also

its

geographic

information

We

will

also

seek

to

address

O

-LRB-

d

-RRB-

storage

requirement

for

the

neighbors

neighbor

lists

Finally

we

would

like

to

perform

an

intensive

experimental

evaluation

to

compare

our

scheme

with

other

reliable

delivery

protocols

-LSB-

-RSB-

This

work

was

supported

by

grant

from

the

Basic

Research

Program

of

the

Korea

Science

and

Engineering

Foundation

-LSB-

-RSB-

R.

Anderson

H.

Chan

and

A.

Perrig

Key

Infection

Smart

Trust

for

Smart

Dust

IEEE

ICNP

-LSB-

-RSB-

Burton

H.

Bloom

Space/Time

Trade-offs

in

Hash

Coding

with

Allowable

Errors

Communication

of

the

ACM

vol

-LSB-

-RSB-

B.

Carbunar

I.

Ioannidis

and

C.

Nita-Rotaru

JANUS

Towards

Robust

and

Malicious

Resilient

Routing

in

Hybrid

Wireless

Networks

ACM

workshop

on

Wireless

security

-LRB-

WiSe

-RRB-

Oct.

-LSB-

-RSB-

H.

Chan

A.

Perrig

and

D.

Song

Random

Key

Predistribution

Schemes

for

Sensor

Networks

IEEE

Symposium

on

Security

and

Privacy

pp.

May

-LSB-

-RSB-

B.

Deb

S.

Bhatnagar

and

B.

Nath

ReInForM

Reliable

Information

Forwarding

Using

Multiple

Paths

in

Sensor

Networks

IEEE

Local

Computer

Networks

-LRB-

LCN

-RRB-

pp.

Oct.

-LSB-

-RSB-

J.

Deng

R.

Han

and

S.

Mishra

A

Performance

Evaluation

of

Intrusion

Tolerant

Routing

in

Wireless

Sensor

Networks

International

Workshop

on

Information

Processing

in

Sensor

Networks

-LRB-

IPSN

-RRB-

pp.

Apr.

-LSB-

-RSB-

J.

Deng

R.

Han

and

S.

Mishra

Intrusion

Tolerance

and

Anti-Traffic

Analysis

Strategies

for

Wireless

Sensor

Networks

IEEE

International

Conference

on

Dependable

Systems

and

Networks

-LRB-

DSN

-RRB-

pp.

-LSB-

-RSB-

J.

Deng

R.

Han

and

S.

Mishra

Defending

against

Path-based

DoS

Attacks

in

Wireless

Sensor

Networks

ACM

Workshop

on

Security

of

Ad-Hoc

and

Sensor

Networks

-LRB-

SASN

-RRB-

Nov

-LSB-

-RSB-

K.

Fall

and

K.

Varadhan

-LRB-

editors

-RRB-

NS

notes

and

documentation

The

VINT

project

LBL

Feb

-LSB-

-RSB-

D.

Ganesan

R.

Govindan

S.

Shenker

and

D.

Estrin

Highly

Resilient

Energy-Efficient

Multipath

Routing

in

Wireless

Sensor

Networks

Computing

and

Communications

Review

-LRB-

-RRB-

Vol

pp.

-LSB-

-RSB-

V.

D.

Gligor

Security

of

Emergent

Properties

in

Ad-Hoc

Networks

International

Workshop

on

Security

Protocols

Apr.

-LSB-

-RSB-

O.

Goldreich

S.

Goldwasser

and

S.

Micali

How

to

Construct

Random

Functions

Journal

of

the

ACM

Vol

No.

-LSB-

-RSB-

L.

Eschenauer

and

V.

D.

Gligor

A

Key-Management

Scheme

for

Distributed

Sensor

Networks

ACM

Conference

on

Computer

and

Communication

Security

-LRB-

CCS

-RRB-

pp.

Nov.

-LSB-

-RSB-

C.

Hartung

J.

Balasalle

and

R.

Han

Node

Compromise

in

Sensor

Networks

The

Need

for

Secure

Systems

Technical

Report

Department

of

Computer

Science

University

of

Colorado

at

Boulder

Jan.

-LSB-

-RSB-

T.

He

S.

Krishnamurthy

J.

A.

Stankovic

T.

F.

Abdelzaher

L.

Luo

R.

Stoleru

T.

Yan

L.

Gu

J.

Hui

and

B.

Krogh

An

Energy-Efficient

Surveillance

System

Using

Wireless

Sensor

Networks

ACM

MobiSys

June

-LSB-

-RSB-

W.R.

Heinzelman

J.

Kulik

H.

Balakrishnan

Adaptive

Protocols

for

Information

Dissemination

in

Wireless

Sensor

Networks

ACM

pp.

-LSB-

-RSB-

J.

Hill

R.

Szewczyk

A.

Woo

S.

Hollar

D.

Culler

and

K.

Pister

System

Architecture

Directions

for

Networked

Sensors

ACU

ASPLOS

IX

November

-LSB-

-RSB-

X.

Hong

M.

Gerla

W.

Hanbiao

and

L.

Clare

Load

Balanced

Energy-Aware

Communications

for

Mars

Sensor

Networks

IEEE

Aerospace

Conference

vol

-LSB-

-RSB-

Y.-C

Hu

D.

B.

Johnson

and

A.

Perrig

SEAD

Secure

Efficient

Distance

Vector

Routing

for

Mobile

Wireless

Ad

Hoc

Networks

IEEE

Workshop

on

Mobile

Computing

Systems

and

Applications

pp.

Jun.

-LSB-

-RSB-

Y.-C

Hu

A.

Perrig

and

D.

B.

Johnson

Efficient

Security

Mechanisms

for

Routing

Protocols

NDSS

pp.

Feb.

-LSB-

-RSB-

C.

Intanagonwiwat

R.

Govindan

and

D.

Estrin

Directed

Diffusion

A

Scalable

and

Robust

Communication

Paradigm

for

Sensor

Networks

MobiCom

Aug.

-LSB-

-RSB-

D.

Johnson

D.A.

Maltz

and

J.

Broch

The

Dynamic

Source

Routing

Protocol

for

Mobile

Ad

Hoc

Networks

-LRB-

Internet-Draft

-RRB-

Mobile

Ad-hoc

Network

-LRB-

MANET

-RRB-

Working

Group

IETF

Oct.

-LSB-

-RSB-

C.

Karlof

and

D.

Wagner

Secure

Routing

in

Wireless

Sensor

Networks

Attacks

and

Countermeasures

The

First

IEEE

International

Workshop

on

Sensor

Network

Protocols

and

Applications

pp.

May

-LSB-

-RSB-

C.

Karlof

N.

Sastry

and

D.

Wagner

TinySec

A

Link

Layer

Security

Architecture

for

Wireless

Sensor

Networks

ACM

SensSys

pp.

Nov.

-LSB-

-RSB-

I.

Khalil

S.

Bagchi

and

C.

Nina-Rotaru

DICAS

Detection

Diagnosis

and

Isolation

of

Control

Attacks

in

Sensor

Networks

IEEE

SecureComm

pp.

Sep.

-LSB-

-RSB-

Y.

Liu

and

W.

K.G.

Seah

A

Priority-Based

Multi-Path

Routing

Protocol

for

Sensor

Networks

IEEE

International

Symposium

on

Volume

-LSB-

-RSB-

S.-B

Lee

and

Y.-H

Choi

A

Secure

Alternate

Path

Routing

in

Sensor

Networks

Computer

Communications

-LRB-

-RRB-

doi

j.comcom

-LSB-

-RSB-

S.

Marti

T.J.

Giuli

K.

Lai

and

M.

Baker

Mitigating

Routing

Misbehavior

in

Mobile

Ad

Hoc

Networks

ACM/IEEE

International

Conference

on

Mobile

Computing

and

Networking

pp.

-LSB-

-RSB-

H.

Morcos

I.

Matta

and

A.

Bestavros

M

RC

Multiplicative-Increase/Additive-Decrease

Multipath

Routing

Control

for

Wireless

Sensor

Networks

ACM

SIGBED

Review

Vol

Jan

-LSB-

-RSB-

J.

Newsome

E.

Shi

D.

Song

and

A.

Perrig

The

Sybil

Attack

in

Sensor

Networks

Analysis

and

Defenses

IEEE

IPSN

pp.

Apr.

-LSB-

-RSB-

B.

Parno

A.

Perrig

and

V.

D.

Gligor

Distributed

Detection

of

Node

Replication

Attacks

in

Sensor

Networks

the

IEEE

Symposium

on

Security

and

Privacy

pp.

May

-LSB-

-RSB-

A.

Perrig

R.

Szewczyk

V.

Wen

D.

Culler

and

J.

Tygar

SPINS

Security

Protocols

for

Sensor

Networks

ACM

MobiCom

pp.

-LSB-

-RSB-

A.

Perrig

J.

Stankovic

and

D.

Wagner

Security

in

Wireless

Sensor

Networks

Communications

of

the

ACM

-LRB-

-RRB-

Special

Issue

on

Wireless

sensor

networks

pp.

Jun.

-LSB-

-RSB-

B.

Przydatek

D.

Song

and

A.

Perrig

SIA

Secure

Information

Aggregation

in

Sensor

Networks

International

Conference

on

Embedded

Networked

Sensor

Systems

-LSB-

-RSB-

E.

Shi

and

A.

Perrig

Designing

Secure

Sensor

Networks

Wireless

Communications

IEEE

Volume

Issue

pp.

Dec.

-LSB-

-RSB-

D.

Tian

and

N.D.

Georganas

Energy

Efficient

Routing

with

Guaranteed

Delivery

in

Wireless

Sensor

Networks

IEEE

Wireless

Communications

and

Networking

-LRB-

WCNC

-RRB-

IEEE

Volume

March

-LSB-

-RSB-

A.

Woo

T.

Tong

and

D.

Culler

Taming

the

Underlying

Challenges

of

Reliable

Multhop

Routing

in

Sensor

Networks

ACM

Nov

-LSB-

-RSB-

A.

Wood

and

J.

Stankovic

Denial

of

Service

in

Sensor

Networks

IEEE

Computer

Vol

Oct.

-LSB-

-RSB-

H.Yang

F.

Ye

Y.

Yuan

S.

Lu

and

W.

Arbough

Toward

Resilient

Security

in

Wireless

Sensor

Networks

ACM

MobiHoc

May

-LSB-

-RSB-

Y.

Yang

X.

Wang

S.

Zhu

and

G.

Cao

SDAP

A

Secure

Hop-by-Hop

Data

Aggregation

Protocol

for

Sensor

Networks

ACM

MobiHoc

May

-LSB-

-RSB-

F.

Ye

H.

Luo

S.

Lu

and

L.

Zhang

Statictial

En-route

Filtering

of

Injected

False

Data

in

Sensor

Networks

IEEE

INFOCOM

-LSB-

-RSB-

F.

Ye

G.

Zhong

S.

Lu

and

L.

Zhang

GRAdient

Broadcast

A

Robust

Data

Delivery

Protocol

for

Large

Scale

Sensor

Networks

ACM

Wireless

Networks

-LRB-

WINET

-RRB-

March

-LSB-

-RSB-

Y.

Yu

R.

Govindan

and

D.

Estrin

Geographical

and

Energy

Aware

Routing

a

recursive

data

dissemination

protocol

for

wireless

sensor

networks

UCLA

Computer

Science

Department

Technical

Report

UCLA/CSD-TR

May

-LSB-

-RSB-

W.

Zhang

and

G.

Cao

Group

Rekeying

for

Filtering

False

Data

in

Sensor

Networks

A

Predistribution

and

Local

Collaboration-Based

Approach

IEEE

INFOCOM

Vol

March

-LSB-

-RSB-

G.

Zhou

T.

He

S.

Krishnamurthy

and

J.

A.

Stankovic

Impact

of

radio

irregularity

on

wireless

sensor

networks

the

International

Conference

on

Mobile

Systems

Applications

and

Services

-LRB-

-RRB-

June

-LSB-

-RSB-

S.

Zhu

S.

Setia

and

S.

Jajodia

LEAP

Efficient

Security

Mechanisms

for

Large-Scale

Distributed

Sensor

Networks

The

ACM

Conference

on

Computer

and

Communications

Security

-LRB-

CCS

-RRB-

-LSB-

-RSB-

S.Zhu

S.

Setia

S.

Jajodia

and

P.

Ning

An

Interleaved

Hop-by-Hop

Authentication

Scheme

for

Filtering

False

Data

in

Sensor

Networks

IEEE

Symposium

on

Security

and

Privacy

degree of multipath
robustness
malicious node
neighbor watch system
cluster key
aggregation protocols
reliable delivery
secure routing
critical area
legitimate node

single-path forwarding
secure ad-hoc network routing protocol
sensor network security
packet-dropping attacks