Secure unattended decryption

[Daniel Eggleston]

I know it's sort of a contradiction in terms, but hear me out:

The case I'm looking at is a High Availability environment hosting a
database. The database is comprised of many Unix files, encrypted via AES,
on shared storage. If the node accessing the database loses enough of its
redundant hardware that it can no longer function as the database server,
control must failover to the secondary node. Since the client systems are
the priority, the goal is the shortest downtime possible.

The encryption key for the databases is stored on-disk, encrypted with PGP
(Gnupg specifically). At first startup, it's no big deal to have the DBA
enter a passphrase to start the database server. Once a failover occurs,
though, time is of the essence. Since paging someone to come enter a
passphrase can take 15 minutes or more after-hours, I'm trying to come up
with a feasible way to allow the second node to access the encrypted
databases without human intervention, with the ultimate goal that if
somebody does somehow walk out with the storage containing the databases,
there will be no way to gain access to the data.  I was thinking this could
be done using gpg-agent, and entering the passphrase when the server starts
up (and the failover can happen arbitrarily, months or even years after the
machine boots).

The problem I've encountered is that there doesn't appear to be a way to
cache the passphrase infinitely. (I read some documentation that said that
passing -1 to the cache-ttl parameters would work, but it doesn't). I've
considered setting the cache-ttl parameters to large values (i.e. two weeks)
and requiring the DBA to re-enter the passphrase once a week.  This isn't
ideal, but it's better than nothing.

Does anybody here have any experience with this sort of situation?  I
realize that anything short of requiring a user with the passphrase at the
terminal is inherently less secure, but uptime is king, and I'm looking for
an "as secure as possible while not requiring human intervention in the
event of a failover".

-- 

          Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100318/9a8d56b9/attachment-0001.htm>