jackbboy / csipsimple

Automatically exported from code.google.com/p/csipsimple
0 stars 0 forks source link

ZRTP key continuity feature in CSipSimple? #1153

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
ZRTP description states that:

...For usability purpose, the SAS can be verified only once, then each party 
can mark the other as “trusted”. In this way the parties do not have to 
verify the SAS in every call. This great feature is provided by the key 
continuity feature of ZRTP...

Are there any chances to implement this functionality in CSipSimple as it is 
VERY important?

It is not difficult to confirm SAS every time if you make encrypted calls time 
to time. 

But suppose you have a workgroup and use SIP for your regular communications on 
daily basis making 30-50 calls a day?.. 

People need to concentrate on their business tasks, not clicking of buttons. 
After very short time they start ignoring that annoying SAS verification thus 
making all your security efforts useless. 

BTW, 
due to similar social factors I fully agree with @jtaylor comment #50 in issue 
262 (http://code.google.com/p/csipsimple/issues/detail?id=262) that we need an 
option to disallow and drop a call if ZRTP session could not be successfully 
established. Or just generate annoying sound tone until ZRTP session is 
established.

Otherwise this is a kind of Russian Roulette when you never can be shure if all 
of your employees calls are being encrypted. Sure, people should check for the 
SAS message every time but imagine making lots of calls every day. Often 
happens that even if both sides have SIP clients with ZRTP enabled ZRTP session 
fails due to networking issues (especially on 3G). But the call is already 
established so people just start talking despite any messages being displayed 
or not.

Original issue reported on code.google.com by d...@dmit.lv on 15 Jul 2011 at 1:44

GoogleCodeExporter commented 9 years ago
Yes, I'm currently doing that.
I'm currently integrating the application the new (clean) way as introduced 
recently thanks to the new pjsip callback.

I'm also trying to fix something more annoying about the fact the second call 
crash now with this new method... just leave me time :) (and do not hesitate to 
contribute ;) source code ).

Also, issue 262 is still open... it means that zrtp is not yet fully 
implemented, you can follow your questions, remark on issue 262 thread. 

More users have stared this issue and for example werner will be able to reply 
(while he do not track each new issue of csipsimple project ;) ).

Original comment by r3gis...@gmail.com on 15 Jul 2011 at 2:25

GoogleCodeExporter commented 9 years ago
Just my 2 Euro cents (as long as they are worth something :-) )

Other clients, for example Twinkle (outdated, no maintenance anymore) and Jitsi 
(former SIP Communicator) implement several ways to support users to detect 
success
or failure during ZRTP:

On success:
- play a short "Acknowledge sound" as soon as key exchange is OK and SRTP was
  established. Thus a user don't need to check the display. If the sound was not
  played 2-3s after the call was established - then check the display.
  Both sounds are available as wav files in the Jitsi project and are not
  copyright protected :-) .

- Obviously a nice informative SAS field and a verify check box (as requested 
above)

On problems/failure:
- play a nasty sound, simliar to a ploice car sirene to warn the user that ZRTP
  detected something odd. In that case the user shall check the display and the GUI
  implementation shall display the error/warning message.

The ZRTP implementation uses callback to inform the GUI about these states and 
the
GUI may display/act accordingly and may trigger playing sounds. The GUI may have
an option to close the call if ZRTP reports an error.

Maybe you can check this info that I wrote for the Jitsi project:

http://www.jitsi.org/index.php/Documentation/ZRTP4JMessageCodes

Original comment by werner...@googlemail.com on 17 Jul 2011 at 1:07