security in ad -hoc networks - unipi.it › ... › slides › ad_hoc-security.pdf · gianluca dini...

SecuritySecurity in in

AdAd--hoc hoc NetworksNetworks

Gianluca DiniGianluca Dini

Dept. of Ingegneria dell’InformazioneElettronica, Informatica, Telecomunicazioni

University of Pisa, Italy

Via Diotisalvi 2, 56100 Pisa

[email protected]

Gianluca Dini Security in ad-hoc networks 2

AD-HOC NETWORK SECURITYThe problem: lack of a priori trust

In a wireless ah-hoc network functions are performed by all available nodes which cannot be trusted for the correct execution of critical network functions

• open environment

• lack of tamper-proof hardware

• lack of strong authentication

• malicious nodes

• selfish nodes

• a node does not cooperate to save power

Key managementKey management


THE KEY SETUP PROBLEM

� Routing protocols need authentication

services

each legitimate node must possess one or more keys unique to that node

each node must have a way to authenticate a

legitimate node

� How to disseminate authentic key informationis the key setup problem


ESTABLISHING PRIVATE KEYS

Establishing a shared secret key between any

pair of nodes

� Key setup must ensure authenticity and secrecy

� Approaches

• Distribution at pre-deploymentPROBLEM: incremental deployment

• Distribution through side channels

• Key exchange based on public keysPROBLEM: Public key management


PUBLIC KEY MANAGEMENTPublic keys pre-deployment

� Pre-deployment of public keys list

• Before deployment a node receives

its own private key and the list of legitimate (node, public key) pairs

from a trusted common authority

• Security requirements

• secrecy

• authenticity

• Problem

• incremental deployment


Public Key Management

• Robust authentication service

• Self-organized PKI


PUBLIC KEY MANAGEMENTRobust authentication service

� Certification Services must be

• on-line

• ubiquitous

• robust (secure and available)

� Certification services are distributed among the network nodes [LL00,ZH99]


DISTRIBUTING TRUSTSimple replication

(ΠΠΠΠ, ΣΣΣΣ)

The public-private key pair of the CA is replicated over

n nodes

The system becomes more available but less secure

It is sufficient to compromise a replica

�

public-private key pair of CA


DISTRIBUTING TRUST(n, t) secret sharing and threshold cryptography

ΠΠΠΠ

�

ΣΣΣΣ

(n, t) secret

sharing

(n, t) secret

sharing

n

n shares

σσσσ1 σσσσ2 σσσσn�

SECRET SHARING

• The secret (private key ΣΣΣΣ) is split

into n shares

• At least t shares are necessary to

reconstruct the secret

• The system tolerates the

compromise of t−1 nodes

THRESHOLD CRYPTOGRAPHY

• Every node uses ΠΠΠΠ to verify a signature

made by ΣΣΣΣ

• A node i can produce a “piece” of signature

(partial signature) by means of σσσσi

• With t “pieces” it is possible to reconstruct

the signature made by ΣΣΣΣ


DISTRIBUTING TRUSTExample of secret sharing and threshold cryptography

1 2 nn−1�

secret

shares

1

1

1 1

with publicly known

mod mod

mod mod

mod and mod

t

x x

x

x x

x x

t

x x xx

t t

x x

x x

x x

s m n m n

s m n s n

s m n m n

α σ

α σ

σ α

α σ α

=

=

Σ

= =

Σ =

∑= = =

= = Α

= Α =

∑

∏ ∏

Polynomial (2, n) secret sharing

RSA-based threshold cryptography

sx is the partial signature made by

node x


DISTRIBUTING TRUSTCompromised servers: incorrect partial signatures

We must defend against compromised servers

� A compromised server could generate an incorrect partial signature yielding an incorrect signature

• Using Π, one verifies the signature and tries another set of t partial signatures in the case verification fails

• More efficient and robust schemes have been

proposed that use inherent redundancies of partial signatures


DISTRIBUTING TRUSTCompromised servers: mobile adversary


� A mobile adversary compromise a server and then moves on to the next victim

(e.g. in the form of a virus)

� a mobile adversary can compromise all servers over a

long period of time

� a mobile adversary can gather t shares and reconstruct Σ

� Periodic share refreshing is a countermeasure(share refreshing does not change the private key)

(proactive systems)


DISTRIBUTING TRUSTCompromised servers: mobile adversary


� A variation of share refreshing allows the key management service to change its configuration from

(n, t) to (n′, t′)

the key management service can adapt itself to network changes

� servers becomes compromised or unavailable

� new server are added


DISTRIBUTING TRUSTSystem model: legitimate nodes

• Each node carries a certificate Χ

signed by Σ

• Every node carries Π and a share

σ of Σ

• Nodes establish trust relationships

using certificates

• Trusted nodes forward and route

packets and monitor each other to

to detect possible attacks and

break-ins

• Nodes without certificates will be

isolated and treated as adversaries

