[VOIPSEC] Using SRTP for University project

[Randell Jesup]

"Hadriel Kaplan" <HKaplan at acmepacket.com> writes:
>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.  

Traffic analysis can be useful, of course, and it's hard to armor that
against interception.  Simple sniffing and 3rd-party MITM can (usually) be
blocked by SIPS/TLS.  (There might be subtler attacks possible if you sit
on the access link of the provider or the user, by subverting DNS
resolution and routing as well, but I haven't investigated this in detail.)

>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.

Pure VOIP providers (no PSTN DID/gateways) currently avoid this rule, but
I doubt that will continue indefinitely - though if it does go away, it
opens a pandoras box to general monitoring of internet traffic, and 
creates a huge roadblock to new services.

>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).

That matches my understanding - they have to provide the keys if they have
them, but are not required to block calls that they can't decrypt.
Decryption becomes the problem of the FBI/NSA/etc.  They also have to
provide the tap in a non-detectable way I understand, which is a big
problem technically unless everything (media) is routed through a proxy.
Originally the FCC orders only applied to PSTN<->VOIP calls, but I think
the more recent ruling covered all calls by providers that have PSTN
gateways, even if the call doesn't transit a gateway (i.e. IP<->IP calls).

>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)

As more and more calls are IP<->IP, the costs associated with making
tapping unnoticable will increase because to keep it unnoticable you have
to make ALL calls at all times transit a media proxy.  This adds cost in
hardware, bandwidth, complexity, downtime, etc.

>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 that's where ZRTP's ability to work within an AVT/RTP stream is good -
if it could do so without needing things like header-extensions.  A
provider could block header extensions, or ones that look like ZRTP.  A
truely transparent variant of ZRTP that operated encapsulated within a
dummy codec (like G.711) would be a far more effective way to provide 
unblockable security.

For example, you could embed an RTP packet including ZRTP extensions and
compressed audio data as a "G.711" packet (padded if need be).  This might
still be sniffable if done straightforwardly, but obfuscation techniques
(while easily cracked) could make it hard or impossible to reliably block
such embedding automatically.  Hmmm.  

>> 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.  

Even back to the blue-box days people were figuring out how to bypass 
phone-company security - usually by people-hacking (social engineering).
It's hard to automate defenses against that.  And the "hackers" might
not be normal 3rd-parties; they could be security agencies (of any
country, not just the one the service provider works out of).

>> 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).

True - but the ease of digital tapping makes it a much more real threat
than a guy up on a pole trying to find the line-pair for your PBX.

>> 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.  

Certainly any provider wanting (non-ICE) NAT traversal with "dumb" SIP
phones ends up using this feature.  (Our service doesn't use SBCs, so we're
well aware of the issues with NAT traversal.)

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)