ZRTP shows improper security notification

[GoogleCodeExporter]

What steps will reproduce the problem?
===
1. both phones must enable ZRTP 
2. establish the call between the two phone, and ZRTP info will be shown on the 
right corner of the calling screen (see http://imgur.com/a/LhUJi#KSkJH)
3. check more info (in the sliding tab), you may see the SRTP status with using 
NULL cipher (http://imgur.com/a/LhUJi#dizYA)

What is the expected output? What do you see instead?
===
The NULL cipher means the voice/video stream is not encrypted.
However, the ZRTP info may give people the false confidence that their calling 
is secured.
ZRTP is the protocol to compute the keys for encryptions and authentications. 
After the keys are computed and no man-in-the-middle exists (checked by SAS), 
the keys are used for SRTP (not ZRTP) to protect communications. So it may be 
better to show SRTP status instead of ZRTP's, because if SRTP is successfully 
established, ZRTP should succeed too. 

What version of the product are you using? On what operating system?
===
0.04-00 r1297 (the newest version built from source?)
Galaxy Nexus ICS 4.0.2

Please provide any additional information below.
===
Thanks

Original issue reported on code.google.com by zhub...@gmail.com on 6 Mar 2012 at 10:47

[GoogleCodeExporter]

SRTP and ZRTP *backends* are two different things from implementation point of 
view..

The details infos doesn't show ZRTP status. It only shows the SRTP status : 
because SRTP backend is implemented inside pjsip while ZRTP is a plugin of 
media transport. Actually you're right, while ZRTP is establish it uses SRTP 
encryption, but from an implementation point of view, it's really two very 
different ways to get things encrypted.

SRTP way uses SDP to negotiate keys. It's maybe a language abuse, but for 
csipsimple ui, SRTP means SRTP using SDP to negociate as defined in 
http://www.ietf.org/rfc/rfc4568.txt. 
ZRTP uses in media key negociation. It relies on zrtp4pj and in the 
implementation it's very different from SRTP media adapter.

That's why the SRTP info in call details doesn't show the SRTP info of ZRTP, 
but only SRTP info reached from an rfc 4568 negotiation. It shows null if the 
info has been negociated through ZRTP (it's not raised to pjsip layer).

You have probably noticed, that it's not possible to activate both SRTP and 
ZRTP at the same time. It's the same reason. It's two separate backend 
implementation.

So if the call card show that ZRTP is up, ZRTP is normally actually up. 

You should check with wireshark/tcpdump instead of trusting a display info. 
This will be real great check if you want to be sure of what the app does :). 

If you are IT skilled you should not trust user interface to know if that's 
secured. 
If you are not IT skilled, trust implementors and any IT skills guys that will 
actually read the code and do actually real test by trying to see what are the 
packets sent by the device and that these packets are actually correctly 
encrypted.

Original comment by r3gis...@gmail.com on 6 Mar 2012 at 11:14

• Changed state: Invalid

[GoogleCodeExporter]

Thanks for your quick reply!

I got it now. The SRTP info is actually for the SRTP-alone option (which is 
disabled in my case), but not for the SRTP used in zrtp4pj. 
BTW I knew CSipSimple adopts pjsip and zrtp4pj, and zrtp4pj implements its own 
SRTP stack...

Maybe in future updates, you can remove that part of info when using ZRTP for 
avoiding confusions (like mine..). And maybe also force the user to choose one 
of No-encryption, SRTP and ZRTP (maybe put the three in a radio-type form).

Original comment by zhub...@gmail.com on 7 Mar 2012 at 1:07