[cryptography] Disk encryption advice...

travis+ml-rbcryptography at subspacefield.org travis+ml-rbcryptography at subspacefield.org
Tue Nov 9 17:34:37 EST 2010

On Fri, Oct 08, 2010 at 05:22:24PM -0500, eric.lengvenis at wellsfargo.com wrote:

> This is a fairly well known problem for which many vendors have
  solutions of varying quality. I'll summarize a few approaches.

I have a friend who has a similar problem with unattended reboots of
systems in a data center.

> 2) Some systems can be configured to boot to Windows, and use
  Windows' IP stack to check for some conditions on the network. If
  the conditions are met, the system stays at the Windows prompt; if
  the conditions are not the system insitigates PBA and shuts down. On
  next boot it will be at the PBA prompt. I know of some vendors that
  do this, but do it really naively. One actually does nothing more
  than ping a series of IP addresses and if *any* of them respond they
  assume they are on the right network. Yes, they pin their network
  location awareness on the fact that nobody could ever think to spoof
  an ICMP echo response. I discourage this mode in general, even if
  done well because it depends on a fully booted windows box before it
  can check. I configured a small lab network to trivially bypass the
  ping test.

You could fix this by having the bootup system determine if the check
is signed by some special server's (call it a keyserver) public key.

The problem even with this is that the logic is all on the end node,
and so can easily be patched.  A competent reverse-engineer could
write a tool to bypass this which targets the specific implementation.

To be secure, the information needed to decrypt the data cannot be on
the end node.

So the next move up is to have the bootstrap query a keyserver for the
key.  Outside the corporate network, there is no key server to
respond, so it prompts the user.

Generally, corporate customers want the ability to decrypt employee
systems anyway, so having a central server with a copy of keys necessary
to unlock the drives is not that much of a threat.  The system still
defends quite well against lost systems.

You can try to authenticate the client, or encrypt the communication
of the encrypted storage key, but that's just icing on the cake.

> 3) There is one vendor that has worked on this problem very hard
  over the last couple years to leverage vPro and Intel's secure
  wake-on-lan, and pre-boot environment to provide secure
  challenge-response based network awareness. If they determine they
  are on a secure network, they will continue past the boot prompt and
  if they determine they are not they'll either sit at the prompt or
  shut down. Oddly enough that company, McAfee, was recently bought by
  Intel. McAfee's leveraging of Intel's on-board security hardware was
  the main deciding factor in that purchase, or so I believe.

Cryptonerd version:

Have the system PXE boot by default, and have it pull down an image
from a corporate server that grabs the key from a keyserver, and then
pivot into the full system boot, with decryption key in memory.

A bit of a usability problem though; if you're off-network, the user
has to know how to disable PXE boot and go to regular boot process and
PBA prompting for passphrase.

Can also replace PXE boot with a USB key.
Good code works on most inputs; correct code works on all inputs.
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email john at subspacefield.org to get blacklisted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20101109/c404a743/attachment.asc>

More information about the cryptography mailing list