Zfone and ZRTP :: encryption for voip protocols
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:
>>>> "...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.
> 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