[VOIPSEC] Using SRTP for University project

[Hadriel Kaplan]

Hi Randell,
Sorry for not responding sooner - got sidetracked with my day job.  
Also sorry for this long email.
Comments inline...

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Randell Jesup
> Sent: Tuesday, March 28, 2006 12:48 AM
> To: Hadriel Kaplan
> Cc: Voipsec at voipsa.org; Christian.Stredicke at snom.de
> Subject: Re: [VOIPSEC] Using SRTP for University project
> 
> There's trust, and then there's trust.  For example: I trust my phone
> provider to route my calls to my bank and not a scammer, but I don't
> trust them to stop a government agency from wiretapping me, even without
> a warrant...  

If wiretapping is really your concern, then you shouldn't trust them,
because they will wiretap you - that's hardly a secret.  Well... the general
fact is not a secret - the fact they're wiretapping you, Randell, is a
secret.  :)  (BTW, the problem I think you mean is that the warrant isn't
legal - not that they don't have one - the lawful intercept systems I've
seen only operate with digitally signed warrants, though there's no question
a human could be involved at an early step before it was signed, and that is
a weak link)

But they will also intercept/tap your signaling, and for some warrants (in
the US) that's all they legally can and will intercept.  That's a sign to me
that signaling is sometimes as important as media.  :)  They will know you
called the bank, and if you use sip Info for dtmf (vs. 2833) they will know
the pin code you entered, too.  And if you called your mistress, they will
know it.  And if you sent her an IM message saying "c u @home @1pm", they
may send agents to watch you there.  

I'm not knowledgeable enough on lawful intercept legal issues to address
this topic; but if you make a call through a service provider covered under
the US FCC mandate (which is basically all of them, and universities now too
I think), they will comply with the ruling.  In fact, according to the FBI,
a judge can order an enterprise to wiretap a call as well.  I've been told
(by people who handle our lawful intercept support) that the service
providers have the legal responsibility of providing such, and that they
(the providers) feel it is required of them to not "support" calls which
cannot be legally tapped, whatever that means.  I've also been told by
someone else that if it's encrypted medium, then the provider does not have
the legal responsibility to provide it in a decrypted form, and can fulfill
the warrant by capturing the encrypted media.  This would be under the
notion of wiretapping only being required if technically feasible.  If
that's true, then zrtp may not be blocked (if it even could be, which is
debatable).  

But my guess is the providers would have figured out if that were not true,
because it's quite expensive to actually build a network which can wiretap
calls, and providers generally don't want to spend more than they have to.
(and no we didn't drive them to this decision - SBCs were used long before
wiretapping of voip became mandated by the FCC, and it's done by many other
elements than SBCs as well)

But that's the US, and the idea is to make this a global thing, right?  Then
the issue gets very complicated.  

Again, the only way to assure it is not wiretapped for signaling or media,
is to make a direct, encrypted and authenticated, sip-sip call and bypass
the service provider proxies of all countries.  Nothing stops you from doing
that today, as far as I know.  Or if media is your only concern, then just
try zrtp or some other end2end media-level encrypt+auth every time and if it
succeeds you succeed. 

> And even here, while I trust them to not route me to a
> scammer on purpose, I might not trust their network security - they might
> have been hacked and their servers compromised.  If the signalling is
> in-the-clear across (or in) ANY of their networks/servers, it's only as
> secure as their entire network.  One keylogger/trojan/virus on the wrong
> IT admin's machine, or 0-day MS exploit, and... poof.  When I call my
> bank's customer service, and have to give my account, SS#, password, etc
> in order to talk to a human, that could all be tapped by a scammer.

The same could be said of the PC or voip phone from which you're making the
call from or to, or the media gateway you're calling to reach the bank, or
the PSTN switches, etc.  The only good news is the service providers have a
lot at stake - if their equipment gets hijacked there is far more at risk
than just your bank account # (unless you're Bill Gates).  So that is the
implicit threat that will drive them to secure it.  But they have to make a
profit, too, and if securing the solution makes it unreasonably expensive,
my guess is the money side will win.  


> Or critical business negotiations might be tapped by a rival or
> competitor.

That can already happen in the PSTN and it doesn't seem to bother
enterprises at all.  In fact, some of them want to tap their own phones.
There are a few institutions which care, but they already do more today to
secure it (and it costs them more).


> Media proxies
> (SBCs) want to modify SDP (IP's, ports, etc).  

Actually this is a common misconception, although I don't think you meant
it.  But to be clear: SBCs don't want to do it - their owners want them to
do it.  (Or most of them I should say - it's not true of all by any means.)
But that's a very big difference.  All the SBCs I know of (including ours)
do not have to modify or touch or look into SDP or RTP at all - that is
completely configurable.  Only non-ICE NAT traversal fixing needs that - but
that's not the most common application for SBCs.  I think I've said before
on this list that nat traversal is not even one of the top 3
features/reasons requested of an SBC. (though it may be #4 or 5)  An SBC
typically still provides a lot of value without touching SDP.  

Regardless of that ability to not touch SDP, most operators choose to enable
it for numerous reasons, and when I say most I mean something like >80%.  At
least those I know of.  It's very possible this is a self-fulfilling fact
for us because if you don't want SDP touched you probably don't think you
need a hardware-based SBC (of course I think you'd be wrong, but that's at
least debatable :).  But we also talk to service providers that don't use
SBCs and the percentage holds.  This may change over time of course.  

BTW, SBCs are not the only "middle-elements" that touch SDP. (another common
misconception, although again I don't think you meant it, but just to be
clear) 

-hadriel