Secure Routing for Mobile Ad-hoc Networks€¦ · Security in MANET Routing Outline 1 Mobile Ad-hoc...

Mobile Ad-hoc NetworksSecurity by Offline Initialisation

Security by BootstrappingConclusion

Secure Routing for Mobile Ad-hoc Networks

Arun Raghavan

Department of Computer ScienceIIT Kanpur

CS625: Advanced Computer Networks

Arun Raghavan Secure Routing for Mobile Ad-hoc Networks



Outline

1 Mobile Ad-hoc NetworksIntroductionMANET Routing ProtocolsSecurity in MANET Routing

2 Security by Offline InitialisationIntroductionExample: Ariadne

3 Security by BootstrappingIntroductionBootstrapping using SUCV

4 Conclusion




IntroductionMANET Routing ProtocolsSecurity in MANET Routing

Outline




4 Conclusion





Need

Often setting up an infrastructure is infeasibleDisaster reliefCommunity networks (OLPC)Military applicationsEnter MANETs





Challenges

No infrastructureWireless (duplicate, delayed packets)Mobility

Highly dynamic topology

Devices are usually resource-limited





Outline




4 Conclusion





Classification

Table-driven / Proactive

Nodes periodically share their routing information with allothersEvery node has routing information for the entire networkProblems w.r.t. efficiency, scalabilityDSDV, CGSR

On-demand / Reactive

First attempt at making a connection triggers RouteDiscoverySubsequently require Route Maintenance in case nodes ina route go downDrawback – setup time for first connection is highAODV, DSR, TORA





Example: DSDV

Table-driven protocolRemember Distance Vector routing?

And the count-to-infinity problem?

DSDV: Destination Sequence Distance Routing

Use sequence numbers to tackle count-to-infinityDestination node gives an even sequence number to itsown updatesIf a neighbour finds a destination down, sends updates withnext odd sequence numberNodes use routing information with the newest sequencenumber (or the one with the best metric if the sequencenumbers are the same)





Example: DSDV

Some optimisations

Send a “full dump” initially and incremental updatesperiodicallyMeasure average time between first and best updates foreach destination

Defer future updates for that time period





Example: Dynamic Source Routing

On-demand protocol

Route Discovery

Source broadcasts a “route request” message containing thedestination and a broadcast IDIf an intermediate node does not have a route, it forwards therequest, appending its own addressIntermediate nodes only forward the first instance of the requestthey seeThe destination gets the request with the list of intermediatenodes and sends back this list using the reverse route, or usinganother route requestThe source now does source routing using this path

Route maintenance

“Route error” messages for broken links and acknowledgments toascertain link status





Outline




4 Conclusion





Attacks

Routing disruption

Loop creationBlackholes (route all packets through self)Blackmail (force blacklisting of a node)Force suboptimal routingPartition the networkWormholes (require collusion, hard to tackle)

Resource consumption

Flood control messages




IntroductionExample: Ariadne

Outline




4 Conclusion





Introduction

First set of protocols assume some form of initialisationindependent of the ad-hoc networkSingle shared secret

One compromised node compromises the network

Trusted KDC

Introduces some infrastructureSingle point of failure

Asymmetric cryptography is an option

Expensive for low-capacity nodes

One-way hash chains





One-way Hash Chains

Used to authenticate messages from a senderWe are given a publicly known one-way hash function, HSender generates a random seed, x , and a set of n keysas follows

k0 = xki = H (ki−1)

Receivers are preconfigured with kn for each senderOne key per message – sender sends encrypted/signedmessage and keyMessages is valid if there if H j (key) is equal to somepreviously received key





Outline




4 Conclusion





TESLA

Every node has a one-way hash chainA node releases keys as per a commonly known scheduleRequires loose time synchronisation (upto ∆ drift)Let maximum end-to-end delay be τ

For each message, sender attaches a keyed MAC using akey that will be not be published before (τ + 2∆) time unitsfrom time of sendingReceiver verifies the TESLA condition

The key with which the message has been signed has notyet been publishedThe key will be disclosed soon enoughBuffers the packet and waits till the key is published





Ariadne

Ariadne is based on DSRAlso assumes pair-wise shared secrets for allsource-destination pairs (but can be done without)Route request

h0 = MACSD (msg)Source sends 〈src, dst , id , ti , h0, () , ()〉An intermediate node, X , verifies that ti is valid

hX = H (X , hX−1)MX = MACXti

(msg)

X sends 〈src, dst , id , ti , hX , (..., X ) , (..., MX )〉

Receiver can calculate h0, and can thus validate therequest (for the most part)





Ariadne

Route reply

Mdst = MACDS (msg)Receiver sends 〈dst , src, id , ti , nodelist , hashlist , Mdst , ()〉Intermediate nodes wait for Xti to be published and thenattach it the list at the endSource can now verify the destination MAC, and that ofeach node in the route

Route error

If a node finds the next hop is unreachable, sends a RouteError to the sourceAgain use Tesla for authentication〈sndr , dst , time, MAC, recentKey〉





Ariadne

Node in path might not return Route Error messages

Get feedback on received packets through somemechanismUse multiple paths, penalising low-reliability pathsIf an intruder is detected, include a “blacklist” in future routerequests

Route request floods

Attacker might flood the network with requests, since theseare only finally authenticated by the targetMaintain a separate TESLA chain for route requests, anddo authentication at neighbours




IntroductionBootstrapping using SUCV

Outline




4 Conclusion





Bootstrapping

Assuming prior initialisation might not be realistic

Not all nodes may be administered by a single body

Hybrid solution

Assume at most t nodes can be compromised(n, t + 1) Threshold Cryptography

Some nodes have to act as servers

PGP-like mechanismStatistically Unique and Cryptographically Verifiableidentifiers





Outline




4 Conclusion





Bootstrapping using SUCV

SUCV

Every node has a public-private key-pairAddress is a hash of the public key

Again built on DSRRoute request: source sends 〈src, dst , id , sig, pubkey , ()〉

Each intermediate node just appends itself to the list at theendDestination can authenticate the request

Route reply: destination sends〈route, src, dst , id , (a, b, ...) , sig, pubkey〉

Intermediate nodes cannot tamper, source can verify





Bootstrapping using SUCV

Route maintenance: intermediate node sends〈sndr , dst , sig, pubkey〉

Source can verify that the message originated at sndr

This mechanism can be used with SEAD, Ariadne, etc.Bugs?

Intermediate node can add arbitrary routes during routediscovery – maybe each intermediate node can append asignatureNeed timestamps and loose time-synchronisation toprevent replay attacks




Q&A

Thanks!




References I

Royer and TohA Review of Current Routing Protocols for Ad Hoc MobileWireless NetworksIEEE Personal Communications, 1999

Perkins and BhagwatHighly Dynamic Destination-Sequenced Distance-Vector(DSDV) Routing for Mobile ComputersSIGCOMM ’94

Johnson and MaltzDynamic Source Routing in Ad-Hoc Wireless NetworksMobile Computing, 1996




References II

Hu, et. al.Ariadne: A Secure On-Demand Routing Protocol for AdHoc NetworksMobiCom ’02

Bobba, et. alBootstrapping Security Associations for Routing in MobileAd-Hoc NetworksISR TR 2002


Secure Routing for Mobile Ad-hoc Networks€¦ · Security in MANET Routing Outline 1 Mobile Ad-hoc...

Documents

Transcript of Secure Routing for Mobile Ad-hoc Networks€¦ · Security in MANET Routing Outline 1 Mobile Ad-hoc...