Securing Every Bit: Authenticated Broadcast in Wireless Networks

1. Securing Every Bit: Authenticated Broadcast in Wireless Networks Dan Alistarh, Seth Gilbert, RachidGuerraoui, Zarko Milosevic, and Calvin Newport

2. The problem

3. 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!

4. 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.

5. 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.

6. 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

7. Plan • Introduction • RobustRB: the building blocks • FastRB: faster is better • Simulation and Performance • Conclusions

8. One-hop transmission

9. One-hop transmission The idea: the source broadcasts the message the receiver broadcasts back the message if the message received is the same as the one sent, then the source is silent otherwise, the source broadcasts a “veto” message and repeats The receiver replies with the veto If it receives a veto, the source repeats = source is silent ≠ message This procedure works because the adversary cannot turn the “veto” into silence.

10. The two-hop case Q: Is there a problem in this configuration? A: Kein Problem!

11. The two-hop case 1 1 Q: How about now? Fix: Append an alternating “sequence bit” to every message. A: There are problems when sending multiple messages.

12. 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.

13. The multi-hop case

14. 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]

15. RobustRB: multi-hop idea T = 1 Idea: A node waits to receive a message across T + 1 disjoint paths located in the same neighborhood.

16. 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?

17. Back to the drawing board… 6x 5x Yes, but this happens very rarely!

18. 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

19. FastRB Adjacent cells can communicate A node VETOes if it hears that a node in its cell broadcasts “suspicious” data

20. “Neighborhood Watch” Lemma: As long as there exists no cell that only contains “pirates”, no dishonest message is ever delivered.

21. FastRB

22. FastRB Observation: The protocol becomes more robust if it requires 2 or more cells to “vote” for the message.

23. 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

24. FastRB: Running time comparison

25. Plan • Introduction • RobustRB: the building blocks • FastRB: faster is better • Simulation and Performance • Conclusions

26. Success rate Note: In this case, density 1 means a device has an expected number of about 20 neighbors.

27. Resilience

28. Network designer’s perspective

29. 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

30. The slide to remember • Wireless networks can tolerate Byzantine faults without use of cryptography • The state-of-the-art optimally resilient solution (RobustRB) can be slow in practice • There is a solution (FastRB) that achieves good levels of fault tolerance, while ensuring low overhead

31. 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!