secure data export

[Orna Agmon Ben-Yehuda]

On Sat, Jun 25, 2011 at 9:28 PM, Oleg Goldshmidt <pub at goldshmidt.org> wrote:

> > The point of the additional file is to leave little room for anything
> else.
> > Regarding the FAT place: Assuming the CD ends up on an infected machine,
> or
> > falls into the wrong hands ( example: you want to make your client an
> offer
> > on a CD, but you do not wish to give the client info about other offers
> you
> > made, in this case the wrong hands are exactly the hands the CD goes to),
> > the infected internal machine and the infected external machine agree on
> the
> > interpretation of the extra space in the table sectors, and may
> communicate
> > information through it.
>
> Let's be clear about one thing. What is the primary concern:
> preventing malware from spreading or preventing information from
> leaking?
>
>
I assume malware spreads in various methods, and am not trying to disinfect
machines/prevent propagation of malware etc. I leave this to antiviruses.

I am trying to prevent a specific action of various possible (imaginary?)
malware, which attempt to export data as hitchhikers on data which is
exported anyhow. I do not assume the malware is trying to add itself to the
CD, in addition to the data.

The OCR idea is indeed nice. However, it is only good for small amounts of
data, or where the accuracy is not so important (English texts). It is not
so good for Hebrew or data (numbers), not to mention binary data.


> Depending on the answer some of the responses you've got may be more
> relevant than others. E.g., I think that Shachar's comment about FAT
> tables is correct in the context of malware propagation. If catching
> steganographic messages is the point (as, e.g., I understood the
> problem) then custom filesystem metadata is as good a channel as any.
>
> I liked the idea of printing the stuff and OCRing it back, by the way.
> A low tech / dead tree step in the middle is a good way to sterilize
> bits. ;-)
>
> --
> Oleg Goldshmidt | pub at goldshmidt.org
>



-- 
Orna Agmon Ben-Yehuda.
http://ladypine.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20110625/02041328/attachment-0001.html>