[guardian-dev] A Network Analysis of Encrypted Voice over OSTN

[Patrick B]

The next post is up! "Threats and Usability of Secure Voice"

Its a longer introduction to problems with encryption usability. It
also has some recommendations for improving the ZRTP implementation of
CSipSimple.

https://guardianproject.info/2012/07/10/threats-and-usability-of-secure-voice/

-Patrick

On Fri, Jul 6, 2012 at 1:11 PM, Hans-Christoph Steiner
<hans at guardianproject.info> wrote:
>
> This is a good example of a problem that can be aided a lot by good interaction design.  For example, it is much easier to setup and troubleshoot a crypto call if it works non-encrypted while ZRTP is being setup, so that's important to consider.  For many users, they just want to make the call, so if ZRTP just didn't work, they'll just dial a normal number. In that case, blocking unencrypted calls won't help the situation that much.
>
> One approach is to make the insecure mode as apparent as possible.  The phone's vibrator could be going off as long as the phone call is insecure.  Then if you have the phone in your hand, you'll feel it.  Another idea is to add a prominent sound into the call as long as its insecure.
>
> .hc
>
> On Jul 6, 2012, at 11:10 AM, Patrick B wrote:
>
>> I haven't been able to test this, but this is the assumption, yes.
>> ZRTP setup packets would be identifiable with application filtering
>> and could probably be selectively blocked without any user notice. The
>> discerning user might notice, but this would be a problem for accounts
>> like OSTN in which a user might just expect encryption to always work.
>>
>> I would assume for now that ZRTP could be silently blocked. Since
>> right now opportunistic encryption is used, both clients use RTP until
>> they see ZRTP hello packets. All you need to do is block those hello
>> packets and it would appear that the other client has ZRTP off.
>>
>> Adding a Force-ZRTP to the client would solve this problem. Blocking
>> ZRTP would just block the call then.
>>
>> -Patrick
>>
>> On Fri, Jul 6, 2012 at 8:56 AM, Tom Ritter <tom at ritter.vg> wrote:
>>> Good analysis.
>>>
>>> Would a man in the middle be able to swallow the ZRTP setup packets and
>>> prevent encryption without being detected*? I can't imagine RTP provides
>>> integrity...
>>>
>>> *Other than the parties knowing they don't have encryption, of course.
>>>
>>> -tom
>>>
>>>
>>> _______________________________________________
>>> 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/patrickbx%40gmail.com
>>>
>>> You are subscribed as: patrickbx at gmail.com
>>>
>> _______________________________________________
>> 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/hans%40guardianproject.info
>>
>> You are subscribed as: hans at guardianproject.info
>