#262 Add support for ZRTP

[Anonymous]

Originally created by: wheresau...@lavabit.com
Originally owned by: r3gis...@gmail.com

Not a bug - enhancement

please add ZRTP support this allows for a more secure handling of handset to handset key exchanges.   Two linux softphones I know of built on pjsip allow SRTP and ZRTP, allow using them at the same time.

other pjsip implementations:
http://www.sflphone.org/
http://twinklephone.com/

[Anonymous]

Originally posted by: nilsjan...@gmail.com

sorry, i used the usual nightlies...

[Anonymous]

Originally posted by: werner...@googlemail.com

@regis (51):
Regis is right. Othe client that support ZRTP just have an enable check box. If
checked then ZRTP tries to negotiate the security data with the other client. If
the othe client also support ZRTP - bingo, secure connection will be established. If
the other partner does not support ZRTP then the ZRTP implementation switches to
listening" mode to see if the other partner sends a ZRTP Hello to announce that it
is willing to negotiate SRTP keys.

You may announce in the SDP that your client supports ZRTP (I need to look if this
is avaiable for pjsip). However, some operators/ISPs/SIP providers block SIP INVITE
if they see an unknown SDP header or they block SIP INVITE if the SDP is not what
they like :-) .

Best regards,
Werner

[Anonymous]

Originally posted by: werner...@googlemail.com

Just a remark to Regis and other that like to build CSipSimple from scratch
or like to use pjsip (pjsua infact) together with ZRTP:
Unfortunatly Benny (the mainatiner of Pjsip) did not include an important feature
in the latest release of pjsip (even it was announce for this release). When you
like to use ZRTP together with PJSUA you must apply a patch (it's a small patch)
that allows an application to enable the ZRTP transport in pjsip/pjsua.

Best regards,
Werner

[Anonymous]

Originally posted by: wheresau...@lavabit.com

Great stuff, just tested on two csipsimple devices attached via freeswitch zrtp pop ups are working! thanks r3gis and werner for all the hard work!

had to enable proxy media
http://wiki.freeswitch.org/wiki/Proxy_Media

[Anonymous]

Originally posted by: nilsjan...@gmail.com

regis, when do you think will this get into the stable version? and what is the seperate tls version for?

[Anonymous]

Originally posted by: r3gis...@gmail.com

It will be included in stable version as soon as I introduce the way to download separately a .so lib (or as a third party application). It's not included in normal version cause TLS build include lib openssl (cause that's not in android NDK), and it make the size of the app twice bigger.
My goal is to have it as a "module" of the app.
It could be either by downloading directly the .so file, but after thinking a lot about that I think that a better idea would be another app that bring the relevant .so files.
I'll have the same problem for the video (that should also be distributed as a plugin).
The way it's managed for themes apps is not so bad I think (with a link in the app to find Themes and Plugins).

For now the only thing I'd have to solve conceptually with this approach is the way to update things (should not be so difficult) and second point the way several plugins could work together (probably some plugins such as TLS that requires to rebuild the entire stack may not be considered as plugin but as "core" and would not be compatible with other "cores".

Then I'll start to make a proof of concept of this "modular" approach and include it in future versions.

A could thing would have been to have pjsip really modular regarding TLS but AFAICT it's not currently easy to do.

[Anonymous]

Originally posted by: nilsjan...@gmail.com

that sounds good. perhaps link to the tls version from https://code.google.com/p/csipsimple ?

best,

nils

[Anonymous]

Originally posted by: nilsjan...@gmail.com

@werner, do you know the min. cpu power needed for zrtp on android?

[Anonymous]

Originally posted by: nilsjan...@gmail.com

did anybody try it via gprs/edge/umts?

for me it currently only works via wifi, but that could be the fault of my mobile provider blocking sip...

[Anonymous]

Originally posted by: wheresau...@lavabit.com

yes, the key exchange does not seem to be happening over 3G but works great over wifi!  3G still connects the call with no SAS(zrtp exchange) message.  r3gis think this could be application somewhere?

[Anonymous]

Originally posted by: r3gis...@gmail.com

Issue 1153 has been merged into this issue.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Issue 1152 has been merged into this issue.

[Anonymous]

Originally posted by: werner...@googlemail.com

@issue 1152:

After ZRTP exchanged keys with both sides it starts the secure connections (SRTP)
immediately. The SAS confirmations is independent of this - one may chosse never
to verify and confirm SAS with the other side. In such a case I strongly recommend
to check the SAS with the other side verbally. Once this was done and was ok you
may click SAS verify and ZRTP implementation remembers this and can perform
additional checks on the next key exhanges and issues warnings if it detects
something is wrong. If SAS was verfied and ZRTP does not reports any warning during
the next key exchanges then no Man-in-the Middle occured and security is ok.

[Anonymous]

Originally posted by: werner...@googlemail.com

@comment 62:

