Roman Rokytskyy wrote:

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

No one can protect the binary to be replaced, but if the data is
important and is encrypted without storing the key inside the database,
the engine must ask for the key to the admin. The admin should check the
binaries to be valid before providing such keys.

> 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 database is encrypted and the key is not stored inside the file,
the only way to get access to the data is trough brute-force attack.

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

While the server is running there is no way to change the executable,
the compromise must be done replacing the binaries and the only way (*I
can think of*) to check this is to verify the binaries signatures
*manualy* before providing any keys to the server.

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

Yes, but the admin would note the change because the file signature
would change and is checked by the admin, not by a self check routine
(that can be changed the same way to fake a valid 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.
>
>

Ok. My sugestion to a encryption a-la Truecrypt is to not hold the key
inside the file, or provide it trough the client app, the key should be
given manually by an admin who had checked the binary integrity before
providing the keys, this is my point.

If the server is compromised at physical level, machine stolen, no one
would be able to access the data without a valid password.
If the server is compromised and the binaries replaced it would be noted
by checking the binary signatures by the admin at start-up time or when
he needs to provide the keys.
If the server is running, and in someway one could access the database
file, he could not access the data, since all data is encrypted and the
key is not on the engine code nor the database file.

For the embeded case, the application should check the binary and self
integrity and provide the key to the server, if the key is stored inside
the database I see "no reason" for encryption at all, since there is
*always* a way to do reverse engineer, if the computer could run the
assembly code, one could read it the same way, IMHO the only secure way
to store a password is on the human head.

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

I though it was just examples, once upon a time ago, I faced a paradox
password protected file, googling gives me a list of valid passwords and
I got access to the data easily, the false sense of security is the
worst scenario I can think of.

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

When I was learning about reverse engineering (again, I am not a reverse
engineer, just try to learn a bit as a hobby and to try to protect
myself a bit), I had read something like:
If there is code it could be reverse engineered, how hard is to find the
right place to change, and how many time it will take could change, but
it is always possible.

The only thing that looks more secure is if part of the code (the key,
the integrity check code, and a critical part of the code) is stored on
a dongle that is encrypted and tied in someway to the serial code of the
dongle so it could not be copied, Without the dongle one has a missing
part of the code, inside the dongle is stored the key to decrypt the
data or the executable itself, inside the dongle is the validation code,
and if the dongle is duplicated the code would be invalid. I don't think
this is the case we are trying to solve...

I think that for 99% of the cases there is no need of such security, but
we must warn the user that the security is as strong as it's hard to get
the key from their code (or to patch their code). A lot of people would
think that because the database is encrypted and the password is not
known by the end user, the data would be protected.

If one has such strong needs for security, embedded is a no go, the only
reliable way is to hold all sensitive data on the server, and keep the
server secure (physically and logically).

> Roman
>

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br