node with a certificate

node without a certificate

� A trusted authority must

initialise the first t nodes


DISTRIBUTING TRUSTSystem model: handling new nodes

• A node requests a certificate

signed by a coalition of t nodes

• If a legitimate node trusts the

requestor then the legitimate

node releases a partial

certificate by using its share

• By collecting t partial certificates,

the requestor generates a

certificate and becomes a

legitimate node

• A node must be trusted by at

least t neighbours

t = 3

� Every node has at least t

legitimate neighbours


DISTRIBUTING TRUSTSystem model: certificate revocation

• A misbehaving roaming node

moves into a zone where its new

neighbours have no information

about him

• The misbehaving node could get

a valid certificate

• “Accusation” messages are

flooded to inform distant nodes

• Accusation messages are

accepted if they come from

legitimate nodes


Public Key Management

• Robust authentication service

• Self-organized PKI


PUBLIC KEY MANAGEMENTSelf-organized Public-Key Management based on PGP

� Capkun et al. suggests an approach similar to PGP [CBH02]

• users issue certificates for each other based on their personal acquaintances

• unlike PGP, certificates are stored locally in a local certificate repository



uu xx yy vvΧu(x) Χx(y) Χy(v) Χi(j) is the certificate

released by node i to

node j

When a node u wants to obtain the public key of another node v, she acquires a chain of valid public-key certificates

The node must trust the issuer of the certificate in

the chain(transitive trust)



uu xx yyΧu(x) Χx(y)

when two nodes want to verify the public keys of each other,

they merge their local certificate repositories and try to find appropriate certificate chains(merging is a rare but expensive operation in time and bandwidth)

vvΧy(v)

yy

node u node v

local certificate repository



uu

xx yy

vvaa bb

rr ss

• Transitive trust is an unrealistic assumption when certificates

are issued by users instead of Certification Authorities

• Authentication metrics [RS99]

(e.g.: the number of disjoint chains between two nodes)



� Building the local certificate repository is an

expensive operation in terms of time and bandwidth

It’s a rare operation provided

• a small number of certificates are revoked

• the certificate graph does not change

significantly

� PGP-like schemes are more suitable for small

communities(authenticity of the key can be assured with a higher degree of

trustworthiness)

Secure routing


SECURE ROUTING

• General considerations

• Relevant ad-hoc routing algorithms

• Threats and attacks

• Relevant secure ad-hoc routing algorithms


ROUTINGGeneral considerations

� Routing algorithms for wired networks are not suitable

• node mobility

• topology rapidly changes

• high communication overhead

� Research in ad-hoc networking have studied the

routing problem in a non-adversarial environment

� Current research takes into account node misbehaviour at the early stages of the routing protocol design


AD-HOC ROUTINGGeneral considerations

� Desired characteristics of ad-hoc routing protocols:

• Distributed operation

• Loop freedom

• On-demand network operations

• Periodic network operations

• Unidirectional link support

• Security


ROUTINGTypes of protocols

� Types of ad-hoc routing protocols - Proactive, periodic protocols

- Reactive, on-demand protocols

Ad hoc Routing Protocols

Reactive Proactive

DSR AODV OLSRTORA TBRPF


SECURE ROUTING



• DSDV

• DSR

• AODV




DSDVOverview (1)

• Destination Sequenced Distance Vector (DSDV)

• DSDV is a proactive algorithm based on the Distributed Bellman-Ford algorithm

• DSDV improves DBF by avoiding routing loops


DSDVOverview (2)

• Every node maintains a routing table that has one

entry for each destination that specifies

• the next hop

• the distance

• the sequence number(assigned by the destination)

• The routing table is periodically transmitted(periodic updates, triggered updates)(full dump, incremental changes)


DSDVSequence numbers

most recent sequence number known for the

destination

sequence number of the sender

route for dst transmitted by src

src, ⟨dst, distance, seqnumdst⟩, seqnumsrc


DSDVOverview (3)

When a node receives a a new route to a destination

• the node prefers this new route if the sequence number is greater (more recent) than in the current route or,

• if the sequence numbers are equal, if the new metric is lower than that current one;

• otherwise the new route is ignored


DSDVAttacks

• Lack of cooperation(Failing to advertise routes, ignorance attack)

• Modification attack

• Replay attack

• Wormhole attack


SECURE ROUTING



• DSDV

• DSR

• AODV




Dynamic Source Routing (DSR)Route discovery

A

C

G

F

D

M

K

B

A

C

G

F

D

M

K

B

A

A, C

A

A, G

A, G, F

A, C, D

A, G, F

A, G, F

A, G, F, K

A, G, F, M

A, C, D, BA, C, D, B

A, C, D, B

ROUTE REQUEST ROUTE REPLY

• Source routing

• Every node maintains a route cache

• Asymmetric links


Dynamic Source Routing (DSR)Route maintenance

A

C

G

F

D

M

K

