Subject | Re: [Firebird-Architect] database encryption |
---|---|
Author | Sijun Kang |
Post date | 2010-11-03T19:43:45Z |
I think we might be able to produce secure encryption under SOME
circumstances - e.g., I want to store my personal information (many bits are
sensitive enough to keep safe, such as bank/credit card information) on
my laptop with peace of mind. I do not expect it be safe in all imaginable
situations, instead I only wish:
*Nobody can gain access to my data (without bruteforce
decryption) in case I lost my laptop in power-off status*.
This, I think, is achievable.
I do agree with Jim that the "key" here is the "key management". Let's dig a
little bit more in depth as to how we can achieve above goal along the
personal information management scenario -
*As long as Firebird only keeps the key in memory when the user is
logged in, and delete the key (and other cached information related with the
corresponding encrypted database) from the memory once the user is logged
out (or timed out after idling for a certain period of time), it seems to me
that the encrypted database is safe. *
Actually we should be able to achieve more (as below) along this line of key
management mechanism (seemingly doable to me):
*Nobody can gain access to my data (without bruteforce
decryption) when I "logoff" from Firebird (let's suppose that we can "login"
to Firebird to let it obtain the key) *.
Someone might argue that, in lots of other situation, especially in server
applications, it's not possible to operate like that. Well, my opinion is:
* Security is not something that can be achieved without clearly-defined
boundary. *
I don't think it a feasible job to maintain data security in ALL scenarios.
For example, somebody might wish that "nobody can read his embedded Firebird
database file after publishing it to a client's computer". With all due
respect to the needs of such kind, I do not think that this goal can be
acheived by any known database (with or without encryption capacity). In
another word, we should not deny the need of decryption functionality from
Firebird just because that scenario is "mission impossible" !
Sorry for my long jabber... your thoughts/comments will be much appreciated!
BTW, Jim and Ann, I look forward to your valuable opinion on this.
Thanks
Sijun Kang
circumstances - e.g., I want to store my personal information (many bits are
sensitive enough to keep safe, such as bank/credit card information) on
my laptop with peace of mind. I do not expect it be safe in all imaginable
situations, instead I only wish:
*Nobody can gain access to my data (without bruteforce
decryption) in case I lost my laptop in power-off status*.
This, I think, is achievable.
I do agree with Jim that the "key" here is the "key management". Let's dig a
little bit more in depth as to how we can achieve above goal along the
personal information management scenario -
*As long as Firebird only keeps the key in memory when the user is
logged in, and delete the key (and other cached information related with the
corresponding encrypted database) from the memory once the user is logged
out (or timed out after idling for a certain period of time), it seems to me
that the encrypted database is safe. *
Actually we should be able to achieve more (as below) along this line of key
management mechanism (seemingly doable to me):
*Nobody can gain access to my data (without bruteforce
decryption) when I "logoff" from Firebird (let's suppose that we can "login"
to Firebird to let it obtain the key) *.
Someone might argue that, in lots of other situation, especially in server
applications, it's not possible to operate like that. Well, my opinion is:
* Security is not something that can be achieved without clearly-defined
boundary. *
I don't think it a feasible job to maintain data security in ALL scenarios.
For example, somebody might wish that "nobody can read his embedded Firebird
database file after publishing it to a client's computer". With all due
respect to the needs of such kind, I do not think that this goal can be
acheived by any known database (with or without encryption capacity). In
another word, we should not deny the need of decryption functionality from
Firebird just because that scenario is "mission impossible" !
Sorry for my long jabber... your thoughts/comments will be much appreciated!
BTW, Jim and Ann, I look forward to your valuable opinion on this.
Thanks
Sijun Kang
On Wed, Nov 3, 2010 at 2:19 PM, Ann W. Harrison <aharrison@...>wrote:
>
>
> On 11/3/2010 6:56 AM, sijun_kang wrote:
> > It seems that "database encryption" was a topic previously discussed long
> time ago and it was concluded that encryption would not be more secure than
> obfustication in some scenarios. But still, I think there are other
> scenarios where encryption is the only methold to help secure the data.
> Since there are already some code (currently disabled) in the source, I
> wonder why it has never been released as a feature to the public? As
> mentioned in ticket "CORE-1913" (Firebird Core - Database encryption
> revisited, http://tracker.firebirdsql.org/browse/CORE-1913), in some
> applications, even the law requires encryption as a must-have. I wish this
> feature be made active as soon as possible. Any comment/insight on this?
> Thanks
>
> As I remember, what was concluded was that the disabled
> code would not produce a secure encryption under any
> circumstances. Yes, it might block a casual reader,
> but it would only give the illusion of security against
> serious attack. Yes, other database systems offer
> the same kind of "security", but the Firebird project
> is not staffed at a level that lets it put in features
> that fundamentally don't work.
>
> Best regards,
>
> Ann
>
>
>
[Non-text portions of this message have been removed]