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 "unprotected"?)
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 [email protected]
