[Commotion-dev] SPAN Android App

[Robble, Jeff]

....

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


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






On 10/15/12 6:34 PM, "Robble, Jeff" <jrobble at mitre.org> wrote:

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