So in a wireless local-area network, all the user terminals (laptops, for the most part) must have a way of differentiating good packets from corrupted zones. This error-checking mechanism is called the checksum, a kind of signature against which the integrity of the packets can be confirmed. The checksum is a numerical value assigned to a data packet based on the number of bits in that packet. A checksum program uses that value to authenticate that the data hasn't been corrupted.
When the receiver's computer gets a packet, it checks for errors using that packet's checksum. Normally, if the checksum is wrong, the computer discards that packet. But if a terminal has the right steganography program installed, it won't discard these intentionally wrong checksums—instead, it will know that these are precisely the data packets to scan for steganograms.
HICCUPS is more difficult to pull off than LACK. That's because this method requires a wireless card that can control frame checksums (good luck finding one of those at RadioShack). Network cards create checksums at the hardware level. We have applied for a patent in Poland for a HICCUPS-enabled card that can control checksums, but so far we haven't built our own card. Detecting HICCUPS wouldn't be easy. You'd need some way of observing the number of frames with incorrect checksums. If the number of those frames is statistically anomalous, then you might suspect the transmission of hidden information. Another way of detecting HICCUPS would analyze the content of those dropped—and therefore retransmitted—frames in order to detect the differences between the dropped and retransmitted frames. Major differences in these frames would constitute an obvious clue to nefarious goings-on.
Any of these detection methods, of course, would require not only that an investigator be aware that a transmission was about to take place but also that he be equipped with the right equipment, ready to monitor the conversation and intercept bits. Such a situation would be unlikely, to put it mildly.
The third method, Protocol Steganography, is a common name for a group of methods that use another aspect of IP: packet header fields. These fields are like sophisticated address labels that identify the contents of data packets to the recipient. Steganograms can be hidden inside unused, optional, or partial fields, because any data in these fields can be replaced without affecting the connection. Some of the more ham-fisted steganography techniques simply replace the content of the unused or optional fields with steganograms. But that would be relatively easy to detect and even jam.
So, to evade detection by simple analysis, the more sophisticated variant of Protocol Steganography uses fields in which the content changes frequently. For example, some of the more esoteric VoIP fields carry security data for authentication purposes. That little authentication subfield changes frequently during the course of a normal call. A steganogram smuggled inside one of its many randomly changing packets would be extremely hard to detect. Of course, there is a trade-off: The user would also sacrifice security, meaning that his or her conversation could be intercepted more easily.
Minimizing the threat of evolving steganography methods requires an in-depth understanding of how network protocols function and how they can be exploited to hide data. The problem is, however, the complexity of today's network protocols. All three steganographic ideas we've outlined here are so simple, we're certain that real-life applications are sure to come, if they aren't already out there. In fact, much more sophisticated methods will appear as Internet communication evolves from VoIP to other real-time media communications, such as video chat and conferencing.
The anonymity of steganography might be good for privacy, but it also multiplies the threats to individuals, societies, and states. The trade-off between the benefits and threats involves many complex ethical, legal, and technological issues. We'll leave them for other thinkers and other articles.
What we're trying to do is understand what kind of potential contemporary communication networks have for enabling steganography, and in effect, create new techniques so that we can figure out how to thwart them. Some readers may object to our detailed descriptions of how these methods can be harnessed. But we would counter that unless someone shows how easy all this is, researchers won't understand the urgency and be inspired to develop protective measures. Not only can VoIP steganography be implemented in telephony tools that require a laptop or PC (like Skype), it can also be used in hard phones, such as the Android VoIP-enabled mobile phones that are starting to proliferate. Steganography on a phone is more difficult, because it requires access to the device's operating system, but no one should doubt that committed individuals will have no trouble rising to the challenge. As George Orwell once wrote, "On the whole human beings want to be good, but not too good, and not quite all the time."
This article originally appeared in print as "Vice Over IP."
About the Author
Józef Lubacz, Wojciech Mazurczyk & Krzysztof Szczypiorski, who wrote “Vice Over IP,” are professors at Warsaw University of Technology, in Poland. As part of the Network Security Group at WUT, they have looked since 2002 for new ways to smuggle data through networks, and more important, how to thwart such attempts. In 2008, the group published the first paper about network steganography in IP telephony. After many years spent anticipating evildoers and their machinations, Szczypiorski says his favorite saying comes from Indiana Jones: “Nothing shocks me. I’m a scientist.”