Unattended reboots (was Re: The clouds are not random enough)

[Darren J Moffat]

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 majordomo at metzdowd.com