Steganography Using TCP Retransmission

Research:

Hiding Information in Retransmissions

Wojciech Mazurczyk, Milosz Smolarczyk, Krzysztof Szczypiorski

The paper presents a new steganographic method called RSTEG (Retransmission Steganography), which is intended for a broad class of protocols that utilises retransmission mechanisms. The main innovation of RSTEG is to not acknowledge a successfully received packet in order to intentionally invoke retransmission. The retransmitted packet carries a steganogram instead of user data in the payload field. RSTEG is presented in the broad context of network steganography, and the utilisation of RSTEG for TCP (Transport Control Protocol) retransmission mechanisms is described in detail. Simulation results are also presented with the main aim to measure and compare the steganographic bandwidth of the proposed method for different TCP retransmission mechanisms as well as to determine the influence of RSTEG on the network retransmissions level.

I don’t think these sorts of things have any large-scale applications, but they are clever.

Tags: , , , ,

Posted on May 28, 2009 at 6:40 AM • 23 Comments

Comments

Bahggy • May 28, 2009 7:37 AM

Since steganography is intended to provide a covert channel for communications, I can see that this has a couple of flaws. Primarily, it would be relatively easy to detect if it is looked for. Second, the integrity of the communications, both primary and steganography could be affected.
An interesting intellectual exercise nonetheless.

Franky B. • May 28, 2009 8:18 AM

@Bahggy,

I’m not so sure that, if used sparingly and attentively, it would be so easy to detect. Just make the steg message look close enough to the original payload of the packet and anyone watching would lose this is the noise.

As to your second point, presumably the primary communication is of little actual value per se, thus it’s integrity isn’t important. The integrity of the steg message could be assured easily enough. Application of this would have way too low bandwidth to be of wide-scale use, but it’s a cool covert channel.

John • May 28, 2009 8:26 AM

Not so certain this is hard to detect. A sniffer that saves a hash of packets along with session identification information (ip addresses, port numbers, sequence numbers) for all packets that have a correct checksum on packets that have a correct checksum would pretty rapidly detect that something strange was going on when it detects 2 packets with the same identification information and different hashes. And it isn’t possible for the sender to “seed” the data stream with packets with invalid checksums since those packets are allowed to be dropped by any intermediate nodes due to the bad checksum.

Craig • May 28, 2009 8:31 AM

From the title alone, I thought this was going to be a little different. My idea was that the hidden message would be contained in the pattern of retransmissions: e.g. if a given packet is received twice, that indicates a 1 bit in the hidden message. The actual payload could be anything at all; it’s completely irrelevant. Where this idea runs into problems, of course, is that packet retransmission sometimes occurs by accident because an ACK isn’t received by the sender, and sometimes a duplicate packet would fail to reach the receiver. Still, there’s probably some clever way to do something with this…

Jason • May 28, 2009 9:16 AM

Wouldn’t an easier method be using pre-chosen or predictable initial sequence numbers and doing the equivalent of an nmap stealth scan (that is sending a SYN and ignoring any replies)? If you based the sequence numbers off of system time, you could have two systems sync’d at a particularly strange time (GMT-3:37 or something) and use a specific sequence number to trigger the start of a stego transmit and receive cycle with another special sequence to stop.

Matt • May 28, 2009 9:25 AM

Is there a typo in Figure 2 of the PDF? The example on the left says “Retransmission of Data #1” after the timeout. The one on the left says “Retransmission of Data #2” Are they supposed to be different?

Matt Simmons • May 28, 2009 9:28 AM

Clever hacks like this really illustrate the fact that you cannot stop communication between people. No matter which ways you try to monitor it, there are infinitely more ways to pass information.

People who think they can prevent Alice and Bob from talking are doomed to failure.

Ward S. Denker • May 28, 2009 9:34 AM

Steganography and large-scale applications has always seemed to be mutually exclusive to me. If you’re relying on something being hidden, it doesn’t make sense that everyone knows about it. I can’t imagine a single steganographic technique (short of employing quality encryption along with it) that would not suffer from having too much exposure. Can anyone?

papa zita • May 28, 2009 10:01 AM

Steganography I doubt would be safe without encryption anymore, but it’s a fairly simple means to transmit messages and there are such a variety of methods. Some IRC friends and I used to pass messages around back in the ’90s and there were a number of methods back then, most simple but since it was in the 56K days, it was only useful for short messages.

