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

Arshad Noor arshad.noor at strongauth.com
Sun Aug 2 19:00:45 EDT 2009


Jerry Leichter wrote:
   How
> does a server, built on stock technology, keep secrets that it can use 
> to authenticate with other servers after an unattended reboot?  Without 
> tamper-resistant hardware that controls access to keys, anything the 
> software can get at at boot, an attacker who steals a copy of a backup, 
> say - can also get at.  

I would be very interested in learning what conclusions you came to,
Jerry.  It is my experience that even *with* tamper-resistant hardware
(TPM, HSM, smartcard), the threat of breach is very high if the server
is configured for unattended reboots.

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.
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, the PINs to the hardware
must be accessible to the application.  If the application has automatic
access to the PINs, then so does an attacker who manages to gain entry
to the machine.

If you (or anyone on this forum) know of technology that allows the
application to gain access to the crypto-hardware after an unattended
reboot - but can prevent an attacker from gaining access to those keys
after compromising a legitimate ID on the machine - I'd welcome hearing
about it.  TIA.

Arshad Noor
StrongAuth, Inc.

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.

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



More information about the cryptography mailing list