[Commotion-dev] SPAN Android App

[Robble, Jeff]

Thanks for the clarification Jeremy.

So you're randomly generating a 256-bit key pair and using the public key
as the device network address. When you want to send data the serval
daemon encrypts it using the 256-bit IP address of the destination and
encapsulates it in a IP/UDP packet. Am I misunderstanding?

It doesn't seem necessary to exchange public keys at all since that
information is contained in the IP/UDP packet header.

Jeffrey Robble
Software Systems Engineer
The MITRE Corporation (Bedford)
Office: 781.271.2790






On 10/15/12 6:10 PM, "Jeremy Lakeman" <Jeremy.Lakeman at gmail.com> wrote:

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