Slashdot Mirror

← Back to Stories (view on slashdot.org)

Phony TCP Retransmissions Can Hide Secret Messages

Posted by Soulskill on 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."

18 of 188 comments (clear)

  1. Does it matter which data you send first? by drinkypoo · · Score: 3, 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?

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    1. Re:Does it matter which data you send first? by ta+bu+shi+da+yu · · Score: 3, Insightful

      Ummm... hopefully the stenographers have a good solid connection with no data corruption!

      --
      XML is like violence. If it doesn't solve the problem, use more.
    2. Re:Does it matter which data you send first? by DontBlameCanada · · 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).

    3. Re:Does it matter which data you send first? by camperdave · · Score: 4, Insightful

      I think you'd want that the other way around. Send the ecrypted data first, then retransmit the true data. That way, when an eavesdropper assembles all of the packets they will overwrite the "damaged" cipher packets with true data packets. They'll wind up with a perfectly clean file.

      --
      When our name is on the back of your car, we're behind you all the way!
  2. Might be a little obvious... by vintagepc · · Score: 3, Insightful

    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?

    --
    Evolution - Est. 4500000000 B.C. Don't piss in the gene pool.
    1. Re:Might be a little obvious... by Exitar · · Score: 5, Insightful

      They probably have another paper ready "Detecting RSTEG use through resent packets frequency statistical analysis"...

    2. Re:Might be a little obvious... by wjh31 · · Score: 5, Insightful

      no, because you can simulate the normal faliure rate, and so send 1kB of steganographised data per 1MB of real data (on average). While this isnt a particularly high rate, it means that you can send a few kB of text to your friend when it seems you are just sending some photos of your holiday/party/whatever. A few kB of text sounds like a pretty reasonable amound of information to be sending, especially if compressed first.

    3. Re:Might be a little obvious... by Opportunist · · Score: 2, 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.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    4. Re:Might be a little obvious... by Spaham · · 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.

    5. Re:Might be a little obvious... by hesaigo999ca · · Score: 2, 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 succeeded, needs only a few words to convey the message, they don't go on about a page and a half about what happened and where they went for lunch! Even morse code could easily piggy back unto this system, and low and behold, the through put would be lessened as such is the way of morse, you say only important abbreviations to convey the message!

  3. Security through Obscurity by ShadowRangerRIT · · Score: 4, Insightful

    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.

    --
    $_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
    1. Re:Security through Obscurity by grommit · · Score: 4, 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.

    2. Re:Security through Obscurity by ShadowRangerRIT · · Score: 2, Insightful

      Or you could just hide the message inside the picture with one of a number of different techniques, which would be far less susceptible to detection, and get you more data transfer capacity for the buck. 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 unless it was hidden in an absolutely huge transmission.

      --
      $_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
    3. Re:Security through Obscurity by Anonymous Coward · · Score: 1, Insightful

      Why "Dmitry"? Censorship, repression, etc. is not the privilege of Russia or ex-socialist countries afaik.

  4. Re:Real errors? by evanbd · · Score: 5, Insightful

    Then your stego channel detects an error thanks to its checksumming. And it retransmits. Much like TCP. In fact, your stego channel could just be another layer of TCP.

  5. lost vs corrupted by Speare · · Score: 2, Insightful

    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. ... [I]f a packet is corrupted, the original packet and the retransmitted one will differ from each other.

    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."

    --
    [ .sig file not found ]
  6. Re:crimilization of ambiguity by phoenix321 · · Score: 3, 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.

  7. why is the reason always "avoiding censorship"? by dtolman · · Score: 2, 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?