User:Slowpoke/Full Disk Encryption

Warning, this page is a work in progress by slowpoke (talk | contribs). Treat its contents with caution.

Article status

This article has some todo items:

• There are various TODOs in the source.

Full Disk Encryption (FDE) is the process of encrypting the entire operating system including all files, except for a small boot partition.

Overview

Why Encrypt?

There are many reasons why you would want or need to encrypt parts of or your entire system, and entire articles can be (and have been) written about this topic, so let's keep it short, and only go over the technical reasons for FDE.

To gain access to a regular system with only password protected logins, you only need a live system, and often not even that. In most cases, setting init=/bin/sh on the kernel command line in the boot loader suffices to gain a shell where you can change the root password. With a live system, you can simply access all files on the local disk.

With a fully encrypted system, that's impossible. While a dedicated attacker could still manipulate your kernel, initram or bootloader (which are usually still in the open, because you need to boot the system somehow), you are safe against most regular attacks or a simple laptop thief.

Tradeoffs

Employing FDE on your machine involves making some tradeoffs. First off all, always keep in mind the most fundamental law of computer security:

   Security = Usability^(-1)

This holds true for FDE, as well. One of the most obvious things you will lose is boot speed, because you'll be forced to enter your passphrase every time you (re)boot. For system which rarely reboot, this isn't a problem, and on some machines, the BIOS stage will cost you more time, anyways.

Another speed loss you will experience is disk access. Since encryption is a transparent process that the kernel has to handle for all access to encrypted devices, this will obviously cost you some percentage of your disk's read and write speed. With a SSD, this is less noticeable, but still present.

Preparation

Securely Erasing the Disk

While this isn't strictly necessary, it's still good to "zero" a disk before encrypting it. The easiest way to do this is using dd.

Warning
This operation is destructive. You will lose all data on that disk.

root #dd if=/dev/zero of=<device>

Depending on the size of the disk, this can take anywhere from a few minutes to several hours. It's a good idea to do this overnight.

Alternativeley, you can also opt to fill the disk with pseudo-random data. To do this, change the input file of the above command to /dev/urandom. This might take a bit longer than just zeroing the disk.

root #dd if=/dev/urandom of=<device>

For the truly paranoid, these operations can be repeated as many times as you deem necessary.

Disk Layout

This can differ depending on your setup, but in all cases, you will need a small boot partition, enough to hold at least a regular kernel, an initramfs, and whatever files your bootloader will need.

For the crypted parts, there are many possible setups, but most will be a variation of the following:

Single Partition

One big encrypted partition, which holds the entire root filesystem of your installation

Multi-Partition

Multiple encrypted partitions, which hold different parts of one (or more) installations (for example, a shared /home and two different / partitions).

LVM on LUKS

One big encrypted partition, which contains an LVM on which one or more operating systems are installed.

LUKS on LVM

An LVM where one or more mapped devices are encrypted.

ZFS on LUKS

Same as LVM on LUKS, but using ZFS instead.

All have various pros and cons, but we will try to cover all of them to some degree.

Partitioning

As mentioned before, you will need a small /boot partition (refered to. A good size is 128MiB, since this aligns nicely with most block sizes. It's up to you (and your machine) whether you want to use GPT or MBR style partitioning, and is out of scope for this article.

For all setups mentioned above, except Multi-Partition, you will want to format the rest of your hard drive as a single partition. For Multi-Partition, create whichever partitions you need.

Using cryptsetup

No matter how your setup will look like, at one point you will have to create the LUKS volumes. For this, we use cryptsetup, which is part of the correspondent package.

The appropriate sub-command for creating new LUKS volumes is luksFormat, which has a number of important flags.

Important
Some of these settings might not provide the best security, they are meant as reasonable defaults. Consult the man-page for more information.

--cipher (-c) <cipher-spec>

Specify the cipher type. You should probably use xts-aes-plain64 here.

--hash (-h) <hash-spec>

Specify the hash type. A good choice is sha512.

--key-size (-s) <size>

Change the size of the generated key. 512 should suffice here.

--iter-time (-i) <number of milliseconds>

The amount of time to spend with PBKDF2 passphrase processing. 5000 is a good value

--use-random

You should specify this to avoid generating an insecure key if your system is low on entropy. This will block and wait for more entropy if the pool is empty.

--verify-passphrase (-y)

Check the passphrase by requiring it to be typed twice. This should be the default, but it doesn't hurt, either way.

So, the command to format your device could look like this:

root #cryptsetup --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 --use-random --verify-passphrase luksFormat <device>

Alternatively, you can use a keyfile instead of a passphrase.