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!

The problem Figure 1. We need to deliver the message from the source S to the honest nodes (blue) in spite of the disruptive malicious adversaries (red).

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.Introduction 2.RobustRB: the building blocks 3.FastRB: faster is better 4.Simulation and Performance 5.Conclusions

One-hop transmission

The idea: 1.the source broadcasts the message 2.the receiver broadcasts back the message 3.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 ≠ message This 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 idea T = 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 size30 x 30 map40 x 40 map Robust RB cycles cycles Simple Epidemic342 cycles380 cycles Quotient158169

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

Observation: 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 Protocol30x30 map40x40 map50 x 50 map FastRB2568 cycles2970 cycles3048 cycles Simple Epidemic342 cycles380 cycles400 cycles Quotient

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

Jamming adversaries

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!