[Commotion-dev] Serval security summary

Thu Apr 12 15:11:31 UTC 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jeremy,

Thanks for the reply. I didn't mean the attacker could discover the
shared secret - rather, the attacker establishes her own shared secret
with each victim, using key pairs that are chosen to generate matching
confirmation words when combined with the victims' public keys.

ZRTP prevents such attacks by forcing the attacker to commit to the
key pair she'll use with each victim before seeing the victim's public
key.

A session-specific nonce sounds like it might also prevent the attack
- - could you describe how the nonce is used?

Generating an infinite stream of words is a cool idea, though I wonder
how many people have the patience to reach a decent level of entropy.
The nice thing about ZRTP's approach is that you can get high security
with only a few words.

For Briar we're assuming even less patience on the part of the users -
instead of asking whether the confirmation codes match, we generate
two codes. Each device displays one and prompts for the other, so
impatient users like me can't skip the confirmation step by hitting 'Yes'.

Cheers,
Michael

On 12/04/12 00:20, 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
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJPhvCjAAoJEBEET9GfxSfM20wH/jn46QYLpCefvsLVW8uPFxpc
EL/oCHaWg7ZlOjjQj65A0YHlzW4W5//rS01eB/ivi/2mWPBKMOSDytOuAhBNrhz8
pW7aUBpjZq/j32UcduxTgjte8QNe4C5CmuliNuJtFsIDDr34SjtEqqWeqYWtL6LY
8qCZsvSaJIwrFYEiJuiO+Vx1Q9eGxR0KzfiGqxTeR4w1qy0q48U2MVH6nJtoXCvJ
WbQfpWKgea4nekwRnSroqSXRb+uiwO6+9wx/v8zTkH2CS5A7yNxsasYDQE51uXR9
JKVKKciP9BC+Ii7sYsiLe1LmVQJlt55UB7amfpLDHj3FxtCddCC5ZTgczSu5UIc=
=ecPh
-----END PGP SIGNATURE-----