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

hop transmission
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 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
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
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!
Comments 0
Log in to post a comment