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 majord...@metzdowd.com