Compressed VoIP Calls Vulnerable To Bugging 140
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: (Score:5, Insightful)
Re:Easy Solution: (Score:5, Insightful)
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: (Score:5, Funny)
Yes, but a joke you can dance on.
Re: (Score:2)
Re: (Score:3, Funny)
Protocol isn't broken - it's badly mixed (Score:5, Insightful)
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: (Score:3, Informative)
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: (Score:2)
Not a joke. Another layer on the onion, friend. (Score:2)
Hey AC: don't be an asshuile. We are all on the same team here no? You are right, but the irony is that because you are right, you are frustrated that people don't get it, and you react in a way that reduces the fraction of readers that will get it.
It's worth noting that the wrongest part of the dintech post you're criticizing has nothing to do with music. It's "Easy Solution"... as if. So is it going to be "give a man a fish" or "teach a man to fish?"
Re: (Score:3, Funny)
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.
I'm only half joking.
Cheers
Not really... (Score:4, Informative)
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.
Re: (Score:2)
I've always found VoIP rather humorous, since you're taking a digital channel, and shoving voice through it - you know, like the reverse of a dial-up modem.
If you're dealing with sensitive stuff that you don't want eavesdropped, do it in a secure IM session or encrypted email. Talk is overrated!
Do what my grandparents do (Score:5, Interesting)
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 (Score:5, Funny)
Re:Do what my grandparents do (Score:5, Funny)
Da!
Re:Do what my grandparents do (Score:4, Funny)
Re:Do what my grandparents do (Score:4, Interesting)
Re: (Score:2, Informative)
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.
Re: (Score:2, Funny)
I saw more than one threat from the Bureau of Prisions warning them to stop using Latvian (their native tongue) during phone calls to the incarcerated.
Re: (Score:2)
Security through obscurity indeed.
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Randomize the packets slightly (Score:2)
Re:Randomize the packets slightly (Score:4, Informative)
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: (Score:3, Interesting)
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
Re: (Score:2)
Re: (Score:2)
Evasive, ummm, technology (Score:5, Funny)
FTFA
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 (Score:5, Funny)
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: (Score:2, Funny)
You're missing one syllable in the middle line...
Re: (Score:2)
He doesn't have a full pause between every syllable. Sometimes, he'll put a couple of words together in one go as well "Spock. How. Areweto. Know. Whattodo?" or "Nurse. Chapel. Let's. Gotomyroom".
Cheers
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It's easy to encrypt your conversations (Score:3, Interesting)
Or maybe you shouldn't say anything on VoIP that you don't want anyone else to hear.
Re: (Score:3)
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: (Score:3, Informative)
Emphasis mine.
This is compressed, encrypted VOIP (Score:3, Informative)
Re: (Score:2)
Re: (Score:3, Funny)
Oooh. Well played, Sir, well played.
Re: (Score:2)
an 8kbps voice codec typically takes 24-28kbps of IP if you don't encrypt it, and maybe double if you do.
As I understand modern encryption, it adds overhead to creating the connection because encryption keys have to be shared before encrypted data can be sent, but the actual encryption is done with a cipher such that it takes up the same amount of space encrypted as decrypted, so it does not cause a size overhead on the main data transfer. Then again, if it changes keys often or is doing something else special, then maybe it would cause that much overhead.
Re: (Score:2)
Re: (Score:2)
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.
Cheers
Bad science (Score:4, Insightful)
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: (Score:2)
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
It's not a flaw in the cryptosystem. (Score:2)
It doesn't matter how good the cryptosystem you use to call the Pizza Hut nearest the Pentagon is, if you just need to count the trucks leaving the Pizza Hut to tell when there's a burst of late night activity so you can tell the invasion is about to start.
Counter measure. (Score:2)
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.
As I said, the counter measure is bloody simple :
Use longer packets.
- It saves your bandwidth because of less overhead (that's why people are *already* doing it).
- It has only a small impact upon latency.
- With long enough packets, the difference between sound averages and nothing can be eavesdropped based on phonemes compression ratio.
Re: (Score:2)
Ummm, no. Every encryption algorithm is guaranteed to be vulnerable to brute force - trying every possible key value.
Okay, wise guy -- leaving aside brute force.
Re: (Score:2)
Yes but presumably if you know that a certain phrase appears in an encrypted conversation, and when it occurs, that could allow an attacker to use a known-plaintext
Fuzzy Logic vs. Binary Information (Score:2)
Yes but presumably if you know that a certain phrase appears in an encrypted conversation, and when it occurs, that could allow an attacker to use a known-plaintext attack to discover the rest of your conversation.
No you can't. Because you don't have the plain text. What you have is a probability that some piece of the crypted transmission sounds somewhat similarly to another piece of audio you have.
You didn't actually get the clear binary data (the original wave form or the original non-crypted compressed stream).
By comparing the two pieces you have matched together you can't infer the key that was used to encrypt into another, because they actually AREN'T the crypted version of the other. They AREN'T the same data
It's only rythm based (Score:2)
If we admit that the conditions are good enough for the trick to work (short packets, no background noise, no additional data interweaved with the voice stream)
ahh, but that can be enough for overzealous evesdroppers to come a knocking. Lets say the words and phrases "Commies" "Americans" and "Kill-em-all" were found in a convo. Depending on which side you are on, and who you are directing it at, you could be either extremely patriotic, or a "terrorist", care to guess which way our overlords will assume?
Then you sent to Gitmo a poor schmuck whose girlfriend happens to be named "Connie", who complained about "drinking a merry can of vodka" the night before and now needs "some tylenol to kill the pain".
Using strong understatement, TFA were basica
ode-cay (Score:4, Funny)
Why change the packet size? (Score:3, Interesting)
Re: (Score:3, Informative)
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: (Score:2)
It would probably increase latency, but given the existing variation in latency I've seen streaming over the public internet I doubt you'd notice any increment from this.
Much like traffic analysis attacks on SSH (Score:2, Informative)
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: (Score:3)
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 (Score:5, Insightful)
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: (Score:2)
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: (Score:2)
Of course you get some compression. You probably get a file that's ever-so-slightly bigger than just one of the encrypted files. The encrypted files—assuming pretty effective encryption—have close to their maximum entropy (ideal encryption, like a well-chosen one-time-pad, would have entropy equivalent to the length of the message in bytes, making it indistinguishable from random data). Repeating them reduces the overall entropy of the message as with each identical packet no additional informat
Re: (Score:2)
Seriously it's not that simple (Score:2)
Totally not even how VoIP works. You're making the assumption that chunk #123 actually got there. There's no ACK packets in VoIP; if a packet is received out of sequence it's dropped. That's that "jitter" that happens when the line breaks up a bit every now and again. It's your packets not all taking the same route and getting to the destination device out of order.
You have to remember: VoIP is a real-time protocol, and keeping up with real time is the paramount concern, not necessarily absolute accuracy.
Re: (Score:2)
The two ends could build an map, where instead of transmitting a duplicate chunk you just send "It's the same as chunk #123".
Great -- now, if an attacker manages to decrypt "chunk #123" they now know the contents of ALL chunks labelled "chunk #123." I can't see how that's good.
Re: (Score:3, Insightful)
Re: (Score:3, Funny)
Sure, drop every other byte. It'll be half as big.
Cheers
Voice codecs are lossy compression (Score:3, Informative)
Re: (Score:2)
Let's try better than "information theory FTW" (Score:3, Informative)
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: (Score:2)
Re: (Score:2)
Omg I didn't know... I am so sorry.... ;-P
Re: (Score:2)
You might want to re-think that (Score:2)
Seriously try what I said to try if you've got a linux/unix/mac system to try it on. You'll come up just slightly larger than the original file pretty much every single time.
Considering the output of a coin toss to be a random variable, and the string of bits to be a randomly variant process of probability 0.5, the probability of any given pattern is 2^(-n) where n is the length of the pattern in bits. Square it to give the probability of that pattern repeating. In order to come up with a file that's small
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:Here's a thought (Score:5, Insightful)
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: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:3, Insightful)
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 (Score:4, Funny)
Re: (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
The third, running over a physically secure line, is certainly not always the case. High-security phones encrypt data for transmission over radio waves for communication to points that landlines don't cover (ships, teams in the field).
Re:Here's a thought (Score:5, Interesting)
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.
Re: (Score:2)
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: (Score:2)
To configure the damn thing you either have to set up a tftp server with the config files, and then pray that it works (because it won't half the time), or enter SIP inform
Re: (Score:2)
Never had any TFTP issues--usually CCM takes care of that, and we use a proxy on top of that (not Cisco Phone Proxy). I'm not a big fan of web interfaces, and I like Cisco's phone interface. That big screen is really helpful. Yeah, it'd probably suck to try and configure something small like a 7911 using the phone keypad, but luckil
Re: (Score:2)
I am not a huge fan of web interfaces (hello, commandline!) but they're leaps and bo
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It sounds like they are using whatever ciphers in ECB mode.
No. This type of attack relies on leaking information through a variable bitrate sound compression algorithm. The problem is there's more information in certain phonemes (individual speech parts) than in others, so they compress at different rates. That means you can look at the amount of information going across the wire as a function of time and guess at some of the phonemes. If there's enough of them, you can guess at some of the words. The
Re: (Score:2)