ZRTP comments part 4: security (everything but SAS)

[EKR <ekr@xxxxxxxxxxxxxxxxxxxx>]

This message continues my comments on ZRTP, discussing everything but
the SAS mode. Although SAS is a key ZRTP feature, most of the issues
with SAS are generic, rather than ZRTP specific, so I'd like to
discuss them in a separate thread.


1. Key Continuity
Because initial authentication decisions can be expensive and inconvenient,
it's attractive to amortize those costs over multiple sessions. The classic
approach here is SSH, which establishes a static authentication key on the
first connection and then merely checks that the same key is in use in
the future. Thus, as long as the first authentication is safe, subsequent
authentications will be as well. ZRTP and DTLS-SRTP both include mechanisms
for providing this. 

There are two main approaches for providing this functionality:

- Have a static authentication key [this is what SSH and DTLS-SRTP do]
- Use secret keying material from connection n to authentication connection
  n+1 [this is what ZRTP does]

The mechanism used by ZRTP has two implications:
- Each device must have its own identity/key continuity information.
  I.e., if you call Alice with handset A, this authentication doesn't
  transfer to handset B, even if they have the same AOR and are
  owned by the same person. This is also embodied in the ZID.
- The state on each device evolves so that it is different between
  calls. 

1.1. False Forgetting/Impersonation [Pointed out by Dave McGrew]
When Alice calls Bob, even if she has called him before, there are two
cases in which ZRTP does not provide continuity of authentication.

  1. Bob (or Alice) is using a different handset.
  2. Bob's handset (or Alice's) has lost some of its dynamic
     state and no longer has the right secrets cached.
     For instance, there may have been a disk crash followed by
     a restore from backup, rolling back your state.
     Also, as noted in S 3.2, this may simply be normal cache expiry.

In practice, it's thus fairly normal for Alice to call Bob and be told
that there's no cached state and have to do a new SAS exchange (and
note that you must or you won't have any MITM defense at all.)
This is unpleasant, but can't be considered a security vulnerability in the
sense that you shouldn't have flashing red lights and alarms going off
on your phone. 

This facilitates the attacks described in S 4.1 because it makes
people used to doing SASes under conditions they don't understand and
so if you do have a workable active SAS attack you can mount it at
any time, not just at the first exchange. This attack can be mitigated
to some extent by making the key continuity information more stable,
as with SSH or DTLS-SRTP, but this would require major changes to
ZRTP.


2. Weak Use of Shared Secrets
In S 6.5, the secret exchange makes poor use of the secret
entropy. Because you are provided the secret hash in the DHPart1
message you can exhaustively search just that secret without having to
build in the others *or* the DH ZZ. This isn't a problem if the
secrets have high entropy, but if they have just made the problem much
easier. Say you had two secrets of entropy A and B. If the hashes
weren't transferred the cost would be A*B. Now it's A+B. A better
design would be for each secret to have an ID or to do the secret
handshake after you had a DH key to work with.


3. Security of Key Derivation Function
The KDF being used here is pure HMAC, which definitely isn't a
FIPS-approved KDF in any context. Note that there's no way to
generate encryption keys larger than the hash function you're
using. I doubt this KDF would get FIPS approval.

I also note that the KDF in S 5.5.4 differs from that in
draft-zimmermann-avt-zrtp-02. Here's the comparison:

-02:    s0 = hash(DHSS | s1 | s2 | s3 | s4 | s5)
-03:    s0 = hash(s1 | s2 | s3 | s4 | s5 | message_hash )

Based on Alan's "what changed" message it appears that this change was
made to fix a bid-down attack against ZRTP-02. Is that correct? I'd
be interested to see a description of that attack.


4. Security of Binding to SIP
Although ZRTP's value proposition is primarily that it works 
without touching the signalling, it offers two modes for 
cryptographically binding the signalling to the MPKM, both
described in Appendix A.

4.1. Pre-ZRTP Binding
The first mode utilizes secrets from the initial offer/answer as
additional secret input to the ZRTP computation (sigs, srtps). These
techniques don't really work that well.  sigs always comes from
material that's in the clear in the SIP dialog, so an attacker who
observed a SIP dialog in progress could attack this binding.

srtps either comes from an SDESCRIPTIONS exchange or a MIKEY exchange.
In the first case, you're again requiring confidentiality of 
the dialog. In the second case, you need to do a full MIKEY
exchange, which seems unlikely. 


4.2. Post-ZRTP Binding
ZRTP also offers a way for the signalling to pass an SAS value in
another SIP exchange after the ZRTP has completed (this can't be done
before because the SAS emerges from the ZRTP handshake).  One side
sends the SAS in an SDP in a new offer/answer exchange (i.e., a
reinvite.) Unlike the techniques described in 4.5.1, this works with a
signalling channel that has integrity even if confidentiality is not
provided.

Unfortunately, this binding mechanism is subject to an active attack.
Let's say that the attacker knows that you're trusting the signalling
and that you don't check the SAS (a presumably common occurrence.)  He
allows the first SIP exchange to go through, plus the ZRTP handshake,
but then blocks the re-INVITE. Because neither ZRTP nor the initial
offer/answer knows who would do a re-INVITE or whether it would occur
at all, there is no way for either side to know that there was an
active attack. The attacker can either simply remove the packet from
the network and let the re-INVITE time out or, if Identity but not
SIPS is in use, then he can inject a fake 200 OK (remember that
responses are not themselves integrity protected.)

-Ekr