B

• Route Error (RERR) packet

specifies the nodes at the

end of the broken link

X

• When a route error packet is received,

the hop in error is removed from this host’s route cache, and

all routes which contain this hop must be truncated at that point.

The data link level reports a transmission problem


SECURE ROUTING



• DSDV

• DSR

• AODV




AODVRoute discovery

A

C

G

F

D

M

K

B

• On-demand version of DSDV

• Symmetric links

routing tablenext

metric

sequence number

destina

tion

• RREQ

• RREP


AODVRoute maintenance

• When the source node moves, it initiate a new

route discovery

• When an intermediate node moves, its neighbours

propagate a link failure notification packet to each

of their active upstream neighbours

The source may re-initiate a new route discovery

• A node periodically broadcasts Hello packets to

inform its neighbours of its presence


SECURE ROUTING



• DSDV

• DSR

• AODV




AD-HOC NETWORK SECURITYGeneral considerations

� Ad-hoc network’s security characteristics:

• Availability � ability to use the informationdesired

• Confidentiality � information not disclosed to

unauthorized entities

• Integrity � no corruption

• Authentication � ensure identity of correspondent

• Non-repudiation � can’t deny a sent message


SECURE ROUTINGThreats

� Passive attacks

• Selfish node

• Lack of cooperation threat

� Active attacks

• Malicious node

• Threats

�Threat using modification (integrity)

�Threat using impersonation (authenticity, spoofing)

�Threat using fabrication (false valid routing messages)

�Wormhole attack


ATTACK USING MODIFICATIONBasic idea

Idea

Malicious node announces better routes than the

other nodes in order to be inserted in the ad-hoc

network

How

• Redirection by changing the route sequence number

• Redirection with modified hop count

• Denial Of Service (DOS) attacks


ATTACK USING MODIFICATIONRedirection by changing the route sequence number

Node A Node B Node DNode C

• Node A wants to communicate with D.

• Node A will broadcast a message asking the better path to reach the

node D

• The best path is chosen depending on the metric of the different routes

• If an intruder replies with the shortest path, it inserts itself in the network


ATTACK USING MODIFICATIONRedirection by changing the route sequence number

Figure 3.2

Node A Node B

Node DNode C

Intruder

• An intruder listens node C announcing to node B its route metric

• The intruder announces to node B a smallest metric to reach D

• B deletes its path with node C and replaces it with the intruder path


ATTACK USING MODIFICATIONRedirection with modified hop count

Node A Node B Node DNode C

Intruder

Metric 1 and 3 hops

Metric 1 and 1 hop

• The node C announces to B a path with a metric value of one

• The intruder announces to B a path with a metric value of one too

• B decides which path is the best by looking into the hop count value

of each route


ATTACK USING MODIFICATIONRedirection with modified hop count

Figure 3.2

Node A Node B

Node DNode C

Intruder

� The path with the malicious node is chosen

according to the hop count value


ATTACK USING IMPERSONATIONBasic idea

Idea

Usurpate the identity of another node to perform changes

How

Spoofing MAC address of other nodes


A malicious node M can listen all the nodes when the others

nodes can only listen their closest neighbors

A

B

C

D E X

M

ATTACK USING IMPERSONATIONForming loops by spoofing MAC address

1. Node M first changes its MAC address to the MAC address of the node A

2. Node M moves closer to node B than node A is, and stays out of range of

node A

3. Node M announces node B a shorter path to reach X than the node D gives

A

B

C

D E X

A


4. Node M first changes its MAC address to the MAC address of the node B

5. Node M moves closer to node D than node B is, and stays out of range of

node B

6. Node M announces node D a shorter path to reach X than the node E

gives

A loop is formed and node X is unreachable

A

B

C

D E X

B

A

B

C

D E X

B

ATTACK USING IMPERSONATION

Forming loops by spoofing MAC address


Idea

Generates traffic to disturb the correct operation of an ad-

hoc network

How

Falsifying route error messages

Corrupting routing state

Routing table overflow attack

Replay attack

Black hole attack

ATTACK USING FABRICATIONBasic idea


ATTACK USING FABRICATIONFalsifying “route error” packets

A

C

G

F

D

M

K

B

N

B moves

� When node B moves, the closest nodes D and N send “route error“ (”link

failure notification”) packet to upstream nodes

� Upon receiving the packet, every node removes routes to B and forwards

the “route error” packet to upstream nodes

RERR

RERR


ATTACK USING FABRICATIONFalsifying “route error” packets

A

C

G

F

D

M

K

B

N

� A malicious node can usurp the identity of another node (e.g. by using

spoofing) and sends “route error” packets to the others

� The other nodes update their routing tables accordingly

� The “victim” node B is isolated

RERR


ATTACK USING FABRICATIONCorrupting routing state

In DSR, routes can be learned from promiscuously received packets

1. A node should add the routing information contained in

each packet’s header it overhears

