Compressed VoIP Calls Vulnerable To Bugging

holy_calamity writes "Security researchers at Johns Hopkins report that a variable bit-rate compression scheme being rolled out on VoIP systems leaves encrypted calls vulnerable to bugging. Simpler syllables are squeezed into smaller data packets, with more complex ones taking up more space; the researchers built software that uses this to spot phrases of interest in encrypted calls simply by measuring packet size."

Easy Solution:

[dintech (998802)]

Easy Solution. Music in the background.

Re:Easy Solution:

[by Anonymous Coward]

Better solution: Fix the stupid, broken protocol.

For instance, the concept of RSA blinding had to be invented because people discovered that certain bits of the SSL private key can be determined simply by measuring the time it takes to encode messages. This was due to some implementation details inside SSLeay where it switched from one multiplication algorithm to a different one depending on the size of certain numbers in the algorithm.

OAEP had to be invented for similar reasons

"Music in the background" is not a security solution. In fact, that's a freaking joke.

Re:Easy Solution:

[Daimanta (1140543)]

""Music in the background" is not a security solution. In fact, that's a freaking joke."

Yes, but a joke you can dance on.

Re:

[ehrichweiss (706417)]

VOIP: It's got a good beat and I can bug out to it.

Re:

[martin_henry (1032656)]

Awesome....a VOIP dance party.

Protocol isn't broken - it's badly mixed

[billstewart (78916)]

This isn't a simple case of a broken protocol - it's an effect of mixing different protocols in ways that don't work together.

