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.

Alex

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