VoIP Watermarking Defenses

Wednesday, February 20, 2008

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

Tuesday, February 19, 2008

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 already?)

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