On Wed, Jan 05, 2000 at 10:22:57AM -0500, Rich Salz wrote:
> > 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 the attacker can insert his own software on the server he
can get his own bytes signed by the key without tampering
with anything and therefore without tripping the alarm.
Depending on the protocol that can be almost as good as getting
the key itself. For impersonating an SSL server, he'd need to
be able to get bytes signed fast enough to be able to return
before users get bored and click elsewhere.
A you pointed out in this message I'm replying to, it's not much more
difficult for an attacker to instert his own software than it is for him
to snarf the private key file. If the private key file is encrypted
with a good algorithim with large key sizes and there are no
implementation issues, a brute force attack on the encrypted private key
file would take too long to be of much use to the attacker. But of
course he can, with comparatively little extra work, install a keyboard
sniffer to snarf the passphrase the next time the machine's booted...
OTOH, all this is more secure than leaving the private key in the clear
on the filesystem.
I would use the machine for as little as possible, lock everything
else out, and instrument the hell out of it so you have a chance
of knowing when it's attacked.
--
Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5
<IMG LOWSRC="javascript:alert('Delete C: and install Linux?')">
