VOIP Encryption

There are basically four ways to eavesdrop on a telephone call.

One, you can listen in on another phone extension. This is the method preferred by siblings everywhere. If you have the right access, it's the easiest. While it doesn't work for cell phones, cordless phones are vulnerable to a variant of this attack: A radio receiver set to the right frequency can act as another extension.

Two, you can attach some eavesdropping equipment to the wire with a pair of alligator clips. It takes some expertise, but you can do it anywhere along the phone line's path -- even outside the home. This used to be the way the police eavesdropped on your phone line. These days it's probably most often used by criminals. This method doesn't work for cell phones, either.

Three, you can eavesdrop at the telephone switch. Modern phone equipment includes the ability for someone to listen in this way. Currently, this is the preferred police method. It works for both land lines and cell phones. You need the right access, but if you can get it, this is probably the most comfortable way to eavesdrop on a particular person.

Four, you can tap the main trunk lines, eavesdrop on the microwave or satellite phone links, etc. It's hard to eavesdrop on one particular person this way, but it's easy to listen in on a large chunk of telephone calls. This is the sort of big-budget surveillance that organizations like the National Security Agency do best. They've even been known to use submarines to tap undersea phone cables.

That's basically the entire threat model for traditional phone calls. And when most people think about IP telephony -- voice over internet protocol, or VOIP -- that's the threat model they probably have in their heads.

Unfortunately, phone calls from your computer are fundamentally different from phone calls from your telephone. Internet telephony's threat model is much closer to the threat model for IP-networked computers than the threat model for telephony.

And we already know the threat model for IP. Data packets can be eavesdropped on anywhere along the transmission path. Data packets can be intercepted in the corporate network, by the internet service provider and along the backbone. They can be eavesdropped on by the people or organizations that own those computers, and they can be eavesdropped on by anyone who has successfully hacked into those computers. They can be vacuumed up by nosy hackers, criminals, competitors and governments.

It's comparable to threat No. 3 above, but with the scope vastly expanded.

My greatest worry is the criminal attacks. We already have seen how clever criminals have become over the past several years at stealing account information and personal data. I can imagine them eavesdropping on attorneys, looking for information with which to blackmail people. I can imagine them eavesdropping on bankers, looking for inside information with which to make stock purchases. I can imagine them stealing account information, hijacking telephone calls, committing identity theft. On the business side, I can see them engaging in industrial espionage and stealing trade secrets. In short, I can imagine them doing all the things they could never have done with the traditional telephone network.

This is why encryption for VOIP is so important. VOIP calls are vulnerable to a variety of threats that traditional telephone calls are not. Encryption is one of the essential security technologies for computer data, and it will go a long way toward securing VOIP.

The last time this sort of thing came up, the U.S. government tried to sell us something called "key escrow." Basically, the government likes the idea of everyone using encryption, as long as it has a copy of the key. This is an amazingly insecure idea for a number of reasons, mostly boiling down to the fact that when you provide a means of access into a security system, you greatly weaken its security.

A recent case in Greece demonstrated that perfectly: Criminals used a cell-phone eavesdropping mechanism already in place, designed for the police to listen in on phone calls. Had the call system been designed to be secure in the first place, there never would have been a backdoor for the criminals to exploit.

Fortunately, there are many VOIP-encryption products available. Skype has built-in encryption. Phil Zimmermann is releasing Zfone, an easy-to-use open-source product. There's even a VOIP Security Alliance.

Encryption for IP telephony is important, but it's not a panacea. Basically, it takes care of threats No. 2 through No. 4, but not threat No. 1. Unfortunately, that's the biggest threat: eavesdropping at the end points. No amount of IP telephony encryption can prevent a Trojan or worm on your computer -- or just a hacker who managed to get access to your machine -- from eavesdropping on your phone calls, just as no amount of SSL or e-mail encryption can prevent a Trojan on your computer from eavesdropping -- or even modifying -- your data.

So, as always, it boils down to this: We need secure computers and secure operating systems even more than we need secure transmission.

This essay originally appeared on Wired.com.

Posted on April 6, 2006 at 5:09 AM • 61 Comments

Comments

Magnus NordlanderApril 6, 2006 5:54 AM

I feel that while Skype is encrypted (using AES, I believe) it is a closed protocol. Security by obscurity is a bad security model, and why should I trust Skype ltd.? For all I know, they could be doing some man-in-the-middle-attack on all my calls.

Zfone (which uses ZRTP) is interesting, and it is an open standard. I also find the protection against man-in-the-middle-attacks very interesting, using short verification phrases.

