Slashdot Log In
Phony TCP Retransmissions Can Hide Secret Messages
Posted by
Soulskill
on Wed May 27, 2009 08:41 AM
from the tricky-packets dept.
from the tricky-packets dept.
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."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Does it matter which data you send first? (Score:4, Insightful)
Does it matter if you send the real data or the masking data first, if you're just going to "fail" it and resend with the other data?
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.
Parent
Re: (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 reques
Re:Does it matter which data you send first? (Score:4, Insightful)
Ummm... hopefully the stenographers have a good solid connection with no data corruption!
Parent
Re: (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 l
Re:Does it matter which data you send first? (Score:5, Insightful)
Parent
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.
Parent
Re: (Score:3, Interesting)
Re: (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:Does it matter which data you send first? (Score:5, Insightful)
>> you'd get an insanely poor data rate
The target application is busting through mass censorship by government entities. Even the equivalent throughput of a 300baud modem is better than no connectivity at all. Heck, I bet most of the /. readers over the age of 35 spent a goodly portion of their youth msging each other on local BBs at 1200baud or less --> and we thought it was lightning speed (compared to pen n'paper over snail mail).
Parent
Re:Does it matter which data you send first? (Score:4, Funny)
Ooooo OOOOOO Weeeeee, oodle, oodle, TSSSSSSSSSSSSSSSSSSS.
WHAT? How dare you, my mother was a saint!
Parent
Might be a little obvious... (Score:3, Insightful)
And, would your bandwidth not also double, if you use this and re-send one secret packet for every 'normal' packet?
Re:Might be a little obvious... (Score:5, Insightful)
They probably have another paper ready "Detecting RSTEG use through resent packets frequency statistical analysis"...
Parent
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.
Parent
Re: (Score:3, Funny)
So this is how "C++" got created in the first place!
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.
Parent
Re: (Score:3, Insightful)
I believe this is not intented to be rfc compliant, but
rather cloak and dagger stealth message sending...
so you can't compare what you tried to accomplish
to what they offer.
Re: (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 w
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
Parent
Hide it in Bittorrent traffic (Score:2)
Deliberately hide the stego resend packets in encrypted Bittorrent traffic. That would make this very hard to detect. Even if the Bittorrent communication was unencrypted, you'd need to figure out which segment of which torrent it's associated with, then calculate the checksum. Since the Bittorrent traffic is encrypted, this makes that much harder. Of course, you could spy on the traffic with your own peer, but the stego could be used to communicate only between known peers, in which case the other peer
Re: (Score:2)
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?
Sigh....at least read TFS?!?
As long as the system is not over-used
In other words, this falls in the category of "probably not practical, but it can be done and its pretty nifty." If they didn't invent it, someone else would have, and not too many other people would give a damn. I doubt that it's of interest to crypto-geeks either, since it's so easily detected and just steganography at the end of the day.
Re:Might be a little obvious... (Score:5, Insightful)
Parent
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.
Parent
Re: (Score:3, Insightful)
It's no problem that you're talking to someone from the US when you're in China.
What matters is what you're talking about.
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.
Parent
Who cares about bandwidth? (Score:2)
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?
That would be an issue if the goal is to hide movie piracy.
If you want to transfer textual descriptions of totalitarian regimes, you do not need a lot of bandwidth.
Re: (Score:3, Insightful)
The technology is sound, this is in let's say a military operation where the government being spied on knows they are begin spied on, and have all communications bugged. This is a new technology that has yet to be decoded, so technically, yes it would double the amount of data sent, and also raise a flag for dropped packets...but the whole premise is that the flag has already been risen, and everything is already under a microscope.
An agent overseas, needing to send a confirmation that an operation has succ
Real errors? (Score:5, Interesting)
Re:Real errors? (Score:5, Insightful)
Parent
Security through Obscurity (Score:5, Insightful)
Re:Security through Obscurity (Score:5, Insightful)
Who said anything about drastically increased retrans requests? The method is meant for short messages to the effect of "Dmitry was arrested on false charges yesterday." that are hidden inside a transmission of a much larger file such as a picture.
Parent
Re: (Score:3, Insightful)
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.
Parent
Re:Security through Obscurity (Score:5, Funny)
64. Because that should be enough for anyone.
Parent
Re: (Score:3, Informative)
lost vs corrupted (Score:3, Insightful)
I suppose it's now critically important to know more about lost vs corrupted statistics. If it's 999/1000 lost, and 1/1000 bit corrupted, then the sudden up-tick in "corrupted" packets could be noticed.
I don't know a lot about the internals of TCP, but can't the sending party re-transmit even without being asked to do so? If so, you have a couple other possible channels for messages. For example, send a packet that says "if I double-send the next packet, take action."
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.
Re:crimilization of ambiguity (Score:4, Insightful)
If ambiguitiy of circumstances is no defense anymore, you have eliminated "in dubio pro reo". Which means you have reached THE definition - and hallmark - of repression, because everyone does ambiguos things sometimes with no ill intent at all and nobody is free when they have to judge their entire day if they're doong something ambiguous.
And no, that's no slippery slope but the bottom of it. Rock bottom.
Parent
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: (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.
Better if roles are reversed (Score:2)
This is definitely a cool idea, but is readily detectable as others have already pointed out because the transmitted and retransmitted packets will obviously differ, and it is easy for someone to detect such a transmission and recover the steganographic message.
But, if you reverse the roles of sender and receiver, a much harder to detect mechanism can be embedded in the occurrence of each retransmission request. In the simplest scheme (which is easily detectable, so I would not recommend it), Alice wants t
Firewalls, Proxies, oh my.. (Score:2)
This won't necessarily bypass the great firewall of china, etc..
Really depends on the proxying in place.
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: (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
Re: (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 f
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
why is the reason always "avoiding censorship"? (Score:3, Insightful)
Every time a new way to beat eavesdropping come out, the only thing mentioned is how we can now beat the censors of totalitarian regimes.
What about its other fun uses? Terrorists sending messages to detonate a bomb (defeating the godless atheist liberal censors trying to read their messages), drug gangs sending messages about who to murder (defeating the overbearing fascist police trying to read their messages), spies sending messages with national or corporate secrets (defeating the evil counter-intel agents), etc.
Are we really so naive that new techniques like this are only going to be used by oppressed do-gooders? Or that we'll agree that they shouldn't be oppressed and suppressed?
Re:torrents (Score:4, Informative)
Parent
Re: (Score:3, Informative)
In a deeply censored regime, there are no unblocked ports, and all traffic which looks encrypted is blocked, and perhaps illegal.
Re: (Score:2)
TCP/IP protocol overhead: 160 bits/packet (TCP) + 160 bits/packet (IPv4) = 320 bits/packet (assuming no data, and that might look a little suspicious)
320 bits/packet * 250 packets/real bit = 80,000 bits/real bit
80,000 bits/real bit * 700 MB (smallest common size of compressed movie) = 80,000 bits/real bit * 5,872,025,600 real bits = 469,762,048,000,000 bits transmitted, or 53.4 TB.
Congratulations: Assuming you use the absurdly noticeable "empty packet" strategy, on a 20 megabit line with no other overhead,