cryptonomicon

or one of the other books chicken! mentions a transport layer encoding? the diamond age maybe?

Translation to plain english

"The technique has important implications for network security because it can be used by attackers to conceal the leakage of confidential information, the paper warns."

The technique has important implications for p2p traffic, because it will be used by file sharers to keep their p2p networks kicking while the RIAAs of the world have to figure it all out once again.

This has been around for ages, Oasis

Take a video stream, blend subtle shadings in the shapes of text of secret msg, say but broken apart across 3 to 5 frames or more, then distrubute rest of msg similarly over different parts of the frame througout movie. That was pubic knowledge in 1994, spo0o00o0o00o0oks would have used it before then for sure...

"Where were you while we were getting h1gh."

Paris, cos I could easily secrete a packet in her communication channels.

@John Sanders

Surely piracy is dead now the Pirate Bay founders are in jail!

ho-ho-ho

It can be detected..

Ok, at one level, this is pretty sneaky in that it is hard to detect. However, its not impossible to detect.

All one would have to do is to capture the network traffic from a given site and to then compare any resends against the initial transmitted packet. If the receiving site sends an acknowledged response then you can clear the packet from the cache. If a resent response is set, you can flag it to check the resent package.

Obviously there's more to this design, but it could be part of a corporate firewall or if you have the budget, something larger.

While the paper acknowledges that the more resent network traffic you have the more likelihood that you will be caught. Clearly you can identify this method fairly quickly.

Clever

It is detectable, but only if a firewall or network analyzer is looking for this sort of activity and secret data is being sent too rapidly. By dynamically monitoring the number of normally retransmitted packets, the rate of payload packets can be kept low enough to avoid suspicion. Even watching for differing resent data is not necessarily effective: a small percentage of packets are corrupted normally, so regular data will be blocked or clutter log files.

Of course, the secret transmission could be further encrypted to keep it from being understood even if it is detected. For example, xor'ing with the previous packet's data would make logging just the secret data useless.

A trickier use is to hide data in a packet stream between two unwitting systems that just happens to pass through the computers trying to communicate secretly. Neither endpoint notices anything but a slightly higher rate of dropped packets. Not as many computers can use this technique, but there may be fewer or no traffic monitors between them.

@John Sanders:

This, and steganography in general, is not practical for p2p traffic because it requires a much larger transmission to hide in. At an almost undetectable level, in a 200KBps connection it can transmit secret data at just 180Bps, and this is considered good compared to other steganographic methods. At the highest level they tested - resending 5% of packets - there's a substantial change in network traffic, so it's likely to be noticed, and you cut your bandwidth by a factor of 20. Want to try sharing a DVD at dialup speeds?

I nominate HICCUPS for the Worst Abuse of Acronyms award.

THE CUSTARD IS ON THE MAT

BANANA DAQUIRI

PURPLE PRUNES SPOKE THE QUEEN'S DANISH PROFFER

ALLO ALLO THIS IS NIGHT'AWK CALLING

ALL YOUR BASE ARE BELONG TO US

ALL MY COAT ARE BELONG TO ME

The easier solution...

...a CD ROM or DVD jammed packed with secret-nasty-bad stuff sent in the (paper) mail....

Slower yes, but it avoids the IT watchers......

Personally, I prefer the Post Office.

This method basically depends on noone knowing that you are using it

So basically security by obscurity (which is actually rather good security - right up to the point where it fails miserably)

But in combination with other methods of encryption, it can be used to add an extra layer of security.

Have anyone wondered whether the edless small variations to the same spam message reportedly being used for the purpose of cheating filters are actually steganographic messages? - Now there's a conspiracy theory for you right there.

Not new.... won't snort pick this up already?

This is so much like the years-old fragrouter technique that it wouldn't surprise me if it tripped snort's detection as is. Otherwise it's just a few trivial tweaks to the rules I'd guess.

Back in the real world?

Where are the examples of real use of steganography?

I've been warned of this one, of payloads on ICMP frames, of packing bits... but I never heard of decent, attested examples of their use by a genuine hostile. It's all very well to say "that just shows how effective it is" -- someone must have got caught, somewhere.

It's like spyware that is aware of proxy settings -- it seems reasonable, it ought to exist,

http://www.digitaloffensive.com/index.php?option=com_content&task=view&id=18&Itemid=2

but you never come across it.

@Brian Miller

"....then a duplicate packet number/sequence with a different or wrong checksum or size could be discarded...."

Very clever. Now, for the case of a "real" packet retransmission, think of some of the possible reasons for said retransmission..........oops.

And

