Securing Every Bit: Authenticated

furiouserectAI and Robotics

Nov 21, 2013 (3 years and 8 months ago)

61 views

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!