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

Re:Randomize the packets slightly

[pclminion]

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:It's easy to encrypt your conversations

[Anonymous Coward]

the problem is it _is_ encrypted

Re:It's easy to encrypt your conversations

[mmkkbb]

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.

Not really...

[msauve]

First, the paper was testing the Speex codec, 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. Get it quick, before the IEEE figures this out and make the author remove it so they can extort their fee.

This is compressed, encrypted VOIP

[billstewart]

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 the network in between to be secure.

2)It's not that compressed VOIP would be inherently more or less secure than uncompressed - if you want it secure, you encrypt it. The problem is that if you use a crypto system that works just fine with fixed-rate voice (either uncompressed or with a fixed-rate codec, which most codecs are) and use a variable-bit-rate codec instead, suddenly lots of information leaks out through the timing, because the crypto system wasn't hiding the size or timing of the voice packets. So no, your decent VPN isn't taking care of it, because it wasn't designed to, and using a VPN instead of VOIP-specific encryption makes it easier for you to use whatever codec you like. Also, IPSEC is really inefficient for VOIP, and SSL or SSH are worse, because VOIP gives you a stream of lots of very small packets, and each layer of protocol (RTP, UDP, IP, IPSEC, etc.) adds more overhead - an 8kbps voice codec typically takes 24-28kbps of IP if you don't encrypt it, and maybe double if you do.

Voice codecs are lossy compression

[billstewart]

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

Re:Easy Solution:

[jonaskoelker]

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 encryptions match the ciphertext. You Have Been Decrypted. You Have Lost. Have A Nice Day.

What OAEP does: instead of encrypting just m, you pad m with some zeroes z and some random bits r. You then do the following:

left = (m and z) xor hash1(r)
right = hash2(left) xor r
return encrypt(left and right)

"and" is the concatenation operator, xor is bitwise; the difference between the hashes is the input/output sizes. Ideally the implement a random oracle.

This fixes a math problem, not a side-channel attack. How that relates to timing attacks on SSL I can't work out. See also the wikipedia article on OAEP.

Let's try better than "information theory FTW"

[mstahl]

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 perfectly random string of bits, zlib, gzip, and all the rest will deliver a bigger file because of the overhead necessary for those file formats.

Try it on the command line, dd if=/dev/urand of=random_bits bs=1024 count=100 && gzip random_bits. Getting a smaller file out of that is more improbable than being attacked by a shark while being struck by lightning while you're holding a winning lottery ticket.

Much like traffic analysis attacks on SSH

[runexe]

This is very similar to traffic analysis attacks on SSH (like this one) where packet sizes and inter-arrival times can indicate which keys you are typing.
Effective, practical counter-measures against good traffic analysis techniques are very difficult - especially if the attacked has enough traffic to work with (i.e. many conversations, many sessions, etc.).

Re:Why change the packet size?

[rantingkitten]

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:Do what my grandparents do

[wyohman]

Apparently virtual no non native arabic speakers ever make it through this program.

Not likely spanky. Were this true, the language school at Monterey would have to answer a lot of very tough questions. Like my wise grandfather used to say, "Believe half of what you see and none of what you hear."

Cheers.