Voice codecs are designed to support a given level of audio quality subject to bit rate and computational complexity limitations. Most codecs are fixed-rate, or fixed-rate with silence suppression. Encryption isn't part of their design; it's somebody else's problem, and many VOIP systems aren't encrypted anyway (for instance, connections between an office phone and a PBX usually aren't.) Variable bit rate codecs are sometimes a good choice, depending on the kind of sounds you're trying to compress and the networks you're transmitting them on, and they're at least an alternative to the usual fixed-rate codecs.

Encryption systems usually aren't designed to deal with real-time message streams or timing attacks. Typically VOIP encryption protocols are designed for constant bit rate codec output, which is what most codecs provide, and the codecs usually package up 10, 20, or 30ms audio samples into a data packet for transmission over IP.

The problem occurs when you're choosing your codec and encryption separately, and you take a crypto system designed for fixed-rate codecs and use a variable-bit-rate codec instead. It's difficult to keep people from doing that sort of thing, especially if they're using huge-overhead approaches like VOIP inside IPSEC as opposed to VOIP systems with the crypto built in. It's also difficult to prevent people from making bad choices like that when they're using open-source software applications, as opposed to proprietary phones that only have the small set of codecs the manufacturer built in (typically uncompressed G.711, or G.729 or a GSM codec, all of which are fixed-rate except for silence suppression.)

Re:

[jonaskoelker (922170)]

OAEP had to be invented for similar reasons

Not true: OAEP fixes problems with the math, which by its declarative nature is timing-independent.

The problem fixed by OAEP is this: suppose you want to a message from a small set (say, a single bit, or "attack" versus "retreat"); assume for convenience the set of messages is contained in [0, n-1], where n = pq is part of the RSA public key.

If you just do plain RSA encryption (c = m^e % n), then the eavesdropper can encrypt all the values from the small set in almost no time, and see which of the encrypti

Re:

[gstoddart (321705)]

Easy Solution. Music in the background.

Oh, sure, give the RIAA reason to get involved in encrypted phone calls.

They'll try to make sure you're not using unlicensed music to mask your conversations. We'll be seeing John Doe subpoenas to get access to what music you were playing. :-P

I'm only half joking.

Cheers

Not really...

[msauve (701917)]

First, the paper was testing the Speex codec [speex.org], and in based in principle on looking at codecs which use variable bit-rate CELP, a compression scheme which is tailored to speech, not music (music sounds terrible through one of these codecs, because their dictionaries are filled with speech sounds). Having music in the background is only likely to confuse the codec, making the speech sound terrible too, possibly to the point of unintelligibility.

The conclusions do not apply to more standardized codecs like G.711 and G.729a, which use fixed size packets.

The paper itself can be downloaded from here [jhu.edu]. Get it quick, before the IEEE figures this out and make the author remove it so they can extort their fee.

Do what my grandparents do

[phorm (591458)]

Anyone wanting to avoid detection could just follow what my German-speaking grandparents do when they don't want us kids listening into the conversation: randomly switch languages on different topics (though I think that this is sometimes also because some concepts are also easier to portray in a given language).

Random switches between languages would probably confuse the heck out of filters guessing compressed data. That or you could just learn Russian... I don't think they *have* any simple-syllable words in Russian :-)

Re:Do what my grandparents do

[smitty97 (995791)]

That or you could just learn Russian... I don't think they *have* any simple-syllable words in Russian :-)

In Soviet Russia, VoIP bugs you!

Re:Do what my grandparents do

[markana (152984)]

>That or you could just learn Russian... I don't think they *have* any simple-syllable words in Russian :-)

Da!

Re:Do what my grandparents do

[mlwmohawk (801821)]

Just speak arabic!! We already know the FBI and CIA don't have enough translators.

Re:Do what my grandparents do

[MindStalker (22827)]

Depends upon how you define "translators." One of my best friends just got out of the Army, he is a really good linguist and knows several langauges, but he flunked out of the Arabic program because its not just hard to learn, you have to learn hundreds of dialects even for Iraq. He could understand it well enough but to be able to go out on the street and translate you have to be certain you won't accidentally offend with a mistranslation. Apparently virtual no non native arabic speakers ever make it through this program. Anyways he go reassigned to listen to and interpret radio broadcast and other incoming information. Not officially a translator. The point to this story?? I don't know..

Re:

[JeffAMcGee (950264)]

Going from one language to two would only make the process of breaking the message a bit more complex, and by that I mean precisely one bit more complex, because there would be about twice as many phrases to look for. This is not a solution. The solution is to not use variable bit rate compression if security is important.

Re:

[hummassa (157160)]

That or you could just learn Russian...

Which would give you an advantage, if you ever have to pilot a bleeding-edge mind-controlled Russian jet fighter.

Randomize the packets slightly

[BasharTeg (71923)]

I would think that a very slight randomization of the packets with filler would add a trivial amount of data to the packet and would tend to interfere with thier analysis. I'm sure after a certain point of added bytes and randomization, you would change their margin of error such that the process wasn't useful or effective anymore.

Re:Randomize the packets slightly

[pclminion (145572)]

Time/space attacks are well known. Somebody who actually, hmm, UNDERSTOOD cryptographic security would never have designed the protocol this way in the first place.

The people suggesting that we should just inject noise or background patterns are being ridiculous. Why sacrifice communication quality when there are BETTER ways to fix it? DO IT RIGHT.

Re:

[Creepy Crawler (680178)]

---The people suggesting that we should just inject noise or background patterns are being ridiculous. Why sacrifice communication quality when there are BETTER ways to fix it? DO IT RIGHT.

Injecting "noise" makes sense for me. Why so?

We use a salt for our hashes, dont we? The "noise" would be the same thing. Consider this: during negotiation, we have chaotic noise formulas in which we propagate the variables so that each side knows the noise transform. We then add the noise after digitalization but before e

Evasive, ummm, technology

[martyb (196687)]

FTFA

In tests on example conversations, the software correctly identified phrases with an average accuracy of about 50%. But that jumped to 90% for longer, more complicated words. Wright thinks these phrases may be the most important. "I think the attack is much more of a threat to calls with some sort of professional jargon where you have lots of big words that string together to make long, relatively predictable phrases," he says. "Informal conversational speech would be tougher because it's so much more random."

So, ummm, what we should do to, umm, well, protect ourselves from, ummm, yaknow, eavesdroppers, heh-heh, is well, make sure there's enough, ummmmmmm, yaknow, like extra noise, like, mixed in, dude.

Re:Evasive, ummm, technology

[gstoddart (321705)]

So, ummm, what we should do to, umm, well, protect ourselves from, ummm, yaknow, eavesdroppers, heh-heh, is well, make sure there's enough, ummmmmmm, yaknow, like extra noise, like, mixed in, dude.

Oh my god, thats like, totally, like, a great idea, yaknow. I mean, like, they'll never figure out what we're, like, saying, yaknow?

Oryoucouldspeakreallyfastwithoutpausesbetweenwords. Thatwaythey'llneverknowwhatyousaid =)

Or. We. Could. All. Speak. Like. Shatner. Random. Long. Pauses. Genius.

Cheers

It's easy to encrypt your conversations

[muellerr1 (868578)]

Just st-st-stuh-stutter when you talk. And use a lot of, uh, you know, um, non-word sounds between, uh, like, your phrases. And don't use any complexificated words without Bushifying them first. Better yet, only speak in Klingon.

Or maybe you shouldn't say anything on VoIP that you don't want anyone else to hear.

Re:

[Ephemeriis (315124)]

Or maybe you shouldn't say anything on VoIP that you don't want anyone else to hear.

A couple honest questions...

1) Why do I see so much about wiretapping/bugging VoIP lately? I guess I've always assumed that VoIP was just as vulnerable to bugging as POTS - maybe even more so. Was I wrong? Was VoIP previously un-buggable and this just recently changed? Or is it just because VoIP is the new, cool thing?

