securing every bit: authenticated broadcast in wireless networks dan alistarh, seth gilbert, rachid...

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!