Peter Gutmann wrote:
(Does anyone know of any studies that have been done to find out how prevalent
this is for servers?  I can see why you'd need to do it for software-only
implementations in order to survive restarts, but what about hardware-assisted
TLS?  Is there anything like a study showing that for a random sampling of x
web servers, y stored the keys unprotected?  Are you counting things like
Windows' DPAPI, which any IIS setup should use, as "protected" or

We recently had some discussion about this inside Sun. Not just for TLS but for IKE as well.

Until very recently our IKE daemon required the PKCS#11 PIN to be on disk (readable only by root) even if you were using sensitive and non extractable keys in a hardware keystore. We changed that to provide an admin command to interactively load the key. However we know that this won't actually be used on the server side in many case, and not in a cluster (the Solaris/OpenSolaris IKE and IPsec is cluster capable).

For Web servers the situation was similar, either the naked private key was on disk or the PKCS#11 PIN that allowed access to it was.

I solicited information here about crypto accellerators with onboard
persistent key memory ("secure key storage") about two years ago and got
basically no responses except pointers to the same old, discontinued or
obsolete products I was trying to replace.

I was hoping someone else would leap in about now and question this, but I
guess I'll have to do it... maybe we have a different definition of what's
required here, but AFAIK there's an awful lot of this kind of hardware
floating around out there, admittedly it's all built around older crypto
devices like Broadcom 582x's and Cavium's Nitrox (because there hasn't been
any real need to come up with replacements) but I didn't think there'd be much
problem with finding the necessary hardware, unless you've got some particular
requirement that rules a lot of it out.

The Sun CA-6000 card I just pointed to in my other email is such a card it uses Broadcom 582x.

Darren J Moffat

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to