2) Why would anyone think that compressed VoIP would be any more or less secure than uncompressed? As

Re:

[mmkkbb (816035)]

From the article summary above: "a variable bit-rate compression scheme being rolled out on VoIP systems leaves encrypted calls vulnerable to bugging" and "spot phrases of interest in encrypted calls simply by measuring packet size."

Emphasis mine.

This is compressed, encrypted VOIP

[billstewart (78916)]

1) You're seeing lots about bugging and wiretapping VOIP because VOIP use is increasing, and because the buggers in government are getting really aggressive about wanting to wiretap people. VOIP is potentially less secure than POTS, because there are more ways to tap the Internet than traditional phones (where you either use alligator clips on the wire or go to the phone company office), and it's also potentially much more secure than POTS, because the end users can do their own encryption without needing

Re:

[6Yankee (597075)]

the buggers in government

Oooh. Well played, Sir, well played.

Re:

[gstoddart (321705)]

Or maybe you shouldn't say anything on VoIP that you don't want anyone else to hear.

Well, then what's the point in saying it at all then? ;-)

Oh, you mean someone other than the person you're talking to. My bad. :-P

Cheers

Bad science

[DrYak (748999)]

First, the article mixes things :
vowels actually are simpler than consonant to compress (because of spectral complexity - consonant use much more different frequencies. They are mostly noises and have a more "random"-like wave form making them harder to compress). They got it completely in reverse.

Then TFA doens't show a method to magically guess was is being said over a crypted channel only by looking at the bitrates, it only says that it finds some predetermined pattern in a given set of samples to test against. The whole thing would only be able to answer to some very simple questions like "did the words XYZ appear in the conversation ? or did ABC appear in the conversation ?" - with a rather bad success rate if those words are long and complex enough - which hardly makes it enough to obtain personal information or otherwise efficiently spy on someone.

Then the whole system has a lot of short comings :
- As said before it assumes that the spy know exactly that some phrase has to be said - if the spy doesn't guess exactly what words he must search for the attack fails (the users may be speaking in a foreign language to begin with).
- It assumes that the speech-generator-made needle they are looking for in the hay sack will be close to what they are looking for. The users may have an accent and pronounce words differently (cf alumnium vs. aluminium, etc...)
- And worse of all, it assume that the granularity of the packed will be small enough so that the phonemes will have an influence on the bit rate. Whereas in reality, short packets have a big overhead of bandwidth, longer packets increases the latency. But lots of VoIP users are happy with a 500ms latency because it really diminishes the overhead. At 500ms you can have a couple of words in a single packet. The whole packet will tend to have a corresponding bandwidth close to the average (there will be small difference between phonemes, but these will all be packed into the same packet and will average).
- It fails to take into account an interleaved video stream. Video conferencing is really popular, and its own bandwith will completely dwarf the bandwidth used by audio. So unless the VoIP uses 2 separate stream (some VoIP systems do), and only encrypt at the stream level, and the transmission is happening over a non crypted channel (no sane person should do that), this method will fail epically.