2. A malicious node can easily broadcast a message with a

spoofed IP address such as the other nodes add this new route to reach a special node S

3. It’s the malicious node which will receive the packets intended to S


ATTACK USING FABRICATIONRouting table overflow attack

� Feasible in "pro-active" protocols

� These protocols try to find routing information before they are needed

� A malicious node sends route information

regarding non-existing nodes in order to

overflow the routing tables

prevent creation of legitimate routes

overwhelm the protocol


ATTACK USING FABRICATIONReplay and Black Hole Attack

Replay attack

� A hacker sends old advertisements to a node

� The node updates its routing table with stale routes


ATTACK USING FABRICATIONBlack Hole Attack

A malicious node uses the routing protocol to advertise itself as

having the shortest path to the node whose packets it wants

to intercept

A

B

C

D

E

F

For example, DSDV

• Node A wants to discover a route to

node F

• A malicious node C promptly

advertises a fresh, short route to

node F

• All the packets from node A and

addressed to node F pass through

node C (black hole)

• eavesdrop packets

• drop packets

• selectively drop packets


WORMHOLE ATTACKProblem statement

A

C

G

F

D

M

K

B

N

An attacker receives packets at one point in the network, “tunnels” them to another point in the network, and then

replays them into the network from that point

The attacker makes the tunneled packet arrive sooner than other packets transmitted over a normal multihop route


WORMHOLE ATTACKExploiting the attack: on-demand protocols

A

C

G

F

D

M

K

B

N

RREQ

RREQ

• The attack prevents routes longer than two hops from being discovered

• All the traffic passes through the attacker who may

discard data packets, selectively discard data packets, modify data

packets

• The attacker is invisible

Wormhole for the RREQ

(DSR, AODV,…)


WORMHOLE ATTACKExploiting the attack: periodic protocols

A

C

G

F

D

M

K

BHELLO

HELLO

Wormhole for the HELLO

(OLSR, TBRPF,…)

adversary tunnels HELLO packetsA and B believe they are neighbours

the routing protocol does not find other routes when A and B

are not

N


CONCLUSIONS

� A lot of different threats for the ad-hoc routing protocols

� A new routing protocol should be created respecting the following rules:

• Focus first on the topology discovery rather than the data forwarding

• Detect a malicious node and react


SECURE ROUTING






CURRENT EFFORTS

� Current efforts are mainly oriented to reactive (on-demand) routing protocols (e.g., DSR, AODV)

� Common to secure routing protocols in the literature

• They address the active attacks but not the selfishness

attack

• They assume a managed environment, i.e., where a TTP does exist

(a priori trust relationships do exist)


SECURE ROUTING AD-HOC

PROTOCOLS� Protocol enhancements

• Secure Routing Protocol (SRP)

• Security Aware ad-hoc Routing (SAR)

• The Selfish Node (TSN)

� New secure protocols

• ARIADNE, an on-demand secure protocol

• ARAN, an on-demand secure protocol

• SEAD, a proactive secure protocol

• Packet leashes


SECURE ROUTING




• Relevant secure ad-hoc routing algorithms• Packet leashes• SRP• TESLA

• ARIADNE• ARAN• SEAD


PACKET LEASHESA countermeasure against wormhole attack

Idea

by authenticating either

an extremely precise timestamp (temporal leashes) or

location information combined with a loose timestamp

(geographical leashes),

a receiver can determine if the packet has traversed an

unrealistic distance


PACKET LEASHESA countermeasure against wormhole attack

Temporal leashes

evaluate the travel time of a packet

require extremely precise time synchronization

Geographical leashes

estimate the distance between sender and receiver

require loosely synchronized clocks and

location information


SECURE ROUTING







SECURE ROUTING PROTOCOL (SRP) Overview

� SRP can be used with DSR or the Interzone

Routing Protocol in the Zone Routing Protocol

(ZRP)

� SRP cope with non-colluding malicious nodes

SRP is subject to the wormhole attack

� Assumptions

• A bidirectional security association (SA) between the

source node (S) and the destination node (D), i.e.,

• nodes S and D share a secret key KS,D


SECURE ROUTING PROTOCOL (SRP) In action

� SRP is designed as an extension header attached

to the ROUTE REQUEST and ROUTE REPLY

packet

� SRP does not attempt to secure ROUTE ERROR

� SRP uses SA to

authenticate ROUTE REQUEST at destination

authenticate ROUTE REPLY at source

� SRP does not attempt to prevent unauthorized

modifications to mutable fields


SRP IN ACTIONBasic mechanisms

S

1

2 3

4

5

6

T

[ ] [ ]( ), , , , , ,, ,, ,ST

S qid qsn MAC K SRRE T quiTQ d qsn ⊥= ⊥

[ ] [ ]( ),1,4, , , , ,1,4, , , ,ST

qid qsn MAC K S T qid qsnR P SR TE =

M1 M2

