Transcript An On-demand Secure Routing Protocol Resilient to Byzantine

An On-Demand Secure
Byzantine Routing
Protocol
David Holmer
Department of Computer Science
Presentation Outline
Introduction
Attacks & Byzantine Behavior
ODSBR
Results
Feel Free to Ask Questions Throughout the Presentation
Mobile Ad Hoc Wireless Networks
Non-centralized architecture - All nodes pass traffic
Advantages
Increased Coverage (overall range & less gaps)
Reduced Deployment Cost (less wired connectivity)
Rapid Deployment (self configuring & self healing)
Security Challenges
Collaborative nature
All nodes participate in routing - can we trust them?
Lack of physical security
Wireless broadcast medium - anyone can eavesdrop
Mobile devices highly susceptible to theft and tampering
Security is a Vital Component!
Publications
 WiSE 2002 – “An On-Demand Secure
Routing Protocol Resilient to Byzantine
Failures”
 SECURECOM 2005 – “On the
Survivability of Routing Protocols in Ad Hoc
Wireless Networks”
 MILCOM 2004 – “The Pulse Protocol:
 NDSS 2005 – “Secure Multi-hop
 INFOCOM 2004 – “The Pulse Protocol:
 INFOCOM 2005 – “Provably Competitive
Sensor Network Routing and Power Saving”
Energy Efficient Infrastructure Access”
 WONS 2004 – “High Throughput Route
Selection in Multi-rate Wireless Networks”
 IZS 2004 – “Swarm Intelligence Routing
Resilient to Byzantine Adversaries”
 WONS 2005 – “The Pulse Protocol:
Infrastructure Access”
Adaptive Routing”
 MONET Journal 2006 – “The Medium
Time Metric: High Throughput Route
Selection in Multi-rate Wireless Networks”
 ESAS 2006 – “Dynamics of Learning
Algorithms for the On-Demand Secure
Byzantine Routing Protocol”
Mobile Ad hoc Network Performance
Evaluation”
Most relevant to this talk
Other work
Basic Problem
Source
Destination
Shortest Path
Trusted Node
Fault Free Path
Correct Node
Adversarial Node
Presentation Outline
Introduction
Attacks & Byzantine Behavior
ODSBR
Results
Feel Free to Ask Questions Throughout the Presentation
Strong Attacks
Attacks
Insertion/Modification
Black hole
Wormhole
Flood Rushing
Denial of service
Black hole
Adversarial Properties
Single ~ Majority
External ~ Byzantine / Insider
Individual ~ Colluding
Wormhole
Byzantine Behavior
Significant research to protect against external
adversaries (traditional secret based exclusion)
However, authenticity and integrity do not provide
any guarantee about the legitimacy of actions
taken by authenticated / insider nodes
Attacks where the adversary has full control of an
authenticated device and can perform arbitrary
actions to disrupt the network
Byzantine Generals problem [Lamport – ’82]
Related Work
 Byzantine robustness for Wired Link State routing: [Perlman – ’88]
 Authentication and integrity: [Zhou, Haas – ’99]
[Hubaux, Buttyan, Capkun – ’01]
[Dahill, Levine, Shields, Royer – ’02]
[Hu, Perrig, Johnson – ‘02, ’01]
 Blackhole: [Marti, Giuli, Lai, Baker - ‘00]
[Papadimitratos, Haas - ’03]
 Wormhole: [Hu, Perrig, Johnson – ’03]
[Hu, Evans – ’04]
 Flood rushing: [Hu, Perrig, Johnson – ‘03]
 Majority do not address the Byzantine adversarial model
 Focus on individual attacks - no comprehensive solutions!
Presentation Outline
Introduction
Attacks & Byzantine Behavior
ODSBR
Results
Feel Free to Ask Questions Throughout the Presentation
On-Demand Secure Byzantine Routing
 Provides Survivable routing in a Byzantine environment
 Original version published in WiSe 2002 (>25 cites)
 Trust model
 Source and Destination are trusted
 Intermediate nodes are authenticated (PKI & Symmetric keys)
