Whole Drive Encryption - Dual Boot

[loftrat]

Afternoon,

I've a requirement to encrypt the whole harddrive of a laptop which is dual-booting Ubuntu and Linux.

Ideally it should request some sort of athentication (preferably two factor: token and password) at boot, and then (if authentication is successful) present me with the standard boot menu (lilo, grub, whatever) so that I can choose my OS.

Ideally I'd like to be able to manage it from within Linux as that will be my primary OS, but if it must be managed from within Windows then that's not too much of a trauma.....maybe.....

Anybody got any thoughts?

[elazar]

http://www.truecrypt.org/
http://www.pgp.com/products/wholediskencryption/

EDIT: TrueCrypt does not support encrypting your boot partition:

From the TrueCrypt site:

Q: Is it possible to encrypt my operating system boot partition?

A: No, TrueCrypt does not allow this. However, there are ways to ensure that the volume where operating system resides is read-only, which should prevent information leakage (registry, temporary files, etc., are stored in RAM) and make it impossible for an adversary to install a Trojan horse on the system. One of the ways is using BartPE. BartPE stands for "Bart's Preinstalled Environment", which is essentially the Windows operating system prepared in a way that it can be entirely stored on and booted from a CD/DVD (registry, temporary files, etc., are stored in RAM - hard disk is not used at all and does not even have to be present). The freeware Bart's PE Builder can transform a Windows XP installation CD into BartPE.
If you use TrueCrypt 3.1 or later, you do not even need any TrueCrypt plug-in for BartPE. You can simply run TrueCrypt in 'traveller' mode under the BartPE system from a BartPE disk itself or from any other location where the TrueCrypt system files (i.e., 'TrueCrypt.exe', 'TrueCrypt.sys', etc.) are stored. The type of the CD or DVD on which you store BartPE should be "write once, read many" (for example CD-R), because rewritable disk types (such as CD-RW) might allow an adversary to alter the contents of the disk.


It might be possible make a small boot partition with just the kernel, truecrypt, and truecrypt's dependencies which could then decrypt your root partition at boot time...

[thorin]

I've used TrueCrypt before though not as you describe. I've used it for USB devices and been very happy with it.

For the scenario you describe I've only had experience with Winmagic/SecureDocs which did a wonderful job.

[blackfoot]

The most effective whole disk encryption is through using OpenBSD instead of Linux, (but a similar state can be achieved under Linux with care).

The whole disk should be filled with random (gosh that takes forever on a big disk - maybe allow a week - no joke) or with zeroes.

That act alone will present any enquirer with information that indicates that the whole disk is full.

The use of lilo or grub will defeat your purpose I guess. It is more effective to use a startup USB stick which carries its own key. A CD can sometimes be used if the system does not activate USB at boot.

The key should be a very lengthy passphrase encrypted with Blowfish or similar at maximum length. (At least 4096 preferably more.) It will be nearly impossible for you to repeat the key and so it should be stored on the USB stick in encrypted form.

The USB stick will enable you to start your preferred OS.

Bear in mind that SWAP might leak and certainly userland programs and data will be processed in the clear during use.

The system should be configured so that so that it only starts from the USB stick. You should remove it whenever the machine is under threat or when out of reach. Turning off the machine by powering down therefore renders it in a useless state.

There are consequences for backing up data. It is possible to encrypt CDs to contain backup data but not entirely satisfactory. It will always have to be processed in the clear.

Watch out for DNS leaks and web use.

Never lose your USB stick. Leave a copy in a safe. Without the USB stick the system is nothing. Plausible denial is difficult. This is not atrivial pursuit but highly enjoyable.

Other ideas mentioned here may be valid and workable but at a significantly less secure state. I cannot verify them as I have not used them.

Best of luck. Not a nothing!

[elazar]

You might want to take a look at this: http://tldp.org/HOWTO/html_single/Disk-Encryption-HOWTO/

The only caveat is the key needs to be stored on a removable medium(i.e USB Drive)


E

[thorin]

http://www.truecrypt.org/
http://www.pgp.com/products/wholediskencryption/

