securing every bit: authenticated broadcast in wireless networks
DESCRIPTION
Securing Every Bit: Authenticated Broadcast in Wireless Networks. Dan Alistarh , Seth Gilbert, Rachid Guerraoui , Zarko Milosevic, and Calvin Newport. The problem. Authenticated Broadcast. N nodes distributed in an ad-hoc network - PowerPoint PPT PresentationTRANSCRIPT
Securing Every Bit: Authenticated Broadcast in Wireless Networks
Dan Alistarh, Seth Gilbert, Rachid Guerraoui,
Zarko Milosevic, and Calvin Newport
The problem
Authenticated Broadcast
• N nodes distributed in an ad-hoc network• A source node S has a message to distribute to
other nodes• Properties:– Reliable Broadcast: the message should be
distributed to all honest devices– Authentication: an honest device should accept
the message only if it originates at the source
Challenge: We need to do this
without cryptography!
Previous Results• Distributed Computing Theory:
– [Koo]: at most ≈ ¼ of nodes in a neighborhood may fail– [Bhandari, Vaidya]: optimally-resilient protocol– [Gilbert, Guerraoui, Newport]: bit-by-bit transmission is optimal in
the single-hop case• Applied Networking:
– Hubaux et al., Strasser et al. : Integrity codes, transmission via frequency hopping, MAC protocols
• The Cryptographers:– Lower bound by Boneh et al. : either synchronization or digital
signatures are required– Protocols: TESLA by Perrig et al.
Our results
We introduce two protocols that solve the problem, without employing any cryptography.
• RobustRB: optimally resilient, and asymptotically optimal in terms of running time.• FastRB: trades some resilience (in theory) for
vastly improved efficiency.
The model
• Nodes know their location, are synchronized and agree on a communication (TDMA) schedule in advance
• The adversary is Byzantine: – Crash failures– Jamming– “Spoofing” messages
• The adversary may cause collisions; however, receivers are always able to detect the collisions
• The energy of the adversary in a neighborhood is limited
Plan
1. Introduction2. RobustRB: the building blocks3. FastRB: faster is better4. Simulation and Performance5. Conclusions
One-hop transmission
One-hop transmissionThe idea:1. the source broadcasts the
message2. the receiver broadcasts
back the message3. if the message received is
the same as the one sent, then the source is silent
4. otherwise, the source broadcasts a “veto” message and repeats
5. The receiver replies with the veto
6. If it receives a veto, the source repeats
= source is silent
≠ messageThis procedure works because the adversary
cannot turn the “veto” into silence.
The two-hop case
Q: Is there a problem in this configuration?
A: Kein Problem!
The two-hop case
Q: How about now?
A: There are problems when sending multiple
messages.
Fix:Append an alternating “sequence bit” to every
message.
1
1
Recap
• So far, we know how to send a message securely over one hop in a multi-hop network
• The sender repeats the entire message every time it receives a veto
• [Gilbert, Guerraoui, Newport]: In this setting, the optimal strategy is to send the message bit-by-bit over one hop.
The multi-hop case
RobustRB
• Sending message across multiple hops, given authenticated single-hop transmission
• Based on a protocol by [Bhandari-Vaidya]• The protocol assumes that nodes know a bound
T on the number of malicious nodes in a neighborhood
• The protocol tolerates ¼ of nodes in a neighborhood to be malicious, which is optimal [Koo]
RobustRB: multi-hop ideaT = 1
Idea:A node waits to receive a
message across T + 1 disjoint paths located in the same
neighborhood.
Do we stop here?
• The protocol is optimally resilient• It is also asymptotically optimal in terms of
running time• How well does it perform in practice?
Map size 30 x 30 map 40 x 40 map
Robust RB 54.000 cycles 64.000 cycles
Simple Epidemic 342 cycles 380 cycles
Quotient 158 169
Back to the drawing board…
Yes, but this happens very rarely!
6x
5x
A new approach
• Insight 1: We trade some (theoretical) resiliency to make the protocol more efficient
• Insight 2: In many applications, the nodes are densely distributed
FastRB
1. Adjacent cells can communicate
2. A node VETOes if it hears that a node in its cell broadcasts “suspicious” data
“Neighborhood Watch”
Lemma: As long as there exists no cell that only contains “pirates”, no dishonest message is ever delivered.
FastRB
FastRBObservation: The protocol
becomes more robust if it requires 2 or more cells to “vote” for the message.
FastRB
• Uses the density of the network to keep byzantine nodes “in check”
• The resulting structure is a grid of “meta-nodes”, on which we may apply routing algorithms
• The protocol can be made more resilient by implementing a “voting” variant
• It is simpler to implement
FastRB: Running time comparison
Protocol 30x30 map 40x40 map 50 x 50 map
FastRB 2568 cycles 2970 cycles 3048 cycles
Simple Epidemic 342 cycles 380 cycles 400 cycles
Quotient 7.53 7.82 7.65
Plan
• Introduction• RobustRB: the building blocks• FastRB: faster is better• Simulation and Performance• Conclusions
Success rate
Note: In this case, density 1 means a device has an expected number
of about 20 neighbors.
Resilience
Network designer’s perspective
Evaluation
• The success rate of FastRB is superior, since it requires simple connectivity
• Both protocols are resilient to Byzantine adversaries, as expected
• If nodes are distributed uniformly at random, the FastRB protocol is at least as resilient as RobustRB
The slide to remember
1. Wireless networks can tolerate Byzantine faults without use of cryptography
2. The state-of-the-art optimally resilient solution (RobustRB) can be slow in practice
3. There is a solution (FastRB) that achieves good levels of fault tolerance, while ensuring low overhead
Tolerance calculations
• For the experiments, R = 4, so the expected number of neighbors of a node is 80.
• The parameter T = 3 means that at most 3 of these should be malicious, therefore the tolerance percentage should be 3 / 80 = 3.75%
• For FastRB, there are about 1.5 nodes/neighborhood
• The expected number of neighborhoods that are entirely malicious is around 10!