but not fully trusted
 Adversarial model
 Majority of colluding byzantine adversaries
 All routing attacks except - eavesdropping, resource
consumption, wormhole creation, other layers
 Our solution
 An on-demand routing protocol
 Link based reliability metric
 Bounded losses as long as there exists a fault-free path
 Avoids the need for Byzantine Agreement (costly & less capable)
ODSBR Protocol Overview
Route Discovery
with Fault Avoidance
Weight List
Discovered Path
Link Weight
Management
Byzantine Fault
Detection
Faulty Link
ODSBR Protocol Overview
Route Discovery
with Fault Avoidance
Weight List
Discovered Path
Link Weight
Management
Byzantine Fault
Detection
Faulty Link
Route Discovery
On-demand protocol
Finds a least weight path
Request flood
Request includes weight list and signature
Signature verified at every hop
Prevents un-authorized route requests
Route Discovery (cont.)
Response flood
Prevents response block attack
Path and weight accumulated hop by hop
Appends signature to response
Lower cost updates are re-broadcast
Every hops verifies the entire path
Prevents flood rushing/blocking attack
A min-weight path is always established
Path is not guaranteed to be fault free
Fault Detection Phase
Route Discovery
with Fault Avoidance
Weight List
Discovered Path
Link Weight
Management
Byzantine Fault
Detection
Faulty Link
Fault Detection Strategy
Probing technique using authenticated
acknowledgements
Naïve probing technique
Too much overhead per data packet!
Secure Adaptive Probing
Source
Destination
Success
Fault 1
Fault 2
Fault 3
Fault 4
Binary search = identified in log n faults
Trusted Node
Successful Probe
Successful Interval
Intermediate Node
Failed Probe
Faulty Interval
Probe & Ack Properties
Probes
Inseparable from data - listed on all packets
Integrity checked at each probe - HMAC
Enforces path order - reverse ordered HMAC list
Acks
Authenticated - HMAC
Single combined ack packet - individual HMAC
of entire ack packet so far added at each probe
Adversary can’t selectively drop some of the acks
Staggered timeouts - restarts ack packet
A node can’t incriminate any link but its own
Fault Identification
Fault Definition
Packet loss rate violates a fixed threshold
Excessive delay also causes packet loss
Identifies faulty links regardless of reason
Malicious behavior
Non-malicious malfunction
Adverse network behavior
Congestion
Intermittent connectivity
Link Weight Management Phase
Route Discovery
with Fault Avoidance
Weight List
Discovered Path
Link Weight
Management
Byzantine Fault
Detection
Faulty Link
Link Weight Management
Maintains a weight list of identified links
Faulty links have their weight doubled
Resets link weights
Timed by successful transmissions
Bounds average loss rate
Weight scheme provides “soft” avoidance
Minimal penalty for false positives
Network is never partitioned
Allows use of aggressive fault thresholds
Presentation Outline
Introduction
Attacks & Byzantine Behavior
ODSBR
Results
Feel Free to Ask Questions Throughout the Presentation
ODSBR Attack Mitigation
Injecting, modifying packets – HMAC
Replay attack – use of nonces
Flood rushing – protocol relies on the
metric, and not on timing information
Black hole – unreliable links are avoided
using metric
Wormhole – creation is not prevented, but
it is avoided using metric
Loss Bound Analysis
Network of n nodes of which k are
adversaries
Assume a fault free path exists
q    q  b  kn  log 2 l


