The Performance Impact Of Linux Disk Encryption On Ubuntu 14.04 LTS

[suberimakuri]

Yeah grub-efi works a treat. Grub has mdadm support.

[Luke]

I've never tried to boot from a RAID so would not have been able to advise on how to do that. More likely to back up one boot partition to the other first partition manually, then installing GRUB on both and booting from one of them by default.

[suberimakuri]

Thanks Luke,
Yes it's a little more hassle having two RAID groups however if a drive fails I still want to be able to boot the machine. If I RAID /boot then this ability is maintained.
After some initial headaches, this now seems to work fine for me with EFI.
Rest of your post all good, appreciate it!

[Luke]

Laptop setup is correct

If that server is using two similar drives, I would not use two separate RAID groups. Instead, make one RAID only from the second (large) partition of each disk, put the LUKS volume on top of that and LVM on top of the LUKS volume, then your filesystems in that. Use one of the first (small) partitions for /boot and leave the other unused, as you don't need a RAID for /boot and it makes setting up the bootloader more complex. A lot like the laptop except that two drives are used as one with the exception of /boot.

Thus, if only two drives are used in the server you might have sda1, sda2, sdb1. and sdb2. Put /boot on sda1, use sda2 and sdb2 for md0, and leave sdb1 unused. Put LUKS encryption on md0, open the LUKS volume and set up your LVM volumes, making sure to put /home in it's own LVM partition so you can reinstall the OS without touching the data partition.

[suberimakuri]

Thanks very much, so something like this.

Laptop:
2 primary partitions: /boot, everything else (LUKS).
LVM the LUKS partition into /, swap, etc.

Server:
2 drives.
2 primary partitions one for /boot, one for everything else.
2 RAID1 groups (md0/1) for these partitions.
LUKS md1 (everything else)
LVM LUKS'd md1 into /, swap, etc.

Yes?

[Luke]

Use cryptsetup/LUKS for all but /boot, not an ecryptfs /home volume. The ecryptfs setup has a reputation for being slow, and it protects too little data. Also, if the root partition is not encrypted anyone with a bootable flash drive can write to your entire OS, not just your boot partition. With the LVM setup, this is simple: one /boot partition, one encrypted partition. On the unlocked encryprted partition goes the LVM, which is partitioned into /, /home, and if used a swap partition. Never, ever swap to an unencrypted partition if encryption is used anywhere, even just to flash drives.

Make one large encrypted partition and putting LVM volumes on top of it is allows entering the passphrase only once. This is the real reason you see LVM used so often with encryption. Same idea on a RAID volume: One big RAID and the encrypted volume sits on top, requiring opening only once. if you encrypt the disks first, then put RAID on top each disk must be individually unlocked. There are ways to unlock multiple disks with one passphrase entry, but doing that requires some custom coding that it is possible to do wrong.

The one time you are forced to unlock disks separately is when a small "system" disk, often an SSD is used alongside a large data drive or RAID of data drives. Even then the encrypted volume is normally made atop the RAID. Assuming RAID 0 the loss of one drive stil destroys the data either way. Loss of the LUKS header (to a corrupted sector etc) also destroys the data, so when using encryption backups (also encrypted) become more important.

There should be little performance difference, as the current default XTS cipher supports multithreading, thus one disk vs separate encrypted disks should have little effect on parallalism. If the server supports AES-NI, there will be be little overhead from encryption anyway on that machine.

BTW, an encrypted server which falls into the hands of an adversary while powered on and running is vulnerable to "cold boot" attacks where the RAM is cooled with freon, then the machine hurredly powered down and rebooted on a forensic disk so the disk key (not the passphrase) can be recovered directly from the RAM. Thus you need to ensure that the server is forcibly powered off if enemies appear. For a server that is only run when the building is occupied, where burglars or are your main concern that is little problem.

For an unattended server some kind of unauthorized entry trap that cuts the power in the event of unauthorized access would pre-empt the cold boot attack, especially if it is a surprise and even more so if the encryption is also a surprise. This kill switch must be between any UPS and the server of course.

If covert access (say by bribed staffers) is an issue you need to worry about keyloggers. The "evil maid" attack isn't what you'd see, a hardware keylogger is. It is trivial to pay off a staffer to plug a USB keyboard into a USB keyloggger, then plug that back into the box, so always check for such things. Also never, ever use wireless keyboards with encryption.

[suberimakuri]

Luke, et al.
Would you mind confirming best option please?
I have two computers and would like to move to encryption. Both running debian sid/unstable.

Have found this article regarding LUKS and LVM on debian. It mentions just /home and /var but I would do everything including swap.
http://www.tecmint.com/install-debia...-partitions/3/


Laptop,
Easy, run LUKS on disk and LVM. (Currently no LVM)

Server/HTPC,
This is currently 3 drives, 1 SSD and 2x2TB 7200rpm RAID1 drives. The RAID1 drives hold 3 partitions: /, swap, and a main data partition for my stuff.
Which order do I do things?
MDADM raid first, then LUKS, then LVM?
Just do one big RAID1 for full size of both drives right? Later use LVM to to partition out / swap data?

Appreciate input, cheers~

[Pander]

Does anyone knkw what the performance of this test is on Ububtu 15.10 with latest upgrades? Has much changed?

[movieman]

I'm not sure how Ubuntu handles swap when the "encrypted user's home directory" is selected. I generally set up encryption manually onto pre-prepared encrypted partitions.

If you enable ecryptfs, it also encrypts the swap partition automatically. Or does on the version on my netbook.

There was definitely a big performance hit with the original Ubuntu install on that machine (benchmarked around 12MB/s after encrypting, AFAIR), but that was before some optimizations which reduced the number of encryptions and decryptions the kernel performed.

[Luke]

Password entry from GRUB transfers trust to BIOS/UEFI

Basically the unencrypted /boot partition is itself an attack vector for evil maid attacks, you could use a grub partition or use grub from EFI partition to avoid that. It does not fix the possibilty of EFI rootkits or modfied grub loaders however but changeing the initrd to store the pw after entering it is very easy. As example how to boot that way look at
http://kanotix.com/files/fix/crypto/
It is possible to store the pw on the encrypted part but thats optional. If you don't it works as well but you enter the pw twice. If you install with /boot or /boot/efi partition in custom mode while using luks you get the same as Ubuntu with the new installer. I would test it in a VM first...
http://nightly.kanotix.acritox.com/latest/

The value of this depends on the kind of attack you expect. It reduces the danger of an evil maid attack, but increases the danger from a pre-existing malicious BIOS. Assume an attacker who does not already know your computer expects you to be using Windows. With Truecrypt using the BIOS/UEFI keyboard driver during bootloader to unlock the disk, the author of a malicious BIOS might not bother with adding code to keep the keyboard driver running and logging after the kernel takes over keyboard entry. In a UEFI machine he might not bother to prevent ExitBootServices from functioning due to added work and detectability. In DM-crypt/LUKS, if the firmware keyboard driver is not running, a simplest-code bug in it will miss the passphrase entirely because unlike in Truecrypt the full Linux kernel loads first and takes over the keyboard driver function.

Of course, if someone with no access to the machine before you got it is the only possible attacker, this situation changes. For encryption against state-level attackers the BIOS is not trusted, against a thief in a hotel room after credit card numbers it may well be, barring a thief that can visit once to identify your board, again to reflash your BIOS, and a third time to harvest the machine and all it's data. A hardware keylogger is easier than this, even in a laptop. If you suspect that kind of danger, epoxy the keyboard down on laptops, nobody can cut the glue without leaving obvious marks.