The problem with adapting ZRTP is that there already is a standard for securing RTP, SRTP, which already is implemented in a lot of hardware for VOIP.

shlurpApril 6, 2006 5:59 AM

My VoIP endpoint is a VoIP terminal adapter, not a PC. It does have firmware upgrades, though.

TimApril 6, 2006 6:10 AM

Although the points you make are all valid, I would have thought unsecured email is a vastly greater threat as it's much easier to scan it for useful information automatically.

It's interesting that there doesn't seem to have been more instances of people's email being intercepted and read - I wonder why that is?

JonasApril 6, 2006 6:12 AM

While Skype hardly is VoIP is any more than a very strict sense of the term, much of it's obscurity encryption was cracked recently at a conference. You can find it with Google. There were remotely exploitable holes in there as well, which shouldn't surprise anybody.

The problem with SRTP is the key distribution. It hasn't succeeded in e-mail for some fifteen years, and now we want to do it with phones? Not a chance. At least Zimmermann has an idea with a lot of potential to it, but it has to get widely implemented as well.

nefthyApril 6, 2006 6:16 AM

@jonas

well thats the paper i linked :) They didn't fully crack (the encryption is good as they said) it but they succeded in using the skype client to do evil things, like scanning a network from behind its firewall.

GiacomoApril 6, 2006 6:31 AM

Bruce,
is this an endorsement of "Trusted Computing" and/or other similar attempts?

GiacomoApril 6, 2006 6:34 AM

Sorry, I didn't want to sound trollish, the question just came up in my mind :)

drjat42April 6, 2006 7:04 AM

You missed the main vulnerability of all phone calls: someone listening directly to either party speaking and maybe (over)hearing the other party through the local speaker. I've listening to hundreds (thousands?) of phone calls this way and never used any of the others.

I've also listenned to a talk by Robert Morris, Sr. about the lengths the NSA goes to try to secure phones against eavesdropping.

Clive RobinsonApril 6, 2006 7:19 AM

Bruce,

The problem you are looking at is a subset of a more general problem that is going to get worse as time goes on.

The Internet is designed for "Insecure" "fixed" end points not mobile systems. The majority of users now want "Secure" "mobile" connectivity, not just in their pocket but (in some currently rare cases) for their services as well (think video feed from a helecoptor to another vehical for Police / Customs / Military use).

Voice / Video and a number of other types of data require very very low latency and some will tolerate packet loss more than they will variable latency (jitter). Basically analogue data (the stuff we humans use) can have the gaps filled by filtering algorithums efficiently, wherease jitter can realy only be cured with bufferes that add further latancy.

There are technologies out there (RSVP, MPLS, RTP etc) that can help but they still rely on Fixed Insecure end points.

Most VPN's are plain unworkable when it comes to realtime/streaming data feeds, they generally use encryption in the wrong way (ie block encryption not stream) and they badly packet mangle. They also have no provision for moving end points.

It was only back in Dec 2005 that people actually started to sit up and talk about this in any real terms, prior to this every body kind of assumed that you could just bolt stuff together from existing technology.

In reality our current protocols are not going to work for "secure" "mobile" systems and the whole issue needs a very serious re-think from the ground up.

Clive RobinsonApril 6, 2006 7:25 AM

@drjat42

I have seen one of these measures, imagine (if you will) a security gaurd pushing a bright yellow device like a large floor polisher. On top it has a flashing light and it emits an audible warning that can be easily heard through a fairly solid wall.

A person who is "not cleared" is acompanied by the gaurd and the device from the reception point all the way to their destination. It's like being acompanied by an automated leper bell.

Dimitris AndrakakisApril 6, 2006 8:15 AM

> A recent case in Greece demonstrated that perfectly: Criminals used [...]

You know, there's a pretty good chance that the "criminals" are actually the NSA or the MI-6. As experts have stated again and again, it is highly unlikely that any criminal or other non-goverment organization has the necessary know-how for something like that.

Nikos KaramesinisApril 6, 2006 8:44 AM

Encryption is a very important issue on VoiP but not the only one. I believe that entity and data origin authentication is equally important as encryption so that you know with who you talk. Otherwise we are definately qoing to experience VoIP phishing attacks in the near future which I am sure they are going to cause a lot of trouble. Bear in mind that encryption provides confidentiality services not entity or data origin authentication. Replay and reflection attacks are always possible even with encrypted messages.

