Menu

#262 Add support for ZRTP

Started
nobody
None
Medium
Enhancement
2013-11-04
2010-10-05
Anonymous
No

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/

Related

Tickets: #1153
Tickets: #1383

Discussion

<< < 1 2 3 4 5 > >> (Page 4 of 5)
  • Anonymous

    Anonymous - 2011-11-07

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

    @r3gis.3R@gmail.com

    can u give a hint on how to fix that ZRTP SAS issue so the SAS always shows up?

    also, if i build with the new jni folder, will ZRTP work ? :p

    keep on up with the great work!

    cheers,
    Francisco

     
  • Anonymous

    Anonymous - 2011-11-07

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

    @fransisco : I just did a commit that should help (even if not yet clean) with the sas display as pointed out by gcjoe. If you use timer.c implementation instead of android_timer.cpp implementation it should work. It may also work depending on device with the timer_android.cpp (depends on the dalvik config).

    About the other issue pointed out by gcjoe : timer_stop never called there is maybe something too. I've to investigate this point too when pjsip-2.0 will be used on nightlies.
    Maybe if Werner can give me some pointers about why timer_stop exists but is never launched by the rest of the code, it could help me to understand what is wrong in my timer implementation or if there is something missing somewhere ;).

     
  • Anonymous

    Anonymous - 2011-11-10

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

    First of all, thanks r3gis for the modification to the source code about SAS display . It works great. I have a question. I am getting this error in LogCat:
    11-10 11:49:32.827: E/libpjsip(21359):  11:49:32.843 timer_android.  Huh, pj is cancelling something already unknown... : 0.

    What does this mean? I understand that there is a problem with the timer. What can I do to fix this? Does this influence ZRTP in any way? I mean, ZRTP is active and my call is secure, isn't it?

    Also I would like to suggest an enhancement which already exists in Jitsi. There, in Options->Zrtp (ZRTP Ninja) you can select in Standard and Mandatory  different key lengths for AES encryption (128 and 256) , and during a call it is displayed on the screen that your call is secured , the encryption method and key length. For example: (Cipher: AES-256). Do you think this could be implemented in CSipSimple also under the 4 digit SAS ?

    Thanks, and keep up the good work.

    I am using CSipSimple [r1064] on a Htc Desire HD (Android 2.3.3) and Samsung S5570 (Galaxy Mini Android 2.2.1) on a Freeswitch Server in proxy media mode.

     

    Related

    Commit: [r1064]

  • Anonymous

    Anonymous - 2011-11-10

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

    The error raised by the timer_android implementation should actually be a warning. It is just to warn me about the fact pjsip is trying to cancel a timer that it has already previously cancelled or that was already fired. I tried to track down which was the root cause of this dupplicate cancel. But seems to be normal, and the timer implementation should (and actually is), robust to duplicate cancel or cancel after execution of the callback. So this error should just be ignored ;). That was just for me to debug that.

    About the key lenght, it should be possible I think. I put that in my todo list :).

     
  • Anonymous

    Anonymous - 2011-11-20

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

    New nightly build available here :
    http://nightlies.csipsimple.com/trunk/

    Now TLS and ZRTP are part of trunk builds. ZRTP support should have been really improved. The UI should not mix infos from several calls anymore and should always display the SAS (it asks to confirm only if needed). It will also show the AES encryption type.

    As it's a new build toolchain and it's based on a different pjsip version there is maybe some possible regression, feel free to open new issues about it :). Also I'm unsure about how it will go on all android phones since the openssl library is not included into the app but it tries to rely on the one of the phone.
    For now I never found a phone without openssl on it. However, if someone has a phone without openssl I can produce a plugin which intent to provide openssl library to CSipSimple. 

     
  • Anonymous

    Anonymous - 2011-11-20

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

    Thank you! My first try with your binary package ([r1129]) is no luck, beacause CSipSimple crashes immediately when the peer answer the call (TLS+ZRTP enabled of course). I'll try build one from source (if I can) in the next week, then I can send a backtrace.

     

    Related

    Commit: [r1129]

  • Anonymous

    Anonymous - 2011-11-21

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

    Thanks r3gis, my first wave of testing on [r1132] did not go so well.  The calling phone would freeze when placing a call to a zrtp enabled peer.  Happened on both my devices. [r1136] works great!  Tested a few calls between espresso devices running cyanogen 7.1.  ZRTP support has come so far in the last year, thanks!!  I did all my testing on tanstagi.net, its been around/stable for a year as well, with more and more people using it, any chance for a wizard with TLS/ZRTP enabled?  It requires no special configuration options just tls/zrtp.

     

    Related

    Commit: [r1132]
    Commit: [r1136]

  • Anonymous

    Anonymous - 2011-11-21

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

    In 1136 I did a couple of fixes specially for android 2.2 device (that were completly broken previously).

    Yes we should add a Tanstagi.net wizard now that ZRTP and TLS are features of the trunk version :D. I've just added an issue about that : issue 1389.
    In a first time maybe some simple link to the web page to create an account. If you think it would be better to do that through a more advanced web api from within the app you can send me infos by mail or on the issue 1389.

     

    Related

    Tickets: #1389

  • Anonymous

    Anonymous - 2011-11-21

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

    Sorry but 1136 is still crash for me when the peer answer the call (ZRTP mode).

    ********** Crash dump: **********
    Build fingerprint: 'samsung/GT-S5570/GT-S5570:2.3.4/GINGERBREAD/XXKPK:user/release-keys'
    pid: 1895, tid: 2208  >>> com.csipsimple:sipStack <<<
    signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 3135327c
    Stack frame #00  pc 000e9874  /mnt/asec/com.csipsimple-1/lib/libpjsipjni.so: Routine pj_lock_acquire in CSipSimple/jni//pjsip/android_toolchain/pjlib/../../sources/pjlib//src/pj/lock.c:178
    Stack frame #01  pc 000ebbea  /mnt/asec/com.csipsimple-1/lib/libpjsipjni.so: Routine lock_timer_heap in CSipSimple/jni//pjsip/android_toolchain/pjlib/../../sources/pjlib//../../android_sources/pjlib/src/timer_android.c:338
    Stack frame #02  pc 0007a5a0  /mnt/asec/com.csipsimple-1/lib/libpjsipjni.so: Routine Java_org_pjsip_pjsua_pjsuaJNI_pj_1timer_1fire in CSipSimple/jni//swig-glue/android_toolchain/../nativesrc/pjsua_wrap.cpp:18713
    Stack frame #03  pc 000180f4  /system/lib/libdvm.so
    Stack frame #04  pc 00046624  /system/lib/libdvm.so
    Stack frame #05  pc 0001d304  /system/lib/libdvm.so

     
  • Anonymous

    Anonymous - 2011-11-21

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

    Another problem that [r1128] - [r1136] versions are never sent REGISTER message to the SIP server while the account status shown as "Registered" (green).

     

    Related

    Commit: [r1128]
    Commit: [r1136]

  • Anonymous

    Anonymous - 2011-11-22

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

    a current walk through for using csipsimple w/ tanstagi
    http://freeborn.devio.us/doku.php?id=androiddiffemyhellman

    gcjo, did you make sure to enable TLS in the transport settings of your account settings?

     
  • Anonymous

    Anonymous - 2011-11-22

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

    Thank you for this pointer! Both problems are solved!

    No I don't use TLS. I try to use CSipSimple with my own Freeswitch build (simple bypass mode). This is a working setup, the ZRTP calls are works fine when I try with an [r1064] build.

    But my config was wrong, because under Network->Secure transport it was checked on the TLS checkbox. After I uncheck this box, now the outgoing calls are works fine with ZRTP (on UDP transport), so in this case no timer crash anymore!

    The REGISTER message problem is also solved. I forgot to fill the "Registration URI" (it was empty) in the account settings and this caused that the account shown as "Registered" (green) but the REGISTER message was not sent.

    Thank you!

     

    Related

    Commit: [r1064]

  • Anonymous

    Anonymous - 2011-11-25

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

    Thanks for the Link!
    Is this kinda common description for setting up an account for crypted use?
    The reason why I am asking: i am new to this and i dont want to open tickets because of misconfigured devices on my side:).
    It would be great if we have smth like an easy to follow walkthrough for the common settings.

    Why do you guys use TLS if SRTP does the work already?
    Btw.. i tried to get some SAS working, but it didnt show up. Therefore ZRTP tells us: "No verification"

    Thanks for you comments

     
  • Anonymous

    Anonymous - 2011-11-25

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

    Well, first thing to know is that there is to communication plan in SIP. There is the media plan (the actual audio other side receive) and the control plan (it's here to invite, hold, cancel, hangup the call).
    SRTP and ZRTP apply both to media plan. TLS (SIPS) apply to control plan.
    If there is a hacker on your network and that the control plan is not secured he will be able to see who calls who and to terminate calls (and maybe to gather some interesting infos about your sip password -- not immediate info, but could be deduced after many calls).
    If the media plan is not secured, he will be able to listen what is said in the conversation.
    So TLS and S/Z RTP are for two distinguished purpose.

    There's guys here much more expert about these points than me so do not hesitate to correct me if I'm wrong ;).

    For TLS you need a sip server that supports TLS to be able to talk with it an encrypted way. So this is a feature of your sip provider.

    About SRTP and ZRTP that's different.
    First about SRTP. This way has to be announced during the negociation of call and to be accepted by both parts. If the media does not go directly between you and your remote party but is modified by your sip provider they also need to support SRTP on their side. Then on between their server and your remote party it's another negociation.
    So in order to have this feature working, either your sip provider (if media gatewway) or your remote party must support this, else it will not be activated.
    About ZRTP. It is not 'necessary' to announce it during the negociation, and can be established over an ongoing call. As previously both party *must* support the feature. If your sip provider filter or does media gateway stuff it may drop ZRTP feature so that the other side will never receive ZRTP hello packets.

    So also, to have this feature working you may first understand what's done on your sip server side.

    If you just want to directly test the feature without further configuration on a sip server, there is a simple way to do so if your two devices are on the same network.
    You can simply create a "local account" on each device (there is a specific wizard for that). Disable all other accounts on each device. And call directly one device with the other using direct IP address (you can get in android settings). To do this peer to peer call, use the text dialer (little icon on the left top corner of the dialer). And type the complete remote address : user2@xxx.xxx.xxx.xxx where the xxx.xxx.xxx.xxx is the ip address of the second device.

     
  • Anonymous

    Anonymous - 2011-11-27

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

    The above timer crash (comment c88) is still occurs but very rarely.

     
  • Anonymous

    Anonymous - 2011-11-29

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

    automate...

    yes thats a guide to get csipsimple running quickly with TLS and ZRTP on tanstagi.  Its even easier now that r3gis has added the wizard.  Good luck, let me know if you have any issues connecting.

     
  • Anonymous

    Anonymous - 2011-11-29

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

    I was just passed this pdf (pdf: http://www.ieee-security.org/TC/SP2011/PAPERS/2011/paper001.pdf ) it states that VBR codecs can be snooped on regardless of encryption.  Im trying to find out which codecs are VBR and which are non-vbr, anyone else have any thoughts on this?

     
  • Anonymous

    Anonymous - 2013-03-04

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

    has someone managed to get CSipSimple working with linphone?
    srtp works, but with zrtp, sound is garbled (using the same codecs as with srtp).
    OnSIP and IpTel seem to work the best, Nymgo seems to hijack the stream and disable ZRTP, Ekiga seems not very reliable or is too picky.

    message: ZRTP INFO zrtp_InfoInitConf1Received
    message: ZRTP secrets on: SAS is abcd previously verified no - algo AES-CM-128/DH3k
    message: sent ZRTP Confirm2 31337
    message: ZRTP secrets for receiver are ready
    message: Authentication token is abcd (unverified)
    message: received ZRTP Confirm1 10
    message: ZRTP secrets for sender are ready
    message: ZRTP INFO zrtp_InfoSecureStateOn
    message: Audio stream is encrypted
    message: All streams are encrypted
    warning: srtp_unprotect failed; packet may be plain RTP
    warning: srtp_unprotect failed; packet may be plain RTP
    message: bandwidth usage: audio=[d=68.5,u=80.4] video=[d=0.0,u=0.0] kbit/sec
    message: Thread processing load: audio=2.180420    video=0.000000
    warning: srtp_unprotect failed; packet may be plain RTP
    warning: srtp_unprotect failed; packet may be plain RTP
    warning: srtp_unprotect failed; packet may be plain RTP
    warning: srtp_unprotect failed; packet may be plain RTP
    warning: srtp_unprotect failed; packet may be plain RTP
    message: received ZRTP Conf2ACK 11
    warning: srtp_unprotect failed; packet may be plain RTP
    warning: srtp_unprotect failed; packet may be plain RTP
    ...a million of these...
    warning: srtp_unprotect failed; packet may be plain RTP
    warning: srtp_unprotect failed; packet may be plain RTP
    error: srtp_unprotect failed 7 ; packet discarded (may be plain RTCP)

    ... BYE ...

    message: cb_sndbye (id=17)
    message: eXosip: timer sec:0 usec:509995!
    message: oRTP-stats:
       Audio session's RTP statistics :
    message:  number of rtp packet sent=1782
    message:  number of rtp bytes sent=306504 bytes
    message:  number of rtp packet received=1750
    message:  number of rtp bytes received=306436 bytes
    message:  number of incoming rtp bytes successfully delivered to the application=305216
    message:  number of rtp packet lost=32
    message:  number of rtp packets received too late=3
    message:  number of bad formatted rtp packets=0
    message:  number of packet discarded because of queue overflow=0
    message: ms_filter_unlink: MSAlsaRead:0x2153ac0,0-->MSVolume:0x2171a00,0
    message: ms_filter_unlink: MSVolume:0x2171a00,0-->MSG722Enc:0x215f240,0
    message: ms_filter_unlink: MSG722Enc:0x215f240,0-->MSRtpSend:0x2102d80,0
    message: ms_filter_unlink: MSRtpRecv:0x215de70,0-->MSG722Dec:0x214cc90,0
    message: ms_filter_unlink: MSG722Dec:0x214cc90,0-->MSDtmfGen:0x215e060,0
    message: ms_filter_unlink: MSDtmfGen:0x215e060,0-->MSVolume:0x20b20f0,0
    message: ms_filter_unlink: MSVolume:0x20b20f0,0-->MSEqualizer:0x215f4f0,0
    message: ms_filter_unlink: MSEqualizer:0x215f4f0,0-->MSAlsaWrite:0x215f140,0
    message: Stopping ZRTP context
    message: ZRTP secrets off
    message: ZRTP secrets off
    message: ZRTP INFO zrtp_InfoSecureStateOff
    message: Destroying ZRTP wrapper
    message: Destroying ORTP-ZRTP mutex
    message: Destroying SRTP contexts
    message: ORTP-ZRTP context destroyed
    message: Audio MSTicker thread exiting
    message: Filter usage statistics:
    message: Name    Count    Time/tick (ms)    CPU Usage
    message: MSAlsaWrite 1743 0.191468 41.5972
    message: MSAlsaRead 3569 0.0834608 37.117
    message: MSG722Dec 1743 0.0316154 6.86858
    message: MSG722Enc 1673 0.0252301 5.26134
    message: MSRtpRecv 3570 0.00999456 4.44606
    message: MSRtpSend 3569 0.00943405 4.19555
    message: MSVolume 3416 0.00094114 0.40061
    message: MSDtmfGen 3570 0.000193293 0.0859863
    message: MSEqualizer 1743 0.000127403 0.0276788
    message: MSFilePlayer 0 0 0
    message: MSSpeexEC 0 0 0
    message: Call 0x215e3f0: moving from state LinphoneCallStreamsRunning to LinphoneCallEnd
    message: Resetting the current call

     
  • Anonymous

    Anonymous - 2013-03-04

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

    sflphone kind of works, after fixing a bug in it, but:

    A ZRTP error forced the call with asdjweklfkwejrj@getonsip.com to fall under unencrypted mode.
    Exact reason: DH Error: bad pvi or pvr ( == 1, 0, or p-1)

     
  • Anonymous

    Anonymous - 2013-03-05

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

    with latest git libzrtpcpp and ortp:
    linphone 3.5.2 works with zrtp without extra patches, ortp needed one patch:
    -               zrtp_processZrtpMessage(zrtpContext, ext_header, peerssrc);
    +               zrtp_processZrtpMessage(zrtpContext, ext_header, peerssrc, zrtp_total_packet_length);

     
  • Anonymous

    Anonymous - 2013-03-29

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

    When calling CS→Linphone, ZRTP does not get enabled.  It works the other way.

    CS→Linphone logs as seen from CS:
    08:59:16.802 zrtp_android.c  ZRTP info message: Responder: Commit received, preparing DHPart1
    08:59:16.802 zrtp_android.c  ZRTP info message: DH1Part: Generated a public DH key
    08:59:17.070  strm0x15a169c  RTP decode error: Invalid RTP version (PJMEDIA_RTP_EINVER) [err:220122]
    08:59:17.070  strm0x15a169c  RTP status: badpt=0, badssrc=0, dup=0, outorder=-1, probation=0, restart=0
    08:59:17.106 sip_endpoint.c  Processing incoming message: Response msg 200/INVITE/cseq=13425 (rdata0x134e42c)
    ...
    08:59:17.151  pjsua_media.c  .....Call 0: updating media..
    08:59:17.151  pjsua_media.c  ......Call 0: stream #0 (audio) unchanged.
    08:59:17.151  pjsua_media.c  ......Audio updated, stream #0: GSM (sendrecv)
    08:59:17.151 timer_android.  .....Scheduling timer 1 of 8 in 0 ms @ 0x5bbc1624
    08:59:17.183 pjsua_jni_addo  .....Get secure for media type 1
    08:59:17.183 zrtp_android.c  .....jzrtp_getInfoFromContext : user data 12d56a0
    08:59:17.183 zrtp_android.c  .....jzrtp_getInfoFromContext : user data 12d56a0
    08:59:17.184    pjsua_aud.c  .....Conf connect: 2 --> 0
    08:59:17.184    pjsua_aud.c  .....Conf connect: 0 --> 2
    08:59:17.224   inv0x130000c  ....Received Response msg 200/INVITE/cseq=13425 (rdata0x134e42c), sending ACK
    08:59:17.224  tdta0x15a4710  ....Destroying txdata Request msg ACK/cseq=13424 (tdta0x15a4710)
    08:59:17.224       endpoint  ....Request msg ACK/cseq=13425 (tdta0x15a4710) created.
    ...
    08:59:31.449 pjsua_jni_addo  .....Call 0 is DISCONNECTED [reason=200 (Normal call clearing)]
    08:59:31.451 pjsua_jni_addo  .....Get secure for media type 1
    08:59:31.451 zrtp_android.c  .....jzrtp_getInfoFromContext : user data 12d56a0
    08:59:31.452 zrtp_android.c  .....jzrtp_getInfoFromContext : user data 12d56a0
    08:59:31.503  pjsua_media.c  .....Call 0: deinitializing media..
    08:59:31.503 timer_android.  .......Scheduling timer 1 of 8 in 1000 ms @ 0x5bbc90ac
    08:59:31.521  strm0x15a169c  .......JB summary:
      size=0/eff=0 prefetch=0 level=3
      delay (min/max/avg/dev)=20/500/45/48 ms
      burst (min/max/avg/dev)=1/5/2/0 frames
      lost=0 discard=56 empty=101
    08:59:31.521  pjsua_media.c  .......Media stream call00:0 is destroyed
    08:59:31.521 transport_zrtp  ......Media stop - encrypted packets: 0, decrypted packets: 0
    08:59:31.521        icetp00  ......Stopping ICE, reason=media stop requested
    08:59:31.521 transport_zrtp  ......Destroy - encrypted packets: 0, decrypted packets: 0
    08:59:31.521        icetp00  ......ICE stream transport 0x13989f4 destroy request..
    08:59:31.521 stuntp0x144e1e  .......STUN sock 0x1574374 request, ref_cnt=8

    Logs from Linphone:
    message: CALL_ACK
    message: sent ZRTP Hello    4258
    message: received ZRTP HelloACK 2
    message: sent ZRTP Commit   4259
    message: Received message:
    INVITE sip:x@85.156.y.y SIP/2.0
    ...
    a=zrtp-hash:1.10 cb4d...
    ...
    message: Stopping ZRTP context
    message: Destroying ZRTP wrapper
    message: Destroying ORTP-ZRTP mutex
    message: Destroying SRTP contexts
    message: ORTP-ZRTP context destroyed
    message: Audio MSTicker thread exiting
    (Linphone has no feature "timestamps in logs")

     
  • Anonymous

    Anonymous - 2013-03-30

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

    What is the verison of the app you are using?
    Recently latest ZRTP version has been added to support in zrtpcpp/zrtp4pj and integrated into csipsimple.

     
  • Anonymous

    Anonymous - 2013-03-31

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

    The change I mentioned was introduced in [r2169] ([r2169])
    I'm not sure to understand from your post if you tried one before [r2169].

     

    Related

    Commit: [r2169]

<< < 1 2 3 4 5 > >> (Page 4 of 5)

Log in to post a comment.