Re: Disk Encryption - Postgresql vs. Oracle

In the last exciting episode, doom@kzsu.stanford.edu (Joseph Brenner) wrote:
> I was talking to someone just recently who was saying that they
> were thinking about going with Oracle rather than Postgresql
> because Oracle has a their story in place about how to do
> disk encryption.  So I am of course, looking into how to do it
> with Postgresql...
>
> (As to why you would *care* about disk encryption, I would guess
> the scenario is you've got a bunch of guys in the back room
> hot-swapping RAID drives, and you'd rather not post armed guards
> there to watch what happens to the older units.)
>
> contrib/pgcrypto looks pretty interesting, but I gather it's
> intended to let you encrypt particular fields inside a database,
> rather than the whole ball of wax.
>
> Maybe the right way to do it is to just get the OS to encrypt
> everything, and not make postgresql jump through any extra hoops?
> I see there's a general Linux disk encryption FAQ out there:
>
>   http://www.telenovela-world.com/~spade/linux/howto/Disk-Encryption-HOWTO/index.html
>
> Doing some searches of the archives, I haven't turned up much
> discussion more recent than about a year ago, e.g.
>
>   http://archives.postgresql.org/pgsql-admin/2004-03/msg00049.php
>
> Is there anything new on this front?

If your threat model indicates that encrypting data at the disk level
represents protection against some attack involving theft of disk
drives, you would presumably find that using some form of OS loopback
device with a crypto layer to be useful, and that would not require
any particular support from PostgreSQL.  Note that this model cannot
protect against threats from system administrators as, in order for
them to mount the filesystems, they must have access to the crypto
keys.  Furthermore, it cannot protect _at all_ against attacks that
can take place while the database is up and running.

A second approach, using pgcrypto, requires that you entrust the
database process, and hence anyone with access to the relevant Unix
user, with the cryptographic keys.  That can allow some portions of
the data to be encrypted, and others to remain plain text, and may
again be suitable if you trust the system administrators with the
keys.  It has the merit that the sensitive data stays encrypted on
disk at all times; it is only in plain text form in memory and
possibly as it is being transmitted between server and client (protect
against that using SSL connections).

A third approach is for the cryptographic layer to stay purely on the
application/client side.  Encrypted data is encrypted on the client
side, and is only ever decrypted there.  If you have any reason to be
concerned about threats that target the server, then you must not
trust either of the first two approaches, but must look to client-side
processing.  Google for _Translucent Databases_ for more on this
approach...
--
output = ("cbbrowne" "@" "gmail.com")
http://linuxdatabases.info/info/slony.html
They are  called  computers  simply  because computation  is  the only
significant job that has so far been given to them.  -- Louis Ridenour