Securing your disk with Luks disk encryption

The other day talking about security topics, we agreed that most of the times the problem is not loosing a laptop / disk, the problem is loosing the data and have someone accessing it.

I decided to encrypt my home folder - I'm not fancy to re install my debian, and anyway my home folder is the only one with security risks. First, install the package:


# apt-get install cryptsetup

This will install what we need to use LUKS, also will update the initrd modules to load dm-crypt and dm-mod (needed to use LUKS).

After that backup my /home partition to somewhere else. Later I will unmount my home folder partition (/dev/sda7). To increase security, I will mess it up with some random data so will be more difficult to crack:

# badblocks -c 10240 -s -w -t random -v /dev/sda7
Checking for bad blocks in read-write mode
From block 0 to 97655807
Testing with random pattern:   3.72% done, 0:38 elapsed. (0/0/0 errors)
...
Reading and comparing:  43.18% done, 24:21 elapsed. (0/0/0 errors)
...
Pass completed, 0 bad blocks found. (0/0/0 errors)

Now is time to encrypt the device, making sure the password is secure enough and yet difficult to forget:

# cryptsetup --verbose --verify-passphrase luksFormat /dev/sda7

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

Are you sure? (Type uppercase yes): YES      
Enter LUKS passphrase: 
Verify passphrase: 
Command successful.

Done. Now we will open the device under the name of "home":

# cryptsetup luksOpen /dev/sda7 home
Enter passphrase for /dev/sda7:

A new symbolik link will appear in the folder /dev/mapper:

# ls -l /dev/mapper/home
lrwxrwxrwx 1 root root 7 Mar 20 09:54 /dev/mapper/home -> ../dm-0

Now we can verify the status of our disk:

# cryptsetup -v status home
/dev/mapper/home is active.
  type:    LUKS1
  cipher:  aes-cbc-essiv:sha256
  keysize: 256 bits
  device:  /dev/sda7
  offset:  4096 sectors
  size:    195307520 sectors
  mode:    read/write
Command successful.

We will create a ext3 filesystem on it. With journal option (-j), reserve 1% of the disk for if we run out of space (-m 1) and several standard options (-O ....):

mkfs.ext3 -j -m 1 -O dir_index,filetype,sparse_super /dev/mapper/home 
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
6111232 inodes, 24413440 blocks
244134 blocks (1.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
746 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

We need to add not the device to /etc/crypttab. Syntax is <device name> <block device> <keyfile (deprecated, specify none)><options - I put just luks, other options available on manpage>

# cat /etc/crypttab 
# <target name> <source device>         <key file>      <options>
home    /dev/sda7 none luks

Then update our fstab to indicate the system to mount the mapper device, and comment the previous entry:

# cat /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
[...]
#UUID=ef7a9c67-aa6a-48e8-ab7f-ea58cb9f856d /home           xfs     defaults        0       2
/dev/mapper/home                        /home           ext3     defaults        1       2
[...]

And we are done to reboot. The system will ask for the password on boot time, so we will need to write it in order to get our /home partition mounted. It is a good moment to copy all our files back to that partition, and afterwards close the access until next reboot with this command:

# cryptsetup luksClose home

The script /etc/init.d/cryptmount-early will ask you the password on boot time, so bear in mind that you will definitely mess the remote reboot.