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

[Peter Gutmann]

Arshad Noor <arshad.noor at strongauth.com> writes:

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

I talked to an auditor about this a while back, here's my summary of this:

  For auditing purposes the only thing that.s required for unattended restart
  is a mechanism to prevent an attacker from copying unprotected keying
  material from the machine.  For example storing the key in a token plugged
  into the machine is generally considered sufficient because it gives you the
  ability to point to a physical security procedure that.s used to prevent the
  key (meaning the token that it.s held in) from being removed.  This
  functions as an audit mechanism because it.ll be noticed if someone removes
  the token, which isn.t the case if someone copies a file containing the
  unprotected key from the machine.  Hardware security modules (HSMs, a
  special-purpose crypto computing device capable of storing thousands of
  keys and performing encryption, signing, certificate management, and many
  other operations) are often used for this purpose, storing a single
  symmetric key in the HSM to meet audit requirements.  If the HSM vendor has
  particularly good salespeople then they.ll sell the client at least two
  $20,000 HSMs (each storing a single key) for disaster recovery purposes.

In other word's the target isn't necessarily what's good enough for security
people, but what's good enough for the auditors, and the above was deemed good
enough for the auditors.

Peter.

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