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

Comments

Easy Solution:

[dintech]

Easy Solution. Music in the background.

Re:Easy Solution:

[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]

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

Yes, but a joke you can dance on.

Do what my grandparents do

[phorm]

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]

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]

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

Da!

Evasive, ummm, technology

[martyb]

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]

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

Re:Here's a thought

[corsec67]

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:Here's a thought

[blueg3]

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:Here's a thought

[wolrahnaes]

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.

Protocol isn't broken - it's badly mixed

[billstewart]

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