Full Disk Encryption - Xen, Windows and Linux?

Bofh To asks: "I'm in an industry that, more or less, requires full disk encryption, and to accomplish this, we use Pointsec on Windows. For the past 8 years, I've been running Linux on my work laptop, and this is the first time I'm running in a Windows only environment. I am interested in changing that, because I want to use Linux as my main platform, and only drop in to Windows when necessary (and use crossover if at all possible). I'm also interested in Xen, and would like to see if I can use that to virtualize Windows under Linux. My thought is that, as long as Pointsec is in dom0 and I use virtual disks for the Windows VM, I should be covered. The problem is that I'd also like a machine that is usable, as opposed to waiting endlessly as the virtual memory, virtual machine, pointsec, and xen all thrash around while I'm working on the machine. Has anyone used Pointsec for Linux, with Xen? "

Comments

looking forward to replies on this one

[Cybersonic]

I have not tried out Pointsec yet, but its a solution my company sells so I should learn it :) I certified myself in PGP, which unfortunately does not support full disk encryption on Linux, just Windows and soon OSX... It also does not support dual boot on Windows. (its a shim into ntloader - but after the actual boot loader the 'pgp' os which asks for the decryption key during boot is linux, so I KNOW they have linux expertise...)

I kind of like the roll your own approach to the Linux full disk encryption scenario, but most large organizations balk at anything thats not a commercial solution

Re:Look at dm-crypt

[phrasebook]

How's the performance of dm-crypt for you?

I use it on my swap and /home partitions on my laptop, but when doing heavy writing to the disk, the whole machine locks up for 1 or 2 seconds at a time - no mouse movement, no sound, no cursor - then it resumes. These freezes occur every 10 seconds or so as data gets flushed out to the disk.

Normal reading/writing load is ok, but doing something like an rsync backup kills responsiveness.

It seems to get a bit better if I renice kcryptd and kjournald. Any experience with this yourself?

Re:Look at dm-crypt

[swillden]

With Pointsec only the MBR plus a couple of other sectors are unencrypted. There is no small partition in plain text which is what I understand dm-crypt to be. Please correct me if I'm wrong.

You're correct, but the difference is irrelevant: it doesn't matter if it's a few KB or a few MB that is unencrypted, the key is that all of the functional system and its data is encrypted, including all swap.

Actually, dm-crypt and Linux can do one thing that Pointsec, AFAIK, does not do, which is to take advantage of a TPM-enabled machine. Given a TPM, TPM-enabled BIOS, TPM-enabled GRUB and Linux kernel, you can bind a portion of the master decryption key to the boot state, ensuring that any attempt to modify the unencrypted portions of the data will simply render the system unbootable. I could have overlooked the TPM support in Pointsec, of course. Please correct me if I did.

Not to mention the fact that for the really paranoid an OSS solution offers auditability that no closed-source solution can match.

Known plaintext attack on encryption

[Anonymous Coward]

Is full disk encryption a good idea? With the operating system within the encrypted partition, it gives a LARGE amount known plaintext to mount an
attack.

Re:Debian's new installer is spiffy

[kestasjk]

I thought I covered this when I said

if it gets it from somewhere else but it is read by the kernel in /boot that's also no good because the kernel could be replaced. If you're protecting against theft having an unencrypted kernel read the password is fine. But if you're protecting against theft why both with full disk encryption; why not just encrypt specific files or use a virtual encrypted drive like TrueCrypt?

The main reason for full disk encryption instead of alternatives is that it makes it impossible to modify any part of the operating system while the machine is offline; so you can have a system running in an insecure environment, and no-one can power it off and steal your hashes or change things around because everything on the disk is encrypted.

Now if the machine can be powered off and the kernel can be modified it can be modified to save the password you entered, or simply rootkitted. If you're going to allow that why not just encrypt the specific files/directories you want to protect?

If you keep the kernel separate (eg on a CD or thumbdrive that you keep with you), and you actually mean full disk encryption when you say full disk encryption, an attacker would have to modify the hardware in the machine. If it was a desktop machine they might add a keylogger, or if it was a server they might replace the BIOS, but it would have to be a more determined and experienced attacker than someone simply swapping out your HDD and modifying your kernel.