I think it is about time that developers started thinking about VoiP security. So far they were all struggling to deliver Quality of Service on VoiP so that their products could be commercially competitive and left security behind.

RCApril 6, 2006 9:12 AM

You could also bug the room at either end of the conversation and, if the bug is sensitive enough, probably hear both persons talking.

Anon Y. MouseApril 6, 2006 9:22 AM

Just want to point out that w.r.t. method two
for landlines, you don't even need aligator clips.
An induction coil placed near the wires will pick
up the signal without ever having to break the
insulation or make contact with the conductors.
Later, when you remove the coil, there's no trace.

My sister had her own phone line in the bedroom,
and my father used this method over thirty years
ago to eavesdrop on her conversations. You can
even rig a tape recorder that will start & stop
with the change in voltage that signals a call
is taking place.

Anon Y. MouseApril 6, 2006 9:27 AM

With regard to method two for land lines, you
don't even need aligator clips. An induction
coil placed next to the wires will pick up the
signal. You never have to break the insulation
or make direct contact with the conductors.
Later, when you remove the coil, there's no
trace. No particular skill required.

AGApril 6, 2006 10:00 AM

@Bruce Strange you did not mention method 5?
The one were the CIA listens to your brain waves from their secret bunker in the polar ice cap. Method 5 can be easily blocked though by wearing tin foil on your head.

derfApril 6, 2006 10:25 AM

There will never be perfect security.

Any information that can be put into a computer or electronic format has to have a method of getting it back out. Anyone with enough time, resources, and ingenuity can get that data.

The real question is - how long will it take?

The time it takes to break into the datastream needs to be longer than the usefulness of keeping the data confidential. Personal information like medical and government assigned identity numbers have no time restrictions - they need to stay confidential indefinitely. However, there isn't a storage or encryption mechanism that can keep data confidential indefinitely, regardless of how well it might be encrypted. If I want your medical history, for example, I can get a job at your doctor's office and get "legitimate" access to your medical file.

Communication is similiar. Even if you had the perfect encryption algorithm, you still have to get the data from your mouth into the phone and back out on the other end. Obscurity might be your best bet for a secure conversation from your end. Pick a random noisy bar and use their phone - prevailing overhearing techniques won't work, and whomever is trying to tap you likely won't have time to intercept the phone call.

alienApril 6, 2006 10:35 AM

VoIP does not equal VoIP over Internet. A PC does not have to be connected to a handset end-point. Risk is inherited by any service using your computer for communication, whether voice, text chat, etc. The only risks inherited by VoIP are those inherent to the lower layers in use. Just because a computer doesn't have to be involved doesn't negate all the sources of risk Bruce has detailed.

For example, SIP calls via a wireless handset can be easily pulled out of the air and decrypted if the wireless networking used is 802.11* without WPA or better.

stacyApril 6, 2006 11:33 AM

"My VoIP endpoint is a VoIP terminal adapter, not a PC. It does have firmware upgrades, though."

Any that I have seen still have an OS under them (Windows CE or VxWorks, etc). You just have different vulnerabilities to deal with. For example:
http://www.wirelessve.org/entries/show/...

Bruce SchneierApril 6, 2006 1:41 PM

"@Bruce Strange you did not mention method 5?
The one were the CIA listens to your brain waves from their secret bunker in the polar ice cap. Method 5 can be easily blocked though by wearing tin foil on your head."

I left out everything outside the phone call. Certainly a room bug is another way of listening in on half a phone conversation.

Bruce SchneierApril 6, 2006 1:42 PM

"You know, there's a pretty good chance that the "criminals" are actually the NSA or the MI-6. As experts have stated again and again, it is highly unlikely that any criminal or other non-goverment organization has the necessary know-how for something like that."

I've thought that from the beginning.

Bruce SchneierApril 6, 2006 1:44 PM

"is this an endorsement of Trusted Computing' and/or other similar attempts?"

Many of the ideas behind Trusted Computing are sound. My only rule is that the user has to be in charge. When it becomes a system to limit competition and enhance monopolies...that's when I don't like it.

Pat CahalanApril 6, 2006 2:02 PM

You don't even need to focus on VoIP. VoIP is just an example.

What this article is really about is the security differences between a packet switched network and a circuit switched network. Eavesdropping techniques that apply to one network don't necessarily apply to the other.

Particularly in the case of the cap-I internet, it's virtually impossible to defend communication without encryption of the packets. Old school circuit switching still has major advantages over packet switching...

@ Nikos, Clive

> I believe that entity and data origin authentication is equally important as
> encryption so that you know with who you talk.

