Quoting Scott Marlowe <smarlowe@xxxxxxxxxxxxxxxxx>:
On Fri, 2006-01-20 at 14:47, David Blewett wrote:
Quoting Scott Marlowe <smarlowe@xxxxxxxxxxxxxxxxx>:
>> Having the table containing the index, or the database object,
>> encrypted would protect against system admins,
>
> IF they've got root, and the unencrypted data or the password / key is
> on the machine or in memory on it, you've lost. It may make it harder
> for them to get it, but they can.
The password shouldn't be saved anywhere, it should be entered manually
when the application starts. Or, only store it on secure removable
media.
But it will be in memory, and root can get anything out of memory that
they want to.
The only way to keep root on this box from getting it is to put the key
on another box that the administrator doesn't have access to. I.e. on
the client side of postgresql. If you want to keep root out of your
data on your server, you encrypt it before you give it to the server.
Then, you can set up a different box with the keys on it that encrypts /
decrypts the data there.
In reading the documentation of Peter Gutmann's Cryptlib, I came across
this section:
"The use of crypto devices can also complicate key management, since
keys generated or loaded into the device usually can't be extracted
again afterwards. This is a security feature that makes external access
to the key impossible, and works in the same way as cryptlib's own
storing of keys inside it's security perimeter. This means that if you
have a crypto device that supports (say) DES and RSA encryption, then
to export an encrypted DES key from a context stored in the device, you
need to use an RSA context also stored inside the device, since a
context located outside the device won't have access to the DES
context's key."
I'm not familiar with how his library protects keys, but this suggests
that it would be possible to use it as a basis for transparent
encryption. He later writes, "There can be a significant difference
between theoretical and effective security. In theory, we should all be
using smart cards and PKI for authentication. However, these measures
are so painful to deploy and use that they're almost never employed,
making them far less effectively secure than basic usernames and
passwords. Security experts tend to focus exclusively on the measures
that provide the best (theoretical) security, however sometimes these
measures provide very little effective security because they end up
being misused, or turned off, or bypassed."
David