qid: query identifier randomly selected with a SPRNG

qsn: query sequence number; it provides freshness but can only be checked at destination

if (QSNT[S] < RREQ.qsn from S) {

QSNT[S] ← RREQ.qsn;

produce RREP

} else discard RREQ

• header DSR

• header SRP


SRP IN ACTIONOther mechanisms: forwarding rate

• An intermediate node records the rate at which a neighbour

node forwards RREQ packets and gives higher priority to neighbours that less frequently forward RREQ packets

+ this avoids flooding attacks

− this exhacerbates the problem of selfish nodes

− forged RREQ packets to reduce the effectiveness of a

node’s authentic RREQ packets


SRP IN ACTIONroute maintenance problem is not addressed

• Route error packets are not authenticated, however

SRP source-routes error packets along the prefix of the route reported as broken

+ the source node can verify that the route error packet

was generated by a node on the path

− a malicious node can harm only the routes it belongs to

S

1 4 T

M2

• M2 attempts to convince S

that link {4, T} is broken

• source-routing defeats this

attack


SRP IN ACTIONCache poisoning

• Routing information gathered by intermediate nodes to

improve efficiency of DSR could be fabricated by malicious nodes

− this causes cache poisoning

� Caching is discouraged and intermediates nodes are notrequired to provide route replies unless

+ an intermediate node has a SA with the source node(this requires an estension to SRP)

+ this can be extended to a group of (intermediate) nodes


SECURE ROUTING




• Relevant secure ad-hoc routing algorithms• Packet leashes• SRP• TESLA [PCST00]



TESLAEfficient authentication of broadcast packets

� In this context, TESLA is used to authenticate routing control

packets

� TESLA adds a MAC authentication code for broadcast authentication

(multiple nodes must know the key for MAC verification)

� TESLA achieves asymmetry from

clock synchronization and

delayed key disclosure


TESLAOne-way key chain

KN � Ki+1 Ki Ki–1

� K0RNG

Disclosure

Generation: Kj–1 = H(Kj) = HN–j(KN)

Key schedule

t0

K0 K1 K2 K2 K2 K2 KN–1 KN

t1 t2 tN–1 tN


TESLAauthentication of an element of the chain

Given an authenticated element of a one-way hash chain, it is possible to verify elements later in the sequence of use within the chain

Example

• Given an authenticated Ki

a node can authenticate Ki–3

by verifying that Ki = H(H(H(Ki–3)))


TESLAdistribution of an authenticated element

an authenticated element of the hash chain can be distributed by means of

• public key certificates

• symmetric key cryptography

• non-cryptographic approaches(e.g., physical contact [SA99])


TESLAbroadcast authentication

Sender → *: packet, MAC(Ki, packet)

Sender reveals Ki in slot i + δ

Receiver verifies that Ki arrives in slot i + δ (is not a replay)

verifies authenticity of Ki

verifies authenticity of the packet

temporal slot i • Receivers know Kj, j≤i

• An upper bound to end-to-end

propagation is known (τ)

• Loose synchronization (∆)


SECURE ROUTING





• ARIADNE [HPJ02]• ARAN• SEAD


ARIADNE

� Ariadne discovers routes on-demand (DSR) and

uses them to source route packets;(forwarding nodes contribute to route maintenance)

� Ariadne uses highly efficient symmetric

cryptography

� Ariadne withstands compromised nodes• copes with modification and fabrication of routing messages

• copes with impersonation

• copes with the wormhole attack

(TIK, the advanced version of TESLA)

• does not cope with selfish nodes


ARIADNE

Ariadne authenticates routing messages• The destination node authenticates the source node

• The source node authenticates intermediate nodes

(present in the RREP)

• No intermediate node can remove a previous intermediate

node

(in RREQ or RREP)

Authentication mechanisms for routing control messages

• Shared secret between each pair of nodes

� Shared secrets between communicating nodes combined with broadcast authentication (TESLA)

• Digital signatures


ARIADNEFormat of routing control packets: Route Request

⟨RREQ, src, dst, id, time interval, hash chain, node list, MAC list⟩

Route Request message

• src and dst: addresses of source and destination

• id: unique, source-chosen request identifier

• time interval: TESLA time interval

• hash chain: hi = h(hi−1, intermediate node address) initialised to h0 = MAC(KS,D, src, dst, id, time interval)

• node list: list of addresses of intermediates (initially empty)

• MAC list: list of MACs of the RREQ (initially empty)


ARIADNERoute discovery

S

A B

D

C • KSD for RREQ authentication

• KDS for RREP authenticationRREQ

RREP

S: h0 = MAC(KSD, RREQ, S, D, id, ti)

S→*: RREQ, S, D, id, ti, h0, (), ()

A: h1 = H(A, h0)

MA = MAC(KA,ti, RREQ, S, D, id, ti, h1, (A), ())

A→*: RREQ, S, D, id, ti, h1, (A), (MA)

