[146004] in cryptography@c2.net mail archive
RE: Disk encryption advice...
daemon@ATHENA.MIT.EDU (eric.lengvenis@wellsfargo.com)
Fri Oct 8 19:28:40 2010
From: <eric.lengvenis@wellsfargo.com>
To: <perry@piermont.com>, <cryptography@metzdowd.com>
Date: Fri, 8 Oct 2010 17:22:24 -0500
In-Reply-To: <20101008162757.17705320@seasnet-6-11.cis.upenn.edu>
> -----Original Message-----
> From: owner-cryptography@metzdowd.com [mailto:owner-
> cryptography@metzdowd.com] On Behalf Of Perry E. Metzger
> Sent: Friday, October 08, 2010 3:28 PM
> To: cryptography@metzdowd.com
> Subject: Disk encryption advice...
>=20
> I have a client with the following problem. They would like to encrypt al=
l of
> their Windows workstation drives, but if they do that, the machines requi=
re
> 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 interve=
ne
> on every machine in their buildings in order to push out software and
> patches.
>=20
> (The general threat model in question is reasonably sane -- they would li=
ke
> drives to be "harmless" when machines are disposed of or if they're stole=
n
> by ordinary thieves, but on the network and available for administration =
the
> rest of the time.)
>=20
> Does anyone have a reasonable solution for this?
>=20
> --
> Perry E. Metzger perry@piermont.com
This is a fairly well known problem for which many vendors have solutions o=
f varying quality. I'll summarize a few approaches.
In general you want to have the window between the time a pre-boot authenti=
cation (PBA) bypass is set and the time of the reboot that consumes the byp=
ass 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 o=
n 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 ma=
nagement consoles, not locally. Ideally it should be protected by some cryp=
to scheme. Checkpoint, McAfee, PGP for sure have this feature, but I believ=
e 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 co=
unter 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 re=
quired reboots allowed.
2) Some systems can be configured to boot to Windows, and use Windows' IP s=
tack 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 sys=
tem insitigates PBA and shuts down. On next boot it will be at the PBA prom=
pt. I know of some vendors that do this, but do it really naively. One actu=
ally does nothing more than ping a series of IP addresses and if *any* of t=
hem 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 spoo=
f an ICMP echo response. I discourage this mode in general, even if done we=
ll 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 l=
ast couple years to leverage vPro and Intel's secure wake-on-lan, and pre-b=
oot environment to provide secure challenge-response based network awarenes=
s. 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 th=
e prompt or shut down. Oddly enough that company, McAfee, was recently boug=
ht 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 wor=
k for either company. I just happen to have dug pretty deeply into disk enc=
ryption 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 int=
erested 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 wait=
ing for vendors to kick-start their products, so Intel bought the company t=
hat 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 fr=
ont 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@metzdowd.com