Not equally important, but important. If I'm calling my wife on an IP phone, and someone other than her attempts to masquerade, I can probably figure that out using the ol' grey matter. On the other hand, I probably don't want anyone listening in. So there's a class of calls where I don't need the verification of the data origin as a built-in feature, I get that through humanint. Whereas I probably always want integrity of the communication (no eavesdropping).

> The majority of users now want "Secure" "mobile" connectivity

We have the tools, we just haven't deployed them. IPv6. QoS. Let's face it, if you want secure mobile connectivity, today's public internet isn't the place to be.

You're right, Clive, but IMO trying to "change" the Internet to provide secure mobile connectivity isn't going to work -> the Internet is just too big of a beast to move easily. I think you'll see more secure mobile connectivity on private networks. Once the private networks get a big enough weight, things will change.

LongwalkerApril 6, 2006 2:55 PM

@Clive Robinson:

Some VPNs will pass VOIP traffic well. Secure VOIP over OpenVPN, for instance, really is just a matter of plugging the parts together. I use a SIP-over-OpenVPN setup routinely. Quality is not degraded even with very strong (2048bit DH keys, 256bit AES) security settings.

In the medium term, the biggest problem with widespread deployment of encrypted VOIP won't be technology but rather government interference. Neither law enforcement or national security establishments will put up with an environment where a non-trivial portion of voice conversations are resistant to legal or illegal monitoring. If a solution is developed that allows for routine use of encrypted VOIP, governments will move to disrupt its deployment in order to 'prevent terrorism.' If governments are feeling generous, they'll tolerate secure VOIP with a backdoor or key escrow. If they're not feeling generous, they'll just ban it outright.

QuantumGApril 6, 2006 5:28 PM

You forgot to mention the immortal classic of putting a tape recorder under the desk where the telephone is typically used. A lot easier than connecting alligator clips to the phone. Similarly, you can install a bug inside the handset.

spanchoApril 6, 2006 7:10 PM

you didnt mention one other way to listen in no phone conversations: most cell phones now are bluetooth inabled, and with the bluetooth antini that was deminstrated at last years Defcon, it is possable to take over a cell phone from long distance and hear whatever the cell phone hears, even if its just sitting in someones pocket

LongwalkerApril 6, 2006 7:10 PM

@JakeS

My thoughts exactly. ISPs are getting so aggressive at filtering traffic that before long, most internet access will be restricted to web and email only. Everything else--VOIP, FTP, VPN, streaming media, downloading large files, P2P, rsync, etc--will be charged a premium transit fee, if it's permitted at all. ISP greed will take care of the VOIP 'problem' and the P2P 'problem' without governments needing to do anything.

LongwalkerApril 6, 2006 7:11 PM

@JakeS

My thoughts exactly. ISPs are getting so aggressive at filtering traffic that before long, most internet access will be restricted to web and email only. Everything else--VOIP, FTP, VPN, streaming media, downloading large files, P2P, rsync, etc--will be charged a premium transit fee, if it's permitted at all. ISP greed will take care of the VOIP 'problem' and the P2P 'problem' without governments needing to do anything.

Jan Theodore GalkowskiApril 6, 2006 7:14 PM

Bruce may have addressed this somewhere in his many blog entries, but i was pretty amazed on the road a couple of times in the past three years how many times someone tried to get into my wireless notebook. i was using the hotel's free wireless LAN and my firewall caught someone trying to get in. i returned to the same hotel over the next couple of weeks and there the guy was. one was so persistent i had to spoof my MAC address to get away.

the other place was Walt Disney World. they have recently added broadbank access in their luxury hotels. well, during a week's stay there, it seemed there were people who just sat on the network looking for people to link in, and they tried to get onto their machines.

i have heard that there are people who hunt for information in hotel clusters catering to business travelers. but until i experienced these attempts, wouldn't have believed it.

LongwalkerApril 6, 2006 8:26 PM

It depends on who's doing the scanning, of course, but a lot of these twits will go away real fast if you turn around and nmap them. If they don't take the hint, a syn flood will get their attention.

RogerApril 6, 2006 8:40 PM

Nice essay, Bruce, and something that needed to be said. I don't think most people realise just how ridiculously weak the security is on these dang things. I recently saw an essay on how SIP works, and my first thought was "Wow, talk about Internet Dark Ages: no security at all!".