Protocol bounds the number of packets
lost communicating with the destination
Byzantine Attack Simulation
Simulated attacks:
Black Hole
Wormhole
Super-Wormhole
Flood Rushing
Random & Strategic
Adversary Placements
AODV Simulation Summery
Black Hole
100
Wormhole Random
Delivery Ratio (%)
90
80
Black Hole Rushing
70
Super-Wormhole Random
60
Wormhole Random Rushing
50
40
Super-Wormhole Random
Rushing
Central Wormhole
30
Central Wormhole Rushing
20
Cross of Death Wormhole
10
0
0
2
4
6
Number of Adversaries
8
10
Cross of Death Wormhole
Rushing
Complete Coverage
Complete Coverage Rushing
ODSBR Simulation Summery
Black Hole
100
Black Hole Rushing
Delivery Ratio (%)
90
80
Wormhole Random
70
Wormhole Random Rushing
60
Super-Wormhole Random
50
Super-Wormhole Random
Rushing
Central Wormhole
40
30
Central Wormhole Rushing
20
Cross of Death Wormhole
10
0
0
2
4
6
Number of Adversaries
8
10
Cross of Death Wormhole
Rushing
Complete Coverage
Complete Coverage Rushing
Conclusion
On-demand routing protocol resilient to a
wide range of colluding byzantine attacks
Adaptive probing scheme identifies faulty
link location without Byzantine
Agreement
Bounded long term loss rate =
guaranteed correctness in any network
Excellent performance in a myriad of
practical scenarios
Experimental Lessons Learned
Most important factors:
Flood rushing
Strategic positioning
Quantify the relative strength of different attacks
ODSBR
able to mitigate wide range of Byzantine attacks
not significantly affected by flood rushing
performance decreased when a large number of
adversarial links exists
ODSBR - simulation
[ACHR - SecureComm05]
Implementation + simulation:
NS2 network simulator
50 nodes randomly placed within a 1000 x 1000
meter square area
In addition, 0 to 10 adversarial nodes were
added
Random way-point mobility model
A traffic load of 10 CBR flows
ODSBR vs. AODV
Black Hole
Attack
An attacker lies along the selected path
The attacker passes routing control traffic
correctly (route request, response, acks, etc.)
However it drops or corrupts data traffic
Strong variants may do this adaptively to avoid
detection
Source
Destination
Black Hole
ODSBR Defense
Secured acks detect ANY damage of data flow
Adaptive probing localizes the damage to one of
the adversaries links
Weight of adversarial link is increased allowing
correct path to be found
Source
Destination
Black hole attack + Flood Rushing
AODV 0 m/s
ODSBR 0 m/s
1 m/s
1 m/s
5 m/s
5 m/s
10 m/s
10 m/s
100
Delivery Ratio (%)
90
80
70
60
50
40
30
20
0
2
4
6
Number of Adversaries
8
10
Worm Hole
Attack
Two attackers establish a path and tunnel
packets from one to the other
The worm hole turns many hops into one virtual
hop creating shortcuts in the network
This allows a group of adversaries to easily draw
in packets and drop them
Source
Destination
Worm Hole
ODSBR Defense
Worm hole creation is not prevented
Impossible without assumptions about links and/or
additional non-standard hardware/information
Worm holes are “benign” unless they disrupt
data flow
Worm hole “link” can be identified and avoided
Source
Destination
Wormhole attack: random placement
10 m/s
10 m/s
5 m/s
5 m/s
1 m/s
1 m/s
AODV 0 m/s
ODSBR 0 m/s
100
Delivery Ratio (%)
90
80
70
60
50
40
30
20
0
2
4
6
Number of Adversaries
8
10
Central wormhole simulation
AODV-normal
ODSBR-normal
AODV-worm
ODSBR-worm
AODV-worm-rush
ODSBR-worm-rush
100
Delivery Ratio (%)
90
80
70
60
50
40
30
20
0
1
2
3
4
5
Speed (m/s)
6
7
8
9
10
Complete Coverage simulation
AODV-normal
ODSBR-normal
AODV-worm
ODSBR-worm
AODV-worm-rush
ODSBR-worm-rush
100
Delivery Ratio (%)
90
80
70
60
50
40
30
20
0
1
2
3
4
5
Speed (m/s)
6
7
8
9
10
Flood Rushing Attack
exploits flood duplicate suppression
authentication doesn’t help
can result in many adversarial controlled paths
ODSBR Defense:
hop-by-hop authentication
process all duplicate flood packets and rebroadcast
lower metric valid flood packets
Byzantine Wormhole attack
Adversary
Adversary
wormhole
Source
• ODSBR Defense:
– wormhole formation is not prevented
– wormhole will be detected and avoided
Destination
Super-Wormhole
a more general (and stronger) variant of the
wormhole attack
several adversaries collude and form an overlay
of Byzantine wormholes
for n adversaries, it is equivalent to n2
wormholes
ODSBR - continued
Fault = any disruption that causes
significant loss or delay in the network
End-to-end ACKs
Reliability metric based on past history
Faulty links are identified using an
adaptive probing technique, and avoided
during the secure route discovery
Maximum damage that can be caused by
adversaries is bounded:
q- -   q+  b  kn  log2n
Black Hole + Flood Rushing
Black Hole = Adversary selectively drops
only data packets, but still participates in
the routing protocol correctly
Flood Rushing = takes advantage of the
flood suppression mechanism
Simulation:
Black hole: drop all data packets
Flood rushing: ignore broadcast delays
Overhead – non-adversarial scenario
AODV
ODSBR
Overhead (packets / second)
60
50
40
30
20
10
0
0
1
2
3
4
5
Speed (m/s)
6
7
8
9
10
Overhead – attack scenario
AODV-BH
AODV-SW
ODSBR-BH
ODSBR-SW
Overhead (packets / second)
25
20
15
10
5
0
0
2
4
6
Number of Adversaries
8
10
Analysis
for a good path
# Losses – (# Gains ) X LossRate < 0
We get
# Losses – (# Gains ) X LossRate < delta
Delta = #nodes X # adv X log ^2 #nodes
Link Weight Management
Maintains a weight list of identified links
Faulty links have their weight doubled
Resets link weights
Timed by successful transmissions
Bounds average loss rate
Network is never partitioned
1
1
1
1
1
1
On-Demand vs. Proactive Routing
Security Concerns
On-Demand
Source Authentication
Caching presents adversarial opportunity
Pro-active
Harder to secure since pieces of information
can not be traced back to a single source.
Black Hole Attack
Problem: Adversary may delete a packet
How do we detect and avoid black holes ?
Reliable node may be blamed
Detecting failing node: Consensus costs ($)
a
b
a
b
X
X
c
c
Worm Holes
Two attackers establish a path and tunnel
packets from one to the other
The worm hole turns many adversarial hops into
one virtual hop creating shortcuts in the network
This allows a group of adversaries to easily draw
packets into a black hole
Source
Destination
Flood Blocking
Flood Blocking Attack
Adversary propagates a false short path
Intermediate nodes do not forward “inferior”
valid path information
Source ignores the false path
No path is established
Path must be verified at intermediate
nodes
Fault Detection Strategy
Probing technique using authenticated
acknowledgements
Naïve technique
D
Receiving an ack from every node overly
costly!
OLD Route Discovery
On-demand protocol
Bi-directional flood
Request
Response
Request flood
Source includes weight list and a signature
Request verified at each hop
OLD Probe & Ack Specification
Probes
List of probes attached to every packet
Each probe is specified by an HMAC
Probes listed in path order
Remainder of probe list is onion encrypted
Ack
Authentication via HMAC
Collected and onion encrypted at each probe
point
Thank You!
Questions??
Authors
Baruch Awerbuch, Reza Curtmola,
David Holmer,Herbert Rubens
Cristina Nita-Rotaru
Johns Hopkins University
Department of Computer Science
Purdue University
Department of Computer Science
{baruch, crix, dholmer, herb}
@cs.jhu.edu
[email protected]
http://www.cnds.jhu.edu/archipelago