VoIP Watermarking Defenses

A couple of years ago (2005) the Rome Air Force Base sponsored research [1] into de-anonymizing VoIP traffic. The researchers developed a modification to the Linux Kernel which inserted a watermark into Skype VoIP traffic that is passed through a low-latency anonymizing network. A 24-bit watermark is inserted through the modulation of the inter-packet timing of data packets. This is essentially the establishment of a covert channel through a timing attack.

The attacker reads the probabilistically hidden bits in the traffic to reconstruct and identify of the originating and terminating nodes of a VoIP call. A defense against this would be to scrub your outgoing traffic to remove the covert channel or increase the probability of error in bit recovery beyond the acceptable rate. The attacker is not manipulating packets as they leave the origin, since then they would presumably already know the origin. The suggested implementation is to watermark packets as they transit through a VoIP gateway. Because of this it is necessary to scrub packets beyond the gateway; after they have been marked.

More interesting would be to alter the packet timing in a controlled manner and embed bits of your choosing. If you had enough knowledge as to how bit patterns are assigned to identities you could arbitrarily alter your identity and pose as another. You could also add incorrect watermarks to random VoIP traffic.

To detect a watermark you can exploit the embedding process. The technique relies on existing latency in the VoIP calls and is able to function with around 20ms - 30ms of latency by making a 3ms adjustment to packet arrival times. A suggestion is to make the latency as low as possible therefore making the existence of a watermark more detectable since the latency would need to be adjusted to unexpected levels. It may not be feasible to keep low latency for a long period of time but that would not necessarily be necessary. Latency could intermittently be pushed to the lowest possible levels and a check for embedded bits could be performed. The method uses the existing latency in the first minutes of the call to determine what an acceptable level of latency to add is. Exploiting this, the first minutes (or so) of the call could be made with high, but still believable, latency so the attacker embeds bits with the appropriate higher latency. Once a watermark has been embedded the latency could be significantly reduced and the alteration of packet timing should be noticeable.

Covert channels based on packet timing have many applications, beyond de-anonymization, and could be made very difficult to detect. Steganographic style embedding of traffic is a possibility as well as watermarking for authentication purposes by the originating and terminating parties.

[1] S. Chen, S. Jajodia, and X. Wang. Tracking Anonymous Peer-to-Peer VoIP Calls on the Internet. In CCS '05. ACM, November 2005.

Using Video as a Covert Channel

