Disk encryption advice...

eric.lengvenis at wellsfargo.com eric.lengvenis at wellsfargo.com
Fri Oct 8 18:22:24 EDT 2010




> -----Original Message-----
> From: owner-cryptography at metzdowd.com [mailto:owner-
> cryptography at metzdowd.com] On Behalf Of Perry E. Metzger
> Sent: Friday, October 08, 2010 3:28 PM
> To: cryptography at metzdowd.com
> Subject: Disk encryption advice...
> 
> I have a client with the following problem. They would like to encrypt all of
> their Windows workstation drives, but if they do that, the machines require
> manual intervention to enter a key on every reboot. Why is this a problem?
> Because installations and upgrades of many kinds of Windows software
> require multiple reboots, and they don't want to have to manually intervene
> on every machine in their buildings in order to push out software and
> patches.
> 
> (The general threat model in question is reasonably sane -- they would like
> drives to be "harmless" when machines are disposed of or if they're stolen
> by ordinary thieves, but on the network and available for administration the
> rest of the time.)
> 
> Does anyone have a reasonable solution for this?
> 
> --
> Perry E. Metzger		perry at piermont.com

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

In general you want to have the window between the time a pre-boot authentication (PBA) bypass is set and the time of the reboot that consumes the bypass be as small as possible. Alternatively (my preferred) you want to have a pre-boot environment that can make a secure check to see if it is still on a safe/secured network and if it is, bypass PBA. This way PBA is bypassed any time the system is in a safe facility.

1) Some type of bypass file placed by the managing system that, if present on reboot tells the system to bypass the pre-boot authentication. The file should be settable only through an administrative function configured on management consoles, not locally. Ideally it should be protected by some crypto scheme. Checkpoint, McAfee, PGP for sure have this feature, but I believe most big vendor-owned solutions have it. I don't much care for *how* they implement it. PGP has a command-line command that sets the reboot flag, so a simple administrative-level cmd script can do it. The file may have a counter that is decremented (Checkpoint does) or it may need to be reset each time. I recommend that you deploy the bypass file as part of the patching process so the window is small as possible with only the known number of required reboots allowed.

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.

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.

Disclaimer: My company isn't a McAfee disk encryption customer. I don't work for either company. I just happen to have dug pretty deeply into disk encryption companies and products over the last couple years and my opinion is that McAfee did it right and the others are playing catch up.

Off topic rant: None of the other security vendors seemed the least bit interested in the on-board security features Intel was building into systems, largely because if vendors built product around it, it might make them too interchangeable; replaceable. McAfee was different. Intel got tired of waiting for vendors to kick-start their products, so Intel bought the company that had gotten the furthest with Intel's tools. Personally, I'd hate to be competing with Intel/McAfee on the disk encryption or systems management front right now. Of course, they've still got plenty of latitude to screw it all up.


Eric Lengvenis
InfoSec Arch., VP

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



More information about the cryptography mailing list