On Tue, Oct 14, 2008 at 4:06 PM, Roman Rokytskyy <roman@...> wrote:

>> So !!! What may I understand !!!??? there is a mechanism to protect
>> database but it is desabled by an #ifdef??
>> Could you illustrate that please by an exemple
>
> The encryption key _could_ be passed in the DPB the same way the user
> name, password, encoding are passed. But I think nobody tried the code
> so far - it was implemented long time ago by Borland but never released
> in public.
>
> Anyway, as it was said here, the issue is the key management. I will
> explain you based on Access (I used it few times, but my story might not
> be very precise)
>
> In Access, when you protect the database by password, you won't be able
> to connect to the database without specifying the right user name and
> password. They are stored in the database itself, but in encrypted form.
> The encryption key is stored in some other file which is located on your
> computer C:\Document and Settings\<your login>\Application
> Data\Microsoft\Access\System.mdw (that is also Access database, but some
> parts are not accessible when you open it).
>
> When you copy the password protected database to some other place
> without copying the .mdw file, you won't be able to connect to it, since
> Access won't be able to decrypt the user name and password. To avoid
> this you have to copy the .mdw file to the new location (but not replace
> the System.mdw, since other databases on that location will be
> inaccessible) and specify the file name in connection string (or as a
> startup parameter for Access).
>
> In Firebird, when you have server installation and your databases are
> protected from direct file access, you're safe - Firebird won't let
> anybody with wrong credentials in.
>
> The problems are with embedded engine - the embedded engine does not
> require password database, so anybody can open it. The encryption part
> that is currently disable does not help you a lot, since anybody can
> build his own version of Firebird (remember, we're open source) and dump
> the encryption key that application passes to the library to the screen
> or log. Having that one, it is easy to create another application that
> would dump the data from your database.
>
> Others (incl. the CodeGear with its new release of InterBase) have it
> easier - the efforts needed to modify the binary library are
> significantly higher, so the most users will be safe.
>
> So, as it was already said, the issue is the key management. In our case
> it is harder than in Access or InterBase, since people can replace the
> fbembed.dll and dump any key that is used to decrypt the database.
>
> We (developers) have already discussed this issue long time ago, but did
> not find any acceptable solution that can be implemented within the next
> releases.
>
> It is however thinkable that some third-party company would create a set
> of components for Delphi, Visual Studio, etc. that would
>
> a) provide access to embedded Firebird;
>
> b) would check the authenticity of the fbembed.dll
> and prevent the application from passing the
> encryption key in case of different library.

I think the best is to keep the private key near database server
(firebird crypto folder)
and public key in the application folder and secured
if the remote database is lost and you have something really sensitive
there then (Let's say an email or some accounts data)
you might need to break the passphrase it could take some time
also if it gets only the public one and not the private one is ok it
can't break it

I think more that it could be usefull like in the ssh/pgp case
http://en.wikipedia.org/wiki/Public-key_cryptography
http://en.wikipedia.org/wiki/Pretty_Good_Privacy

>
> Roman
>

--
developer flamerobin.org