> Adding passphrases to the keys or storing them in a encrypted partition
> doesn't really get you any additional level of security.

Perhaps in the specific case that started this thread, but in the
general case, this is wrong.

Let's consider a common co-location scenario.  Or where the MIS/IT
department physically controls the machine, has root, etc., but is not
responsible for the server application running on the machine.  Surely,
those are commonplace set-ups.

If they have physical acccess or have root, they can get root. :)  For
example, a third-shift operator of my colo facility might be convinced
to hit the RESET button for a bucket of cash.  The adversary has root. 
If the private key is encrypted, they must also break that passphrase to
get the key. If I, as the owner of the machine, am diligent I will not
restart my server after my system has "mysteriously" crashed.  Proper
diligence requires defining mysterious, of course.  (Insert Windows BSOD
joke here.)

>  If you're
> worried about your private keys you need to keep them (and do your key
> operations) in hardware (nCipher, Broadcom etc).

It depends on the configuration.  If the hardware crypto has no extra
passphrase, then the adversary described above has an *EASIER* time
getting the hardware device to sign anything (install trapdoor software)
then the defense described above.  If you put the hardware crypto PIN in
a file on the local machine, then you've spent a lot of money for a
little performance and a false sense of security. :)

[ The industry-standard API for hardware crypto devices is PKCS#11.  It
is hard to find a vendor that doesn't support PKCS#11, although it might
be dis-recommneded over their own API.  PKCS11 has a "login" command
that you must invoke to create a session.  Where do you get the PIN for
that login command?  If you get it from a file, then see previous
paragraph. ]

        /r$
-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [EMAIL PROTECTED]
Automated List Manager                            [EMAIL PROTECTED]

Reply via email to