Slashdot Mirror
Is Security Holding VoIP Back?
phoneboy writes "Voxilla is running a piece I wrote on security issues present in Voice over IP. While an increasing number of people are ditching their ILEC in favor of using Voice over IP from companies like Vonage, VoicePulse, Packet8, and Broadvox Direct, there are a number of potential security issues to be aware of. Is VoIP secure enough to replace the PSTN as we know it?"
Today's Firewalls dynamically open and close multiple ports as required by VoIP signaling protocols such as SIP, they remain ineffective in securely supporting unsolicited incoming connections. NAT prevents two way voice and multimedia communication, because the private addresses and ports inserted by the client devices (SIP phones, video conferencing etc.) in the packet payload are unable to be routed in public networks. Therefore, incoming calls that are in any service intended to replace the PSTN just are not possible with todays existing NAT/Firewalls.
Why climb up the pole at all, when many residential subscriber blocks are mounted on the front of people's homes? Most of these units are unlocked. Merely open the door, insert a splitter from Radio Shack, and off you go.
Nothing but the finest in meaningless drivel
one interesting (related) note, is that security is holding back voice over wireless. Not directly because of security concerns, but because of speed. The time to authenticate from AP to AP is causing QOS issues with the voice communications.
Really? I've been using Vonage quite happily for over a year now. Great quality, uptime, service. Althpugh I haven't ditched Ma Bell yet (she provides my DSL service, and my grandfathered-in static ip address would be sorely missed).
What we need is a simple and fast encryption method for VoIP.
IPv6 supports encryption natively. Running voice-over-ip using version 6 is another great reason to make the upgrade.
I'm somewhat wondering at which level they need security..
If you want VoIP over the Internet, you defintly need to care about security.
Then again if an operator wants to do this over the internet, there are alot other things than security to think of
as well,(e.g how goddamn unreliable the internet can be.. packet loss, long unpredictable delays , etc.)
Now, many are already doing VoIP, but at a complete diffrent layer.
They replace their internal core switching network with IP networks.
Networks ofcourse nowhere near the internet, only as their internal bearer of signalling and in some cases the voice
as well.
Readers can go through the RFCs for the Sigtran stack for more info. Some are considering SIP/SIP-T as well.
The issue they face are not security, but maturity. Protocols and implementations are not that ready.
In this scenario noone talks about security, its the same as in the "old" telco network, phyisically security.
Which btw. isn't that secure. I can very well dig up an 2mbit SS7 cable, hook e.g. our SS7
simulator(www.utelsystems.com) onto it, and call for free, or cause lots of trouble for the switches..
PSTN communications are not easily physically available to most non-electronically-savvy people.
VoIP is (relatively) easily available to any computer-- it uses standard protocols and is intended to travel via networks which are physically publically available during at least some portions of a phone call's life. The access issues are those of any network crack. Exploits can be expected to be passed around thru the saddo script-kiddy-krackers as soon as discovered.
And as regards encryption -- no encryption can withstand brute force. If you are tracking someone's calls, you can simply copy them all to your own disks, then bruteforce open them in your own time. It might take a few days per call, but hey, that's good enough for most purposes.
--
Sal
Writings: saltation.blogspot.com
Wravings: go-blog-go.blogspot.com
For us, it was simply cheaper than paying for telco service in our house.
It is more complicated than it needs to be.
Huh? They shipped us a black box that plugs into our cable modem. You plug a phone into the black box. There was no configuration to do. You don't need a computer.
Cell phones accomplish the exact same thing for the same cost and at a sadly higher reliability level.
We now have a cell phone and a Vonage line, and no telco service. The Vonage service is cheaper and more reliable than the cell service, and the quality is better. YMMV.
It's going to be regulated as hell sooner or later.
Or maybe not.
It's not a satisfactory long-term solution.
Because...?
Find free books.
...over at SecurityFocus - Voice over IP Security by Matthew Tanase
I use Vonage (SIP Phone) on my nat/firewall connection at home, and it works perfectly fine. I'm not sure if you are aware how these technologies work at all...
A slip of the foot you may soon recover, but a slip of the tongue you may never get over. -Benjamin Franklin
Voice over IP actually creates some particularly hairy security problems that traditional approaches really, really don't manage well. Some disclosure: I work for Avaya, one of the big vendors of large scale VoIP systems, though much more for the enterprise market than for anything to do with the public space (Vonage, Packet8, etc).
Lets start by looking at the wire protocols. We have two separate domains within which VoIP operates: Signaling, which determines where a call should route, and traffic, which is the actual stream of speech that needs to arrive at its destination in under a tenth of a second. These are very different protocols. Signaling was originally implemented using H.323, which can be basically thought of as a port of the existing telephony protocols (SS7) to IP.
H.323 is...well...not entertaining to work with. It's a very messy protocol. To a first level of approximation, H.323 is being reimplemented with SIP, which applies the semantics of HTTP to VoIP signaling. SIP is still complicated, but in a more manageable way.
Whether one is using H.323 or SIP to route calls, the actual traffic is moved over a relatively simple protocol entitled RTP. RTP basically involves chunking compressed audio into small packets, attaching a timestamp and a codec identifier, and throwing the packet at the appropriate host. UDP Port selection is managed dynamically by whatever signaling protocol is being used, meaning a firewall either needs to open the entire range of ports that VoIP might use (not small) or it needs to directly parse the signaling traffic to determine what ports to open.
Remember how both SIP and H.323 are both very complex protocols? Add in that complex protocols can hide many security vulnerabilities, and put that complexity in the firewall: Mistakes are made. (That's not theoretical -- a recent mass audit of H.323 exposed holes not merely in VoIP endpoints, but VoIP-aware firewalls. Microsoft, who actually has a pretty impressive firewall solution, was hit pretty bad.)
It's now that we can start discussing the differences between Enterprise VoIP and the kind of PSTN-Bridge VoIP that Vonage sells. Phones in enterprises receive connections from every other potential phone -- in other words, there's generally no central proxy that copies all the traffic towards where it needs to be. In the enterprise world, there's relatively few firewalls inside the corporate network, those that are deployed can be made VoIP aware, and the "central gatekeepers" really only manage directory services (go to this IP for this extension), conference-call mixing, and in the Avaya case, encryption keys.
You don't have that situation in the public realm. Firewalls -- which are everywhere, as deployed through NAT -- simply won't accept incoming connections from hosts that a backend client wasn't communicating with in the first place. But that's almost OK, because the only host a Vonage box needs to communicate with is Vonage itself. So if you actually examine the Motorola device that Vonage is presently deploying, you'll see that it itself accepts almost no incoming connectivity of any form that doesn't appear to come from Vonage itself (just DHCP and ARP, basically). The public providers basically proxy all traffic, because they have to: Nodes on the public PSTN network (normal phone lines) can't be told to just send IP packets at the Motorola device. So the proxying is basically mandatory.
It's ironic that, at least at the moment, PSTN integration carries with it an architecture that's infinitely more wiretap-friendly than what VoIP could eventually become. Tapping a complex mesh where any node often communicates with every other node is difficult-to-impossible to do, at least with any form of reliability. Create a finite number of junction points that must be passed through in order for connectivity to be established, however, and tapping becomes feasible.
AOL Instant Messenger is the most interesting va
I've been using vonage for about a year and I havent had hardly any problems (no more than I did with a regular land line)
I ditched my land line about 2 months after I got my vonage, I haven't looked back since. I moved accross country and I brought it along and still no problems. I'd bet alot of the problems people have had are on their own end and their cable company (my company told me they didn't have to support any service as long as I could view web pages)
GSM phones are very insecure. A lecturer I had in cryptography had implemented a code breaker for GSM phones. Given 4 minutes of recorded conversation you could break the encryption on that particular call. If you place a recorder by a specific GSM base station you can break all calls routed by that cell in just a few seconds. (That requires about a 100 GB or recorded data though.)
Besides, current phone networks only authenticate the phone, the phone newer authenticates the base station. Get yourself your own station, place it in a van outside a company and you now control all mobile phone calls going through there.
If you have the resources you could in some cases reprogram the cell phones over the mobile network to make them "mobile microphones".
These last two would require a lot of resources naturally. But it's not impossible.
All that is required is that each adaptor gets a key signed by the VoIP telecom company. That would be just as safe as it is with PSTN - only the telecom could be the "man in the middle".
City College of San Francisco just switched to VoIP for their internal phone network.
It's been a disaster. Phones cut people off, the wrong people get transferred calls, weird noise on the phone line.
I'm waiting for the whole system to go dead any day now.
One of the IT guys who helped install it keeps an analog phone in his office just in case.
At least the fax phone line in Registration is still analog.
I read a Cringely report in InfoWorld where a company had VoIP and when it prevented customers from calling them, they didn't know it until the voicemail overflowed - and then they couldn't call support - because the phone didn't work.
VoIP - nice concept - bad execution.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
GSM phones are very insecure. A lecturer I had in cryptography had implemented a code breaker for GSM phones. Given 4 minutes of recorded conversation you could break the encryption on that particular call. If you place a recorder by a specific GSM base station you can break all calls routed by that cell in just a few seconds.
Also the encryption only applies between handset and the basestation. Even if you have a call between two handsets on the same basestation the encryption is not end to end. In actual fact the call may well be "tromboning" several hundred miles. Since the base station probably dosn't have the ability to connect the call internally or generate the the billing data.
These last two would require a lot of resources naturally. But it's not impossible.
Resources can be stolen, people can be bribed/blackmailed for information. Depending on the purpose of intercepting the calls a criminal gang, commercial corporation, national government, etc could consider the expense "worth it".
I suppose, that if I encrypt with my private key, then encrypt with your public key. Nobody in the middle can tell what I'm saying. You can know you are talking with someone, but if they can intercept all of the messages, how can you tell them apart from me, if you've never met me or them? They could say the are me, and do what I'd do. With no pre-shared information you can't tell the difference between them and me. What you would know, is that whoever you are actually communicating with it's secure. What you don't know is that you are communicating with who you want to be communicating with. I can demonstrate it for you via the equations if you'd like.
In essense, with no pre-shared information, between Alice and Bob, how can they communicate if Marla can intercept anything they send.
All Alice knows is that she's communicating with the person with the key PK[MB] (who must have pk[MB]), and Bob with PK[MA] (who must have pk[MA]). They know that no one without the associated private keys can read the conversation. Marla now controls the conversation between Alice and Bob. The problem, is that Marla controls the network. That's enough control to subvert public key cryptography.
What Alice doesn't know is that PK[MB] is associated with Marla. They trust the first person who comes along and says they are Bob, to be Bob. At some point, the string of bits has to be associated with Bob, and not with Marla.
What is different about Public Key cryptography instead of Symmetric Key cryptography, is that Bob can tell everyone and their brother his public key, and it's no big deal. So he can publish it in a well known location and that's good. In Symmetric Key, the key must be kept a secret. In public key, you can use the same key pair to communicate with everyone, if you also use their pair in the communication. In symmetric key cryptography that isn't the case.
There is a reason that Versign exists. It's to provide PKI. You really need PKI to make Asymetric Cryptography to work.
With Public Key Cryptography, you can be sure that you are talking with the person who knows the private keys associated with the public keys. However, Public Key Cryptography has no guarantees that who you think has the private keys is who they say they are. At some point, a secure transaction must take place to associate a particular person with a particular key (normally a third party does this, and they are known as a Key/Certificate Authority, think VeriSign. Everyone implicitly trusts the Third Party).
The alternative way to do this, is to build a distributed web of trust. This is what GPG does. Which is "better" from a security standpoint, but very difficult to bootstrap to a point where it's useful.
Kirby