Slashdot Mirror
Hiding Packets in VoIP Chat
holy_calamity writes "Two Polish researchers say they have developed a system to hide secret steganographic messages in the packets of a VOIP connection. It exploits the fact that VoIP uses UDP, not TCP; it is designed to tolerate some packets going missing -- so hijacking a few to transmit a hidden message is not a problem." You may also be interested in reading the original paper.
To continue reading this article, subscribe to New Scientist. Get 4 issues of New Scientist magazine and instant access to all online content for only USD $5.95
Thanks Slashdot, because I really want to go to Slashdot to get links to a story that I have to pay to read.
The complete article, accessible without NewScientist subscription, may be found here.
____
~ |rip/\/\aster /\/\onkey
Sort of... "Blocking Steganosonic Data In Phone Calls" http://it.slashdot.org/article.pl?sid=08/04/02/0133212
There is this too... http://it.slashdot.org/article.pl?sid=04/01/10/2358247
If you want to hide packets over VoIP I suggest making "beeping" noises.
Here is the actual paper as a clean PDF. This is the good version.
The linked Technology Marketing Corporation page mentioned in the parent post has only the beginning of the article. It also has 24/7 Media ads in the middle of the article, Google ads on the right, TMC ads at the top, bottom, and in boxes within the article, buttons for more promoted services at the left, a Flash banner at the top, ads from OAS at the lower right, a Digg button, and an email signup box. Oh, and the page refreshes itself every two minutes to change the ads.
First, Stenographic or Stenophonetic solutions are supposed to disguise that you are actually communicating encrypted information, which is 1/2 the battle. If you know two parties are transmitting encrypted information that is sometimes enough (especially in this day and age) to either attack via brute force, or even worse, make them legally hand over their decryption keys, where then you need plausible denability. When the third party doesn't even know you are transmitting information, you are in a much better situation.
First, wide adoption of RTP transmission via TCP is highly unlikely, due to the nature of streaming media in general which UDP is designed for and TCP is not. Fixed datagrams and packet ordering protocol are a major pain in the a$$ for streaming media.
Where as the call control protocol (SIP, H.323, MGCP, etc) via TCP is probablly more likely and most standards support transmission under either, though the vast majority is still UDP based.
You are right from a security perspective with TCP you know if information is gone missing, where as UDP you never really know.
D.O.U.O.S.V.A.V.V.M.
Only as long as you'd try to hide your secret data in the Audio stream. If you inject your secret data directly into the network "connection" (read: the sequence of UDP Packets sent) it bypasses manipulated background noise.
bickerdyke
Plain cryptography is something like having a locked car sitting in a room. It might not be easy to get into, but you know it when you see it. This is like having a car behind a painting. You don't notice that there is anything being kept away from you. Well, other than that big-assed painting.
No? How about this...
Plain cryptography is something like having a locked car sitting in a room. It might not be easy to get into, but you know it when you see it. This is like having the locks of the car behind paintings. You don't notice the keyholes. Well, other than those out-of-place paintings hanging off the door handles.
No? How about this...
Plain cryptography is something like driving your car across the border while trying to keep from having to show your passport to the border patrol (by showing them fake ID). This is like doing the same while having the trunk full of cocaine when you do so.
Bah, nevermind.
That reminds me of a neat story.
A few years ago at a tech conference I met someone who worked for the data storage division at Dell. Some of the technical manuals that the engineer needed for their work were classified as secret (product hadn't gone to market yet) and the engineer had to sign various NDAs with the company to get access to the documents.
Said engineer compared their copy of a manual with another engineer's copy and discovered that each manual had a different set of spelling errors. Apparently Dell was generating documents with unique sets of typos in order to be able to track down the identify of the person who leaked a document.