Zfone and ZRTP :: encryption for voip protocols

Alex Pankratov ap at hamachi.cc
Fri Mar 17 22:27:33 EST 2006

That's not what I described. An attacker uses his own ZID
and valid shared secrets that he creates with A and B on
some prior occassion. In other words -

* M talks to A as himself. This creates cached AM secret.

* M talks to B as himself. This creates cached BM secret.

* M intercepts A-B handshake and completes each 'leg' of
  the handshake using his own ZID and above secrets.

Since responder's ZID in not a part of a hash in Commit,
this key exchange will complete just fine.

I don't see the draft talking about how/if ZIDs might be
linked to non-ZRTP peer's identities, so I can't see how
A or B can actually discover that they've been MitM'd by
M *unless* they do SAS check. They do however see that KE
used cached shared secret, and they (being humans) are
likely to skip SAS check because of that.


Philip Zimmermann wrote:
> An attacker can easily present the wrong ZID, but he will not possess 
> the cached shared secrtes held by the real owner of that ZID.  The  user
> interface will tell the user that there are no shared secrets,  which
> means he must reverify the SAS.  Thus, his attack will fail.
> On Mar 17, 2006, at 4:21 PM, Alex Pankratov wrote:
>> Damien Miller wrote:
>>> On Wed, 15 Mar 2006, Ed Gerck wrote:
>> [snip]
>>>> "...allows the detection of man-in-the-middle (MiTM) attacks by
>>>> displaying a short authentication string for the users to read and
>>>> compare over the phone."
>>>> Depends on the trust model. May not work.
>>> This is incomplete. The paragraph goes on to say:
>>>> we still get fairly decent authentication against a MiTM attack,  based
>>>> on a form of key continuity. It does this by caching some key  material
>>>> to use in the next call, to be mixed in with the next call's DH  shared
>>>> secret, giving it key continuity properties analogous to SSH.
>> Here's a quote from the draft -
>>>  We use an analogous baby duck security model to authenticate the DH
>>>  exchange in ZRTP.  We don't need to exchange persistent public keys,
>>>  we can simply cache a shared secret and re-use it to authenticate a
>>>  long series of DH exchanges for secure phone calls over a long  period
>>>  of time.  If we read aloud just one SAS, and then cache a shared
>>>  secret for later calls to use for authentication, no new voice
>>>  authentication rituals need to be executed.  We just have to  remember
>>>  we did one already.
>> The draft says that shared secrets are keyed by ZID when stored
>> in a local cache, where ZID is a unique persistent random ZRTP
>> endpoint ID.
>> Unless I am missing something, ZIDs exchanged by peers during a
>> handshake remain unauthenticated. This means that if both A and
>> B have cached shared secrets with M, then M can mount MitM
>> attack against A-B session and both A and B will be under the
>> impression that they are protected by 'key continuity' from
>> their previous (A-B) session.
>> Their SAS won't match of course, but since they see shared secret
>> being used for KE, they are not likely to bother with SAS check.
>> Alex
> ----------------------------------------------
> Philip R Zimmermann        prz at mit.edu
> http://philzimmermann.com  tel +1 650 322-7223
> (spelled with 2 n's)       fax +1 650 322-7877

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

More information about the cryptography mailing list