full-disk subversion standards released

[Peter Gutmann]

Thor Lancelot Simon <tls at rek.tjls.com> writes:

>Almost no web servers run with passwords on their private key files. Believe
>me.  I build server load balancers for a living and I see a _lot_ of customer
>web servers -- this is how it is.

Ah, that kinda makes sense, it would parallel the experience with client-side
keys (SSH in this case since client-side PKI is virtually nonexistent) were
nearly 2/3 of all private keys were found to be stored in plaintext form on
shared machines.  This is why a security developer some years ago started
referring to the private key as "the lesser-known public key" :-).

(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"?)

>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.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com