I don't understand the arguments about QoS etc. Zimmerman made PGPfone, an encrypted VoIP software phone, freely available all the way back in 1995. I used it on a Pentium Pro for transcontinental phone calls over a dial-up modem, and it worked just fine. Latency issues were barely perceptible but not enough to annoy, although it did introduce a little echoiness if one of the callers was using speakers and desk mike instead of a headset. Noise and other signal quality issues were no worse than an average cellphone call. Certainly it was easily possible to recognise a speaker's voice.

PGPfone still exists (although no longer maintained) and works on Win 2K. On a Pentium IV and ADSL, with voice quality turned up to the max, it is clearer than a landline.

The security model is interesting; basically it just did unauthenticated Diffie-Hellman for key establishment (which as we know is secure against passive eavesdroppers but is vulnerable to a man-in-the-middle attack), then authenticated both the users and (a hash of) the session key by human voice recognition.

In fact the only thing PGPfone had missing more than decade ago was a roaming directory service [1]; you had to go on IRC and say "hey Alice call me on 192.0.2.1". And since 1996, systems like ICQ (and later AIM, Yahoo Messenger, MSN Messenger, Jabber etc.) have had the roaming directory "problem" solved.

So to the product manufacturers who are moaning that security is too hard to integrate with QoS, I call bull.

____
1. Well, one other small issue is that PGPfone works peer-to-peer, which means it doesn't work if BOTH endpoints are NATTed, unless at least one end can configure their NAT for particular incoming services. Thus, not too friendly to unsophisticated home users or for "unofficial" inter-office use. On the other hand it also means that over ADSL, calls with endpoints in the same country have negligible latency.

nbk2000April 6, 2006 10:21 PM

About cryptofone:

While the algorithm may be open-source and found secure, is the hardware it's running on secure?

Could be that there is a backdoor key installed in the chip that the datastream is encoded to before it's run through the actual encryption algorithm that the phone creators are using.

It'd take putting someone in the chip fab plant on the payroll to design in the required backdoor, but how hard would that be for the NSA or its equivalant?

VidKidApril 6, 2006 10:41 PM

I think too much is made of the vulnerability of IP packets vs traditional phone tapping methods. A VoIP call is susceptible to the exact same problems as a traditional voice call - someone with access along the path can intercept the call. Yes, one can make up scenarios in which the VoIP call is vulnerable but the analog call is not, but those are 'movie-plot' attacks (as someone is fond of saying).

Filias CupioApril 6, 2006 11:13 PM

@Bruce "Many of the ideas behind Trusted Computing are sound. My only rule is that the user has to be in charge. When it becomes a system to limit competition and enhance monopolies...that's when I don't like it."

Would a TC system designed for the benefit of the computer user look different from a TC system designed for the benefit of the RIAA?

