[Commotion-dev] Serval security summary

[Michael Rogers]

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