B: h2 = H(B, h1)MB = MAC(KB,ti, RREQ, S, D, id, ti, h2, (A, B), (MA))

B →*: RREQ, S, D, id, ti, h2, (A, B), (MA, MB)

C: h3 = H(C, h2)MC = MAC(KC,ti, RREQ, S, D, id, ti, h3, (A, B, C), (MA, MB))

C →*: RREQ, S, D, id, ti, h3, (A, B, C), (MA, MB , MC)

target authenticates route requests(the target can authenticate each node in the node list of the RREQ)


ARIADNEFormat of routing control packets: Route Reply

⟨RREP, src, dst, id, time interval, node list, MAC list, dst MAC, key list⟩

Route Reply message

• src, dst, id, time interval, node list and MAC list: set to the corresponding values from RREQ

• dst MAC: MAC computed on the preceding fields with KDS

• key list: list of the TESLA keys on the intermediate nodes (initially empty)


ARIADNERoute discovery

S

A B

D

C • KSD for RREQ authentication

• KDS for RREP authenticationRREQ

RREP

D: MD = MAC(KDS, RREP, S, D, id, ti, (A, B, C), (MA, MB , MC))

D→C: RREP, S, D, id, ti, A, B, C), (MA, MB , MC), MD, ()

C→B: RREP, S, D, id, ti, A, B, C), (MA, MB , MC), MD, (KC,ti)

B→A: RREP, S, D, id, ti, A, B, C), (MA, MB , MC), MD, (KC,ti, KB,ti)

A→S: RREP, S, D, id, ti, A, B, C), (MA, MB , MC), MD, (KC,ti, KB,ti , KA,ti)

Per-hop hashing(the target can authenticate each node in the node list of the RREQ)


ARIADNEroute maintenance and avoiding routing misbehavior

S

A B

D

Cdata packet X

RERR

• the sender authenticates the ROUTE ERROR packet by means of TESLA

• Ariadne chooses routes based on

their prior performance in packet

delivery

• End-to-end feedback is necessary

broken link


ARIADNEOther issues

� Ariadne is also protected from a flood of RREQsthat could lead to cache poisoning

• Benign nodes can filter out forged or excessive

RREQs

• Ariadne is also protected from intermediate nodes that fail to forward packets

• Ariadne chooses routes based on prior performance in

packet delivery

• Ariadne uses end-to-end feedback


SECURE ROUTING





• ARIADNE• ARAN [DLRS02]• SEAD


ARANOverview

� ARAN is an on-demand protocol based on AODV(route discovery, route maintenance)

� ARAN ensuresauthentication, integrity and non-repudiation and

protects from

modification, fabrication and impersonation

� ARAN uses digital signatures

Each node has a certificate signed by a CA (TTP) which

binds an IP address to a public key and a validity period

ARAN is subject to DoS


ARANRoute discovery

( )

( )( )( )( )( )( )

( )

( )( )

( )( )

* : , , , ,

* : , , , , ,

* , , , , ,

* : , , , , ,

: , , , ,

: , , , , ,

: , , , , ,

: , , , ,

S S

S AS A

S BS B

S CS C

D D

D CD C

D BD B

D

S RREQ D cert N t

A RREQ D cert N t cert

B RREQ D cert N t cert

C RREQ D cert N t cert

D C RREP S cert N t

C B RREP S cert N t cert

B A RREP S cert N t cert

A S RREP S cert N

→

→

→

→

→

→

→

→ ( )( ) , AD At cert

• source node: S

• destination node: D

• intermediate nodes: A, B, C

• For freshness

N: nonce, t: timestamp


ARANRoute maintenance

( )

( )

: , , , ,

: , , , ,

B B

B B

B A RERR S cert N t

A S RERR S cert N t

→

→

• Node B discovers that the link from itself to node C is broken, then

node B initiates route maintenance

• A node can be verified as the source of RERR(non-repudiation)

• A malicious node cannot generate RERR for other nodes


ARANCertificate Revocation

� CA broadcasts a revocation packet

• A node records the revoked certificate until it expires

• Any neighbour of the node with the revoked

certificate needs to reform routing excluding the

untrusted node

• When two nodes meet, they merge their revocation notices

revocation notices can be forwarded or broadcast as

needed


ARANCertificate Revocation: a Problem

CACA

The untrusted node is the sole connection between two parts of the network

This leads to a partition

The partition lasts until

• the certificate of the untrusted node expires or

• the node is no longer the sole connection between the two

partitions

revocation notice


SECURE ROUTING




• Secure ad-hoc routing algorithms• Packet leashes• SRP• TESLA

• ARIADNE• ARAN• SEAD [HJP02]


SEADOverview

� SEAD is based on DSDV

� Secure Efficient Ad hoc Distance vector (SEAD) is

robust against multiple uncoordinated attackers

creating incorrect routing state or

replaying routing state

� SEAD does not use asymmetric cryptography but