At least one "user TC" application (playing network games and assuring other participants you aren't running a hacked client) demands the same capabilities as some "RIAA TC" applications.

packratApril 7, 2006 5:22 AM

@Filas Cupio "At least one "user TC" application (playing network games and assuring other participants you aren't running a hacked client) demands the same capabilities as some "RIAA TC" applications."

That's not a "user TC" application, though, at least in the sense that I understand the term. IMO, no trusted computing system should prevent a user from running code of their choice on a system they own. The only legitimate application of TC is to prevent code from performing actions that the user has not authorized. A robust game protocol should prevent cheating to begin with, instead of relying on an arms race of hack and counter-hack.

David CantrellApril 7, 2006 7:11 AM

It's worth noting that lots of cordless phones use digital signalling, so you can't just listen in with any old radio receiver. In fact a quick check on a few online shopping sites didn't turn up a single analogue cordless phone.

I believe that the DECT standard includes some encryption, although I have no idea what they use.

Bruce SchneierApril 7, 2006 8:14 AM

"Would a TC system designed for the benefit of the computer user look different from a TC system designed for the benefit of the RIAA?"

Ross Anderson has written about this. I don't have time right now to chase down the URL, but his writing on the topic is worth finding and reading.

Bruce SchneierApril 7, 2006 8:15 AM

"You forgot to mention the immortal classic of putting a tape recorder under the desk where the telephone is typically used. A lot easier than connecting alligator clips to the phone. Similarly, you can install a bug inside the handset."

I deliberately ignored the "room bug" type of attacks.

Bruce SchneierApril 7, 2006 8:19 AM

"What this article is really about is the security differences between a packet switched network and a circuit switched network. Eavesdropping techniques that apply to one network don't necessarily apply to the other."

That's a really good point.

Clive RobinsonApril 7, 2006 10:23 AM

@Bruce & Pat Cahalan

"What this article is really about is the security differences between a packet switched network and a circuit switched network. Eavesdropping techniques that apply to one network don't necessarily apply to the other."

Actually the differences between the two as far as monitoring is concerned are in many ways quite slight. Also with the majority of voice traffic now actually being carried on private IP networks overlaid on circuit switched networks it's largley irelevant. Due to this illicit interception now becomes more interesting as you pick the network layer to attack...

The real difference (and it is an important one) between traditional circuit and packet switched networks is the ability to subvert the network to do the intercept and monitoring.

Traditional IP networks use in band signalling and route packets on a packet by packet basis, this gives an inteceptor the ability to divert a data stream to/through their own node. This is an integral part of the way IP is routed and can be done at any time during the "call in progress".

This ability gives IP it's traditional resiliance to network loss (which is why most major Telcos are moving over to private IP networks on top of their circuit switched backbones).

However this "call in progress" re-routerbility is starting to disapear for a number of reasons. Primarily (for this discussion ;) however is that traditional IP network routers are being replaced with switched routers, that implement RSVP and Tagged packets (MPLS/LDP/TDP). The IP trafic is now effectivly circuit switched to get QoS and other efficiencies (see Cisco networks MPLS enabled switches / routers, http://www.cisco.com/univercd/cc/td/doc/product/... for more details).

If you are confused at this point I am not surprised ;)

Traditional Circuit switched systems have used outof band signalling (SS7) for many years, and unless the ability is already built in the switches do not support "call in progress" re-routing, they just fail when network problems occur (which is why the DoD started TCP/IP).

This is a result of the circuit switched networks +100 year history (yes it preceads Strowger and his "Womenless Fickleless system") in that the network is assumed to be either in service or out, and untill fairly recently needed manual intervention to bypass any network faults that occured.

This is why various Goverments insist on a monitoring ability is built into the circuit switched networks switches, usually in the CO switches not the trunk switches. It works like the Unix TEE command in that the CO switch duplicates the packets and sends the duplicate to the monitoring destination.

Whilst it is possible to detect traditional IP network routing changes on a "call in progress" by changes in lag, jitter and route monitoring (traceroute) it is not possible to do this on a circuit switched network unless you have access to the out of band signalling, and even then it is unlikley.

The upshot of this is that modern circuit switched systems can easily be monitored undetectably to the users by the network owner (or those that have influence over them) and their "trusted" but not nesceseraly reliable employees.

The ability of third parties to do the same requires them to actually gain acces to the switches and subvert them via the out of band signalling system at the CO switch (which should be nigh on impossible).

Unfortunatly as has been proved a number of times "security" is not something inherent in the SS7 signalling network and it has been quite easily suborned in the past often due to implicit trust within the network (think IP and rhosts for comparison).

Also unfortunatly the ITU does not appear to particularly rate SS7 security as an issue so this situation is not likley to change any time soon.

Due to a traditional IP networks inband signalling it could in the past be quite easily intercepted and monitored by any other user on the network any where in the world almost untracably. All they needed was the technical ability to change the routing table on intervening nodes.

This was known for many years in the security community before it became public knowledge (Kevin Mitnick / Tsutomu Shimomura). Because of this IP based networks are changing to make this sort of "exploit" increasingly more difficult (but not impossible).

I guess the ITU and the Telco's need to play catch up darn fast...

Clive RobinsonApril 7, 2006 11:37 AM

@Pat Cahalan

"IMO trying to "change" the Internet to provide secure mobile connectivity isn't going to work -> the Internet is just too big of a beast to move easily. I think you'll see more secure mobile connectivity on private networks. Once the private networks get a big enough weight, things will change"

Pat, there is no reason to change the Internet (whatever it might currently be ;) all the problems to do with mobile - mobile connectivity are due either to history (fixed end point design) or hacks to get around other issues (NAT, Firewalls).

The main issue is that all of the protocols out there at some level have the inbuilt assumbtion of one or more fixed end points for the duration of a call. There are hacks that will allow one end to move around during a call but not both.

SIP for instance allows both ends (clients) to move around at any time but not the proxies. It assumes however that once a client has registered with a proxie the clients network address remains unchanged if it does then the client has to register again. SIP registering can be expensive as it requires re-authentication (SIP needs tickets and simple re-register ;).

Likewise once a call is in progress RTP cannot dynamically change the IP addressess.

Like wise most VPN systems cannot handle end point IP address changes without re-starting the tunnel. Also most VPNs have other significant problems due to their design (packet mangaling and bad latency). The cure for VPN latency by the way is to use stream encryption and pre-compute the key stream, that way the overhead on the payload is the XOR process on each byte. However as Bruce will confirm there are a number of interesting issues with stream encryption that do not happen with the various chaining modes of block encryption, so packet size mangaling remains a requirment.

What is needed is for somebody to actually sit down and say "fixed point to point connectivity has been out grown", "What is required by users is full mobile connectivity".

From a simplistic point of view what you need is VPN that is designed specifically for IP address changes and fully dynamic routing.

For a start you could assume that the easiest way is to put a gateway on every device that comes after the IP stack and works just above the network layer. That way all the existing software will continue to work just fine, the gatway converts the changing "mobile" network level addresses back to a fixed end point scheam for it.

For initial simplicity and low complexity clients (like IP phones) you would have to assume a mid-point proxy and registry that has fixed network addresses (it's not strictly nessacary but it makes life easier ;) that each mobile client connects to. Therby converting the complex "many to many" problem to two (or more) simple "one to many" problems.

Likewise you would probably make the proxy responsable for handaling the "or more" and "many" issues with the one to many relationships. Thus simplifying the client andMobile-VPN issue by reducing it to a point to point encryption link.

However there is no real reason why you have to do this, again using the SIP view of the world the gateway on each mobile client could on detecting that it's network address was about/likley to change could re-register it's new address with the SIP registry and send re-invite messages to the gateways on the devices it is communicating with (or the proxies they are using).

Also as the gateway to gateway VPN is established there is no reason for it to be torn down and re-established providing it has in built network location less authentication (ie payload level).

To deal with the issues of NAT and firewalls you would need to use inband signalling, and a general broadcast model working on a single port for all gateway to gateway communications which SIP does not currently support (look at how IAX gets around the issue for a starting point).

While I'm on my soap box STUN is realy the wrong way to go about it SIP needs to be changed to a general broadcast model on one real (UDP) network port using a virtual port (circuit number) for signalling and a virtual port for each media stream, that way it will become NAT independent irespective of the number of NATs it has to traverse.

That way all a NAT has to do is redirect any incomming (UDP) packets on the inbound port to the originating device, irispective of which network address it has come from.

Any one feel like writing an RFC?

Pat CahalanApril 7, 2006 3:58 PM

@ Clive

> If you are confused at this point I am not surprised ;)

No, I follow you. What I was saying is that Bruce (in his article) was comparing historical telecommunications interception to modern telecommunciations interception, using the particular case of POTS vs. VoIP.

Sure, you can pass VoIP traffic on non-public networks (and you can pass IP traffic through virtual circuits and all that if you control the network), but I don't think he was trying to talk about the security implications of how major telcos do business.

He was pointing out to the Wired audience that for the most part, your old POTS line could only be eavesdropped upon in certain ways, most of which required you to be a particular target and/or some sort of privilidged access to the communications network. Whereas nowadays if you're on the public Internet using a VoIP application, any network between you and the target of your VoIP communication can sample the packets as they pass by (therefore, they have to be encrypted)... both the "particular target" and "privilidged access" elements are more or less removed.

RofloApril 7, 2006 4:08 PM

@drjat42:

I probably got this link precisely from Bruce's blog, but I can't remember:

http://networks.silicon.com/mobile/...

For the lazy: A guy talking out loud with a blackberry (in the London Intercity train) gives out a conference number and pass code. The writer decides to join the conference.

winstonApril 10, 2006 12:13 AM

Older analog cellphones are vulnerable to eavesdropping with a modified phone or scanner. As of 2001, there were a fair amount of conversations that could be picked up.

jthdApril 10, 2006 2:19 PM

To add to your threat model for POTS, there is 4(b):
if you are using a intermediary to route your calls (e.g. low-cost international provider), they can listen in too. In the UK at least this is quite a significant issue (as there are many such providers, competing on their bargain basement costs).

I thought of this when reading the following text:
http://www.jajah.com/info/en/usage.asp
"Is my conversation secured when I use JAJAH?
Since JAJAH offers phone-to-phone services, the conversation is as secured as any other call you make from the same phone. "
- this nicely glosses over the fact that they've inserted a man-in-the-middle into the call.
(This is extra confusing in the context of this discussion, as they make a wild claim of being a VoIP company, purely because they force you to /setup/ your call over IP)

MichaelApril 12, 2006 8:38 PM

How hard is it to get a wiretap by impersonating law enforcement officials? From what I understand, the tap has to be installed even on a faxed request. How many telcos know how to authenticate a request from law enforcement? How many do it?

Same impersonation problem as applies to many other entities, such as apartments. If two guys showed up in suits and claimed to be from the CIA and needed to get into apartment 123 right away, is a little apartment manager or rentacop gonna try to verify?

Ricky CharletApril 17, 2006 1:49 PM

Bruce,
I think you have covered less than 5% of the solution. The problem space you laid out was to make VOIP calls secure from evesdropping while in transmission across the Internet. Your solution was (my paraphrase) "apply a cipher".

Yes, that would work. However it sort of skips around the hard point of authenticating the end points. For we know that it does no good to have a private conversation with your-not-really-sure-whom.

Any to any authentication is still not a solved problem in the Internet. And if it ever were solved would carry along with it radical social implications. Therefore any to any VOIP security is a very much harder problem than "apply a cipher".


shogunApril 24, 2006 2:18 AM

Is Zfone by Phil Zimmermann real? I have already tried to download Zfone several times, however, I have never received an e-mail with a download link as I should have according to the Zfone download site. So is (i) Zfone real und why does Zimmermann (ii) not just provide a standard download URL or even a repository?

dewdFebruary 11, 2007 5:40 PM

Corporations and Gov Municipalities are running VoIP more than ever. They can try and protect the perimiter ie IPS/IDS firewalls, SSL/IPsec. But internally...you can listen live to any VoIP call you want to with a LAN/WAN analyzer.

Corporate-if they want to can listen into the conversation...scarey

SnowmanJuly 2, 2007 12:55 PM

I'm noticing some fuss around ZFone, and honestly, the software is not secure at all. Secure means that it's secured, and what I realized is that is just puts some difficulty for someone who's eavesdropping.

Even myself -- not an expert -- could hear the conversation, what both parties were talking. Here's how it went:

I tried ZFone some time ago, and it worked fine, like advertised. Then, I sniffed the voip traffic, expecting to later decode and hear the audio as an old dial-up-modem-waterfall sound, or somethin' like it.

However, this wasn't the case. The audio gets lots of clicks, but at a same time interval, and I can still hear the voices of both parties, but much slower, making it almost unintelligible. So I decide to process the audio, removing the clicking sound, and compressing the time to double the speed, and voila. It's not perfect, but I could hear most of the conversation! And I did this with ready available tools, in a matter of minutes!

Perhaps the reason is ZFone is still beta, I don't know, but I got really disappointed about it.

It just makes it a little difficult for people eavesdropping on voip calls, who are not really putting some effort and time into the eavesdropping. I don't see any encryption going on there, just some audio scrambling.
Perhaps no one is seriously reviewing the software, I don't know whats going on.

Just my 2 cents

unixJanuary 30, 2008 7:02 PM

Thanks for this article Bruce Schneier.
Good work again from you.
Blessings for you.
unix

TyroneOctober 5, 2008 9:57 AM

Skype being recently caught implementing a real-time eavesdropping scheme for the Chinese government to monitor the content of Skypes Chinese customers highlights the importance of not relying on the encryption of the carrier. (http://www.theregister.co.uk/2008/10/02/skype_surveillance_in_china/) In all cases, you have no way to verify the encryption was not compromised, but in the case where you encrypt the VoIP yourself and have the recipient decrypt themselves means you do not have to rely on the integrity of the VoIP carrier. Again, Skype has shown relying on the integrity of the VoIP carrier is a big mistake.

Stand alone VoIP encryption is the only way to have a chance the communication is secure.

Mazuba GondweMay 18, 2010 6:44 AM

hi am a student at the copperbelt university in Zambia Kitwe in the school of technology and a diploma student. Am current carrying a research on encryption of Voip? would be glad if you can help me out with data. I will be so glad to here from you.

Best Regards
Mazuba Burwel Gondwe

Jose Antonio LuzJuly 13, 2010 5:14 PM

Uma empresa na qual fiz um consultoria usa um Gateway Criptografado no VOIP que permite criptografas todas as chamadas entre ramais cm criptografia 4096Bits para troca de chaves e AES 256Bits durante a conversa.
O que achei interessante e a integração desse VOIP com telefones móveis smartphones com se esses fossem ramais externos e tambem usando esse nivel de criptografia.
Todas as comunicações entre esses aparelhos móveis e os ramais internos da empresa me pareceram estar seguros.

Wizard_HuApril 16, 2011 5:59 AM

Can ANy oNe tell is there any open source code available implementing Encryption in SIP for Voip Calling.............?

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..