secure data export

[is123 at zahav.net.il]

On Fri, 24 Jun 2011 00:35:16 +0300
Orna Agmon Ben-Yehuda <ladypine at gmail.com> wrote:

> Hello all security experts,
> 
> I would like to export data from a machine on a business's internal
> network on a safe media, such that only the files I want exported are on
> the media. Specifically, I consider the possibility that the machine may
> already be infected by a malware which adds business-sensitive data to
> all outgoing media, and would like to defend against such a theoretical
> malware. The question may be limited to text files.

If I understand the problem, and you have no trusted reference file, then
there is no way to do what you want to do, since you have nothing to verify
against.

If you have a trusted file, then you can use digital signatures to make
sure the contents aren't altered and to make sure you will be able to
detect if the contents are altered.

> Things already considered:
> *The media is a CD, which will be written and then finalized. No USB
> devices.

If you have a trusted reference copy and a digital signature of that file
then the media become irrelevant in that you will be able to verify that
the copy is either intact or not.

> *An artificial file will be added to the data file, to fill the media as
> much as possible. This, however, leaves a part of the disk capacity
> unused - the part used for the structure table (what used to be FAT),
> which is a place where additional data can hide.

Sounds like a very unproductive approach.

> What about a malware compressing the data, using the extra space for
> additional data?

That's an interesting attack but it all gets back to what you can trust and
what you can't. If you have a known, good copy then you can preserve that
or at least detect unauthorized alterations. If you don't, it's over.

> If I compress the data to avoid further compression, how can the person
> verify it contains exactly what it should?

Digital signatures. There are two ways to do it. For text files, you can
wrap the signature around the text file and the whole bundle can be sent in
one piece. The recipient can verify the signature against your public key
that you make available and verify the copy they have is valid and
unchanged. For binary files you can create what is called a detached
signature. That's a separate file that contains the digital signature of
the file you want to protect. Then you or anybody you wish can verify the
contents of the file in question against the detached signature.

> What can I not defend against?

The recipient cannot trust that the digital signature you issued was really
made at the time stamp contained in the digital signature and conversely
you cannot prove message chronology. For example if you are making a stock
trade a digital signature by you on the trade will not be enough to
prove that you issued the trade at a certain time, to do that you need a
trusted third party called a time stamping service. The recipient can also
not trust that the digital signature belongs to you, unless they involve a
trusted third party called a Certification Authority, or unless they trust
you to issue your own certificate (which contains your public key). I run a
Root Certification Authority but I am not licensed by the State so my
signatures are not accepted in legal proceedings. One very popular and well
known Root Certification Authority in the country was also not licensed the
last time I checked, so if you are intending to defend against claims in
court you must establish that any Certification Authority or time stamping
service you use has been properly licensed here in this country or your
digital signatures won't have legal validity.

Depending on what size keys you choose, a motivated attacker could factor
(crack) those keys. If so, they will be able to forge documents in your
name and alter documents you signed without any way of being detected. If
you're in an embedded environment key size tradeoffs are critical for
performance reasons. On the desktop or server, much less so unless you are
doing much signing and verifying.

You have to have a way to verify that all of the software you use in
generating key material, signing, verifying etc. hasn't been tampered with.
The way to do this is to have a known good copy of openssl, PGP or GPG so
that you can verify the signatures on your tools.