Sorry no. What I did to reduce CPU consumption was: enable elliptic curve
Diffie-Helman public key exchange as default. This requires much less CPU power
than finite-fiel DH while more secure (win-win, isn't it :-) )

@comment 63 and 64

Sometimes 3G operators filter RTP packets that are not _real_ RTP. ZRTP uses the
RTP connection to exchange data and use a RTP format, but these are not _real_
RTP packets. To check this someone should use Wireshark to analyse the real
data traffic and check whether or not ZRTP packets make their way thru 3G
connections.

I cannot check 3G because I don't own an Android device.

Just a note here:
in comment 64 I read: ...still connects the call with no SAS message... . As said,
I can't give a response here how CSipSimple implemented the GUI for ZRTP. Other clients that support ZRTP usually display a small textfield that contains the 4-char
SAS and a check-box to "verify" the SAS with ZRTP (see comment 67). A client
may also show which crypto algorithms are active in SRTP. The SAS shall be shown as
soons as secure call was established (ZRTP uses a callback to inform the GUI).

[Anonymous]

Originally posted by: r3gis...@gmail.com

About last point, I did a very recent change to improve this point. It's still not yet perfect and I'll try to add your advise on issue 1153 to improve how it's integrated.

For reference, what is expected now is :
when call is secured it show "ZRTP : SAS" with a little icon on the top right of the call card. If SAS has to be verified, it shows an alert that one can accept to verify it (previously it was asking each time - now it does only if it has actually to be verified).
Except from pure UI issues, there is also still something I have to solve on my side. That's more complicated to manage and should allow multiple calls with ZRTP. (It's about the way the UI store the reference to the zrtp transport... that's not so easy to manage with JNI on the middle ;) ).

[Anonymous]

Originally posted by: a...@privatemail.lv

can you please list the ZRTP-enabled SIP servers that you were able to use to establish a ZRTP connection successfully between two CSipSimple clients?

When switched "Create ZRTP" On (and SRTP off, or any other choice), the call is started and ended immediately on 2 of the servers I checked (Kamailio and FreeSWITCH).

Thanks!

[Anonymous]

Originally posted by: werner...@googlemail.com

There are no specific SIP servers that handle ZRTP because this is not required. ZRTP
is a protocol that negotiates the keys that are required to setup a SRTP context and
does this via the RTP session (usually the audio connection). Thus no SIP involved.
ZRTP starts it's negotiation as soon as the first media session is ready.

ZRTP uses it's own underlying SRTP - thus if you like to use ZRTP please switch off
the other SRTP which uses a  specific SIP mechanism to exchange the SRTP keys.

When I test ZRTP I use kamaillio (openSER) as SIP proxy and registrar and it works
quite well. Which problems do you see? Any logs from kamaillio?

[Anonymous]

Originally posted by: ya...@airjaldi.org

Apologies for the slightly off-topic question....

Does anyone know of a termination provider that offer ZRTP support?
(For the specific threat model, it's enough we encrypt until the service provider {assuming it's not in a particular country} and make simple unencrypted PSTN calls onward).
This would be also used for conferencing a number of ZRTP supported clients within the problematic country.

Naturally, we can setup our own server for that - but there are benefits for using an existing service provider.

Thanks,

Yahel.

[Anonymous]

Originally posted by: werner...@googlemail.com

I'm not aware of any termination provider that connects VoIP to PSTN that also
supports ZRTP. AFAIK this requires a Asterisk server with ZRTP enhancement and you
need to have a ZRTP implementation that support a specific ZRTP feature: trusted
Man-in-the-Middle. Currentliy the PJSIP implementation (CSipSimple uses this
implementation) does not support this feature because it is considered a security
risk.

Just send me a PM if you need some more support and/or discuss specific features.

Regards,
Werner

[Anonymous]

Originally posted by: ursu.adr...@gmail.com

