> The physical security to the server is a must, I am talking when this
> security is broken.

But if the physical security of the server is compromised, how can you
protect yourself from replacing the server binary?

The only case that I can imaging is the case where server is partly
compromised: Firebird remains authentic and keeps running, somebody gets
access to the file system with databases and is able to copy the file. A
typical admin error. We can't protect against such mistakes anyway.

If the security of the server is compromised remotely, this, most
likely, will go via some exploit/root kit. In this case one can also
inject malicious code into our authentic Firebird server...

If the security of the server is compromised physically, one can always
replace the binary.

At this level we can only discuss whether personal estimates of the
probabilities of which case is more likely are correct or not. I would
not base the decision to implement database encryption a-la TrueCrypt
only on these probabilities.

>> But so far the discussion was about the embedded engine - the software
>> is distributed with the fbembed.dll and database.fdb, no control over
>> who has access to the files. And this approach does not work - it is
>> always possible to forge a version of Firebird that will dump the keys.
>>
>
> I didn't realize that the discussion was about embedded engine...

It looks like it was my private conclusion, since the Access and Paradox
were mentioned...

> For me
> it was about all the versions. For the embedded engine your approach to
> check the binaries integrity inside the application is the only possible
> solution, and make it harder to the attacker disassembly or patch the
> place where the signature is stored and/or checked. We must not forget
> that in most cases the "security" check is something like:
>
> if SHA('fbembed.dll') = '1234567890ABCDEF' then
> OpenDatabase('mydatabase.fdb', My_Encryption_Key)
> else
> ShowMessage('Hey you forged the engine I will not tell you my
> password !')
>
> And is bypassed with a single byte patch (change JNE to JE or a JNZ to
> JZ) in a few minutes.

There are tools to protect the executables from such analysis, so, I
think, we should not worry about it. In general even such simple code is
enough for 80% (or 99%?) of embedded engine use cases. The rest 20%
(1%?) require much more sophisticated approaches that cannot be targeted
in the database engine in a standard way.

Roman