Jason • May 28, 2009 10:07 AM

Encrypting stego defeats the purpose. Encrypted traffic is easy to detect; you know what encrypted traffic looks like. While stego is supposed to look like something other than a normal document, image, or audio file. You could encrypt the stego part of the file without detection maybe. But if you encrypt the whole thing, you might as well just rely on strong encryption and authentication.

nick • May 28, 2009 10:41 AM

Jason, I really doubt papa zita was suggesting anyone send stego data through an encrypted channel. Sending encrypted data through a stego channel is clearly the right way to implement something like this.

Clive Robinson • May 28, 2009 1:48 PM

A simple way to set up the channel with a bit more reliability is to also use early/late transmission of data as well.

Let us assume that instead of sending a new packet of data which lets face it has a good chance of being detected it correctly re-sends the packet that was not acked.

But impoertantly the re-send can be sent on time or late. If sent ontime this signifys say a zero if late a one.

The choice of which packet to fail to acknowledge also sends a bit of data.

In this way you have a bi-directional channel sending a bit both ways each time.

To improve the chance that it will not be detected then “stream encrypt” / Direct Sequence Spread Spectrum modulate the data streams.

Miramon • May 28, 2009 2:04 PM

For really low bandwidth, even a steganographic packet is too much. Anyone can still see the payload, after all. Split each message bit into multiple symbols, and use the delivery failure itself as one of several signals that together make up a symbol. Sure, it takes 10,000 apparently failed packets to say “the eagle flies at dawn”, but, you know, better safe than sorry.

Ward S. Denker • May 28, 2009 5:19 PM

Encrypting stego defeats the purpose. Encrypted traffic is easy to detect; you know what encrypted traffic looks like.

Unless the purpose of the steganography is to disguise encrypted data as something else. One could easily incorporate one-time pad mechanics into their hidden message scheme, which would make the encrypted data look random. Distort the pixels of an image with those ‘random’ values, and it will be both encrypted and hidden without decent methods of detection.

Mr R • May 28, 2009 6:33 PM

“Wojciech Mazurczyk, Milosz Smolarczyk, Krzysztof Szczypiorski”

I love those names. It seems like they contain a steganographic message. 🙂

magetoo • May 28, 2009 9:31 PM

My idea was that the hidden message would be contained in the pattern of retransmissions

My initial thought on seeing the headline was that you would use retransmission requests to send a few bits – i.e. the receiver of the packets is really the sender of the hidden data.

sooth sayer • May 29, 2009 11:26 AM

I agree these are not for mainstream applications – but they point to an ever increasing need of secure communications.

IP has more or less outlived it’s use. The world has changed from the time when it was conceived. I think a new paradigm is in order and it’s no IP-V6!

Anonymous • May 29, 2009 11:32 AM

Nick is correct. We didn’t do it that way (seemed not worth the trouble back then, and we got bored and went on to other things), but that was the way we’d have implemented it.

Anewmynous • May 29, 2009 11:35 AM

“the utilisation of RSTEG for TCP (Transport Control Protocol)”

Ironic, they’re fiddling with the intimate details of TCP without actually knowing the name of the protocol.

Clive Robinson • May 30, 2009 7:03 AM

It is sometimes difficult to distinquish between “Stego” and “side channel” communications as often they are in many cases considered the same.

However as a general rule stego that is “in band” as opposed to “out of band” is usually detectable or preventable which is one of the reasons “digital watermarking” kind of died the death.

Out of band communications often called “side channel” can be via channels that exist as a natural consiquence of the primary channel, or are deliberatly created (the forma is preferable for many reasons).

Idealy what you would be looking to do to get this sort of communications to work is,

1, Find two side channels, atleast one natural.
2, Employ low entropy control signaling in one channel.
3, Send data in the second channel.
4, Provide suitable data hiding to reduce the chance of any correlation between data and control and likewise between sent data and known data.
5, Decouple the transmission of information from events causing the information to be sent.

It is relativly easy to create stego and side channels but very difficult to keep them hidden. Which is why it is best to use already occuring side channels and decoupling of events to data transmission over and above any info hiding techniques you chose to employ.

Then when you have done that you have the thorny problem of ensuring reliable data transfer and control mechanisms.

Ho Hum life is always a little uncomfortable where the “rubber” of theory hits the “rocky road” of reality, and the faster you go the more it hurts…

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.