[guardian-dev] Blog post: VoIP Security Architecture

[elijah]

On 11/22/2013 12:03 PM, Lee Azzarello wrote:

> How could the RTP channel be encrypted prior to key agreement
> through a verbal SAS confirmation?

None of the session encryption keys are derived from the SAS. It is the
other way around. Both the session encryption keys and the SAS are
derived from the result of the unauthenticated DH exchange (in the case
of the first time contact) or preshared key (in some cases where you
have talked previously).

Failing the SAS doesn't do anything except alert you that you are
probably being MiTM'ed.

From
http://zfoneproject.com/docs/ietf/rfc6189.html#SASVerifiedFlag:

> A user interface element (i.e., a checkbox or button) is needed to
> allow the user to tell the software the SAS verify was successful,
> causing the software to set the SAS Verified flag (V), which
> (together with our cached shared secret) obviates the need to perform
> the SAS procedure in the next call. An additional user interface
> element can be provided to let the user tell the software he detected
> an actual SAS mismatch, which indicates a MiTM attack. The software
> can then take appropriate action, clearing the SAS Verified flag, and
> erase the cached shared secret from this session. It is up to the
> implementer to decide if this added user interface complexity is
> warranted.

In effect, the SAS is just an after the fact authentication of the 
unauthenticated DH, and it is up to the application to decide how to 
handle a SAS mismatch.

> It's my understanding that the 1st time two peers agree on a key the
> RTP channel is in the clear. No prior keys exist so no hash can be
> transmitted for the DH exchange. It is also my understanding that the
> nth time these peers communicate the RTP stream is never in the
> clear. The spec describes the probability of a MitM attack's success
> on the nth time as mathematically impossible unless the 1st SAS was
> middled.

Sure, DH exchanges are usually in the clear, since it is a bootstrap 
after all. But after the first DH, the next call usually uses a cached key.

-elijah