Re:

[pclminion (145572)]

Then TFA doens't show a method to magically guess was is being said over a crypted channel only by looking at the bitrates, it only says that it finds some predetermined pattern in a given set of samples to test against.

I don't care. Good cryptosystems should be absolutely impenetrable. Even the smallest flaw is like a crack in a dike. Maybe it will expand and blow the dike, maybe it won't. But it's simply UNACCEPTABLE to have cracks in the dike, and it's UNACCCEPTABLE to have known weaknesses. Whether

ode-cay

[fahrbot-bot (874524)]

Ust-jay eak-spay in ode-cay.

Why change the packet size?

[argent (18001)]

Send fixed size packets, splitting longer syllables into more packets and packing multiple short syllables into single packets.

Re:

[rantingkitten (938138)]

Then you'd be losing the point of compression, in which case you could bypass the problem entirely since the attack relies on examining the compression. :)

In fact, you might be making it worse at that point, since now it's not compressed and you're splitting things into more packets than you were before, which could compound any latency-related issues that may be present.

Re:

[pclminion (145572)]

Hahaha! Compressing encrypted data?! My sides are splitting!

In case you can't figure it out: good encryption makes data look completely random. Do you know of any algorithms which compress PURELY RANDOM data? I sure as hell don't.

Re:Here's a thought

[blueg3 (192743)]

There's a reason for that. With a good encryption mechanism, the ciphertext will have maximum entropy (one bit of entropy per bit of ciphertext). Random data also has maximum entropy.

The point of compression is to take data that's expressed in a way that doesn't maximize entropy and reexpress it in a way that is higher-entropy (more information per bit). As such, maximum-entropy data is, by its nature, incompressible.

Re:

[mhall119 (1035984)]

It's funny, because if I take any random file, make 10 copies of it, encrypt all 10 with the same key, then compress them all together, I actually do get some amount of compression.

Unless you plan on not duplicating sounds or sound sequences throughout your conversation, or using really big packets, chances are that you'll be repeating some of the same chunks of data, which will result in the same chucks of encrypted data, which would allow for compression. A generously lossy encoding of the original data

Re:

[marcansoft (727665)]

Even a one bit change in the input totally changes the output of data after encryption (with secure encryption algorithms anyway). So unless you feed a deterministic voice synthesizer to the VoIP compressor and adjust the timing to exactly match that of the packets, no, you aren't going to get any compressible chunks in the output data after encryption. At all. Besides, if the encryption is any good it'll use a random IV for every packet, because encrypting the same plaintext to the same ciphertext [wikipedia.org] itself c

Re:

[gstoddart (321705)]

In case you can't figure it out: good encryption makes data look completely random. Do you know of any algorithms which compress PURELY RANDOM data? I sure as hell don't.

Sure, drop every other byte. It'll be half as big. ;-)

Cheers

Voice codecs are lossy compression

[billstewart (78916)]

Voice codecs are lossy, so they'll happily compress your encryption data to something smaller, treating it as if it were audio samples from a human vocal tract. Unfortunately, you won't get all the bits back when you uncompress it, so decrypting the data isn't going to reconstruct anything resembling the original voice stream :-)

Let's try better than "information theory FTW"

[mstahl (701501)]

The entropy for a perfectly random coin toss will always be one bit. The formula, if I'm remembering right, is -sum(p_i * log(p_i)) where the p's are the probabilities of the various possible outcomes. In the case of a fair coin toss, these are both 0.5 and the outcome is 1, or 1 bit.

If the stream you're compressing has patterns in it, it is purely by coincidence and overall, the average entropy of any number of these streams will turn out to be 1 if you sample enough of them. Furthermore, if you do have a

Re:

[kbonin (58917)]

The output of any decent encryption algorithm should be indistinguishable from random noise for any non-trivial size sample, which breaks compression. In practice, most compressions of encrypted data are slightly larger than the original, as they generally are comprised of a header stating "use this directly", then the original data.

Re:Here's a thought

