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?"

I see it like this

[barenaked]

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.

Re:insecure network - insecure services

[alexatrit]

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.

Security... sort of

[mental_telepathy]

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.

Re:Crappy service is holding VOIP back

[dr3vil]

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

Re:insecure network - insecure services

[c_g_hills]

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.

PSTN Security ?

[noselasd]

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

The DIFFERENCE is: Script Kiddies

[Saltation]

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 [blogspot.com]
Wravings: go-blog-go.blogspot.com [blogspot.com]

Re:Why do we even need VoIP though?

[bcrowell]

It doesn't really do anything that is currently needed.
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...?

Another article on this subject...

[ManxStef]

...over at SecurityFocus - Voice over IP Security [securityfocus.com] by Matthew Tanase

SIP

[Servo]

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

Converged Security

[Effugas]

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 [avaya.com], 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

Re:Crappy service is holding VOIP back

[azuretek]

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)

Re:Um

[Hast]

Tell me how a cellphone is insecure (They have encryption and cdma is pretty secure by itself.)

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.

Re:As opposed to the security of PSTN?

[gnuman99]

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

I'd Say Incompetence Is Holding It Back

[Master of Transhuman]

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.

Re:I see it like this

[Tmack]

NAT is only an issue if you do not own/control the thing doing NAT. If you can control the NAT device, you can set the ports required for whatever service to be forwarded to an internal device. If you have more than one device internal that needs said service, then you should get more IP's and not use NAT. Alot of Apps are now written to take NAT into account (ie: all Instant messengers), and by using a central server to initiate an outbound connection, can allow many of the same App to work with only one public IP address. As this relates to VoIP, it depends entirely on the implementation, but 99% of the time is no issue what so ever.

The issue of NAT becomes null when the terminating VoIP device on the customer's end is the gateway router that de-VoIPify's the voice traffic back to POTS lines or CAS/PRI(ISDN) style digital trunks(look up Cisco IAD 2430), while taking care of the LAN's NAT and other data traffic as well. Granted this one is aimed more at companies that have multiple internal lines connected to a PBX, but is also the model being implemented by several other providers as well with smaller routers and DSL. It also proves VoIP is not limited to the assumed stereotype of Vonage style VoInternet for a single line. One of the advantages of VoIP is that you do not need 1 IP address per Line/TN. The routing is done by IP, meaning 1 or 100000 TN's can be mapped to terminate at any single IP address. The only time NAT would be an issue at all is if you are trying to implement VoInternet and your ISP gives you only a NAT'd IP address. If you want to use multiple VoIP phones at a location where the LAN sits behind a NAT box, you route all VoIP traffic to a VoIP gateway/PBX from that NAT box, then from the VoIP Gateway/PBX you route the calls internally based on whatever you want, thats what PBX's are specifically for.

Your post also makes the mistake that it seems the whole /. crowd has made toward VoIP, in assuming VoIP==VoINTERNET. There are CLECs out there already using 100% VoIP comunications, on their own internal networks. The difference is the CLEC becomes both your Telco provider and ISP while providing security and reliability (voice traffic does not leave the CLEC network to travel the "wild" internet, and therefore cannot be sniffed/comprimised without first comprimising the LECs internal network). As an employee of such a company, I have first hand knowledge of how it works. Voice traffic is routed completely seperate from data, and on a "private" IP subnet that wont route out of the LECs cloud.

Tm

Re:Um

[mpe]

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

Re:As opposed to the security of PSTN?

[ComputerSlicer23]

Read up on "Man In the Middle" some more. If I can intercept everything that passes thru, and you only send the public key in the clear, I can set things up so you can't tell I'm the man in the middle.

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.

1. Alice sends a public key to Bob (PK[A], Alice has the matching private key pk[A]).
2. Marla captures this, and sends Bob (PK[MA], Marla has the matching private key pk[MA]).
3. At this point, Alice knows nothing about Bob. Marla can respond with to Alice just like Bob would. Alice can't tell the difference between them. Marla sends PK[MB] (Marla has the matching private key pk[MB]) to Alice (who believes it's Bob).
4. Bob responds to Marla (who is masquarading as Alice) with PK[B] (Bob has the matching key pk[B]), which Marla again captures.
5. Marla uses pk[MA] and PK[B] to communicate with Bob. Bob uses PK[MA] and pk[B] to communicate with Marla (whom he believes to be Alice)
6. Marla uses pk[MB] and PK[A] to commuicate with Alice. Alice uses pk[A] and PK[MB] to communicate with Marla (whom she believes to be Bob).

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