6

I'm looking for a solution to fully encrypt my dual-boot SSD drive (it's still new and empty, and I want to set up encryption before I put anything on it).

While there's a lot of chaos on the web regarding that question, it appears that TrueCrypt might be able to do this, although I might need its boot loader on an extra boot disk. From what I'm reading, some Linux tools (including some modified GRUB2) might also be able to do that.

However, I have my doubts, and no article I read really went in deep enough to answer a basic question: if the whole disk is encrypted, and some pre-boot tool asks the user for a key to decrypt it, doesn't that mean this tool has to run beneath the OS that's going to boot? In other words, are there tools that leave the OS unaware of the fact that the disks it sees are actually encrypted?

If there's no such tool, doesn't that mean the decryption tool somehow has to pass decryption information to the OS on boot? I can imagine that this would be hard to do cross-platform.

5

If the whole disk is encrypted, and some pre-boot tool asks the user for a key to decrypt it, doesn't that mean this tool has to run beneath the OS that's going to boot?

Yes, pretty much. Hardware-based full disk encryption does this: the encryption is handled entirely by the device (hard disk/flash) or possibly in a controller along the chain leading to the physical device(s), and is not "visible" to the OS.
With this, the OS does I/O exactly like it would if it was dealing with a plain, unencrypted device, the magic happens in hardware (and/or firmware - "below" the OS in any case).

If there's no such tool, doesn't that mean the decryption tool somehow has to pass decryption information to the OS on boot?

There would have to be some form of information transfer indeed, if the encryption cannot be done "underneath" the OS (either as above, or possibly using virtualization techniques – but then you sort of have two (or more) OSes running). And yes that means cross-OS is hard.
You'll also need the boostrap code (bootloader at the very least) to be un-encrypted if you don't have hardware/firmware assistance.

The Wikipedia disk encryption article has more about this.

4

If you have hardware (or more precisely firmware, i.e. BIOS) support for encrypted drives, then you can encrypt the full disk with the firmware. There are downsides to doing that: there aren't many computers around that support disk encryption, and it ties you to a particular firmware (or worse, if your computer has a TPM and the encryption key is in a TPM, it ties you to this particular motherboard unless you've backed up the storage encryption key).

If the operating system does the encryption, then there has to be a small space on the disk that is not encrypted, where the initial parts of the operating system are stored. A common configuration with Linux is to have a separate cleartext /boot partition, and to encrypt every other partition. “Full-disk encryption” is a bit of a misnomer: it's usually used to mean “full volume encryption”, where a volume is typically a partition rather than a disk. Full-disk encryption is when you don't encrypt every file (or at least a directory tree) separately.

Under Linux, the standard tool for full-disk encryption is dmcrypt. It is available in all major distributions and integrated in many installers.

1

Yes, with Grub2 the /boot partition can be encripted by LUKs:

  • /boot as a folder on / on a LUKs encrypted partition
  • /boot on a LUKs encrypted on a partition
  • And so on, since Linux let you use any non sorted block list as a device and such can be the root (initramfs is very complex to configure for such non sorted block list, but can be done, it is a paranoid way)

I had also tested the paranoid way to encrypt /boot (when is a partition) with more than one layer:

  1. /dev/sda5 as the only logical partition on the disk (MBR with only two Extended partitions /boot and /)
  2. Over /dev/sda5 i put LUKs level 1, mapped to /dev/mapper/level_0001
  3. Over /dev/mapper/level_0001 i put LUKs level 2, mapped to /dev/mapper/level_0002
  4. Over /dev/mapper/level_0002 i put LUKs level 3, mapped to /dev/mapper/level_0003
  5. And so on, Over /dev/mapper/level_#### i put LUKs level ####+1, mapped to /dev/mapper/level_####+1
  6. Over /dev/mapper/level_3436 i put LUKs level 3437, mapped to /dev/mapper/level_3436
  7. Over /dev/mapper/level_3437 i put an Ext4, mounted as /boot
  8. Over /boot i install Grub2 after running echo GRUB_CRYPTODISK_ENABLE=y >> /etc/default/grub
  9. Over /dev/sda6 i put / with only one level of LUKs

At boot time it asks me 3437 different passwords, i use more than 32 chars on each.

It was just a proof-of-concept, boot time is horrible.

But if i do the same on / then all system read/write speed is also horrible, but at least Linux works. I had also tested with more than ten thousand levels; it partially works, read/write goes down to 10KiB/s (yes, really horrible) on my CPU, boot takes a full day and applications tend to crash a lot caused by disk time-outs when doing OnLine access (surfing, etc).

So putting three or fout levels of LUKs is acceptable, also ten, it depends a lot on your CPU and for what you use CPU versus DISK, 3D Render vs Huge data scramble, etc.

P.D.: You can also use different hash function and algorith on each level of LUKs and also can use --iter-time=# to make mount time bigger (warning: at Grub2 pre-boot that mount time is three or four times greater, using a value arround ten thousand causes near thirty seconds on pre-boot).

  • the paranoid way to encrypt /boot (when is a partition) with more than one layer: May I ask what this is good for? – countermode Feb 10 '17 at 9:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.