[Commotion-dev] Serval security summary

[Jeremy Lakeman]

Confirmation words are derived from the shared secret between 2 peers
which may also include a session specific nonce, this is not based
directly on their public keys.

A man in the middle attacker can't know the shared secret or the
encryption itself would be suspect.

The UI for the confirmation process could be built to generate an
infinite stream of words, displaying some kind of strength meter to
both parties and prompting them to take turns reading words. The
paranoid could keep reading for quite some time....


We want to build a network that can operate over multiple protocols,
requiring the simplest end user configuration, and the largest address
space for avoiding the birthday paradox.

Possible use cases include small access point based networks, using
the same 192.168.X.X address space, interconnected via bluetooth or
other radio interfaces that may not have IP addresses at all. Routing
between these separate private IP networks just wouldn't work, and we
can't expect our users to know how to resolve all of the potential
networking issues.

That's not to say that the overlay network couldn't be mapped directly
onto an IP network, utilising a service like DNS to map keys to global
addresses and/or public key hashes for host ID's in the FD/8 private
address space. But this implementation detail will be encapsulated and
hidden from any end user applications.

Although on a mesh network, it would be much better to map directly
onto layer 2 (ala batman adv. / TRILL) and skip IP routing tables
altogether as this will allow for a number of different routing tricks
that are impossible using something like olsr.

On Thu, Apr 12, 2012 at 2:23 AM, Michael Rogers <m-- at gmx.com> wrote:
> Hi Josh,
>
> Thanks for sharing this document. If I've understood the verification
> process correctly, it's missing an important step when compared with
> ZRTP. As I understand it, Serval does this:
>
> * Each party generates a long-term public/private key pair
> * Each party derives a shared secret from her own private key and the
> other party's public key
> * Each party derives some confirmation words from the shared secret
> * The parties verbally compare their confirmation words
>
> In contrast, ZRTP does this:
>
> * Each party generates an ephemeral public/private key pair
> * The parties first exchange the hashes of their public keys
> * Then they exchange their public keys
> * Each party derives a shared secret from her own private key and the
> other party's public key
> * Each party derives some confirmation words from the shared secret
> * The parties verbally compare their confirmation words
>
> Consider a man-in-the-middle attack against these two approaches. ZRTP
> only gives the attacker a single attempt to choose key pairs that will
> produce the right confirmation words. The attacker has to commit to the
> hash of the public key she'll send to each victim before she sees that
> victim's public key, so she can't know which confirmation words the keys
> will produce. The confirmation words can therefore have low entropy -
> for example, if the words have 20 bits of entropy, the attack will have
> less than one chance in a million of going undetected.
>
> In contrast, Serval (if I've understood correctly) gives the attacker
> unlimited attempts to choose key pairs that will produce the right
> confirmation words for a given pair of users. The attacker can generate
> key pairs offline before the users attempt to connect and try them
> against the users' public keys until she finds key pairs that produce
> matching confirmation words. To make such an attack infeasible, the
> confirmation words would need to have high entropy - and it takes a lot
> of dictionary words to reach 128 bits of entropy.
>
> A second issue is forward secrecy: if the shared secret is derived from
> long-term key pairs, the connection can be decrypted at any time in the
> future if one of the private keys is compromised. Using ephemeral key
> pairs (and securely deleting the private keys after deriving the shared
> secret) would avoid that problem.
>
> I'd also like to second Hans-Christoph's comment: it's not clear what
> benefit is provided by using public keys as overlay addresses. Why not
> use IP addresses for routing and public keys for end-to-end
> authentication, as in existing protocols?
>
> Cheers,
> Michael
>
> On 03/04/12 22:10, Josh King wrote:
>> Hi all,
>>
>> I just wanted to share out a document for discussion that I got a while
>> back and have been meaning to send out, namely a summary of some of the
>> security architecture that the Serval Project is working on for
>> Commotion. It's just a general summary at this point, but there will be
>> more forthcoming.
>>
>> One question that I wanted to pose is: the document doesn't talk much
>> about routing. Is there a sense of how routing is going to work in the
>> secure overlay network, or am I missing that in the document?
>>
>> Thanks to the Serval folks for providing this!
>>
>>
>>
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>
>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev
>