Subject | Re: [Firebird-Architect] Key management with encrypted databases |
---|---|
Author | Alex Peshkoff |
Post date | 2012-04-05T11:57:54Z |
On 04/04/12 19:36, Ann Harrison wrote:
Before saying why I do not want to do it let me recall that we have 2
main reasons for database encryption - protection of enterprise data in
case of stolen HDD/server (enterprise mode) and protection of
distributed databases, pre-filled with some valuable data. It's supposed
that application, working with such database, is protected from being
stolen in some way, but actually the most important part of such system
is data, stored in database (distribution mode). The second appears to
be the most interesting, cause the first one can be relatively easily
replaced with any disk encrypting software like TrueCrypt. Certainly,
keeping database online during this process is problematic.
In enterprise mode storing secret key on workstations appears to be
complete madness - key, distributed over a lot of boxes will stop to be
secret very soon :) It's supposed that crypt plugin itself knows a way
how to get crypt key - for example, from the RAM of server, in which
it's placed from some particular workstation after server is booted. In
this case we do not deal with keys at all.
In distribution mode the main problem people will meet becomes not
man-in-the-middle but open source nature of firebird. It seems quite
possible to replace engine with one which will save all pages in
unencrypted way after getting a key from protected application.
Therefore looks like that for efficient protection people will have to
be able to check with what engine do they work. I.e. it is embedded mode
(completely OK for systems sailed on CD/DVD/etc). And mentioned attack
also appears to be impossible. But I anyway do not want to let open
source code access secret keys directly. To transfer key from
application to engine I want to use a kind of callback from crypt plugin
to application. And let plugin writers crypt a key in that channel in
any way they wish.
> Perhaps I missed the discussion of key management in the flurry ofThe best way to avoid this kind of attack is not to transfer keys in DPB.
> how to encrypt databases discussion. How are you going to avoid
> man-in-the-middle attacks?
Before saying why I do not want to do it let me recall that we have 2
main reasons for database encryption - protection of enterprise data in
case of stolen HDD/server (enterprise mode) and protection of
distributed databases, pre-filled with some valuable data. It's supposed
that application, working with such database, is protected from being
stolen in some way, but actually the most important part of such system
is data, stored in database (distribution mode). The second appears to
be the most interesting, cause the first one can be relatively easily
replaced with any disk encrypting software like TrueCrypt. Certainly,
keeping database online during this process is problematic.
In enterprise mode storing secret key on workstations appears to be
complete madness - key, distributed over a lot of boxes will stop to be
secret very soon :) It's supposed that crypt plugin itself knows a way
how to get crypt key - for example, from the RAM of server, in which
it's placed from some particular workstation after server is booted. In
this case we do not deal with keys at all.
In distribution mode the main problem people will meet becomes not
man-in-the-middle but open source nature of firebird. It seems quite
possible to replace engine with one which will save all pages in
unencrypted way after getting a key from protected application.
Therefore looks like that for efficient protection people will have to
be able to check with what engine do they work. I.e. it is embedded mode
(completely OK for systems sailed on CD/DVD/etc). And mentioned attack
also appears to be impossible. But I anyway do not want to let open
source code access secret keys directly. To transfer key from
application to engine I want to use a kind of callback from crypt plugin
to application. And let plugin writers crypt a key in that channel in
any way they wish.