uses one-way hash functions to save CPU and

avoid DoS


SEADOverview

SEAD makes DSDV robust against

� lack of cooperation attack

� failing to advertise new routes

� ignorance attack

� modification attack

� modification of the metric, the sequence number, the

destination or the source address

� replay attack

� sending old advertising

SEAD does not cope with wormhole attacks


SEADSecurity measures

The objective is to authenticate route updates

Using asymmetric cryptography has disadvantages

• exposition to DoS

• Compromised nodes

• resource consumption

� SEAD uses the following mechanisms

• authentication of metric and sequence number

• authentication of neighbours


SEADAuthentication of metric and sequence number

m

n

oneone--way hash chainway hash chaingeneration →

← use

� upper bound to the network diameter is m−1

� n | m

h0 hn



sequence number (i)

metric (j) with km j

nh k i

m+

= −

h0 hn


SEADAdvertising a route

localhost, m: 0, sn: i, hkma node advertise a route to itself:

• the metric is 0

• sn is its sequence number

• the authenticator is authentic

(e.g. signed)

dst, m: j, sn: i, hkm+ja node advertises a route to some

destination

• dst is the address of the destination

• sequence number i and metric j are from

the node’s RT

• the authenticator is the one in the

advertisement from which the node

learnt the route



The use of hash chain prevents an attacker from advertising a route to some destination claiming

a greater sequence number or

a smaller metric

Each node receiving a route update can easily authenticate it, given any earlier authentic hash element from the same hash chain


SEADAuthentication of source of a route

The source of a route update must be authenticated or an attacker may be able to create routing loops

Alternative approaches

� Efficient broadcast authentication mechanisms(TESLA, HORS, TIK)

require synchronized clocks

� Shared key among each pair of nodes

(SEAD)

Cooperation

enforcement


THE NODE SELFISHNESS PROBLEMMain approaches

� The problem

• A selfish node does not cooperate in network operations, saving battery life for its own communications

• A small fraction of selfish nodes leads to a severe degradation of

network performance [MM02c]

� Solutions

• Currency based technique

�Nuglets [BH01]

• Local monitoring technique

�CONFIDANT [BLeB02a, BLeB02b]

�Core [MM02a, MM02b]

�Token-based approach [YML02]


NUGLETSGeneral concepts

Issues

� End-users must be given some incentive to cooperate in the network operation

� End-users must be discouraged from overloading the network

Idea

� introduction of a virtual currency, called nuglet, in

every packet transaction


NUGLETSThe Packet Purse Model: the idea

srcsrc

pkt

fwdfwd fwdfwddstdst

pkt pkt

The source loads the packet with nuglets

Each forwarding node takes out a nuglet for its forwarding service


NUGLETSThe Packet Purse Model: pros and cons

PROS

• End-users are discouraged from flooding

CONS

• The source needs to know exactly how many nugletsit has to include in the packet

• A forwarding node may take out more nuglets than they are supposed to do � tamper-proof hardware is necessary


NUGLETSThe Packet Trade Model

fwdfwd fwdfwd

pkt

fwdfwd fwdfwd

pkt

Each packet is traded for nuglets by the intermediate nodes

Each intermediate node buys the packet from the previous node in the path(the destination node has to pay for the packet)


NUGLETSThe Packet Trade Model: pros and cons

PROS

• The source end-user is not required to know how many nuglets need to be loaded in the packet

CONS

• packet generation is not loaded � malicious flooding is possible

• A forwarding node may deny the forwarding service after taking out the nuglets � tamper-proof hardware

is necessary


CONFIDANTGeneral concepts

� Malicious behaviour and non-cooperation should be punished and should not pay-off

� Detection has to lead to reaction

� isolation (from the network)

� re-socialization (reintegration in the network)

� Inspiration from The Selfish Gene by Richard Dawkins [D76]

reciprocal altruism is beneficial for every biological system when favours

are granted simultaneously


CONFIDANTNode architecture and behaviour


CONFIDANTMonitor

Monitor watches neighbours and

registers deviations from normal behaviour

• no forwarding (of route control packets)

• unusual traffic attraction

• route salvaging although no error has been observed

• lack of error messages although an error has been observed

• unusually frequent route updates,

• get proper responses (tampering with the message

header of either control or data packets).


CONFIDANTTrust Manager

Trust manager deals with incoming and outgoing ALARM messages

� Distributed trust management similar to PGP

• The trust level of an alarm is a weighted function of the

trust level of the senders of the related ALARM messages(none, unknown, marginal, complete)

• A list of friends to which ALARM messages are sent


CONFIDANTReputation System (continua)

Reputation system is responsible to maintain a qualityrating of participants

� A node rating is changed when there is enough evidence of malicious behaviour and it has occurred an exceedingly number of times

� Rating is a weighted function of the type of malicious behaviour detection

• Experience: greater weight

• Observations: smaller weight

