Re: Disk Encryption - Postgresql vs. Oracle

Wow, nice analysis.  Should this be in our documentation somewhere?

---------------------------------------------------------------------------

Christopher Browne wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073