Disk encryption with LUKS

So, as I mentioned in my previous post, my next task was to set up a virtual machine with KVM, the Linux hypervisor, and libvirt, a virtualization API, and add an encrypted disk to it. This I achieved yesterday with the LUKS encryption mechanism supported by libvirt.

But enough with throwing around ominous acronyms, what I did was fairly simple. As I said, KVM is a Linux hypervisor, which basically means it supervises the virtual machines you have running on your Linux system. To create or edit a VM, you can use libvirt, an API that registers components (like disks or networks) with KVM and also creates virtual machines according to settings provided by the user and hands them over to KVM. Basically, it acts as a bridge between KVM and the user. To tell libvirt what you want, it is easiest to write an XML-file as a sort of “recipe” for the new virtual component. For example, if you were to create a new virtual disk, it could look like this:

        luksvol.img
        500
        
                /guest_images/luksvol.img
		
		
			
		
        

With this XML-file, you tell libvirt that your new virtual disk shall be named luksvol.img and have a capacity of 500MB. In your host system, it is located at /guest_images/luksvol.img. The field encryption is what is most important for my project: It says to use encryption format LUKS and specifies the properties of the encryption.

LUKS is short for Linux Unified Key Setup: it was invented to standardize hard disk encryption in Linux. As you might know, there is a lot of encryption algorithms and before LUKS, every algorithm hat their own tool with their own commands and you needed a different tool to take care of your key management. Just like when you have different e-mail-addresses with different e-mail providers, and on one web portal the logout button is on the right, on the other one on the left. LUKS is the Mozilla Thunderbird for encryption of hard disks. It lets you select the disks you want to encrypt, and specify the encryption algorithm it should use to do so. It takes care of the key management and regardless of the algorithm you are using, the commands to encrypt a hard disk are always the same.

But what does key management mean? To encrypt a message (and a hard disk is nothing more than a potentially very long message), you need a (master) key. If you are not sure how that would work, have a look at the Vernam cipher. But as I’m sure you are all aware, you should change your passwords frequently. If you do so with this key, the whole message would have to be encrypted all over again, which would take considerably long for a long message. This is why LUKS makes you define a user key which then in turn encrypts the master key generated by the system. The master key is used to encrypt the hard disk. When you change the user key, only the master key has to be re-encrypted, but the hard disk stays the same. This is called a two-level key hierarchy.

LUKS also takes a few measurements for increased security. While I don’t want to go into detail here, all those measurements follow the same principle: Make the attacker’s life hard. There is no practical way to set the unbreakable password, but there are many ways to slow down the password’s calculation on the attacker’s side, so LUKS makes sure an attacker has to go through many CPU-intensive operations to find the right password. That doesn’t make breaking the encryption impossible, but unlikely.

That’s it for now, next up is some benchmarking on this setup. I’m very excited for that since it is something I have never done!