2006-11-13
Dual boot and full encryption
I’m trying to set up a laptop which needs as much security and privacy as I can get. It turns out the main problem is that I want and need dual-boot: Windows XP Professional and Linux (Debian Etch). Now, Encrypting of all partitions used (except /boot of the Debian installation) is a must. Without dual-boot, this won’t be any problem, but not with the wish to dual-boot.
The Linux side isn’t a real problem, I simply use a dm-crypt’ed partition as the only “physical” volume in an LVM volume group, which contains three logical volumes: Swap, / and /home. This means I only need to enter my LUKS/dm-crypt password once during boot.
Shared partitions (shared between Windows and Linux) are also encrypted with dm-crypt/LUKS and decrypted by FreeOTFE (which is a really nice little OpenSource tool BTW), formatted as FAT32.
The Windows side on its own won’t be too much of a problem either, since BestCrypt, PGP Whole Disk Encryption as well as DriveCrypt PlusPack (this probably isn’t a complete list) allow encryption of the Windows boot partition, but at least the latter two need their pre-boot authentication part (which is needed to be able to decrypt the Windows boot partition) to be installed into the MBR.
Now, I wasn’t yet able to get Linux installed to the disk without breaking the Windows decryption. If anyone knows a program which allows encryption of the Windows boot partition and dual-booting into Linux, I would welcome a hint. Preferably, this solution should use grub as the primary boot manager.
See also Dual boot and full encryption – Part 2
See also UK going completely crazy on cryptography law.
See also live-cd-on-removable-disk
Permalink
Anonymous said,
November 13, 2006 at 21:49 UTC (+0000)
One of these things is not like the other…
A few suggestions:
You could just single-boot to GNU/Linux, and then run Windows via qemu or similar. Together with the qvm86 acceleration module, this would run at fairly reasonable speed. Running in qemu also gives you the ability to do various interesting things, like saving off a pristine Windows image to revert to, running in snapshot mode which doesn’t touch the disk image, using qemu’s virtual SMB server to serve up a directory on the host system to the guest, or “save state” to a file and load the state later.
Also, if you truly want the best security possible, you should not leave your unencrypted /boot partition on the laptop drive; instead, you should keep it on trusted bootable media, like a CD or a write-protected USB key. Remember, disk encryption doesn’t just keep people from reading your data, it also keeps them from changing it, such as by installing a rootkit; that does no good if you leave the kernel and initrd on an unencrypted partition.
The external media solution would also solve your dual-boot issues, if you don’t want the emulation solution: either use two different trusted boot media, or use trusted media for the GNU/Linux bootloader and /boot and let Windows have the MBR. (Just remember that if you leave the Windows encrypted-partition loader in the MBR, someone could rootkit your system by tweaking that code.)
For convenience, you might also consider getting a GPG smartcard and a PCMCIA card reader, which (among other things) would let you authenticate by popping in the smartcard – more convenient and more secure.
sven said,
November 13, 2006 at 22:01 UTC (+0000)
For one, the laptop in question has a smartcard reader and I would like to use it under Linux, but according to a colleague (and openct developer), it isn’t supported yet under Linux.
Aynway, I don’t necessarily want encryption for maximum security, but for maximum privacy. I simply don’t want a potential thieve to be able to read my data.
And as for the emulated system inside the other system (i.e. running Linux or Windows in a qemu/vmware virtual machine inside the other OS): I already tried that and it worked out nicely for about 75% of the time, but had problems on like every fourth occasion. It would have worked nicely I suppose for standard uses, but it didn’t work out for me.
Anonymous said,
November 13, 2006 at 22:17 UTC (+0000)
Actually, thinking about it further, you don’t need to have two different media; you can just have your trusted media include a copy of the Windows MBR, so that you can verify the one on disk before you chainload it. grub includes a cmp command, which might work for this purpose; if the compare fails, you could boot into GNU/Linux and restore the MBR.
Anonymous said,
November 13, 2006 at 22:19 UTC (+0000)
Could you elaborate on what kinds of problems you had when emulating Windows from within GNU/Linux?
sven said,
November 13, 2006 at 22:25 UTC (+0000)
Booting from a second media might work (this would probably have to be a USB device, but as USB sticks became much more compact (I like the Sandisk Cruzer Micro, it’s fast and really compact), this might be an option.
Regarding emulation problems:
The biggest problem is that I sometimes need to reproduce problems which involve VMware inside Windows (which happens more often than the other way around), and VMware inside VMware (or inside qemu) simply didn’t work. The other problem was that I needed (and need) to support a custom Linux installation CD which works with a giant initrd (>200M unpacked), which had problems because I simply ran out of memory.
Anonymous said,
November 13, 2006 at 22:36 UTC (+0000)
Heh; so you can’t use emulation to run Windows because you need to test emulation in Windows?
Hmmm; if VMWare fails to run inside qemu, that represents a qemu bug that needs fixing.
How much memory does the laptop have? Don’t forget that qemu defaults to supplying the guest with 128MB of memory, and if you need more, you need to increase that with the -m option.
sven said,
November 13, 2006 at 22:50 UTC (+0000)
Well, I don’t know wether VMware currently runs inside qemu, but even if it doesn’t, I don’t know wether that would be a (fixable) bug in qemu.
The laptop has 1.25GB of RAM (the new laptop where I’m trying to set this up has 2GB), and of course I know I need to tell qemu and/or VMware that they should provide more than their respective standard amount of memory.
But, even if this emulation method would run perfectly, I would still need to be able to run each OS individually, without any additional layer which could introduce unexpected behaviour. Just one example: At my working place, we try to use IP-video-conferencing, and we were so far unable to get VMware (and as far as I know, qemu wasn’t better) to allow the Windows guest to use the USB webcam on a Linux host OS. USB smartcard readers and usb storage worked perfectly on the other hand. And on some systems, the windows guest was unable to access the microphone input of the soundcard. So all-in-all, I need to be able to run Windows from the disk without any emulation layer and the same is true for Linux.
Which brings us back to my initial (encryption) problem. I will try the USB boot option one of these days. We’ll see how it works out.
textshell said,
November 14, 2006 at 01:49 UTC (+0000)
dd the mbr of the windows stuff and try to chainload it with grub. I think that should work.
I think grub can load it just as if it was run directly from the mbr. But i never tried that…
boot ed said,
November 14, 2006 at 04:17 UTC (+0000)
How about using the original Windows boot loader (NTLDR) to boot Windows and booting from there to GRUB – thats how I do it. So basically OS’s are “insulated” from one another during boot process, the disadvantage is obvious – additional booting step.
>
http://www.geocities.com/epark/linux/grub-w2k-HOWTO.html
there is a nifty (windows/dos) program to ease this process – boorpart
http://www.winimage.com/bootpart.htm
Anonymous said,
November 14, 2006 at 04:22 UTC (+0000)
qemu definitely supports granting the guest access to USB devices; you might give it a try.
Seegras said,
November 14, 2006 at 12:59 UTC (+0000)
Using lilo, dd if=/dev/hda4 of=bootsect count=1 bs=512 and putting that sector onto the windows-harddisk and include it into the windows boot-menu won’t work?
sven said,
November 14, 2006 at 15:20 UTC (+0000)
Thanks for the suggestions about using the ntloader as the primary boot loader/chooser. This has one minor problem though:
I would have two boot loaders where I would need to make a choice: The ntloader to choose between windows and linux followed by grub to choose between different kernels or kernel options. Thats quite inconvenient, but a possibility I will surely try out. Currently, I like the option of using an externel storage for grub and linux’s /boot better though. We will probably see how it works out.
The optimal solution would still be some disk encryption software for windows which doesn’t require to be put into the MBR.
And special thanks to boot ed for the link to bootpart. That tool is really useful.
Benjamin Seidenberg said,
November 25, 2006 at 05:27 UTC (+0000)
Hmm – I’d look into what textshell said. It may be possible to do the reverse of what Segras and and boot ed were talking about – Have grub launch NTLDR to launch windows. This saves the nastiness since there aren’t usually options for NTLDR so you don’t have redundancy in your boot loaders.
sven said,
November 25, 2006 at 06:23 UTC (+0000)
I’m sorry, but neither PGP Whole Disk Encryption nor Drive Crypt Plus Pack (the two whole disk encryption tools for Windows I tried) allowed Grub to be in the MBR, loading the saved MBR with their code from somewhere else. They check the MBR to verify that their code wasn’t tempered with, it seems.
I posted a feature request for PGP WDE to allow putting it into the Windows partition boot sector so that it would allow another boot manager to be in the MBR but didn’t get a feedback on that yet.
Benjamin Seidenberg said,
November 25, 2006 at 06:26 UTC (+0000)
Ah, got you. Hmm – does grub have a way to forge the response to the request for the mbr? Anyway, let me know what you find out, as I’d love to lock down window’s disk. (Though I think I may have a bios way to do it through the TPM chip)
Anonymous said,
February 15, 2007 at 17:00 UTC (+0000)
Using DriveCrypt Plus Pack with Linux / GRUB HOWTO:
http://keitin.net/jarpatus/articles/dcpp_grub/index_eng.shtml
better late than never
Anonymous said,
February 21, 2007 at 15:47 UTC (+0000)
CompuSec has a free program to do full disk encryption (AES 128bit), and will support linux/winxp dual boot.
How’s that for better late than never?
sven said,
February 21, 2007 at 17:03 UTC (+0000)
You are probably talking about the CompuSec software from CE-Infosys. However though I looked closely at their site (including data sheet and FAQ), I found no hint that they would support dual boot options.
Also, I’m expecting that they would only support this option if their software is installed in both Linux and Windows. I would prefer to use standard Linux mechanisms for encryption on that side though.
Regards,
Sven
Odette said,
March 14, 2007 at 10:13 UTC (+0000)
Good site! I found in google.com +
mlabonte said,
April 4, 2007 at 13:51 UTC (+0000)
CompuSec says right in their datasheet that “Multiple Operating systems are supported on a single computer”. And I believe that supports a mixed-environment. However, I had trouble getting their Windows software to run, and it seems to bundle in a bunch of junk I didn’t want or need, (identity management etc.). However this is your best bet, despite the fact it isn’t a standard linux mechanism.
sven said,
April 4, 2007 at 14:36 UTC (+0000)
mlabonte:
I didn’t try CompuSec because I didn’t want all the bundled Windows software. Apart from that, the method at http://keitin.net/jarpatus/articles/dcpp_grub/index_eng.shtml works for me though. A very similar approach should work for PGP Whole Disk Encryption.
Marco Gruß said,
April 25, 2007 at 15:25 UTC (+0000)
CompuSec only ships with precompiled kernels for some SuSE and RedHat versions. Its driver will be useless for any other kernel since sources are not available.
However, the following worked for me:
- Install Windows
- Create the partitions intended for use with Linux before encrypting. CompuSec seems to change the partition type of partitions created after encryption to 0×07 (NTFS) at every reboot. It doesn’t do this if the partitions were there before encryption.
- Install CompuSec and encrypt the entire hard disk
- Install/copy your installed Linux to the partitions you created earlier, using dm-crypt at your convenience
- Follow the steps in Jari Eskelinen’s HOWTO, using GRUB to launch the CompuSec MBR
You’re done.
Careful: If you ever decide to decrypt your hard disk using CompuSec, CompuSec will use your Linux partitions as the cipher text and turn them into gibberish, so do backup your data!
leetlover said,
July 21, 2008 at 18:25 UTC (+0000)
You could use TrueCrypt, which is cross-platform.
I have a similar problem now.
In fact, I have both sides encrypted separately, Windows XP and Ubuntu, but I haven’t figured out yet how to use the Windows volumes from Linux without formatting them and making them TrueCrypt volumes.
PGP WDE can encrypt your Windows partition and it plays along nicely.
Here’s my issue on their forums:
http://forum.pgp.com/pgp/board/message?board.id=54&thread.id=3889
sven said,
July 22, 2008 at 07:01 UTC (+0000)
@leetlover:
PGP WDE has no driver for Linux yet (as most other competitors, with CompuSec being only half – if that – useful to Linux users). So Linux only sees the encrypted data on your partitions and doesn’t have a way of decrypting that.