Problem :

P1. The enterprises data

In some cases users require available protection of DB
against theft. Stolen DB must be impossible to read in the
other place.

P2. Databases distributed with applications

There is a number of the applications distributed together
with the valuable data. In these applications the data are not
the property of the user as they are created not by the user
but by supplier. It may be, for example, dictionaries, maps of
cities, encyclopedias, catalogues of spare parts etc. Suppliers
are interested in that it was not possible to take advantage of
their data without their applications, easier speaking - that
the data could not be stolen and used not to destination or even
to resell (as part of the another applications, for example).

P1 frequently possible to solve by administrative means
(correctly adjusted security, the encrypted volumes etc.), but
in some cases it is not enough (for example: there is no trust
to the system administrator, physical theft of a hard disk or
the whole computer or notebook).

However P2 will be hardly possible to solve without the
builtin encryption - practically never there is control where
and how distributed DB is used and especially it is impossible
to demand to establish from the buyer of the electronic catalogue
him on encrypted by OS volume.


Below I have tried to define what it is necessary for us
for support of encryption DB by means of Firebird. I have no
purpose to create absolute protection - it is impossible.
Therefore I don't count attacks like disassembling of applications.
However it would be desirable as much as possible to complicate
the non-authorized access to the protected data, taking into
account that our sources is open. I also do not offer the full
decision, I just want to start discussion which will result us
in such decision


Requirements

R1. It is necessary to support encryption of database by the engine.

It will solve problem P1, but it is not enough to solve P2 -
everybody may build the version of the server which simply stored
deciphered DB. Therefore:

R2. It is necessary to provide an opportunity of authorization of
the application for work with concrete DB.

This authorization should be necessary only for that component
which ciphers the data, i.e. authorization is unessential to usual
uses (non-encrypted databases).

As our sources are open it imposes a number of additional
requirements if we want to give real protection instead of
simply play with encryption:

R3. The mechanism of a finding of a confidential encryption key
should be separated from an engine's open code.

R4. It is necessary to provide protection against theft of DB by
substitution of the server or its components by special.

It is obvious, that P2 is not possible to solve without R1 or R4
R4 is a very important requirement for the decision of problem P2


It would be desirable to satisfy the following requirements also

R5. All utilities should be able to work with protected DB. gbak and
nbakup should create protected backups and be able to restore DB
from them

R6. All this should work so that not create inconveniences to the
end user. If the decision will demand end user programming, it
should be maximum easy too

R7. It would be good, if the engine might distinguish ciphered DB
from not ciphered

R8. It would be good, if the engine might cipher different DBs by
different ways (algorithms etc)


Simple ability of DB encryption is already builtin into engine.
It assumes presence of external encryption library with the fixed
name "fbcrypt" and with very simple interface:

a) The library exports 2 functions "encrypt" and "decrypt",
defined as

int crypt_routine (const char* key,
void* in_buffer, int size_buffer, void* out_buffer);

Names of parameters speak for themselves, returned value is
not used currently

b) The key transfers through DPB.

I specially have not named this key an encryption key - it
can have any meaning, encryption library uses it in its own purposes.

c) All connections should use an identical key

(As for me this is a bad requirement)

This simple decision satisfied requirement R1.

It may satisfy requirement R2 too if a key transmitted through
DPB will take part in encryption process and access to it will have
only an authorized applications.

It also satisfies R6 since the interface is really very simple

Let's note, that transfer of a key through DPB is not necessary
for satisfaction of requirement R1. Cryptoplugin may take a confidential
encryption key from the command line of the server (or utilities), the
external hardware device, an external file with determined by plugin
name (fixed in the elementary case) etc.

Moreover, if through DPB transfers a confidential key it is
violation of requirement R3. Thus, it is allowed to transfer through
DPB or a session key, authorizing the application (for satisfaction R2)
or in even nothing, if application's authorization is not required.
Accordingly transfer of a DPB-key to each call of encryption functions
is superfluous and unnecessary step. It is enough to define additional
function called once at establishing of connection.

However this solution does not satisfy R4 and R5 at all.

R4 this solution can't satisfy essentially. It is very easily to
create such version of the engine which, after establish connection
from the authorized application, will save deciphered DB.

R5 can be partly satisfied by introducing of the utilities command
line switch (or other mechanism) and extending of syntax CREATE \
CONNECT DATABASE for the key definition. However it will not work with
gbak which currently has no interface with cryptoplugin and can not
create encrypted backup. Moreover it is possible to create the gbak
version which get legal access to encrypted database and will create
not encrypted backup.

This solution also does not satisfy R7 and R8.


I see 2 ways to satisfy requirement R4:

1) Cryptoplugin should check the control sums (or digital signatures)
of the engine component(s). Accordingly it will work only with
concrete builds of this engine component(s)

2) We may create a number of .lib libraries for monolithic linking
of necessary components of the engine into the user application.
The application will carry out functions of cryptoplugin, for this
purpose it is necessary to define appropriate callbacks. Thus the
user can create my_fbserver, my_gbak, my_fbclient etc.

About R7 and R8 i offer to speak after the agreement on the solutions
for previous requirements.

Comments, please

Vlad

PS I know my english is terrible here - so thanks to all who reads
this whole letter :)