On Tue, 18 Oct 1994, Brett Lymn wrote:
>
> Welcome to the world of security and things called covert channels.
>
> You are not quite right about the transport method when embedding code
> into an image. Imagine you take the image "Monique" and starting at
> some byte in the image you either set or clear the least significant
> bit of that byte depending on the most significant bit of the data you
> wish to hide. Imagine that you keep setting/clearing the lsb of each
> successive byte depending on the bits in the data you wish to hide.
> Qualatively there will be no real discernable difference in the
> picture data. Now you package up the image using gif (cannot use jpeg
> here or you will lose the data!), uuencode it and mail this image to
There is a patch available for the Independant JPEG group's software
which allows for 1-bit steganography. It works on the principle that not
all the stages of JPEG encoding are lossy. The non-lossy stage uses
Huffman encoding to compress the data.
> your friend. Without an original, untouched version of the picture
> ("Monique" in this case) there would be no way you could tell there
> was extra data. You do not even have to encrypt the data, plaintext
> would be good enough. Once your friend has the image all they need to
> is unpack the image and extract the data using the reverse of the
> encoding procedure.
>
No, encoding is not enough to ensure a secure transfer of the data.
Compressing the data before injecting it would help, however. There is a
program called "stealth", which takes a conventionally encrypted PGP file
and stripts the header from it. Such a file would then be suitable for
steganographic injection.
> This is a very simple example, no doubt if you were clever you could
> insert the stuff directly into, say, a jpg file (I am not certain
> about the effects on the image in this case). About the only way to
> defeat this covert channel, apart from totally blocking it, is to do
> something like feed the image through a high quality jpeg/un-jpeg
> process which will scramble the lsb's of the image before passing the
> image on.
This wouldn't be an effective solution, assuming that the filtering software
identifies image files based entirely on magic numbers. Since the data
doesn't necessarily have to be stored in the lsb, the "scrambler" will
fail. The quality of the image will be quite poor of course, but the
filter will let it through nonetheless.
-jc
References:
|
|
