> Your comments about locking down the server host are correct. I think the
> distinction becomes realistic in a worst case scenario.
I disagree, but that's what makes a horse race. :)
If the private key is ondisk, then the adversary can snarf it and
try various passphrases at their leisure until their snarfed copy
of the database decrypts. I believe better protection would be to
keep private keys on external tamper-evident hardware. At least
then you can know if someone has (attempted to) snarf the public
key. (E.g., the way some PC systems say "Alert! The cover has been
opened" at powerup time.)
> If you assume that
> even a locked down server may be broken in to, if the pass phrase to your
> encrypted database isn't on disk then you're better off.
Agreed. But again I feel that "assume they can break in and read"
is essentially the same as "assume they can break in and modify" for
a reasonably-locked-down system. I.e., one in which there are basically
no user accounts.
> If you're running
> tripwire then you should be able to detect altered software and reload it, and
> your secret is still safe as long as you used a strong encryption algorithm.
Only if you know that tripwire itself -- or other parts of the system such as
various shared libraries -- haven't been altered.
My concerns and threat model might be more than you need. But you
should know what you're explicitly ruling out and document it, if only
to CYA (cover your a..).
Another approach would be to double the number of systems that the adversary
must compromise. HostA will run the service, but only when HostB sends
it startup info. At boot A pings B. B "calls back" over over an SSL link
and sends the passphrase using something like S/Key perhaps.
Hope this helps.
/r$