Hello guys.I am really excited about ZRTP support in CSipSimple. I have a problem and mostly I think is a GUI one.
    I am testing ZRTP in CSipSimple with a HTC Desire HD (Android 2.3.3) and 2 Samsung Galaxy Mini (Android 2.2.1) clients connected to a Freeswitch server (which runs in proxy media mode).
    The problem is that I only sometimes see the 4 digit SAS displayed on both phones,sometimes the SAS appears only on one phone but most often it is not displayed at all on any phone, although ZRTP is active (I know that because I registered on the Freeswitch server with a client on the phone and a client on a computer (Jitsi-former SIP Communicator) and in Jitsi it showed me that ZRTP is active, but on the phone it didn't display the 4 digit SAS or that ZRTP was active).
The catch is that if I select "Disconect" from the app menu, and I restart the app again (on both phones) then, on the first call made after that the SAS is displayed on both phones, but on the other calls it is just like I've mentioned before.
  So, even if ZRTP is active, the user won't know that because it isn't displayed anywhere and he can't verify the SAS with the other party.
Please check this problem, and I will continue to test the app and post updates.
Keep up the good work.

[Anonymous]

Originally posted by: werner...@googlemail.com

Regarding @74

I cannot really test this because I don't have a freeswitch setup. Thus just a question: do you use anything like the "PBX ZRTP registration" feature in freeswitch? I know that freeswitch support this sort of trusted Man-in-the-Middle feature?

If it is really purly "proxy-media" I would be interessted in some network traces between both clients and the freeswitch.

Best regards,
Werner

[Anonymous]

Originally posted by: gcjo...@gmail.com

I play with [r1064] and ZRTP. My experience is:

The ZRTP SAS only show at the first call, because the implementation is not complete, see that [r1060]
"// For now, just get the first one..." is the problem. Another problem that the transport_zrtp.c is often crash with sigsegv.

********** Crash dump: **********
Build fingerprint: 'samsung/GT-S5570/GT-S5570:2.3.4/GINGERBREAD/XXKPK:user/release-keys'
pid: 1359, tid: 1411  >>> com.csipsimple:sipStack <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 07000004
Stack frame #00  pc 0010b260  /data/data/com.csipsimple/lib/libpjsipjni.so: Routine pj_lock_acquire in apps/pjsip/project/build/..//pjlib/build/..//src/pj/lock.c:178
Stack frame #01  pc 0010c672  /data/data/com.csipsimple/lib/libpjsipjni.so: Routine lock_timer_heap in apps/pjsip/project/build/..//pjlib/build/..//src/pj/timer.c:104
Stack frame #02  pc 00151ebe  /data/data/com.csipsimple/lib/libpjsipjni.so: Routine timer_add_entry in apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/transport_zrtp.c:303
Stack frame #03  pc 00152504  /data/data/com.csipsimple/lib/libpjsipjni.so: Routine activateTimer in apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/ZrtpCallbackWrapper.cpp:42
Stack frame #04  pc 00153018  /data/data/com.csipsimple/lib/libpjsipjni.so: Routine activateTimer in apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/ZRtp.cpp:2126
Stack frame #05  pc 00158f9e  /data/data/com.csipsimple/lib/libpjsipjni.so: Routine startTimer in apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/ZrtpStateClass.cpp:1352
Stack frame #06  pc 00159c90  /data/data/com.csipsimple/lib/libpjsipjni.so: Routine evInitial in apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/include/libzrtpcpp/ZrtpStates.h:76
Stack frame #07  pc 00159dd8  /data/data/com.csipsimple/lib/libpjsipjni.so: Routine processEvent in apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/ZrtpStateClass.cpp:129
Stack frame #08  pc 0015352c  /data/data/com.csipsimple/lib/libpjsipjni.so: Routine startZrtpEngine in apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/ZRtp.cpp:199
Stack frame #09  pc 001513aa  /data/data/com.csipsimple/lib/libpjsipjni.so: Routine zrtp_startZrtpEngine in apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/ZrtpCWrapper.cpp:122
Stack frame #10  pc 00151c90  /data/data/com.csipsimple/lib/libpjsipjni.so: Routine pjmedia_transport_zrtp_startZrtp in apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/transport_zrtp.c:754
Stack frame #11  pc 00152082  /data/data/com.csipsimple/lib/libpjsipjni.so: Routine transport_send_rtp in apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/../../../pjlib/include/pj/string.h:634
Stack frame #12  pc 000e49c0  /data/data/com.csipsimple/lib/libpjsipjni.so: Routine pjmedia_transport_send_rtp in apps/pjsip/project/build/..//pjmedia/build/..//src/pjmedia/stream.c:1345
S

this is because the timer_pool did not freed at transport_destroy(), but the pjlib destroys it automatically at end of first call (pool_caching.c:108), so when the next call started the timer_pool is already destoyed and the sigsegv occurs. The problem maybe that the timer_stop() function is not used, so the implementation is not complete also.

Furthermore the timer_android.cpp is unstable, with that the SIP stack always sent a REGISTER message to the SIP server at every 1-3 seconds. I dont know why and I don't know that this is related to ZRTP or not. When I build the library with the original timer.c this problem is gone, but CSipSimple does not accept incoming calls when device is in idle.

[Anonymous]

Originally posted by: r3gis...@gmail.com

About timer_android.cpp, you're right for TLS version.
ZRTP and TLS builds are broken til the next stable release (which will come really soon). If I want to have something stable without regression risk on trunk with android 1.6 I've to break ZRTP support for a while.

I've something working again but based on pjsip-2.0.
So for now hold for a couple of week if you need ZRTP (or try to build with the new jni folder ;) ).

About the fact it take only the first SAS, good point, I forgot that I postponed this implementation :). So to be done :)

[Anonymous]

Originally posted by: r3gis...@gmail.com

Oh, and I forgot to add that with the pjsip-2.0 builds (after the next stable release on the android market), ZRTP and TLS will be on of stock features of csipsimple :).

I finally found a fancy way to use openssl if available on the platform (99.99% of cases) and to load it dynamically else. (Many other native features will becomes available through plugins too : codecs, audio and video device implementations etc).

[Anonymous]

Originally posted by: gcjo...@gmail.com

Thank you! If the new trunk with ZRTP will be buildable, I will test it! :)