[guardian-dev] Blog post: VoIP Security Architecture

[Dominik Schürmann]

Hi,

I uploaded you one slide from a presentation I have done last year:
http://sufficientlysecure.org/uploads/zrtp.pdf

The sequence diagram is not 100% accurately ZRTP but it shows the basic
workings of ZRTP.
You have a Diffie-Hellman key exchange, but instead of exchanging at the
same time, it is sequential.
What's interesting: Bob "commits" a hash h_b using the public value y_B
and sends this hash _instead_ of sending the public value y_B itself
(in contrast to traditional diffie-hellman).
Then its normal diffie-hellman, Alice sends y_A and Bob now "reveals"
his previously committed y_B.
A shared secret s can be derived and a secure communication is
established (SRTP).
Now the channel is encrypted, BUT not protected against MitM attacker.
So now the SAS is calculated and both sides should read this SAS aloud
over encrypted SRTP to reveal if there was a MitM present during the key
exchange.

Okay, so what's really interesting here:
With traditional Diffie-Hellman the SAS would be a very long hash of y_a
and/or y_B, this would be impractical to read aloud.
Here comes the trick with committing a hash in the first roundtrip
instead of directly sending y_B:
An attacker would need to somehow recalculate y_B when h_B is send to
Alice. He would need to find a hash collision for example.
The attacker needs to do this, because later this committed h_B is part
of the SAS which is read aloud by Bob (sure the attacker can try to fake
the voice, but this is considered difficult).

Hope that clarifies the protocol.

there's a small bug on the slide: the secret s on Bob's side also uses
h_B (there is no h_A!)

Regards
Dominik

On 11/22/2013 09:03 PM, Lee Azzarello wrote:
> Hi Elijah,
> 
> How could the RTP channel be encrypted prior to key agreement through
> a verbal SAS confirmation? 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.
> 
> It seems that a good test would be to use the VoIP tools in Wireshark
> to attempt a RTP stream reconstruction between two peers who have
> never shared an SAS. Do you agree?
> 
> Best,
> Lee
> 
> On Fri, Nov 22, 2013 at 2:49 PM, elijah <elijah at riseup.net> wrote:
>> On 11/21/2013 04:11 PM, Lee Azzarello wrote:
>>
>>> Second, there is ZRTP. This protocol enters into the mix after a
>>> successful SIP dialog establishes a call session by locating the two
>>> endpoints. It transmits key agreement information over an RTP channel
>>> between the peers. The peers use their voices to speak a secret they
>>> read over a plaintext channel.
>>
>>
>> Perhaps you know something I don't, but it seems unlikely to me that short
>> authentication string exchange happens over a cleartext channel, as it would
>> defeat the purpose. ZRTP has a really cool property where you never need to
>> authenticate with the SAS, but if you do it once, you can be assured that
>> all your prior conversions were secure.
>>
>> -elijah
>> _______________________________________________
>> Guardian-dev mailing list
>>
>> Post: Guardian-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>
>> To Unsubscribe
>>        Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>        Or visit:
>> https://lists.mayfirst.org/mailman/options/guardian-dev/lee%40guardianproject.info
>>
>> You are subscribed as: lee at guardianproject.info
> _______________________________________________
> Guardian-dev mailing list
> 
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> 
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/dominik%40dominikschuermann.de
> 
> You are subscribed as: dominik at dominikschuermann.de
>