Subject Re: [firebird-support] Re: Undocumented internal encrypt/decrypt in FB
Author PenWin
>> (In other words, if I store my database in TrueCrypt
>> volume, all that an attacker has to do is to run my application and
>> 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?

It is different in that with my proposal, this kind of attack does not work.

>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.

See my description of the attack - I don't even need to know that any
encryption is in place because I work through Firebird server, to which the
encryption is completely transparent (otherwise it couldn't be used at all -
that's the disadvantage of external application).

>> Or someone who has administrative privileges (=everyone who has
>> access to the machine) and knows that it is enough to replace the
>> database with his custom one.

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

I could, but then I could take ownership of that one file (security
database) - I don't care that it will make its content unreadable because I
will overwrite it with new data anyway.

>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.

I realize my suggestion is not perfect. If necessary, the attacker can
simply debug my application until he finds the key. The point here is not to
make it impossible to access the data, but to make it difficult enough that
it's not worth the bother. I could obfuscate my code. I could modify the
client library to be compiled into my application rather than into
standalone library. I could do many things, depending on the level of
difficulty I want to achieve. I would have choice. Right now, I don't have
anything - Firebird developers decided that since PERFECT security is not
possible, it makes no sense to attempt ANY security.

Curiously, they didn't follow the same reasoning with protection from
damage - they did create backup tools (even though backup media can fail,
too) and they did create GFIX (even though it is conceivable that a certain
kind of corruption will cause GFIX to actually increase the damage).