[VOIPSEC] VoIP and Banking Security

[Eugene Nechamkin]

> Besides someone mentioned very accurately that it takes a lot of 
> work and prior knowledge to get anything useful by sniffing the 
> RTP stream. 
Actually, the presense of the various tools freely available on the Internet
to anybody (e.g. "VOMIT"), makes this task trivial for almost anyone. This
makes leaving the voice in the clear to be a severe security threat for any
VoIP user in general and for the banks' customers in particular.

> So in my opinion, it is probably "ok" to leave the 
> voice in the clear (RTP) but encode and protect the 
> signalling information that sets up the voice in the first place.
Given the availbility of the "packets sniffing" and RTP analysing tools, the
voice (RTP) confidentiality and integrity are becoming very much mandatory in
VoIP systems. The best (standard) way to protect a sensitive VoIP info is to
use the SRTP (RFC3711) on the voice path along with the corresponding
security protocols on the signaling path (e.g. TLS or IPSEC). Obvioulsy, this
requires the corresponding back-office functionality and equipment to support
it, and wilingness of the management to implement these measures. I would
think that doing so is especially important when VoIP is used in banking,
financial and other security sensitive areas.

Looking at the particular problem which seems to be coming from ComCast, I
think that the majority of the security threats are addressed in the Cable
industry by the PacketCable 1.0 Voice-Over-Cable architecture, which provides
the confidentiality and integrity for both - voice (including RTCP) and
Sigaling traffics.

Eugene Nechamkin,
Broadcom Corp.

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Pankaj Shroff
Sent: Monday, June 27, 2005 9:45 AM
To: Voipsec at voipsa.org
Subject: Re: [VOIPSEC] VoIP and Banking Security

I beleive all of you are missing a fact that Al mentioned in his original
email which is that he could see the DTMF Event type in
(possibly) an INFO message in the SIP signalling. Obviously, it is shocking
that a bank or even Al's VoIP service provider is using SIP signalling in the
clear (and not using TLS). Thats the core problem here. There should
regulations against that!!

I sent my original response to point out that this could be avoided with
simply sending in-band DTMF tones and avoid out-of-band signalling for DTMF.
But the more I read from this mailing list, the more I am convinced that
out-of-band signalling (such as KPML combined with an authenticated
SUBSCRIBE-NOTIFY transaction) using SIP over TLS is probably the best way to
secure DTMF relays.

To encode the entire RTP stream using SRTP (which is not even an industry
standard yet) seems to have very low ROI. Besides someone mentioned very
accurately that it takes a lot of work and prior knowledge to get anything
useful by sniffing the RTP stream. So in my opinion, it is probably "ok" to
leave the voice in the clear (RTP) but encode and protect the signalling
information that sets up the voice in the first place.

Like in all security, it is the information at the top level that you
control, that determines the effectiveness of your security. In other words,
if you had a thousand dollars cash in your wallet, would you advertise that
fact on your forehead? SIP signalling in the clear combined with SRTP is kind
of like that - it defeats the purpose of SRTP.

Pankaj




On 6/24/05, Brian Rosen <br at brianrosen.net> wrote:
> >.... I could be wrong, but I believe SRTP would take care of this.
> Thoughts?
> 
> 
> Yes, SRTP would take care of this as long as the DTMF was carried as 
> RFC2833 (there is a revision coming), or just as inline G.711 encoded
audio.
> 
> We're moving in the direction of not sending key presses as DTMF for 
> VoIP enabled services.  The "KPML" work (in the RFC editor's queue) 
> does that; it turns a key press into a signaling message, not a media
stream event.
> Securing your signaling would be needed there.
> 
> Brian
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 


--
Pankaj Shroff
shroffG at Gmail.com

_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org