[Commotion-dev] SPAN Android App

[Jeremy Lakeman]

On Tue, Oct 16, 2012 at 4:04 AM, Robble, Jeff <jrobble at mitre.org> wrote:
> Serval does a decent job with security; however, it seems that for each
> device they randomly generate a public/private key pair such that the public
> key is an IPv4 address they statically assign to that device. While the
> probability is low that there will be IPv4 address collision in a class C
> subnet, there is still a possibility, and that doesn't sit right with me.

There's a good reason that doesn't sit right, because we aren't doing
that at all. Sure we assign a random IPv4 address, but that has
nothing to do with our security layer. Note that the following
description refers to the upcoming 0.90 version, version 0.08 just
uses BATMAN or olsr with unencrypted network packets.

We're generating 256-bit ECC key pairs and using those as network
addresses. That doesn't mean we're putting public keys in standard IP
headers. We've basically written an entire network stack in user-space
with our own payload forwarding protocol that we encapsulate into
IP/UPD packets. And send them between instances of our servald daemon,
acting as routers.

When you send a payload via MDP, you address it to a 256-bit public
key and hand it over to your local servald daemon. This daemon
encrypts the payload, adds it to a queue, works out which neighbour to
use as the next hop, then stuffs a number of small payloads going to
the same broadcast/unicast address into an IP/UDP packet to reach that
neighbour.

In that respect, MDP behaves more like a many-to-many VPN that doesn't
(yet) have a tap/tun virtual interface.

Note that I've also done some work recently to support a small number
of servald daemon's operating on a larger olsr network. Essentially we
have a mode where servald will send mesh-wide flood messages, like
phone number lookup requests, via an olsr plugin. Servald will use
receipt of those messages to discover the unicast addresses of other
servald nodes on the network. From then on we can send encrypted
payloads, like phone number / public key responses or voice call
payloads, directly across the mesh.

I'm also extending the work I did for olsr, supporting unicast
destinations in servald's routing table, to build Serval's first piece
of infrastructure. An opt-in dns like global directory of phone
numbers, public keys, and current internet addresses. Some time in the
future, you will be able to use Serval to place phone calls over the
internet, or send any other kind of encrypted payload to anyone in the
world. And all you'll need to know is their phone number or public
key.