[Commotion-dev] Serval security summary

Thu Apr 12 00:43:14 UTC 2012

I'm curious why serval wants to avoid proven end-to-end crypto like
ZRTP, OTR, OpenPGP.  Admittedly, they have historically not been easy to
use, but OTR is proven easy and reliable.  ZRTP is recently gotten easy
in CSIPSimple for Android, as well as other apps like Twinkle for KDE.
And OpenPGP has recently gotten much easier on the desktop with
Enigmail/Thunderbird, GPGTools/Apple Mail, etc.

These protocols also have the big advantage of working regardless of
whether all users are on the mesh overlay network or not.  So for
example, if the mesh network has routes to the internet, secure
messaging can happen with any OTR or ZRTP client.

The two key issues that need to be addressed in the mesh that I can see are:

1) preventing mesh nodes from injecting bad route information

2) anonymizing the traffic on the mesh

.hc

On 04/11/2012 07:20 PM, Jeremy Lakeman wrote:
> 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
>>
> 
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev
> 