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

Reply via email to