Phony TCP Retransmissions Can Hide Secret Messages 188
Hugh Pickens writes "New Scientist reports that a team of steganographers at the Institute of Telecommunications in Warsaw, Poland have figured out how to send hidden messages using the internet's transmission control protocol (TCP) using a method that might help people in totalitarian regimes avoid censorship. Web, file transfer, email and peer-to-peer networks all use TCP, which ensures that data packets are received securely by making the sender wait until the receiver returns a 'got it' message. If no such acknowledgment arrives (on average 1 in 1000 packets gets lost or corrupted), the sender's computer sends the packet again in a system known as TCP's retransmission mechanism. The new steganographic system, dubbed retransmission steganography (RSTEG), relies on the sender and receiver using software that deliberately asks for retransmission even when email data packets are received successfully (PDF). 'The receiver intentionally signals that a loss has occurred,' says Wojciech Mazurczyk. 'The sender then retransmits the packet but with some secret data inserted in it.' Could a careful eavesdropper spot that RSTEG is being used because the first sent packet is different from the one containing the secret message? As long as the system is not over-used, apparently not, because if a packet is corrupted, the original packet and the retransmitted one will differ from each other anyway, masking the use of RSTEG."
Real errors? (Score:5, Interesting)
Why send diffrent packages? (Score:1, Interesting)
You could transmit data over retransmission requests.. One retransmission request within 250 packages counts as a 1.. no retransmissions withing 250 packages counts as a 0. Then add an CRC on that, if the CRC doesn't match, throw it all away and resend your hidden message.
This way you could stream a movie and send your data over the retransmissions, without even writing it down into the tcp stream.
This could however of course be detected, if the government know about the algorithm and searches all TCP streams for it. :-)
If you on top of this add some sort of scramble key, it would be really hard to detect that a transmissions was ongoing.. Except the fact that one user constantly suffers from bad networking
How does this avoid censorship? (Score:1, Interesting)
How does this get around censorship? The packets, even though retransmitted, is still from a blacklisted IP isn't it?
Re:Does it matter which data you send first? (Score:3, Interesting)
If you send the real data first, you have to know which piece to ask to resend.
If you know what the encrypted data looks like, you know which packet to ask for a resend on. The sender knows what the real data looks like. The receiver must necessarily know how to deal with the encrypted data. If you send the masking data first and then ask for a resend a third party can (expensively) detect the technique by reconstructing the data and deciding yourself if the data was valid or not; if you send the real data first and then the masking data this looks more like a bad packet with a request for a resend. It does, however, require that the receiver simply take the encrypted data on the sender's schedule (or terminate the connection.)
crimilization of ambiguity (Score:5, Interesting)
For the purpose of this discussion it helps to bear in mind the criminalization of ambiguity. If I have a source of physical randomness and I use this source to write a multi-GB file to my hard drive, when the Mounties show up to repo my computer system (on false allegations under the Canadian DCMA soon to be shoved down our throats), and I'm unable to provide a password which unlocks my monolith of randomness into something with a lot less entropy, I expect I'll be successfully charged with obstruction of justice.
Ignorance of law is no excuse. No one in the legal system has the balls to state this point blank, but it appears as things are shaping up that ambiguity of circumstance is no defense either.
You can do this with ICMP too (Score:3, Interesting)
Embedding a message in an ICMP (ping) packet is as old as the hills. Sure , you need root privs to send and receive the packet but you'll need the same privs to read the individual TCP control packets in this scenario anyway. Nice idea though but I imagine it could be extended to a number of different protocols.
Re:Does it matter which data you send first? (Score:3, Interesting)
Re:You can do this with ICMP too (Score:2, Interesting)
Re:Security through Obscurity (Score:4, Interesting)
Or you could just hide the message inside the picture with one of a number of different techniques
Or you could do both. Or you could do neither. Or you could put a decoy message inside the picture with shoddy obfuscation, and the real message in the TCP stream. Or you could use the message in the TCP stream to decrypt the message in the picture. Or you could completely bypass the Internet entirely and use a telephone, or radio, or written letter, or whatever else.
It's another option. Nothing more, nothing less.
and get you more data transfer capacity for the buck.
I'm not sure this is really necessary. The summary indicates that 1 in 1000 packets are normally corrupted... Which lets you put about 1KB data in a 1MB transmission... How many KB does it take to send a meaningful message? And just how much data do you want to risk if a single transmission is compromised?
Assuming you don't want others to see your message, you can't put more than a bit or two per retrans request, and even your message would require quite a lot of retrans requests, such that statistical techniques would reveal the existence (if not the content) of the message
Again, they're talking about duplicating what normally occurs - about 1 retransmission per 1000 packets. Which would not show up as anything terribly unusual statistically.
unless it was hidden in an absolutely huge transmission.
Again, just how much data do you need to transmit?
If you were to employ this technique on a website like DeviantArt or flickr you'd have plenty of data being transmitted... Plenty of room to hide a message or two.
Re:Does it matter which data you send first? (Score:1, Interesting)
If TCP does come with checksums in the header, then the packets should have the pattern
transmit: packet payload = A, checksum is ok
retransmit: packet payload = B != A, checksum is ok
This is highly suspicious and indicates steganography.
If on the other hand, the sender causes the checksum to fail on the first one, then isn't the network allowed to drop such packets along the way?
Even if the network doesn't drop corrupted packets along the way, the exact quote is "on average 1 in 1000 packets gets lost or corrupted". What is the breakdown for "lost" and "corrupted" separately? It seems that this system will be causing a lot of the latter but not the first.
A dozen better stega strategies: (Score:4, Interesting)
Heh, I can think up a half dozen better stegas:
(1) Encode the data as the packet length.
(2) Encode the data as the packet checksum
(3) Encode the data as the fragment offset.
(4) Encode the data as the number of extra ACKS.
(5) Encode the data as the starting connection sequence number.
(6) Encode the data as the window size.
(7) Encode the data as the inter-packet delay.
Steganography has the fatal flaw that the method has to remain secret. One basic rule of encryption is to assume the method is discernible and
the security must be all in some secret key.
Re:Might be a little obvious... (Score:5, Interesting)
I can tell you right now this research will get savaged in peer review. At my university, we were working on delaying ACKs to get a server to push the full window all at one time so a wireless device could power down between transmissions. Even though the server sent the packet and we sent the ACK, we were absolutely demolished in peer review because what we were doing wasn't proper TCP. If what we were doing isn't proper TCP even though it technically didn't violate the protocol at all, there's no way in hell this will fly.
Re:crimilization of ambiguity (Score:1, Interesting)
Theoretically you can make a one time pad password to transform random bytes into any data you want (ie you could transform a random block into something harmless). Any extra bytes on the end of your bogus transform and be transformed into a checksum. Of course if the government really is out to get you then there's not much you can do one way or the other
Re:Security through Obscurity (Score:1, Interesting)
I realize that all forms of steganography are basically security through obscurity, but this one is even more inane. Unless subjected to additional protection, anyone aware of this form of steganography could easily track it, and more importantly, it would look suspicious in traffic logs (drastically increased retrans requests, but only for a small subset of the TCP connections logged). Steganography should look innocuous, in addition to hiding information, if you want it to work.
That makes very little sense, especially since the article specifically says "as long as you don't overuse it".
Run some long-term traffic analysis over a normal connection. Heck, even do some preliminary data mining on the traffic over the connection you are actually going to use for the secret data. Then you can mimick the normal patterns of data loss over your link.
You would generally want to just toss a retransmitted packet out at random intervals, interspersed with short bursts of 3 to 5 packets in a row. The trick is to not get greedy- have some patience. This isn't something you'd want to try & run an encrypted torrent over, for example. But this could have some very handy uses for text files or small amounts of other data.
You still don't want to just rely on this type of obfuscation. This type of technique is very useful when you don't want anyone to know that you are even trying to send encrypted data... or in other words it doesn't protect the data itself, it protects the fact that you are delivering data in the first place. You can pre-encrypt the data (in fact I would recommend it) to protect it from packet inspection analysis or capture.
Not a bad method depending on the actual implementation, but it is just another form of stenography.
In most real-world cases it would be a lot simpler just to find an unsecured wifi spot and send your data through a proxy.
Or save it to one of those micro-mini HD cards like the 4gig one I have in my phone, and glue the damn thing into a book binding or something and snail mail it.
Re:A dozen better stega strategies: (Score:3, Interesting)
You miss the point of steganography. Encryption assumes that it's acceptable for an attacker to know there's a communications channel, the requirement is to keep the attacker from finding out the contents of the channel. Steganography is intended to conceal the very existence of the communications channel from a potential attacker.
Consider the situation a dissident in China might be in. Merely concealing what he's posting won't help him. The government doesn't care what the content is, the mere fact that he's hiding it from them's enough to convict him as far as they're concerned. For him encryption isn't required, an encrypted message the government can't read is just as damning as the plaintext would be. What he needs is a channel that's so unobtrusive that the government doesn't realize he's posting anything at all. And if the government doesn't realize there's a message there, they aren't even going to try to read it.
Re:A dozen better stega strategies: (Score:3, Interesting)
Tis but a flesh wound.
The beauty of Steganography is that it doesn't have to remain secret, it only has to remain secret while it is being used. The shear number of options for Steganography makes it nearly impossible to detect, unless you know what and where to look.
A previous poster listed several other means for Steganography
(1) Encode the data as the packet length.
(2) Encode the data as the packet checksum
(3) Encode the data as the fragment offset.
(4) Encode the data as the number of extra ACKS.
(5) Encode the data as the starting connection sequence number.
(6) Encode the data as the window size.
(7) Encode the data as the inter-packet delay.
I can probably think of another couple of dozen ways, including layering the Steganography, by using any of the above methods in conjunction with other methods of obfuscation and encryption, where the TCP Steganography is combined with Image based Steganography, or Regular encryption methods or whatever.
The point of Steganography isn't to encrypt, it is to hide in plain sight. Reminds me of the guy who used to shoplift, but he only took REALLY big things, like a canoe, from the store. His premise was that nobody asked him for a receipt for the thing he was walking out the front door with.
Shoving clothes down your pants looks suspicious, walking out the door in plain view of everyone with one of the biggest things in the store, doesn't. Nobody would steal a boat like that. Of course now with security cameras everywhere, that doesn't work.
Re:Might be a little obvious... (Score:3, Interesting)
The reason you were likely demolished in the peer review is that by delaying the ACK, you're probably going to force the sender to retransmit the data, and when you turn your radio back on you'll have to receive multiple copies of it, blowing away any power savings you might have had from keeping the radio off for a bit longer.
Asymmetric bandwidth border crossings (Score:5, Interesting)
Whoever your peers were, they weren't familiar with best common practices for asymmetric bandwidth border crossings.
We did this in 1996 for the Whistle InterJet, back when the idea was relatively new, but it's now common practice. The problem is that if you have a border router with a relatively fast network inside the border and a slow connection to the Internet, with a faster connection for the router on the other side of the slow connection (e.g. for a DSLAM, for example, then what you're going to end up with is any larger transmission starving interactive traffic (for example, an update download vs. transient mail traffic, or a large file download vs. an ssh session.
The only reasonable way t deal with this situation from a bandwidth management perspective is to manage how full the buffer is on the routers on the other side of the slow connection, and that means banging the window size larger or smaller than it actually is in order to allow bandwidth control. Otherwise, your fast connection packs the router buffers full of data packets for the large transfers, and there's no room for packets not specifically related to the large data transfers, unless your router decides to do RED queueing. And that has its own performance issues (specifically, it increases the effective bandwidth delay product until it's the same as if it had been multiplied by your actual queue size divided by your high watermark at which pint you RED 50% of your incoming packets).
PS: This is why I always laugh at things like AltQ, which try to flow rate limit in order to do traffic shaping, since you can do that, but unless you adjust the window size, you're still going to pack up your router buffers with data unrelated to the flows that you wanted to prefer.
-- Terry