[Commotion-dev] SPAN Android App

[Robble, Jeff]

The packet layout helps clarify. 256-bit key addresses are used to
determine how to route packets between serval daemons in user space. IP
addresses are still used to send packets between devices over the wireless
interface.

I assume the "payload body" is the only part of each serval payload that's
encrypted and it's encrypted using only the final destination's public
key. Is that accurate?

You mention that the source IP address is used to only send a unicast
reply. I assume that a message with payloads destined for specific peers
(i.e. the message does not contain a broadcast) is sent via unicast to the
next hop. Is that accurate or are all messages broadcast over the wireless
interface, received by the serval daemon on each device, and filtered
accordingly? 

I'm trying to figure out if your version of OLSR is using IP addresses or
256-bit key addresses. Does serval perform a lookup on the next hop
256-bit key addresses to determine its IP address and then send the
message via unicast to that IP address?

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




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

>On Tue, Oct 16, 2012 at 9:04 AM, 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?
>
>A picture is worth a thousand words... The logical structure of our
>transmitted IP packets look something like this;
>
>[ethernet header; source MAC, dest MAC, ...]
>[ip / udp header; source IP, dest IP, source port, dest port, ...]
>[serval packet format version number]
>[transmitting device PK]
>[payload list;
>  [payload;
>    - original source PK
>    - final destination PK or broadcast identifier for de-duplication
>    - next hop PK
>    - payload length
>    - payload body
>  ],
>  ...
>]
>
>Though the wire format does have some space saving tricks for sending
>short abbreviations for PK addresses that are already known by both
>parties.
>
>When we receive a packet, we only use the source IP address to work
>out where to send unicast reply packets destined for the "transmitting
>device PK". And only if we're running in olsr mode or the transmitter
>is in a different network sub-net.
>
>We then look through the payload list for anything addressed to us as
>the destination or next hop address, and process and/or forward them.
>
>So yes, the network discovers public keys as it builds the routing
>table and communicates with other devices. So we can easily encrypt
>any packet with a PK destination over the network. But that doesn't
>mean we've authenticated anyone's identity or done anything to detect
>a man-in-the-middle attack.
>
>Public key verification is still best done in person. Though we are
>also looking at verification via an audio channel; relying on your
>brain's ability to do voice print verification of identity, while
>confirming the fingerprint of a shared secret.
>
>Eventually we may also implement key signing for building a web of trust.