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."
Re:torrents (Score:4, Informative)
Re:Does it matter which data you send first? (Score:5, Informative)
You send the masking data first, since the recipient is the one who controls *which* masking data they ask for a retransmit on. Then the sender retransmits the real data. If you send the real data first, you have to know which piece to ask to resend. That requires some sort of framing or similar protocol, which would make it easier to spot.
Re:Might be a little obvious... (Score:5, Informative)
They probably have another paper ready "Detecting RSTEG use through resent packets frequency statistical analysis"...
Parent is correct. arXiv is full of papers that have really poor methodology, and quite often the authors "improve" upon their earlier papers. This is also common in the field of data mining, where crap is initially packaged to look shiny and then Crap++ is sold as an improvement, all the while racking up the author's publication count. And that, unfortunately, is the currency of research in computer science.
Re:Might be a little obvious... (Score:4, Informative)
Doesn't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets?
And, would your bandwidth not also double, if you use this and re-send one secret packet for every 'normal' packet?
From TFA...
"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,"
This isnt designed to hide bittorrent traffic but should be able to hide someone posting on a web bog or some other low bandwidth activity.
The downside seems to be it hides what you're sending but not who you're sending it to.
Re:Does it matter which data you send first? (Score:5, Informative)
I believe the procedure will be something like this:
Msg1: "The next character is part of a secret msg: /" --> Reciever NACK ." --> Reciever NACK
Msg2: "The next character is part of a secret msg:
Msg3: "The next character is part of a secret msg: R" --> Reciever NACK
Msg4: "The next character is part of a secret msg: o" --> Reciever NACK
Msg5: "The next character is part of a secret msg: x" --> Reciever NACK
Msg6: "The next character is part of a secret msg: {ascii null}>"
Secret msg: /.Rox
It works because each tcp retransmission updates several fields in the tcp header as part of correct operation (check sum etc). So brute force comparison of the previous datagram to the new datagram will always fail. In order to detect this, the eavesdropper would need to strip the headers. That in itself isn't too hard, however since 1:1000 normal packets get a retransmit, the device doing the snooping will be hugely overwhelmed with noise.
It be like trying to overhear whispered conversations in a huge auditorium with loudspeakers blaring a static hiss (white noise) at high volume.
Even 1 bit per 1 megabyte might be a problem (Score:5, Informative)
With the packet size of ~1500 bytes a 1MB send means ~700 packets. With an average of 0.1% packets lost even sending a single bit of information (a single 0 or 1) per 1MB transfered gives you a 150% increase in lost packets
With dialup and it's default packet size of ~500 bytes combined with much higher packet loss you might be able to sneak in 1-2 bytes per MB without making it possible at all to detect. Considering 56kbps modem upload speed and need for some error/fault correction in the protocol sending an equivalent of SMS (160 characters) would take more than 2 days.
All that is assuming that someone is looking for that type of transmissions. If not it looks like a very nice method to send very short messages.
Re:Does it matter which data you send first? (Score:2, Informative)
If the masking data is sent first, the intercepting party can only be certain of what the data looked like at the time it passed through whatever hop he's listening at. Obviously, corrupted data must become corrupted at some point, and just because the data appears good when you intercept it doesn't mean that the intended recipient necessarily saw it as good when it arrived. That's not a problem.
The problem with sending the masking data first is that when the interceptor looks at the real data, it won't look valid to him. And it'll be real suspicious when the server doesn't ask for a resend.
I think the obvious thing to do would be to seed the sent data with a large number of actually corrupted packets. The recipient can then at his leisure ask for a resend on a packet that was actually good. When this happens, the sender can send a packet of real data. As long as the connection is actually good enough, the man in the middle should be fooled into thinking the interlocutors have a really shitty connection, and most of the data should get through.
That should work pretty well, even to the point of allowing the recipient to ask for a resend of any real data that might (ironically) actually get corrupted. All he has to do is ask for a resend on a packet the sender knew to contain real data.
Re:Does it matter which data you send first? (Score:3, Informative)
Some people are willing to accept insanely high overhead to avoid censorship - Ever try Freenet?
But I agree - You could conceivably configure a router to just shut this down (I assume - I'm not really an IT guy). If you notice that two IPs are trying to communicate with large amounts of traffic at a 0.1% success rate, you may just block that traffic to save your network.
Re:You can do this with ICMP too (Score:3, Informative)
A lot (most, probably) of firewalls will drop packets with reserved bits set to nonzero.
It's this problem that means that ECN is still not usable, many years after its introduction... the reserved bits are effectively useless.
My firewall does random sequence numbers (Score:3, Informative)
My firewall does random sequence numbers.
It does this to make up for a number of commercial operating systems that *don't* do random initial sequence numbers. Then it rewrites the packets as they go through the TCP stream, including the checksum, on both the way in and the way out.
This is a common method of mitigating "guessable" initial sequence numbers for older systems behind good firewalls.
-- Terry
Re:Security through Obscurity (Score:3, Informative)
Re:torrents (Score:3, Informative)
In a deeply censored regime, there are no unblocked ports, and all traffic which looks encrypted is blocked, and perhaps illegal.