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

[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 the first place. The problem is that the spacetime information of the conversation was NOT TAKEN INTO ACCOUNT when the protocol was designed. This, in turn, means it was designed by a crew of fools.

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

Bad science

[DrYak]

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

[JeffAMcGee]

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

[rml1997]

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 shorter transmission. Complex syllables are more likely to be more different than simpler ones, so that the codec decides to encode and send the new data. Thus another solution would be to improve the codec to recognise and reuse previously sent data better for longer syllables, or maybe to resend old data more often than neccesary and at random. Before doing this, I'd like to see just how much of the data can be deciphered using this technique. I bet its not much.

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

Re:Here's a thought

[marcansoft]

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 itself carries a whole load of security problems. Your file encryption program sucks.