Forgot your password?
typodupeerror
Communications Censorship Security The Internet Technology

Phony TCP Retransmissions Can Hide Secret Messages 188

Posted by Soulskill
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."
This discussion has been archived. No new comments can be posted.

Phony TCP Retransmissions Can Hide Secret Messages

Comments Filter:
  • 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?

    • by evanbd (210358) on Wednesday May 27, 2009 @08:53AM (#28108947)

      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: (Score:3, Interesting)

        by drinkypoo (153816)

        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

        • by ta bu shi da yu (687699) on Wednesday May 27, 2009 @09:17AM (#28109261) Homepage

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

          • Well, the receiver would "know" to a certain extent what kind of data to expect. He could easily signal the sender that the transmission was unsuccessful (independent from TCP's error checking mechanism), by implementing his own error checking on top of TCP.

            Yes, it's more overhead. But in the time of faster and faster connections being monitored tighter and tighter, it's pretty much the logical step.

        • Re: (Score:2, Informative)

          by Anonymous Coward

          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

        • by camperdave (969942) on Wednesday May 27, 2009 @09:59AM (#28109779) Journal
          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.
          • by VanessaE (970834)

            Unless the eavesdropper has already thought of this and has configured his snooping tools to keep *all* of the received packets. A good tool would, of course, also run comparisons among packets, especially those having been re-sent. If "diff" can pick out the differing bits of text from two otherwise unknown sources, why couldn't one write a similar tool that's focused on pseudo-binary data?

          • by drinkypoo (153816)

            That's what I said. The real data is the encrypted message. The masking data is the unencrypted (or possibly weakly encrypted) innocuous traffic. Please see sig. P.S. Why wouldn't they capture the rejected packets? They're packets, too. In any case, see sig.

    • by DontBlameCanada (1325547) on Wednesday May 27, 2009 @09:03AM (#28109057)

      I believe the procedure will be something like this:

      Msg1: "The next character is part of a secret msg: /" --> Reciever NACK
      Msg2: "The next character is part of a secret msg: ." --> Reciever NACK
      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.

      • Re: (Score:3, Interesting)

        by Alarash (746254)
        That might work, but you'd get an insanely poor data rate since the TCP overhead is eating up all of the bandwidth. And some of the newer routing devices can monitor abnormal packet loss rates (normally to enforce SLA's) so it's pretty easy to detect that behavior.
        • Re: (Score:3, Informative)

          by gnick (1211984)

          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.

        • by DontBlameCanada (1325547) on Wednesday May 27, 2009 @09:31AM (#28109417)

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

          • Ooooo OOOOOO Weeeeee, oodle, oodle, TSSSSSSSSSSSSSSSSSSS.

            Welcome to the Atomic Cafe
            login:

        • So then you just keep the bad data to a minimum, say, one substantive packet retransmit in every hundred thousand. If the information is the important thing, and you have time, you'll get what you need without alerting anyone.

          Just make sure you don't have a keylogger running on the transmitting computer.

  • by vintagepc (1388833) on Wednesday May 27, 2009 @08:47AM (#28108847) Journal
    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?
    • by Exitar (809068) on Wednesday May 27, 2009 @08:51AM (#28108903)

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

      • by caffeinemessiah (918089) on Wednesday May 27, 2009 @08:54AM (#28108961) Journal

        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: (Score:3, Funny)

          by Anonymous Coward

          So this is how "C++" got created in the first place!

        • by hal2814 (725639) on Wednesday May 27, 2009 @09:47AM (#28109631)

          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: (Score:3, Insightful)

            by Spaham (634471)

            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)

            by jandrese (485)
            To be fair, what you suggested and more is already in use in the industry. There are some QoS type appliances that will actually mess with the TCP window size on packets on the wire to reduce their bandwidth without adding unnecessary delays for instance. Some that can even "pause" a connection just by rewriting the window size to 0 on the stream.

            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
            • by tlambert (566799) on Wednesday May 27, 2009 @01:09PM (#28112703)

              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

          • by dr2chase (653338)
            Demolished in peer review doesn't necessarily mean it is a bad or non-working idea. Certain CS communities have goofy norms; for instance, for a paper on a lock-free queue, I wrote the algorithms with all the necessary barrier points noted (i.e., so it could be used on a real computer). My co-author, with more experience in that conference to which the paper was submitted, said that they had to come out, that these guys prefer an idealized (aka, "non-existent") memory consistency model. The advantage of
      • 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

        • by dr2chase (653338)
          I wondered about this myself. Sagans and Sagans of international encrypted BitTorrent traffic, it just seems to me this cannot make the NSA happy.
    • 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.

    • by wjh31 (1372867) on Wednesday May 27, 2009 @08:56AM (#28108985) Homepage
      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.
      • by hal2814 (725639)

        How can you simulate the normal failure rate? The normal failure rate is how often normal packets will need to be resent. The expected number of extra packets sent assuming you don't go over the expected number of normal packets lost would be zero. You would have to be lucky to get a failure low enough to be able to shove these extra packets into the stream and keep the same number of resends.

        • And here the "beauty" of heavily oversubscribed providers shines.

          Have you ever tried what happens when you start using a provider that unscrupulously oversubscribes even worse than anyone could possible do without blushing with shame? Try using one of their subscriber lines at prime time. You'll be subject to packet loss and transmission errors, fluctuating wildly. One day is fine, next is crap, hell, one MINUTE is fine next is crap.

      • by Yaur (1069446)
        The eavesdropper will know when the packet passes if it is corrupt or not by looking at the checksum. If it is "corrupt" he is free to drop it and/or request retransmission if it is not it would be highly suspicious if the sender retransmitted data that was different. In order for this to occur naturally there would have to be a very specific and very rare (something on the order of 1 packet in 10 billion) error occurring before the eavesdropper intercepted the packet followed by loss or corruption after
    • by click2005 (921437) on Wednesday May 27, 2009 @08:56AM (#28108987)

      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.

      • > This isnt designed to hide bittorrent traffic...

        Then it is of no interest to the average Slashdotter.

    • by Etylowy (1283284) on Wednesday May 27, 2009 @09:08AM (#28109119)

      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.

      • by kasperd (592156)
        I think the intention was to use the full packet. So fill up some packets with entirely encrypted covert channel data and ensure the TCP checksum is bad. Every packet retransmitted that way gives you more than 1400 bytes of actual payload. Of course if it is done that way, it can be distinguished from random corruption. Random corruption is more likely to flip individual bits.

        If you just flip single bits, you get around 13 bits of covert payload per corrupted packet, because the offset of the corrupted b
    • 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.

    • With today's providers and their notorious stability and reliable loss-free packet transmission, where never ever for some miraculous reason you suddenly get transmission errors in the vicinity of 20+ percent?

      If (really big IF) they notice it, they'll probably be poking their routers because they'd (rightfully) expect the error to be somewhere on their side. In my experience, though, they don't bother until you get off your butt and poke their support endlessly for the packet loss and transmission errors.

      • by Yaur (1069446)
        But almost all of that loss is congestion related, which doesn't introduce bit errors. You either get the whole packet or you don't get any of it.. bit errors are rare. In order for the two packets to be different you need 2 bit errors in one packet that cancel each other out in the checksum followed by a congestion loss or more, detectable corruption. If there are enough errors that this could go undetected normal traffic wouldn't be working anyway so you could disconnect the flow without impacting any n
    • Re: (Score:3, Insightful)

      by hesaigo999ca (786966)

      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)

    by PhireN (916388) on Wednesday May 27, 2009 @08:47AM (#28108855)
    What happens when one of the packets actually gets corrupted?
  • by ShadowRangerRIT (1301549) on Wednesday May 27, 2009 @08:50AM (#28108897)
    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.
    • by grommit (97148) on Wednesday May 27, 2009 @09:02AM (#28109049)

      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.

      • Re: (Score:3, 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 absol
        • by Ephemeriis (315124) on Wednesday May 27, 2009 @09:34AM (#28109443)

          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.

    • by mcrbids (148650)

      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.

      I guess you haven't seen wh

  • lost vs corrupted (Score:3, Insightful)

    by Speare (84249) on Wednesday May 27, 2009 @08:58AM (#28109003) Homepage Journal

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

    • by bwindle2 (519558)
      If there is a stateful firewall between the sender and receiver, the firewall may block "unexpected" packets, such as those who's sequence numbers are off, or unrequested retransmits.
      • by Tony Hoyle (11698)

        In fact if it's a working firewall it must. One of the primary functions of a firewall is to drop unexpected packets.

    • by againjj (1132651)
      You can't double send without acknowledgment for each send. This is because you can not know if the receiving end received both packets, since packets get arbitrarily dropped during intermediate hops.
  • by epine (68316) on Wednesday May 27, 2009 @09:04AM (#28109063)

    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.

    • by phoenix321 (734987) * on Wednesday May 27, 2009 @09:55AM (#28109729)

      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.

    • Without meaning to contest your deploration of current trends, I'd suggest a workaround.

      Accumulate a corpus of innocuous data comparable in size to your chunk-o-random. (I'd recommend a partial backup of your OS.) XOR them, keep the product, and toss the original. When They Come For You, present the product as the key, and instruct Them to XOR it with the chunk-o-random. Presto, intelligible and hopefully non-incriminating data.

  • by Viol8 (599362) on Wednesday May 27, 2009 @09:10AM (#28109151)

    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:2, Interesting)

      by Vanders (110092)
      Hell, the TCP header has an entire 6 bits unused (Reserved, but will likely be usable). Just stick your data in there.
      • Re: (Score:3, Informative)

        by Tony Hoyle (11698)

        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.

  • 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

  • This won't necessarily bypass the great firewall of china, etc..

        Really depends on the proxying in place.

  • The receiver could have a website with empty pages pages titled 0.html and 1.html. To send the ascii character 'a', the sender accesses 0.html, 1.html, 0.html five more times, and then 1.html one last time. The receiver would then look in their web server log and see that the letter 'a' was transmitted.

  • Covert channels like this are well known and have been part of the common criteria for decades. This is why systems handling classified data are usually physically isolated from others. When data is transferred into the classified system there no ACKs and the wires that would normally carry them aren't connected.

  • by Ancient_Hacker (751168) on Wednesday May 27, 2009 @09:46AM (#28109617)

    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)

      by Todd Knarr (15451)

      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

      • by rgviza (1303161)

        Of course, now that this method is public knowledge the communications channel is no longer concealed.

        Security by obscurity never works because the truth can be probed out by an astute attacker. In this case it's no longer even obscure.

        -Viz

    • Re: (Score:3, Interesting)

      Steganography has the fatal flaw that the method has to remain secret.

      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

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

      Secrecy isn't a bug, it's a feature. For the target audience, if you get caught sending out encrypted messages, you immediately become a suspect. Which, in turn, can lead to a pleasant stay in the local version of Guantanamo until you decide to cough up the key. The object of the game is to prevent the authorities from know

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

      Not if you encode it in the sequence number. The sequence number is supposed to be a cryptographically strong random number, and if you replace it with part of an encrypted message, nobody should notice.

      • 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

    • by ericfitz (59316)

      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.

      None of these are better, as they will all be interfered with or blocked by NATs and inline IDS. The sole exception is extra ACKs, which might be caught and cause a channel reset with some IDS devices.

      The payload in a retransmitted packet will be carried unaltered regardless of intervening network hardware.

      Detecting retransmits can be done and statistical anomalies detected. However most router, proxy & firewall vendors will probably not want to save the extra state per-connection (last seq# transmitt

  • These days, physical link layers seem to be pretty stinking good. How common are TCP retransmits for reasons of corruption?

    Why do this at the TCP layer? Why not the application layer? Consider all of the covert channels that might exist with the ability of POST, PUT, and even method=GET.

    I've thought off and on about botnets that use spamblogs or google search + zeitgeist queries to coordinate their activities. The web is the largest visible surface area of the internet, so if I wanted to hide something

  • Like encoding the message in whether you request a retransmission of the packet or not.

  • by dtolman (688781) <dtolman@yahoo.com> on Wednesday May 27, 2009 @10:26AM (#28110183) Homepage

    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?

    • ... we should also ban the terroristic device known as the "telephone" (because they can use it to coordinate their actions), the evil "postal service" (because they can send money through it), and the especially horrific "smoke signals" (highly secure because only people within range can see, dontcha know).

      Sure, these techniques can help bad guys communicate. That doesn't mean they should be banned.

      • by dtolman (688781)

        Who says they should be banned?

        But at the same time - why is there always editorial commentary about the "good" some invention X will cause, when we damn well know that the "good" use probably won't be its primary user base...

  • ... so... wouldn't it be the same just putting your data in the body of an ICMP echo message (ping)?

  • There is a principle that if there is any means of systems affecting each other, that mechanism can be used to communicate.

    Consider classified and unclassified processes in a "secure" operating system, separated by a process boundary, and disjoint credentials (so, they can't see the same resources, like files).

    The can communicate because the system has a finite amount of memory and simply requesting memory resources and noting successes and failures can be used to communicate.

    It's awfully inefficient, but i

  • While the approach is obvious, you can do much better, e.g. by using the random initial sequence number to transport a (short) encrypted message. This is practically undetectable and doe not modify any TCP characteristic.

    I call this non-nwes...

  • Not only do they seemingly not understand cryptography, stenography, or data tracking, they do not understand how much of Asia's network will not let this pass even as it stands now. There is a lot of Asia that runs through SAT links and they use true TCP acceleration which proxies the TCP segments. The retransmission will be pointless here at best. At worst they will screw up the far side connection resulting in a RST.

    Also it would be like a little red flag saying "Look at me!" every time it was used. With

  • In other news: Empty envelopes might be used to convey messages! News at 11!

"Morality is one thing. Ratings are everything." - A Network 23 executive on "Max Headroom"

Working...