[Commotion-dev] Serval security summary

Sun Apr 15 18:32:02 UTC 2012

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

After thinking about this a bit more, I'm not sure a session-specific
nonce would solve the problem.

Let's say Mallory wants to carry out a man-in-the-middle attack
against Alice and Bob, whose keypairs are (pubA, privA) and (pubB,
privB). Mallory generates two keypairs, (pubM1, privM1) and (pubM2,
privM2), and makes sure Alice gets pubM1 when she looks up Bob's key
and Bob gets pubM2 when he looks up Alice's. (I'm assuming that's
possible, because if Alice and Bob have a secure way to discover each
other's keys you don't need confirmation words at all.)

Now, when Alice tries to connect to Bob, they first exchange nonces.
Mallory gets in the middle and passes Alice's nonce (nonceA) to Bob
unchanged. When Mallory receives Bob's nonce (nonceB), she calculates
the words Bob will see (wB):

wB = words(nonceA, nonceB, pubM2, privB)
= words(nonceA, nonceB, pubB, privM2)

The words Alice will see (wA) will depend on the nonce Mallory returns
to Alice (nonceM):

wA = words(nonceA, nonceM, pubM1, privA)
= words(nonceA, nonceM, pubA, privM1)

Mallory searches for a value of nonceM such that wA = wB. If the
entropy of the confirmation words is 20 bits, she'll need to try an
expected 2^20 nonces before finding a suitable one to return to Alice.

So it seems to me that session-specific nonces transform an offline
attack into an online one, but they don't raise the cost of the attack
above the entropy of the confirmation words.

With ZRTP's hash commitments, on the other hand, the cost of the
attack is negligible but it's detected with very high probability.

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)

iQEcBAEBAgAGBQJPixQiAAoJEBEET9GfxSfM7nsH/0RHGdXoslL0mCtg7QTdXmp1
FyLcd2Cepk9TtTp8ckdDWko6N9H3rsTDmxi5JqJCD1F7QqI/oN9e5cdFd3xknhkS
8M8B7sMITjHRALJA/jg5nebl1lRUXIpfcyhbplmN84WseNB5Gn9N4BojYruU1n+v
yLNRPtF9GqBRD8xBnXRQiNvEZ4LS9C2uNdBuFbp5vZ6byobG/hQRCHXQjppX8tVb
WrZDThBjQdzmj3ax/KRRkFw34LUGlxI0z16U1HlKpY5EnHhpn7nAr/aty6DyNH7j
CSw4vXESjbjFnfB3o8jCwLER9P+mvdLI8Uk3rYzn3jHCJuu+cA4djLnUVenYBfs=
=Ids8
-----END PGP SIGNATURE-----