Re: Disk encryption advice...

2010-10-08 Thread Victor Duchovni
On Fri, Oct 08, 2010 at 04:27:57PM -0400, Perry E. Metzger wrote:

 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?

Commercial products have a mode in which you can drop the requirement
for a key for one reboot. Presumbly the key is then erased. This may
a reasonable compromise. The devil is in the details.

-- 
Viktor.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


RE: Disk encryption advice...

2010-10-08 Thread eric.lengvenis



 -Original Message-
 From: owner-cryptogra...@metzdowd.com [mailto:owner-
 cryptogra...@metzdowd.com] On Behalf Of Perry E. Metzger
 Sent: Friday, October 08, 2010 3:28 PM
 To: cryptography@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  pe...@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 

Re: Disk encryption advice...

2010-10-08 Thread Paul Wouters

On Fri, 8 Oct 2010, Perry E. Metzger wrote:


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?


Use a VM based solution where the Windows images are stored on a NAS
that uses disk encryption (and requires an admin when it would reboot), yet
the Windows based VM's would need no disk encryption supported whatsoever.

My laptop for instance is running Fedora with whole disk encryption, and I
run various Windows VM's that have their image stored on that encrypted disk.

Paul

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Disk encryption advice...

2010-10-08 Thread John Denker
On 10/08/2010 04:27 PM, Perry E. Metzger wrote:
 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?

1) Thanks for being explicit about the threat model and objectives.
 As is so often the case, what the client wants is probably not
 exactly what the client is asking for.

2) In this case, I reckon the client would be content to encrypt
 _everything of value_ on the drive ... even if this is not quite
 the entire drive.

 In particular: On every normal boot, the machine boots into a
 preliminary kernel that uses key A to request key B over the
 network.  Key B is the disk key, which then gets stored in some 
 guaranteed-volatile place that will survive a chain-boot but
 not survive anything else.  Then the pre-kernel chain-boots
 Windows.

 To be clear:  The entire Windows partition is encrypted, but 
 the pre-kernel lives in a tiny partition of its own that is not
 encrypted.

 If the machine is stolen, it is immediately harmless because it 
 is no longer connected to the network.  If the machine is to be
 disposed of *or* if theft is detected or suspected, then the 
 keyserver that hands out disk-keys will stop serving the key 
 for that machine, so even if it is reconnected to the network 
 somehow it is still harmless.  For icing on the cake, the keyserver
 can check IP addresses, virtual circuits, etc. ... to check that 
 a machine that is supposed to be on the secure wired network has 
 not suddenly relocated to the insecure wireless network that serves
 the lobby and leaks out into the parking lot.

 If the network is down and somebody wants to boot his machine
 anyway, he can type in the key by hand.

3) The same effect can be achieved using a hypervisor / VM approach,
 rather than chain-booting.  The same effect can be achieved by
 messing with grub, although that would be more work.  The same
 effect can be achieved by messing with coreboot, but that would
 be even more work.

4) If the customer absolutely insists that the entire Windows drive
 be encrypted, just add another drive, perhaps a very small flash drive.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com