Slashdot Mirror
Phony TCP Retransmissions Can Hide Secret Messages
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."
-----"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 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."------
Ok so we're re-tran'ing on packets we claim to be corrupt, but that were received successfully. So by monitoring traffic and keeping careful note of which packet the retransmit is requested on, and seeing what the checksum of that packet was, we will know whether an anomalous request is being sent. Basically the checksum of an uncorrupted packet will be correct, so while not a conclusive test, it's a tip off that something is up (either malicious intent, or a network problem downstream between the monitor and the receiving host causing corruption). Some analysis can also be done at this point to compare the frequency of these with run of the mill retransmits and possibly detect odd behavior. Yes it will be mixed in with noise, but I think with some careful observation a pattern could be recognized.
Some other ways off the top of my head to go about this:
- Remote host intentionally sends a corrupt packet in response first, which is actually some creatively XOR'd version of what was expected but intended to look like typical upstream nonsense. The retransmit, which is now keyed off an actual corrupt packet, sends what should be there. The receiver can then combine the two into a meaningful secret message, while not actually sending retransmit req's for properly assembled packets. IMO this is only really detectable by abnormally high levels of retrans, or something which knows the trick and proactively tries to reassemble the information. Encrypt it and likely it will never appear as anything more than line garbage.
- Since the only thing that must remain constant is the destination (or does it?), why not distribute this. Set it up using a botnet, and since these are very small messages now being spread out across a hundred hosts (or more), the requirements to monitor and detect traffic and then correlate it go up significantly. Will a single slightly "off" packet from a host trigger an alarm? Probably not. Spread out the signal distribution over a bunch of servers to receive the traffic as well and it will probably never be noticed.
I understand Comcast uses a variation of this to hide BT traffic; they send an RST in response to a connection attempt.