> (In other words, if I store my database in TrueCrypt
> volume, all that an attacker has to do is to run my application and

then

> copy the GDB file from the mounted volume; that would not be

possible with

> native encryption).

Yes they could, but how is this any different to what you are proposing?

NTFS (despite the reputation of MS file systems) has arguably stronger
ACLS than most *nix file systems). As an Administrator user, I can NOT
read a file that is encrypted with the key of another user unless my
Key was added to the file also. If I change the password of the other
user to a password I know, that user can no longer decrypt that
password. Obviously there are the rainbow table attacks on Windows
user accounts that could be done, choose a strong password and disable
the legacy authentication techniques that are long broken.

> Or someone who has administrative privileges (=everyone who has

physical

> access to the machine) and knows that it is enough to replace the

security

> database with his custom one.

You could also NTFS encrypt the Firebird folder to avoid that.

@Dean,

GBAK does not need access to the database file, in fact it never
touches it. The Firebird engine reads the data on its behalf (and for
obvious reasons this can not be prevented).

@Pepak,
Alexandre is right, it is trivial to compile a custom embedded dll
that outputs the connection string used, so your security is defeated
quite easily. I have also written a proof of concept code called
gbak.exe that outputs the parameters it was called with to demonstrate
a man-in-the-middle attack. It was about 5 lines of code and took 5
minutes from start to finish.

And all this is before we introduce attacks through virtual machines.

I will leave you with a quote from Geoff Worboys' paper which can be
found here:
http://www.firebirdsql.org/manual/fbmetasecur.html


"Encryption is not a panacea for security. If you are not in control
of the environment (the hardware, the operating system and all
software running on that system) then you have no control over the
security – regardless of what encryption schemes you may have in
place. This is the situation when you distribute your database to
remote server installations."


Adam