I would strongly suggest that you read this (http://it.slashdot.org/it/07/10/04/1639224.shtml) before you decide to use PGP whole disk encryption.

[PrairieFire]

I would strongly suggest that you read this (http://it.slashdot.org/it/07/10/04/1639224.shtml) before you decide to use PGP whole disk encryption.

PGP Whole Disk Encryption - Barely Acknowledged Intentional Backdoor

Popular whole disk encryption vendor, PGP Corporation, has a remote support “feature” which allows unattended reboots, fully-bypassing the decryption boot process. The feature, which until recently was not documented (customer accessible only) in most support manuals, allows a user who knows a boot passphrase to add a static password (hexadecimal x01) that the boot software knows. If this flag is set, the boot process does not interrogate a user. It simply starts the operating system. The feature can be accessed via the command line (ignore line wrap) You have to set this bypass up it is not created automatically.. Also some of my passphrases are over 65 Characters long so good luck shoulder surfing...

[shamanvirtuel]

and the worst, if i remember well is that pgp creator , zimmermann, was forced to disclose algorythm & methods used in pgp for whole encryption.....

i remember it's because of the law for cryptographic software in USA, but maybe one us citizen can precise this....

maybe it's only my brain which is too fuzzed by MJ but pgp is dead for me !:p

[blackfoot]

Yes there were/are many allegations concerning the presence of a backdoor.

There are also US export restrictions...which is one reason why the OpenBSD/OpenSSH team have moved to Canada.

My first reply in this thread still stands as my advice.

GPG is an alternative to PGP if required. I use GPG for my emails.

[thorin]

@ PrairieFire

I wasn't meaning to make it sound like the end of the world for PGP, I just wanted ppl to be aware of it.

@ blackfoot
I also recently started using GPG for encrypted email/attachments. So far I'm pretty happy with it.

[elazar]

You might want to look at cryptsetup to encrypt your Linux root partition. You can make a custom initrd to decrypt it at startup. I am going to post a tutorial one of these days when I get around to testing it. As far as encrypting Windows, the major caveat with whole disk encryption is that the boot loader needs to handle the encryption/decryption routines(Kinda like a marriage between cryptsetup or loop-aes and syslinux :p), and then kick off the OS specific bootloader(s), and as far as I have seen, there aren't many of those. If someone could figure out how to keep a very small Linux kernel between Windows and the harddisk then cryptsetup might be feasible. For example, your bootloader loads a small vmlinuz and custom initrd with cryptsetup, prompts your for the volume password, and then transfers control to the OS kernel, say ntldr, but the Linux kernel is still sitting between the OS and the disk handling the encryption/decryption, sounds familiar, doesn't it, think VM's and hypervisors. I can envision future disk encryption technologies using vm hypervisors to handle encryption/decryption...

[blackfoot]

...but (with respect, Elazar) you missed the whole point.

I believe the original question was concerning 'Whole Drive Encryption'.

What you postulate as your vision is already here. These forms can already be done. To achieve a satisfactory schema one needs external booting and key safe.

(Your early link was to quite a good paper).

[elazar]

...but (with respect, Elazar) you missed the whole point.

I believe the original question was concerning 'Whole Drive Encryption'.


Point taken. Cryptsetup is not whole drive encryption because it is not OS independent. I mentioned it because it will solve half of his problem and to possibly pique interest in building a kernel that can handle disk encryption regardless of the OS.


What you postulate as your vision is already here. These forms can already be done. To achieve a satisfactory schema one needs external booting and key safe.

(Your early link was to quite a good paper).


That link describes a method that is not OS independent, hence lacking the "whole drive" capability. As I mentioned previously, my theory is to build a Linux kernel with Cryptsetup that can handle drive encryption regardless of the OS, because it sits between the OS and the drive. Keep in mind that whatever boots the drive cannot be encrypted, whether it is on or off the drive. The end result is a method very similar to the way virtual machines function, given that most modern processors have vm optimizations, I envision whole disk encryption using already available vm technology where the OS(s) are encrypted and the unencrypted hypervisor handles the encryption/decryption process.

[blackfoot]

Cryptographic File System is available.

Linux has export control restrictions if it emanates from the USA.

Since it bootstraps into existence it must use an external drvier to start proceedings. To do otherwise is not possible since the script would be encoded and the interpreter would not be able to decrypt it.

You might note it is not my wish to go into a protracted debate. This is only a marginal issue here. My own option has always been to stay with OpenBSD and CFS. This distribution is not up to that, nor seeks to be.

[elazar]

Cryptographic File System is available.

Linux has export control restrictions if it emanates from the USA.

Since it bootstraps into existence it must use an external drvier to start proceedings. To do otherwise is not possible since the script would be encoded and the interpreter would not be able to decrypt it.

You might note it is not my wish to go into a protracted debate. This is only a marginal issue here. My own option has always been to stay with OpenBSD and CFS. This distribution is not up to that, nor seeks to be.

Agreed. I took a quick look at CFS, its pretty cool. I don't have any experience with OpenBSD, I will have to check it out one of these days...

[davebailey]

Hello,

I'd love to post some links, but since this is a new account, the software won't let me.

Google for "LINUX UNIFIED KEY SETUP dm-crypt" and the first response has lots of links how to do this from various distributions. I've used this with openSUSE 10.3 with success. A note that all the tools are still in progress, although at least with openSUSE 10.3, it is an official function.

- David