[corsec67 (627446)]

Except that might not help here.
The issue is that VOIP is an application that needs low latency. You have to send the data you have within (.1 seconds? something small) a specific amount of time, and can't wait for the buffer to fill before sending it, compressed, encrypted or not. Thus you get packets that are different sizes.

This isn't sending the whole conversation at once, this is a constant stream of data with specific requirements on latency.

A solution would be to make each packet the same size by padding it with random data that the other side will discard. But that eliminates some of the benefit of compression.

Maybe just use a fixed bit rate, as opposed to a VBR encoding?

Re:

[rml1997 (929311)]

GSM already performs some pretty nifty compression involving regenerating missing packets. By enhancing this, it should be possible to just send the encrypted message text and a voice profile and have the receiving phone talk in your voice. I'll get right on it... Actually, part of the problem with the encryption could be the GSM (or other codec) compression itself. It looks for similar packets and tells the receiver to use a previous packet instead of sending the new one. This would obviously be a much sh

Re:

[your_mother_sews_soc (528221)]

Some of the codecs, at least those that were developed a few years back when internet telephony first became legitimized, compress first for a good reason. They model their encoding on the "physiological" aspects of speech. The audio is analyzed for things like the noise component and formants, and simplified considerably. It is this analysis, I'm guessing, that is the "compression."

Re:

[by Anonymous Coward]

What idiot modded this up? Encrypted data is (pretty much by definition) uncompressable. Encryption works by hiding information and removing redundancy. Compression works by identifying and removing redundancy. The two concepts simply CANNOT BE APPLIED IN THAT ORDER. Go back to school -- both the OP, and whatever moron was moderating.

"Just stutter when you talk!" "Just play music in the background!" "Just switch languages in mid-sentence!" God help us. You must be the idiots who designed this protocol in

Re:Here's a thought

[oodaloop (1229816)]

Voice data just CAN'T be securely encrypted.

Really? I have a Top Secret phone on my desk, and I can assure you it's pretty secure. (And no, it's not a shoe.)

Re:

[pclminion (145572)]

I bet you that phone is not packet based, not compressed, and runs over a physically secure line. BIG fucking difference.

Re:Here's a thought

[wolrahnaes (632574)]

Voice data just CAN'T be securely encrypted. That's because the spacetime information HAS to be there because we inherently interpret voice data according to these characteristics. Either you reveal this information in the stream, or you must increase the latency to the point that communication is impossible. If you want security, don't speak, WRITE, and use a cryptosystem that isn't a piece of shit.

I disagree. The problem pointed at in this article can be easily solved on many SIP endpoints. I spend all day working on VoIP phones from vendors such as Linksys, Polycom, Aastra, Cisco, and if I really have to snom. Most of these have an option where it'll just send blank full bitrate audio rather than the usual "put silence here" instructions on G.711 calls. In fact that is the default behavior on some, since it makes the latency a bit more predictable to have a constant-rate data stream. If you want to use a VBR codec, of course this is a problem, but don't act like it's impossible or even hard to solve. If you are concerned enough to encrypt your conversations, use a CBR codec. 64 kbit/sec is not hard to free up.

Re:

[Quattro Vezina (714892)]

I love that you put "and if I really have to" before you mentioned Snom :D

Their phones are a pain in the arse to configure. You pretty much have to use their web interface. Not to mention the buttons require so much effort to push, you're pretty much guaranteed to typo anything you try to enter. Bleh.

On the other hand, I love working with Cisco IP Phones and Avaya one-X 96xx phones. The Cisco IP Phone 7970 is particularly awesome.

Polycom and Aastra phones look pretty sweet, but I've not had much of a chance

Re:

[Quattro Vezina (714892)]

Wow, I bet you're a lot of fun at parties.

Re:

[srmalloy (263556)]

What I find amusing about this announcement is that the VOIP encryption methods are reported to be vulnerable to "bugging", while Homeland Security et al. is blatting on about how it is vital to national security that they be allowed to require all ISPs to install back doors in their VOIP setups to allow them to tap and monitor VOIP calls. I guess Homeland Security can't afford to pay for decent IT security people.