• Reported experience: PGP trust level


CONFIDANTReputation System

� Rating table ⟨node, rating⟩

• Local black lists are exchanged with friends

• Black sheep's are included in route requests and alarm

nodes on the way

• Management of false accusation

• recovery of nodes that have behaved well for a specified

period of time


CONFIDANTPath Manager

� The path manager performs the following functions:

• Path re-ranking according to security metric

• Deletion of paths containing malicious nodes

• Action on receiving a request for a route from a

malicious node (e.g. ignore, do not send any reply)

• Action on receiving request for a route containing a

malicious node in the source route (e.g. also ignore, alert the source)


CONFIDANTConclusive remarks

� Confidant is vulnerable to concerted efforts of

spreading wrong accusations (in a later version Bayesian statistics were used for classification and

exclusion of liars)

� The limitation of Confidant lies in the assumptions for detection-based reputation systems

• Events have to be observable and classifiable for

detection

• Reputation can only be meaningful if the identity of each node is persistent


REFERENCES

(continua)[BLeB02a] S. Buchegger, and J.-Y. le Boudec, "Nodes Bearing Grudges: Towards Routing Security, Fairness,

and Robustness in Mobile Ad Hoc Networks," in Proceedings of the 10th Euromicro Workshop on

Parallel, Distributed and Network-based processing.

[BLeB02b] S. Buchegger, and J.-Y. le Boudec, "Performance Analysis of the CONFIDANT protocol," in

Proceedings of MobiHoc 2002.

[BH01] L. Buttyan, and J.-P. Hubaux, "Nuglets: A Virtual Currency to Stimulate Cooperation in Self-

Organized As Hoc Networks," Technical Report DSC/2001/01, Swiss Federal Institute of

Technology, Lausanne, 2001.

[CBH02] S. Capkun, L. Buttyan, and J-P Hubaux, “Self-Organized Public-Key Management for Mobile Ad-

Hoc Networks,” IEEE Transactions on Mobile Computing, Vol. 2, No. 1, January-March 2003, pp.

52−64.

[D76] R. Dawkins, The Selfish Gene, Oxford University Press, 1989 edition, 1976.

[DLRS02] B. Dahill, B. N. Levine, E. Royer, and C. Shields, “ARAN: A secure Routing protocol for Ad hoc

Networks,” University of Massachusetts, Technical Report no. 02-32, 2002.

[HPJ02] Y-C Hu, A. Perrig, and D. B. Johnson, “Ariadne: A Secure On-Demand Routing Protocol for Ad Hoc

Networks,” Proceedings of MOBICOM 2002.

[HJP02] Y.-C. Hu, D.B. Johnson, and A. Perrig, “SEAD: Secure Efficient Distance Vector Routing in Mobile

Wirelesess Ad Hoc Networks,” Proceedings of the 4th IEEE Workshop on Mobile Computing

Systems and Applications (WMCSA 02), pp. 3−13, 2002.


REFERENCES

[LL00] Haiyun Luo, Songwu Lu, “Ubiquitous and Robust Authentication Services for Ad Hoc Wireless

Networks,” Technical Report, UCLA-CSD-TR-200030, October 2000.

[MM02a] P. Michiardi and R. Molva, "Core: A Collaborative Reputation mechanism to Enforce Node

Cooperation in Mobile Ad Hoc Networks," in Proceeedings of IFIP Communication and Multimedia

Security Conference 2002.

[MM02b] P. Michiardi and R. Molva, "Game Theoretic Analysis of Security in Mobile Ad Hoc Networks,"

Institut Eurocom Research Report RR-02-070, April 2002.

[MM02c] P. Michiardi and R. Molva, "Simulation-based Analysis of Security Exposures inMobile Ad Hoc

Networks," in Proceedings of European Wireless Conference, 2002.

[PCST00] A. Perrig et al., “Efficient Authentication and Signing of Multicast Streams over Lossy Channels,”

Proceedings of the IEEE Symposium on Security and Privacy, pp. 56-73, 2000.

[RS99] M. Reiter, S. Stubblebine, “Authentication metrics Analysis and Design,” ACM Transactions on

Information and System Security, 1999.

[SA99] F. Stajano and R. Anderson, "The resurrecting Duckiling," 7th International Workshop on Security

Protocols, 19–21 April 1999, Cambridge, UK, LNCS 1796, Springer-Verlag 2000.

[YML02] H. Yang, X. Meng, and S. Lu, "Self-Organized Network Layer Security in Mobile Ad Hoc Networks,"

in Proceedings of the First ACM Workshop on Wireless Security (WiSe), 2002.

[ZH99] L. Zhou and Z. J. Haas, “Securing Ad Hoc Networks,” IEEE Network, November/December 1999.

Thanks for your Thanks for your

attention!attention!

security in ad -hoc networks - unipi.it › ... › slides › ad_hoc-security.pdf · gianluca dini...

Documents