With steganography being all the rage these days why not up the ante and use video as a covert channel? (I haven't looked around for this but I bet someone else is already doing it.) With all the bandwidth, and the data already being put through some sort of transcoding, the opportunity to embed seems ripe. I'm not sure how this would work, but let's assume the process is: (a) hardware camera, (b) software transcoding and compression of signal, (c) network traversal, (d) software transcoding and decompression of data, (e) video display. We'll assume adding data before (b) and extracting data after (d) will not work due to loss from the transcoding. To do live video stego insert a step between (b) and (c) to add data and between (c) and (d) to extract data. The method would be rather detectable. A better solution may be to drown yourself in transcoding and (de)compression code for a while and develop a stego (or stego capable) codec or a stego module for either a specific existing codec or any codec satisfying certain requirements. (Do these exist alraedy?)

Embedding of small amounts of data should be difficult to detect. A simple (well, maybe) exercise would be to embed a chat in a video conference. Binary files, VoIP, other video conferences, multimedia files, or any sort of network traffic are all nice things to be able to embed.

The hardest needle to find is the needle you're not looking for.

(Relatedly, it would be desirable to be able to determine if someone has found your covert channel. How or if this could be done using lacking some sort of quantum crypto I'm not sure. Use of an additional channel to influence the convert channel in ways known by the covert parties might work but not be provably correct. The idea would be that when an ease dropper is present their would be some impediment to making the expected change in the channel, similar to quantum crypto. Although, "some impediment" is pointlessly vague.)

Oh, It's a "Friendly" Unrequested Illegal Malware Intrusion

Microsoft, in their quest to rid the world of the poorly written code they have burdened it with, has decided that exploiting vulnerabilities in their products in order to repair their products is an acceptable practice. A research group of theirs is building "friendly" worms.

By definition a standard symbiotic relationship imparts benefits on both groups. It's arguable that existing worms/botnets could be considered symbiotic worms, even "friendly", in a sense. When you click on that Valentine's day attachment, and Storm pawns your machine, one of the first changes it makes, after establishing a command and control channel, is to somewhat harden the operating system so that other worms/viruses/trojans cannot infect the new captive. This is comparable to what Microsoft's friendly worms are going to do. Storm continues from there to look for more nodes and send out spam. If Microsoft is going to label their home-brewed malware a "worm", they have some intrusive (but not that unexpected) company. Let's hope they don't decide to spin some "friendly" mass-mailings into their worms as well.

The proposed Microsoft worms would only be beneficial for the worms in the sense that the hosts allow the worms to distribute themselves. Do the worms receive other benefits from being infected by the hosts? This could be like a reverse parasite, the worm infects and the host is parasitic on the worm (what is the standard biology term for this?). Other then the partial lack of symbiosis, what distinguishes our "friendly" worm from a Storm/Mega-D infection? (1) It's not sending out Spam/performing auxiliary illegal functions (2) It's distributor is known (3) It deactivates itself? (4) It's "friendly". Point (2) will give victims legal recourse and establish an amount of responsibility with the distributor, Microsoft, this appears to be a good thing.

I genuinely hope (3) is true, this seems like the most important aspect. But, when will it deactivate? After repairing the infected system? After the previous and infecting an additional N neighbors? And, how will it deactivate and how complete will this deactivation be? On a theoretical level, it seems like you should run into some analog of the halting problem here. Virus infects machine, repairs machine, uses control (a) to delete self, control (b) to delete control mechanism (a), mechanism (c) to delete mechanism (b)... we all know were this leads, no where. What am I overlooking in this analysis? Wouldn't a control channel be needed to delete any preexisting control channels? A potential solution would be to send a message to Windows Update's servers after cleaning the machine and to have the server remove the mechanism, or it seems like some one-way function could be used as well. Contacting a Windows server is very similar to a command and control channel. (Although it's likely hopeless) let's hope no one subverts this or related channels.

With respect to (4), "Let Us Just Pour Some Oil Down This Slide and Balance Our Cluster Bombs On Top Of It."

This could go very bad very quickly for whomever performs the researching, let alone for Microsoft, a company with such a history of vulnerability-less code. Is the lack of "Windows Genuine Update" worthy of repairing? There could be a flaw in the old version of Windows Update rationalizing this view. The worm infects the victim, updates the system software, and after the user reboots they're locked out because they do not have a genuine version of Windows, regardless of whether they pirated Windows or the machine they purchased came with a pirated version unbeknownst to them. Many variations on this theme are imaginable.

Slightly more insidiously, a patch is applied to Internet Explorer closing all previous vulnerabilities and opening a new vulnerability. Has Microsoft (or any company) consistently released patches that have not created new vulnerabilities? They have not, and it's not because they're not extremely skilled programmers, it's because that is usually not a software development requirement or possibility. Patch away if the patch is going to be accompanied with a proof theoretic verifier of the patched code that (by somehow avoiding all of the paradoxes Turing, Church, and others have pointed out) proves the invulnerability of the code, this is actually more realistic than it sounds. Until then, this could easily do much more harm than good, even if performed in the friendliest of manners.

Furthermore, the potential for subversion of the worm or control channels seems intolerably significant. Any of the nearly daily (hourly?) zero-day Microsoft exploits do enough damage as it is. Imagine what would be possible with a zero-day exploit that wormed it's way through. Imagine a modification to the worm making all Windows machines appear as though they need to be patched. Reverse engineering Microsoft code is trivial compared to reversing Skype's code, and both projects have already been done and are actively being enhanced. The way in which this problem is addressed will need to be brilliant or we'll see some brilliant attackers flourish.

What are the legal implications of releasing this worm or of even pursuing research in this direction? The courts have never been to knowledgeable in the area of data security and seem to err on the side of, "if it sounds possibly not good it's horribly bad." Recall the fines given for non-malicious use of an open public WiFi networks. Whether released by Microsoft, or the Russian Business Network (RBN), a worm is a worm like sarin is sarin. If Pfizer were researching sarin to develop a variant of the gas that would repair paraplegics I'm pretty sure that would be illegal (so maybe the previous is an absurd stretch). When Iran researches nuclear weapons for "peaceful" (sounds close to "friendly") use they receive attempted sanctions and threats of invasion (from the more irrational congressmen). Does it behoove the EFF to do the equivalent? In a metaphorical way I do think so.

U.S. laws likely do not allow a computer worm to be released into the wild by a private company, certainly not by an individual. Simply performing the research is arguably illegal as well. Looking abroad, a release is certainly illegal in Germany, and likely the research as well. KisMAC moved their servers to Switzerland after Germany ratified their new cyber security laws. I'd suspect the U.K. and Australia would be rather unfriendly to these "friendly" activities as well.

Would there be legal recourse for those infected with the worm? If it's egg patching (or simply infecting) your system it will require bandwidth. In many (most?) European countries internet connections are paid for on a bandwidth basis. Microsoft is then literally stealing a commodity that you have paid for when they infect you with their worms. Shouldn't they be required to remunerate you? The virus will also use other commodities, such as disk space and processor cycles, and will through these use electricity as well as ware down your equipment (to some degree). This seems to clearly fall under unauthorized use, although it is moving into a new frontier for these types of arguments and lawsuits (I cannot think of any related precedents?).

There's always the possibility of an accident. Does Microsoft expect to develop a worm with no impact on performance/other applications/other services? They do not know every line of code that has ever been written for their products so this will certainly be a problem. If they inadvertently crash another application, maybe a load balancer, they could bring down a server or a cluster. What if it belongs to a Broker/Dealer and financial records are lost? I could image damage in the USD billions being caused, or worse, it is a worm. And, whose pockets go deeper? Most corporations would love to sue Microsoft (ignoring the formidable legal defense team for a moment), the European Union and U.S. Federal/State governments certainly seemed to enjoy it, to some extent.


This would be a service/product to be released once P == NP, "black hats" have no profit incentive, computer security laws become internationally well defined, version control is perfected and "friend" is no longer a transient term. Unfortunately, I only see one of these things ever becoming true (you know which one I'm thinking of). Apparently, Microsoft want us to go into a future in which malware is our friend.