Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Hiding Messages In VoIP Packets

samzenpus posted more than 2 years ago | from the obscure-message dept.

Encryption 83

Orome1 writes "A group of researchers from the Warsaw University of Technology have devised a relatively simple way of hiding information within VoIP packets exchanged during a phone conversation. The called the method TranSteg, and they have proved its effectiveness by creating a proof-of-concept implementation that allowed them to send 2.2MB (in each direction) during a 9-minute call. IP telephony allows users to make phone calls through data networks that use an IP protocol. The actual conversation consists of two audio streams, and the Real-Time Transport Protocol (RTP) is used to transport the voice data required for the communication to succeed. But, RTP can transport different kinds of data, and the TranSteg method takes advantage of this fact."

Sorry! There are no comments related to the filter you selected.

I dub thee... (2)

Commontwist (2452418) | more than 2 years ago | (#38080720)

Deep Tone.

Re:I dub thee... (1)

wooferhound (546132) | more than 2 years ago | (#38080856)

I would just use a modem

Re:I dub thee... (1)

blackicye (760472) | more than 2 years ago | (#38082740)

I was going to say the same thing, why not just couple your old 56K modem to your VOIP phone service?

Re:I dub thee... (4, Informative)

metacell (523607) | more than 2 years ago | (#38083092)

The point is to hide from an eavesdropper that data is being exchanged. That's what the "Steg" in "TranSteg" stands for (Steganography).

Re:I dub thee... (0)

Anonymous Coward | more than 2 years ago | (#38081286)

Watching a bit to much H
Baka

Re:I dub thee... (0)

Anonymous Coward | more than 2 years ago | (#38093326)

Deep Throat is H?

Hidden message decoded (-1)

Anonymous Coward | more than 2 years ago | (#38080722)

It says: "FIRST POST".

Re:Hidden message decoded (0)

BatGnat (1568391) | more than 2 years ago | (#38081326)

DECODE FAIL: According to my screen, your 2nd

Re:Hidden message decoded (0)

Anonymous Coward | more than 2 years ago | (#38082944)

According to my screen, your 2nd

My 2nd what? Don't leave us hanging!

A sad necessity (4, Insightful)

Hentes (2461350) | more than 2 years ago | (#38080818)

Steganography is tech which while I admire, I hope that I will never need to use. Sadly, the world seems to be going the other way.

Re:A sad necessity (0)

Anonymous Coward | more than 2 years ago | (#38080882)

What is going to be more sad is when no one knows how to read your damn messages.

Re:A sad necessity (1)

morgauxo (974071) | more than 2 years ago | (#38084718)

For most Slashdoters that really isn't true.

Re:A sad necessity (4, Insightful)

Anonymous Coward | more than 2 years ago | (#38081140)

It is indeed headed that way, which is exactly why you won't get to use it. Steganography is an extremely powerful tool which would be a game ender against current and mass interception and surveillance methods. This can't be allowed to happen and you can expect a shift towards centralised control over the communication endpoints, i.e. the computer in your own home and the phone in your hand. Of course any purely technical measure can always be circumvented when one has access to the hardware, which is why you can also expect that installing your own OS, or jail breaking your phone, hell, even loosening a few screws will all be felonies with severe penalties. If you think this is far fetched, remember it has already started to happen with game consoles.

Re:A sad necessity (3, Insightful)

postbigbang (761081) | more than 2 years ago | (#38081232)

You can hideMayorBloomberg messaisaages in all sorbigjerkts of ways. Shoving encrybecauseheevictedtheOWSpted or unencrypted information is child's play. VoIP is just one more medium.

The Internet is seven bit; everything is text. We start from there.

Re:A sad necessity (0)

Anonymous Coward | more than 2 years ago | (#38083028)

Despite your obvious attempt at inserting a message in that post, I can read the post as if the message wasn't there. The addition of that message didn't seem to hinder the comprehension of that sentence. Conversely despite the "hidden" message being as clear as day, it actually took a bit of effort to read it. So I'm if one were to only drop a letter or two in every sentence of a post one could conceivably hide a message without it being so obvious. Most people are pretty tolerant of spelling errors (a point very clearly made in an earlier story on reading and comprehension). Then again, that might just incur the wrath of spelling and grammar perfectionists.

Re:A sad necessity (2)

postbigbang (761081) | more than 2 years ago | (#38084468)

The parser used to input messages and/or extract them can be much more intelligent than the silly one I used. My point is that adding in data to nearly any protocol is child's play. Detecting the same is different, which is why noise needs to be understood (as in my feeble attempt) to identify potential mods that are actually data, but the best ones are simply undetectable because they spent more than the pittance that I did to form the system. You were a parser already.

Re:A sad necessity (2)

interval1066 (668936) | more than 2 years ago | (#38081290)

You make it sound as though this is a bad thing. Any tool I can use to thwart preying eyes, especially the governments, is a good thing.

Re:A sad necessity (0)

Anonymous Coward | more than 2 years ago | (#38084014)

You misread it. The suppression of its use IS a bad thing.

Re:A sad necessity (5, Interesting)

betterunixthanunix (980855) | more than 2 years ago | (#38081270)

Steganography is already widely used by the movie industry. Movies sent to movie theaters have robust watermarks hidden in them, which helps the MPAA identify the theaters where unauthorized recordings of movies are being made. Steganography is also used in laser printers, to help the FBI identify the origin of printed documents.

Like cryptography, steganography is not just limited to keeping your information private or to fighting censorship.

Re:A sad necessity (1)

paxcoder (1222556) | more than 2 years ago | (#38081480)

Wouldn't some statistical analysis of video records from N theaters (to reduce/weed out the differences), combined with some added random noise (for those more obscure, note CAMing does this) yield a video that has no discernible hidden info?

Re:A sad necessity (1)

betterunixthanunix (980855) | more than 2 years ago | (#38081538)

As far as I know, the watermark is placed in different frames for different theaters, which would make averaging attacks difficult. The watermarks are pretty resilient to noise -- they can be detected even when a cheap video camera is pointed at the screen in a movie theater -- and the amount of noise that would have to be added in order to kill the watermark would result in an unacceptable quality even for people who sell illegal DVDs on the streets. This is not your run-of-the-mill "put data in the low order bits" sort of watermark; while I do not doubt that it could be defeated by researchers, it is fairly well designed.

Re:A sad necessity (1)

Commontwist (2452418) | more than 2 years ago | (#38081612)

Two different theaters with two different sets of watermarks. Run them through a digital comparison and filter away the differences?

Re:A sad necessity (1)

jackbird (721605) | more than 2 years ago | (#38081926)

You're dealing with two different camcorder recordings off a projection screen, and looking for differences at individual frames somewhere in a 90 minute movie. There's a hell of a a lot of difference as a baseline. For DVD screeners, though, that could work.

Re:A sad necessity (1)

paxcoder (1222556) | more than 2 years ago | (#38081982)

If the difference is no more distinct than the noise, the noise itself destroys the info.

Re:A sad necessity (1)

Commontwist (2452418) | more than 2 years ago | (#38082706)

Yea. DVD not cams. lol

Re:A sad necessity (3, Informative)

Anonymous Coward | more than 2 years ago | (#38082090)

Last I heard it was done using slight timeframe modifications, one part of a movie playing slightly faster / slower with a pattern of fluctuations, not noticeable to somebody watching the movie, but measurable in a recording regardless of the quality of that recording.

Different segments for different theatres, with some overlap, not immediately obvious, and causes havoc if trying to digitally combine the output, especially if you're dealing with non-digital projection in the first place which is going to add it's own layer of imperfection.

It's surprisingly effective

Re:A sad necessity (0)

Anonymous Coward | more than 2 years ago | (#38087698)

There are many ways of doing it. And the article is not news, there are full books on proofs of concept of passing hidden messages around using SIP and VoIP (anything from messing with headers, as simple as spaces in control messages up to encrypted data piggybacked in the payload).

The actual issue which people have been working on, is determining if there's actual hidden data in the communications. A powerful detector which can differentiate between encrypted voice from an actual conversation and a trade secret being exfiltrated would be the news. Not just exfiltrating the information.

Re:A sad necessity (1)

paxcoder (1222556) | more than 2 years ago | (#38081680)

Let me rephrase "statistical analysis". Oh, and I'm now assuming a watermark is an image overlaid on one or more frames (this is what I get from what you wrote). The watermark is of specific shape so as to identify the specific theater that a certain video was given to. Now, consider this: I take videos from 2 theaters, and compare them with one another - say, subtract the values of each pixel in one frame from another; I should get all black frames. Anything other than identical (black frame) is a watermark. I can either drop the frame, or, given a third video source, choose the two frames from the two sources that are identical. Granted, carefully combining watermarks so as to fool up to N sources is possible. But if you have a sufficient amount of video sources, you just pick, for each frame, those that match.
Got any link explaining the methods they employ in watermark design? I've been thinking about similar ways of protecting lossy data myself, so I wonder what the state-of-art is.

Re:A sad necessity (1)

Anonymous Coward | more than 2 years ago | (#38082444)

Watermarks are usually frequency encoded rather than magnitude encoded. For example, a DCT or DWT will be used to transform both the host image and watermark into frequency components and then combined together. After using the inverse transform, the watermark data is redundantly smeared all over the frame which protects against most types of "attacks" Attacks being loss of resolution, noise, re-compressing, clipping of frame, marks across the frame, etc. Even with the attacks, up to a certain threshold, the watermark can still be extracted whole with increasing loss of fidelity as the attacks get worse.

Re:A sad necessity (1)

xenobyte (446878) | more than 2 years ago | (#38083346)

But wouldn't a simple comparative analysis between two distinct sources reveal the frames most likely to contain the watermark, which can then be dropped or replaced with a 'morph' between the previous frame and the next frame?

Of course if the watermark is encoded in every frame, this is not an option...

Re:A sad necessity (1)

cffrost (885375) | more than 2 years ago | (#38096120)

But wouldn't a simple comparative analysis between two distinct sources reveal the frames most likely to contain the watermark, which can then be dropped or replaced with a 'morph' between the previous frame and the next frame?

Dropping/morphing could reveal the locations from which watermarked frames were removed/replaced, which could be used to identify source(s) used. To avoid this, you'd need to be able to distinguish which of the two frames is unmarked; likely possible, but nearly guaranteed with three sources.

Of course if the watermark is encoded in every frame, this is not an option...

If you had two sources that contained full-frame marks on every frame, I think that averaging would produce a cleaned video. However, the presence of a unmarked frame(s) in either source, averaged with another source's corresponding marked frame, would produce a detectably-marked frame(s), identifying one or more of the sources/custodians.

Re:A sad necessity (5, Interesting)

EdIII (1114411) | more than 2 years ago | (#38081592)

Except this is not steganography. Not exactly. It is a lot more complicated and highly unlikely to work.

RTP streams can carry multiple data streams. That's how voice and audio can be sent in the same connection. The summary implies that additional RTP streams are added, which is not steganographic at all. The additional streams are easily detected. It is as much steganographic as alternate data streams are in Windows files.

However, reading the article indicates something completely different from the summary. This method is not taking advantage of alternate/additional RTP streams at all. It is choosing different codecs based on a complex mapping pattern known only to the sender and receiver. The difference must allow the newly compressed, and transcoded, stream to contain extra hidden data without altering the expected size.

1) Not all VOIP systems use different codecs. It is not really required. My own systems use g729 exclusively from the handsets/deskphones/softphones all the way to termination and origination providers. Without a robust codec library the number of variations here is pretty low. Not to mention both sides would have to support it.
2) This assumes the RTP traffic is encrypted. Which means you are only using steganography as an additional layer of security.
3) If the RTP traffic is in plain text.... this makes it that much easier to defeat. If you were expecting a jpeg file, but upon inspection, found a bmp file, would you not suspect something? This method seems to rely on saying you are using one codec but choose another one. That would seem to be trivial to verify as a 3rd party intercepting packets.

The whole idea is not very workable since the value of codecs is their ability to preserve audio quality, work around iffy connections, and achieve a smaller transmission footprint.

Re:A sad necessity (2)

e9th (652576) | more than 2 years ago | (#38082576)

I think you've hit the nail on the head. Any decent large-scale eavesdropping facility like, oh, I don't know, the one the NSA is building in Utah [gcn.com] will be scanning VoIP traffic for audible triggers ("bomb" "whitehouse" "boom") and will certainly notice when the nominal codec doesn't match the payload. Such traffic will certainly be flagged for closer inspection.

Re:A sad necessity (0)

Anonymous Coward | more than 2 years ago | (#38085766)

The method is apparently a "security through obscurity" type deal.

Sure, if you have no intervening parties (switches, gateways, etc) transcoding, you could negotiate G711 ulaw (64 kbps) and use the corresponding payload ID in the RTP header, but nonetheless send a single frame of an efficient codec like AMR (4.4-12.2 kbps) + extra data with the additional 52kbps or so available to you. If the far end knew how to interpret the payload, the audio part of the call would work fine and the audio quality would be decent enough. Anyone intercepting and listening, if they didn't know the deal, would hear noise as they'd interpret the entire payload as G711. But if they did know what was going on, of course, they could extract the AMR payload and listen in, and extract and potentially interpret the data component as well. And the data needs some redundancy, as RTP is typically carried over UDP, given that losing 10-20 milliseconds of voice data periodically cause no significant quality issues. You could also sneak data into the padding and/or an RTP extension header, if you want to use the codec that is negotiated and get a bit of extra data through that way...

Mind you, if you go for video RTP streams, which are vastly more complex as a rule, you'd have more bandwidth to play with and could use the relatively greater complexity of the codecs, say H264, to hide things better. But it is still mostly counting on the novelty/obscurity of the method for security.

Re:A sad necessity (1)

morgauxo (974071) | more than 2 years ago | (#38084730)

Suddenly I see a use for all the homemade printers I see on maker blogs like Hackaday...

WOW you can hide data in your data! (1)

Osgeld (1900440) | more than 2 years ago | (#38080878)

its bits, electrical pulses, on and off 1 and 0, the gear does not give a shit what that represents just to shuffle it from point A to point B

Techniques for enabling terrorism (0)

Adult film producer (866485) | more than 2 years ago | (#38080886)

Not sure if I'm a big fan of this although the work interesting. I can subversive groups using this proof-of-concept to implement communication networks hidden from the authorities. I could be the next victim in a terrorist attack so I have to refrain any enthusiasm in this regard.

Re:Techniques for enabling terrorism (4, Insightful)

khellendros1984 (792761) | more than 2 years ago | (#38081000)

It's more likely you'll be the next victim in a car crash (unless you're living in a few specific parts of the world). "Subversive" doesn't necessarily equate to "terrorist", and not everyone that wants to hide their communications are dangerous to the public (or at all, necessarily).

Re:Techniques for enabling terrorism (1)

AK Marc (707885) | more than 2 years ago | (#38094662)

You'll more likely be hit by lightning or killed by a meteor than killed by a terrorist (unless you are in an Arabic country).

Re:Techniques for enabling terrorism (1)

AHuxley (892839) | more than 2 years ago | (#38081144)

If this is in the open, i.e. people are talking about it, every gov around the world will have or will soon have some rent a box to find this.
Your simple voip chat will glow in the dark and you will get a nice file opened or added to.

Re:Techniques for enabling terrorism (1)

betterunixthanunix (980855) | more than 2 years ago | (#38081328)

There are plenty of ways that "subversive" groups can hide their networks from the authorities right now. Anyone can post encrypted messages to alt.anonymous.messages to hide the recipient, and anyone can use the remailers network to hide the sender. If you are curious about criminals doing this sort of thing, look up the "Yardbird" pedophile group, some of whom have continued to evade capture.

It is also worth mentioning that steganography is neither new nor undeveloped. Plenty of steganography tools exist right now and can be used by anyone. Anyone who runs an publicly accessible wiki has probably seen steganography on their wiki, in the form of inexplicable spam messages (my local LUG saw this). The movie industry routinely uses steganography in the form of watermarks that are embedded in movies, which identify the theater the movie was shown at.

Re:Techniques for enabling terrorism (1)

White Flame (1074973) | more than 2 years ago | (#38081342)

The terrorists' actions don't matter any more to you, since you obviously have already been terrorized and there's nothing more they need to do to you. Those who still have their self intact will continue on with progress.

Re:Techniques for enabling terrorism (1)

cffrost (885375) | more than 2 years ago | (#38096242)

Not sure if I'm a big fan of this although the work interesting. I can subversive groups using this proof-of-concept to implement communication networks hidden from the authorities. I could be the next victim in a terrorist attack so I have to refrain any enthusiasm in this regard.

People like you are responsible for the rapid erosion of our civil liberties. Try spending a little more time understanding statistics, probability, and security, and a little less time sounding like a cowardly fucking idiot.

This is a great idea (5, Funny)

squiggleslash (241428) | more than 2 years ago | (#38080918)

You can avoid your messages being intercepted using this technique simply by piggybacking it on the one protocol that large telcos in every country are trying to find ways to block. Hooray!

OK, I'm being an ass. It's a cool concept.

Re:This is a great idea (0)

Anonymous Coward | more than 2 years ago | (#38082286)

This raises the question: could we do the reverse: hide VoIP packets in what appears to be top-secret text documents?

Re:This is a great idea (1)

jimthehorsegod (1210220) | more than 2 years ago | (#38084550)

That's interesting - then leave said documents on a laptop in a cab or train for authenticity.. The lag may be hard to deal with, though

Would this really work? (5, Interesting)

BenGL (810895) | more than 2 years ago | (#38080924)

From what I understand, steganography works if an observer (Carl) cannot tell that transmission of covert data is taking place between Alice and Bob. The proposed method results in an RTP bitstream that does not hold the payload advertised in its headers -- the audio is compressed using a more efficient codec than advertised in the packet headers, and the extra space is used to carry the "hidden" payload; Alice and Bob agree beforehand on the audio codec to use.

Now if Carl wants to eavesdrop on the conversation by hijacking (or owning) an intermediary network node, he would get corrupted audio data when trying to decode the packets with the (fake) advertised codec. Wouldn't this be a strong indication that covert communication is taking place?

Re:Would this really work? (0)

Anonymous Coward | more than 2 years ago | (#38081046)

What about using the same codec, packet headers claiming it was being used at a higher bitrate than it actually was? An eavesdropper paying real attention would still notice, but it wouldn't be as easy to pick up on as if the packet header was claiming the audio data was uncompressed PCM and the actual data was compressed with speex or something.

Re:Would this really work? (1)

bugs2squash (1132591) | more than 2 years ago | (#38081184)

Perhaps signal using background noise or something. But to my way of thinking, the "lie about the codec trick" just isn't steganography as any reasonable attempt to decode the signal without knowing the secret would just result in a decoding failure. I think that goes for the sample rate example too.

Re:Would this really work? (2)

russotto (537200) | more than 2 years ago | (#38081398)

Now if Carl wants to eavesdrop on the conversation by hijacking (or owning) an intermediary network node, he would get corrupted audio data when trying to decode the packets with the (fake) advertised codec. Wouldn't this be a strong indication that covert communication is taking place?

It would seem so. I would think that a better way of doing steganography would be to hide data in the audio itself, or in details of the encoding.

Re:Would this really work? (1)

bill_mcgonigle (4333) | more than 2 years ago | (#38081686)

It would seem so. I would think that a better way of doing steganography would be to hide data in the audio itself, or in details of the encoding.

Right, which is already known how to do. You'd just need to apply enough forward error correction to survive the codec. Ideally, you'll embed already encrypted and compressed data so it looks like noise.

Actually, hrm, are there any cryptographically secure FEC methods?

Re:Would this really work? (0)

Anonymous Coward | more than 2 years ago | (#38081678)

There's no mention of it in TFA, but TFP says use SRTP. We'll, hiding information inside an encrypted packets -- someone ought to patent that!

Re:Would this really work? (4, Interesting)

wierd_w (1375923) | more than 2 years ago | (#38081948)

The better approach would be to preprocess the audio signal of the conversation through another device (such as the handset itself) which normalizes the audio in a fashion tailored to the advertised codec. The idea being that the resulting bitsream will obey certain predictable rules. (You need to have very detailed knowledge of the codec used, but that shouldn't be seen as a barrier.) Your steganographic payload makes subtle, but permitted changes to the encoded audio data to disrupt this predictable ruleset. Your message is thus folded into the bitstream using the mathematically freed bandwidth of the "noisy" audio channel. (Once you remove the normal audio signal, the difference bits are the secret message.) To the interceptor, the codec uses the correct bandwidth, uses the correct codec, and is easily played by that codec.

For a simplified example, say we have gzip'ed pcm audio, in the 44100khz,16bit,stereo flavor. The preprocessor makes all the pcm samples an even multiple of 2. This frees up a portion of the channel for data, by having an understood second codec that encodes say, RLL data into a series of single bit additions to the samples (making them odd values instead of even ones.)

The pcm decoder will play the steganographed audio file without any noticable signal (single bit manipulations are too small to be detected by human ears). The secret message codec looks at all the samples, records a bit pattern of even or odd, and then decodes the resulting RLL pattern, recovering the message.

More sophisticated codecs would require more sophisticated preprocessing of the raw audio, but the idea is still potentially employable.

Re:Would this really work? (1)

jenic (1231704) | more than 2 years ago | (#38082294)

I've always wondered why Alice and Bob are so secretive.

Re:Would this really work? (4, Funny)

wierd_w (1375923) | more than 2 years ago | (#38082696)

That's easy.

Alice is secretly a BDS&M dominatrix, into humiliation, flagellation, and golden showers. She also is president of the knitting club, and a well respected member of her local orthodox church.

Bob is secretly a masochist with a diaper fettish, and gay bestiality, and also the mayor who has openly critised alternative lifestyles to appease the conservative demographic of his constituency.

Eve is the reporter for the local tabloid, who suspects Alice and Bob of shennanigans, since they seem to spend inordinate amounts of time together, and always seem to be missing or unavailable at the same times. Hopes to gain subversive access to the private correspondences of Alice and Bob as part of her scoop. .........
That's aways the way I envisioned the "alice, bob, eve" scenario anyway...

Re:Would this really work? (0)

Anonymous Coward | more than 2 years ago | (#38086690)

Good scenario. One question, what is gay bestiality as opposed to just bestiality? Since Bob is a male, would that require a male animal, fucking him in the ass?

Re:Would this really work? (1)

jenic (1231704) | more than 2 years ago | (#38091096)

I'd be interested in the further development of this storyline.

The names give it away (1)

dutchwhizzman (817898) | more than 2 years ago | (#38082864)

Any time you see Alice and Bob are trying to communicate, you know they're up to no good. Every text book on security tells you so!

Speaking of which... (4, Interesting)

ADRA (37398) | more than 2 years ago | (#38080962)

I was thinking that a way of sending hidden messages between two locations (assuming a reasonably reliable network), one could introduce send messages by controlling the rate of the replies in a predictable manner (using ECC and varying transition timings for error rate compensation).

Another simple one would be with TCP/UDP in forcing out of order packets for positive/negative bit representation and similar correction routines as above.

Both hidden message systems are slow to send any substantial amount of information, but I can't see a reasonable approach to intercept without a full dump of the entire packets and timestamps which is more laborious than just the session data contents (assuming one is ManInTheMiddle). Further security on the payload as necessary, but the transmission of the message itself is hard detect.

Re:Speaking of which... (2)

Gothmolly (148874) | more than 2 years ago | (#38081302)

Easier way to do encryption:

dd if=/dev/urandom bs=1k count=700000 | mkisofs -o - | cdrecord -v -pad dev=(your device)

Make a copy for your friend.

Send all your stuff encrypted with a one time pad composed of a random length and offset based on numbers on some public site - temperature in Madrid, the # shares sold on the Dow, etc.

Obligatory xkcd comic applies, of course.

Re:Speaking of which... (1)

rthille (8526) | more than 2 years ago | (#38087072)

Even better, run the command twice, keeping one CD for you and sending the other to your friend!

Re:Speaking of which... (1)

betterunixthanunix (980855) | more than 2 years ago | (#38081416)

I was thinking that a way of sending hidden messages between two locations (assuming a reasonably reliable network), one could introduce send messages by controlling the rate of the replies in a predictable manner (using ECC and varying transition timings for error rate compensation).

This is a well known covert channel that has been covered in many security engineering books. One of the design principles for military computer networks is to keep the bandwidth of such a channel below 1 bit per second, although for very sensitive data it may need to be even lower.

Re:Speaking of which... (1)

Jonathan_S (25407) | more than 2 years ago | (#38085290)

This is a well known covert channel that has been covered in many security engineering books. One of the design principles for military computer networks is to keep the bandwidth of such a channel below 1 bit per second, although for very sensitive data it may need to be even lower.

Of course that type of leakage rate limiting defense can lose its effectiveness when dealing with encrypted data. If the encrypted data is output and can be recorded then all the bad guys need to sneak out is the corresponding key which is tiny in comparison.

At the rate you mentioned it only take about a minute to covert channel out the largest AES encryption key (256 bit). But that key might have been used to encrypt all the traffic sent in the last day (which you could've already intercepted and copied).

Even the largest common RSA key size (4096 bit) would only take a bit over an hour to output.

out of order (1)

dutchwhizzman (817898) | more than 2 years ago | (#38082872)

Out of order won't be very reliable, since there's no telling the Internet won't shuffle up your order a bit more.

It would work... but there are better ways (4, Interesting)

Anonymous Coward | more than 2 years ago | (#38081150)

Most used codecs use some internal ECC, so filling RTP packets with your data will be easily recognized.
Another approach would be doing FFT on decoded audio. Codecs tend to produce wideband noise with random data and that is very different from usual speech frequency response.
Much better method would be using LSB bits in codec to transfer message. It would result in slight differences in pitch or other parameters, but it would be almost undetectable.

Encrypted AFSK (0)

Anonymous Coward | more than 2 years ago | (#38081500)

You can do 56kbps AFSK (3.7 mbyte) and encrypt it yourself. Surprise! Someone rediscovered dialup.

Re:Encrypted AFSK (1)

rubycodez (864176) | more than 2 years ago | (#38086520)

but then any wiretapper knows you are sending an encrypted message, and they know to whom you are sending it. maybe their next step is to bug or stake out the facility your or your receiver uses, and they find out your secrets using the XKCD $5 wrench interrogation.

The 1950's called. They want their credit... (1)

Anonymous Coward | more than 2 years ago | (#38081972)

for robbed-bit signalling back.

um, well, duh (1)

angryargus (559948) | more than 2 years ago | (#38082040)

This is only noteworthy or nonobvious if you only have a basic understanding of computers. RTP allowed extension headers, and IPv4 does as well so you could embed extra data for almost any type of traffic on the Internet.

Ring messages (0)

Anonymous Coward | more than 2 years ago | (#38082542)

Many moons ago when phone calls were expensive, we used a system of rings to signal our parents to come pick us up at the movie theatres or whatever. For example, 3 rings, then hang up. Sometimes we used 3 rings followed by 2 or 3 rings if more information needed to be exchanged. This was a simple covert messaging system that didn't cost any money, so you could use a 'tickey box', without consuming a 'tickey'.

So much for the voice quality... (1)

blanchae (965013) | more than 2 years ago | (#38082616)

VoIP datagrams are intentionally small in the order of 10 - 20 bytes. VoIP uses UDP because it is a fast and efficient protocol. These datagrams are small so that if there is loss, there is minimal interruption of the real-time voice stream. You may hear nothing or a small blip. Adding overhead to the rtp stream by increasing the payload size defeats the quality of the voice transmission. The major concern of VoIP is sound quality, hiding data inside an rtp stream will do the opposite of exactly what the industry wants - the added payload will create poor audio quality. This just sounds like a bad idea (pun intended).

Using the protocol as designed is hardly HIDING! (1)

GiantRobotMonster (1159813) | more than 2 years ago | (#38082624)

Stenography this is not.

Re:Using the protocol as designed is hardly HIDING (0)

Anonymous Coward | more than 2 years ago | (#38096156)

Yes, it clearly isn't shorthand, but is it steganography?

How is that even news? (5, Funny)

formfeed (703859) | more than 2 years ago | (#38082656)

Women have been hiding messages in voice streams in like forever.

Re:How is that even news? (1)

rubycodez (864176) | more than 2 years ago | (#38086634)

Some problems with that technology: S/N ratio so very low, device become erratic and potentially dangerous a few days a month and then leaks biohazardous fluids, very high maintenance costs, increasingly frequent nag messages displayed to upgrade from trial package to lifetime support contract with total vendor lock-in (Girlfriend 0.5 -> Wife 1.0)

I'm a victim, save yourself!

Chickspeak to English. Now there's an app! (0)

Anonymous Coward | more than 2 years ago | (#38089096)

Thanks formfeed. I needed a giggle!

The camera moves over some dude's shoulder, so we can see the screen of his smartphone and his girlfriend at the same time. Girlfriend starts speaking. Smartphone provides real time translations.

Re:How is that even news? (1)

cerberusss (660701) | more than 2 years ago | (#38122876)

Well, if you're going to talk like that, then I guess you need to think about what's really important for you.

In VoIP? (0)

Anonymous Coward | more than 2 years ago | (#38083652)

Had they considered just recording it backwards?

SIP (2)

quetwo (1203948) | more than 2 years ago | (#38084484)

Ummm.... This is what SIP was designed for, right? I mean, not really hiding, but passing messages along with a phone conversation?

But SIP aside, the other major VoIP protcol, H.323 allows for MISC messages of varing length with the packet as well. Oh, and if you are talking only about only encoding the message within the codec, G.722k allows for 4k per packet to be as "RESERVED, SPECIAL USE", which isn't apart of the voice stream.

And if they are talking about encoding messages in video, the MPEG standards which I believe are using allow for TEXT data withing the streams (or completely hidden streams all together).

Obligatory XKCD (1)

TangoMargarine (1617195) | more than 2 years ago | (#38085192)

Communicating via VoIP?! NO WAI!!

MacGyver Gets Lazy [xkcd.com]

TFO (0)

Anonymous Coward | more than 2 years ago | (#38085812)

This technique is used by ancient mobile switches to hide extra data in G.711 stream. Oh, good old TFO, RIP.

How do they track sequence? (0)

Anonymous Coward | more than 2 years ago | (#38086952)

Are they embedding a protocol that checks packet sequence?

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?