And I thought one could be sneaky by creating a variant of live Linux and hide the messages within a number of picture folders marked say Desktop real estate or some other innocuous name within the ISO itself so that when you boot it up it behaves like a normal like Knoppix or the even more common M$ Windows such as 98SE XXXXXXX variant but however if you decompress the ISO there they be run a picture extracting key text thus .

For after all what spy organization will bother downloading a p2p torrent for computer software they already have any way ?

RE: Obvious once someone did it

You are surely right. The job of security researchers is not to provide a new tool for "bad guys" or someone in need of hiding information as is this case, because most likely they have all the tools they need already.

It is to help improving security tools by pointing out where they may fall short. In this case the tools that potentially need improvements are IDS (or other TCP scanners and analyzers). If your IDS vendor was not aware of this technique, you might not have the right tool to detect it.

Cryptography Quiz

> Wojciech Mazurczyk, Miłosz Smolarczyk, and Krzysztof Szczypiorski

Now from that muddle of letters find the real names of the cryptographic hackers!

:)

Why bother?

Why wouldn't i just encrypt the data i wanted to secretly send and send that in normal packets? Why bother with stenography, what advantage does it offer me as someone trying to get data out of an organisation to elsewhere?

There are more interesting algorithms out there

Any noisy channel can be used for stego. There's nothing in particular that makes this idea stand out as interesting. As pointed out by several posters, this is quite easy to detect, particularly if the parties try to get a lot of bandwidth from the channel by giving up any attempt to make the retransmitted packet look like a slightly-mangled version of the original (or vice-versa). Anyone suggesting using this for bittorrent traffic obviously has no idea about how bandwitdh-limited subliminal channels have to be.

A more interesting system, IMO, is Rivest's chaffing/winnowing system:

http://people.csail.mit.edu/rivest/Chaffing.txt

The chaffing/winnowing system could be used on top of any communications channel, so it would be easy to implement on top of the retransmission system. Both parties would have to have to have to be running a synchronised message authentication algorithm (either a secret algorithm, or a known algorithm seeded with a shared secret key or nonce) so they can flag a retransmission as containing stego data at one end, and recognise it as such at the other. This would make the system more robust in the face of genuine transmission errors, but as noted with the basic system, you're still generating more noise than would be normal, which will betray your use of the channel to transmit more information.

Yet another option would be to encode your message as a function of the data actually being transmitted. If you're uploading a web page, you could build, say, a Huffman tree or markov model based on the word or character frequencies in the document. Your message could then be encoded in a compressed form by using shorter codes for any word appearing in the document. You could then send an unsolicited retransmission containing your message that's been compressed relative to the main stream and an authentication code to show that the retransmission contains a subliminal message. Throwing in a few more "chaff" retransmissions (which would fail the message authentication code) makes the job of analysing the substance of the subliminal channel more difficult. This is a bit more interesting (again, IMHO) and should use less retransmissed packets than the schemes described in the article, but it's still of fairly limited use..

@What a load of turd.

> When a re-sent packet comes along with a completely different CRC from the first then it's

> quite obvious that something dodgy is up

It's trivial to create a new packet with the same CRC as the original.. the CRC is simply the remainder in a polynomial division (in GF_2), so a small bit of linear maths is all that's required to calculate a constant term to add to your new packet so that it has the same CRC as the original.

@May already be defeated:

> I think some firewalls already deal with this e.g. from Checkpoint SmartDefense

> you would get the message "Retransmitted data does not match original data".

It really depends on where Mallory is situated. If she's doing egress filtering on your connection to make sure that you're not sending secret messages, then it's a valid point. Packets with transmission errors are, by definition, going to have different contents in general, though. If Mallory is close to you, then she has a better chance of detecting that the error rate on your transmission link is higher than it should be... Someone eavesdropping at the far end has slightly less chance of determining this because each node the packet passes through has a cumulative chance of inserting an error. With the internetworks being quite reliable, and getting more so, though, using error packets becomes more detectable, no matter where Mallory is situated.

Already been done

There was a much simpler version out some years ago, filling the padding of ICMP echo packets (pings) with data. So simple, assuming ICMP is allowed through of course :-)

Anyway, this isn't really steg - its more of a covert channel.

I'll try and have a look at it all the same.

SSL?

Isn't SSL meant to prevent looking at the data from the server to the client EVEN WHEN YOU INTERCEPT the traffic?

What would the point of stenography be if the connection is encrypted, anyway?

If the firewall prohibits SSL traffic, then it will not be worth your time to use the network to get the information in/out anyway - use SneakerNet(tm)!