Arshad Noor wrote:
Almost every e-commerce site (that needs to be PCI-DSS compliant) I've worked with in the last few years, insists on having unattended reboots.
Not only that but many will be multi-node High Availability cluster systems as well or will be horizontally scaled. This means that there are multiple machines needing access to the same key material. Or it means putting a crypto protocol terminator "on the front" - the down side of that is loosing end to end security.
Even when the server is configured with a FIPS-certified HSM and the cryptographic keys are in secure storage with M of N controls for access to the keys, in order for the application to have access to the keys in the crypto hardware upon an unattended reboot,
This is because availability of the service is actually more important to the business than "real" security.
> the PINs to the hardware
must be accessible to the application. If the application has automatic
Or at least a broker for the application.
access to the PINs, then so does an attacker who manages to gain entry to the machine.
The way we have traditionally done that in Solaris for IKE is to write the passphrase/PIN in the clear to disk but rely on UNIX permissions to "protect" ie readable only to root or the user account the service runs as.
P.S. As an aside, the solution we have settled on is to have the key- custodians enter their PINs to the crypto-hardware (even from remote locations, if needed, through secure channels). While it does not provide for unattended reboots, it does minimize the latency between reboots while ensuring that there is nothing persistent on the machine with PINs to the crypto-hardware.
We recently added this ability for the IKE daemon on Solaris/OpenSolaris for the case when the private keys IKE uses are stored in a PKCS#11 keystore (HSM or TPM). However we don't expect this to be used in the case where unattended reboots or cluster failover be used.
This is really no different to storing a root/host/service keytab on disk for Kerberos - yet that seems to be accepted practice even in organisations that by policy don't want passphrase/PIN on disk.
-- Darren J Moffat --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com