|
|
Posted by Christopher Browne on 12/11/05 04:54
> Christopher Browne wrote:
>> > Martin wrote:
>> >> I'd venture to say that most db's
>> >> are not designed to have strong security at the file level. I understand
>> >> why (cpu and system load in managing constant encrypt/decrypt processing)
>> >> but it is disturbing nevertheless.
>> >>
>> >> -Martin
>> >
>> > SQL Server 2005 has strong encryption built in to the database. The
>> > user decides whether that applies to all of the database or just
>> > selected data.
>>
>> Unfortunately, that means that you have to trust the database engine
>> with the cryptographic keys.
>>
>> That means the DB engine is free to do whatever it likes with them,
>> which is an inherent, vast, gaping security hole.
>>
>> It's so gaping that it obviates any value to the use of encryption.
>
> You mean to say that you only run open source and you inspect every
> line of code that runs on your hardware? If not, how can you trust any
> of it?
That would the sort of process required to validate comprehensively that
a system is secure.
That is not my goal; I merely need to indicate the obvious *holes*.
If crypto keys are passed into the database system, there are several
blatantly obvious places where modifications could be done to capture
crypto keys.
1. If they are passed across some interface like SQL-CLI, then the
query parser will have the key in plaintext form.
Capturing crypto keys might well be as simple, in this case, as
turning on query logging, which is a pretty standard database feature.
2. It is more than likely that there will be a single,
well-identifiable crypto library to which the key must be passed.
Know the address, inside the library, and you can find the code that
uses it. And hence you can either modify the library, or add a
wrapper library, in between (e.g. - on Unix, via a mechanism like
LD_LIBRARY_PATH), which can capture the key.
These are blatantly obvious mechanisms for capturing keys; supposing
implementors try to be clever, it can become less easy, but even so,
someone with anything near to physical access to the hardware can
examine memory contents, sniff network traffic, and the like, making
it extremely difficult to *truly* hide the keys from the system
operators.
There are hardware-based crypto cards which have special provisions
for how *their* keys are populated which can, if competently operated,
in a secure physical environment, provide pretty strong tamper
resistance.
But I'd take a guess that the cost of establishing that "competently
operated secure physical environment" is on the order of hundreds of
thousands of dollars, which isn't affordable for terribly many users.
--
output = ("cbbrowne" "@" "ntlug.org")
http://linuxdatabases.info/info/lsf.html
Rules of the Evil Overlord #114. "I will never accept a challenge from
the hero." <http://www.eviloverlord.com/>
Navigation:
[Reply to this message]
|