Slashdot Mirror

← Back to Stories (view on slashdot.org)

Hiding Messages In VoIP Packets

Posted by samzenpus on from the obscure-message dept.

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

22 of 83 comments (clear)

  1. I dub thee... by Commontwist · · Score: 2

    Deep Tone.

    1. Re:I dub thee... by metacell · · Score: 4, Informative

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

  2. A sad necessity by Hentes · · Score: 4, Insightful

    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.

    1. Re:A sad necessity by Anonymous Coward · · Score: 4, Insightful

      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.

    2. Re:A sad necessity by postbigbang · · Score: 3, Insightful

      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.

      --
      ---- Teach Peace. It's Cheaper Than War.
    3. Re:A sad necessity by betterunixthanunix · · Score: 5, Interesting

      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.

      --
      Palm trees and 8
    4. Re:A sad necessity by interval1066 · · Score: 2

      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.

      --
      Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
    5. Re:A sad necessity by EdIII · · Score: 5, Interesting

      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.

    6. Re:A sad necessity by Anonymous Coward · · Score: 3, Informative

      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

    7. Re:A sad necessity by e9th · · Score: 2

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

    8. Re:A sad necessity by postbigbang · · Score: 2

      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.

      --
      ---- Teach Peace. It's Cheaper Than War.
  3. This is a great idea by squiggleslash · · Score: 5, Funny

    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.

    --
    You are not alone. This is not normal. None of this is normal.
  4. Would this really work? by BenGL · · Score: 5, Interesting

    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?

    1. Re:Would this really work? by russotto · · Score: 2

      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.

    2. Re:Would this really work? by wierd_w · · Score: 4, Interesting

      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.

    3. Re:Would this really work? by wierd_w · · Score: 4, Funny

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

  5. Speaking of which... by ADRA · · Score: 4, Interesting

    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.

    --
    Bye!
    1. Re:Speaking of which... by Gothmolly · · Score: 2

      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.

      --
      I want to delete my account but Slashdot doesn't allow it.
  6. Re:Techniques for enabling terrorism by khellendros1984 · · Score: 4, Insightful

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

    --
    It is pitch black. You are likely to be eaten by a grue.
  7. It would work... but there are better ways by Anonymous Coward · · Score: 4, Interesting

    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.

  8. How is that even news? by formfeed · · Score: 5, Funny

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

  9. SIP by quetwo · · Score: 2

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