wiki:luks

LUKS

LUKS is the modern linux standard for encrypted block devices. It's a good, simple way to encrypt any data that needs to be written to disk

background

The idea behind LUKS starts with the fact that a given disk (or partition) is treated by the computer a block device.

Normally, you'd put a filesystem directly onto the block device. With LUKS, there is a short header at the start of the block device that contains a well-scrambled secret key and a set of 1 or more scrambled passphrases.

When you want to use a LUKS-formatted volume, the computer you're using asks you for a passphrase (or a passphrase file). It uses that passphrase with one of the scrambled passphrases to unscramble the secret key. The key is then used to unscramble sections of the underlying block device as they are requested by the OS. This is represented as a new virtual block device available to the system. A regular filesystem can be written to the virtual block device, and the actual data stored on disk will be encrypted.

how to use LUKS

on debian systems, to put a layer of encryption over /dev/sda1, running an ext3 filesystem, it would look something like this:

0 root@lemur:~# aptitude install cryptsetup
0 root@lemur:~# cryptsetup luksFormat /dev/sda1 

WARNING!
========
This will overwrite data on /dev/sda1 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase: 
Verify passphrase: 
Command successful.
0 root@lemur:~# cryptsetup luksOpen /dev/sda1 mynewdisk
Enter LUKS passphrase: 
key slot 0 unlocked.
Command successful.
0 root@lemur:~# mkfs -t ext3 -q /dev/mapper/mynewdisk
0 root@lemur:~# mount /dev/mapper/mynewdisk /mnt
0 root@lemur:~# 

When you're done with the disk, you unmount it and release the encryption:

0 root@lemur:~# umount /dev/mapper/mynewdisk
0 root@lemur:~# cryptsetup luksClose mynewdisk
0 root@lemur:~# 

If you want regular access to an encrypted block device (might not make sense for a portable drive, for example), you can add entries in /etc/crypttab to prompt for keys at boot time. Note that if you do this, you need to be at the computer (or have remote console access) when it boots, or it will wait forever for you to get to the console and put in the keys!

advantages of LUKS

encrypting at the block device layer means that you can put whatever type of filesystem you want on the virtual block device it exports, and the filesystem code doesn't need to know anything about encryption.

the LUKS header contains information about what kind of key is used, and what cipher (method of block-device encryption) is used (there are several different standards). By including that information in the header, if the "default choice" of key type or cipher changes in the future, you'll still be able to access your old volumes.

Having a set of key slots allows you to give different people the right to decrypt the volume, without asking them to share a passphrase. More importantly, it also allows you to change the passphrase without having to rewrite the entire disk

disadvantages of LUKS

It seems like having key type/size and cipher info in the LUKS header would reduce the search space for any attacker trying to recover data from the device, because they only need to search within one algorithmic scheme.

cryptsetup (a common GNU/Linux userspace tool for managing LUKS volumes) also somehow knows when your passphrase is wrong. I'm not sure how that works, but if it knows that it's wrong, presumably an attacker can determine the same thing. So all the attacker needs to break is your passphrase directly. This is probably no worse than other schemes, and isn't a very well-thought-out objection.

having a LUKS header at all is an indication to an attacker that you've got an encrypted volume in the first place. Something that looks like totally random data might be more secure in really paranoid situations.

Once an encrypted block device is "LuksOpen"ed on a computer, any process running as superuser on that computer has access to all the unencrypted data. If you want individual files to be opaque to the system administrator, you probably should encrypt those files individually somewhere else before transferring the encrypted version to the computer in question.

Last modified 10 years ago Last modified on Nov 15, 2007, 4:04:15 PM