Automatically Mounting Secondary Encrypted Disk/Partition at Boot

There are a wide variety of use-cases for disk encryption, and the idea of automatically mounting an encrypted disk/partition without user intervention is an anathema to many of those - anyone who can take physical possession of your system will have the disk auto-mount for them.

However, there is a very simple use-case which benefits from being able to automount a second encrypted disk.

If you're storing data unencrypted on a drive and it fails, you're now potentially left with something of an issue, particularly if you intend to RMA it (return it under warranty) - could the drive be fixed, allowing someone else to pull that data off the drive (bearing in mind the manufacturer may fix the drive and sell as refurbished)?

Similarly, when you need to expand your storage, you hit a similar conundrum - do you trust disk wipes sufficiently to be willing to sell/pass the disk on (a particular concern with SSDs where data may previously have been written to a now bad block, so won't be overwritten by your wipe), or do you feel you have to physically destroy the disk, un-necessarily generating e-waste.

Using Full Disk Encryption (FDE) addresses both of these situations - the manufacturer might fix the disk, but without the key the data's just random bytes, similarly, for whoever buys your disk off ebay.

But, FDE can quickly become a major inconvenience at boot - your system will stop booting and ask you to provide the decryption passphrase. That's particularly problematic if you're talking about a headless system like a NAS, where you want things to come up working following a power cycle.

It's possible (trivial even) to configure so that the system uses a key stored on another disk (like your root filesystem, or if you prefer, a USB flash drive) so that the partition is automagically mounted.

This documentation details how to set up ecryptfs on a disk (or partition) and add it to /etc/fstab so that it automatically mounts at boot

All commands are run as root, so use sudo -i/su

 

 

Why Ecryptfs

When I was first setting this up, I had to make a decision on the encryption mechanism to use. Do I use ecryptfs or something like luks?

Although the difference is (largely) transparent to the user, LUKS encryption applies to the entire block device, whilst ecryptfs is applied to the files individually. So, in essence, the difference is encrypting one 2TB blob vs lots of small files.

I went for the small file approach on the (possible erroneous) basis that a few bad blocks/sectors were more likely to render everything inaccessible on LUKS. With ecryptfs you may lose whatever files are on those blocks, but shouldn't lose everything.

 

Setting up encryption

In this documentation, I'm going to apply to a partition, if you've not partitioned your drive then just run the commands against the block device instead.

Install ecryptfs if not already present

apt-get install ecryptfs-utils

Put a filesystem on the device and create a mount point for the ciphertext version

mkfs.ext3 /dev/sdc1
mkdir /mnt/encrypted
mount /dev/sdc1 /mnt/encrypted

Then create a mountpoint for the decrypted version and trigger the initial encryption

mkdir /mnt/decrypted
mount -t ecryptfs /mnt/encrypted /mnt/decrypted

You'll be asked to provide a passphrase - make it a strong one (you can use gen_passwd for this if you don't already have a chosen generator). Make a note of the password somewhere safe (as you'll need this to recover files if your main disk ever fails)

You'll also be asked to select various options relating to the encryption mechanism:

Passphrase: 
Select cipher: 
1) aes: blocksize = 16; min keysize = 16; max keysize = 32
2) blowfish: blocksize = 8; min keysize = 16; max keysize = 56
3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24
4) twofish: blocksize = 16; min keysize = 16; max keysize = 32
5) cast6: blocksize = 16; min keysize = 16; max keysize = 32
6) cast5: blocksize = 8; min keysize = 5; max keysize = 16
Selection [aes]:  
Select key bytes: 
1) 16
2) 32
3) 24
Selection [16]: 32
Enable plaintext passthrough (y/n) [n]: n
Enable filename encryption (y/n) [n]: n

Once you've made your selections, a block of information will be dumped out - keep a note of this

Attempting to mount with the following options:
ecryptfs_unlink_sigs
ecryptfs_key_bytes=32
ecryptfs_cipher=aes
ecryptfs_sig=2f78095989f63c55

You'll then be prompted to confirm whether you want to proceed

WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key 
before. This could mean that you have typed your 
passphrase wrong.

Would you like to proceed with the mount (yes/no)? : yes
Would you like to append sig [2f78095989f63c55] to
[/root/.ecryptfs/sig-cache.txt] 
in order to avoid this warning in the future (yes/no)? : yes
Successfully appended new sig to user sig cache file

Your partition should now be mounted. If you write a file into the decrypted partition:

echo "hello world" > /mnt/decrypted/hello.txt

It should also appear in /mnt/encrypted but will be an encrypted binary blob

 

Automating the mount

We've got our encrypted filesystem set up, but it won't currently mount at boot. There are a few bits we need to do before we can put it into fstab.

First, we need to create a keyfile. I'm going to put it into root's home directory - if you're planning on using a USB flash drive, you should put it there instead

Write the encryption passphrase into the keyfile

echo passphrase_passwd=abcdef12345678 > /root/.extra_hd.key

Next we need to generate config to tell ecryptfs where to find the key, and which volume to use it for. This is where we need the output we saved before - specifically ecryptfs_cipher, ecryptfs_key_bytes and ecryptfs_sig.

cat EOM | tee -a /root/.ecryptfsrc
key=passphrase:passphrase_passwd_file=/root/.extra_hd.key
ecryptfs_sig=2f78095989f63c55
ecryptfs_cipher=aes
ecryptfs_key_bytes=32
ecryptfs_passthrough=n
ecryptfs_enable_filename_crypto=n
EOM

 

Add to fstab

Now we can look at adding the mounts to /etc/fstab. We need mounts to be listed in a specific order

• Filesystem containing the key (root in my case, maybe a USB flash drive in your case)
• Encrypted volume
• Decrypted overlay

I tend to use UUID's in fstab, so get the UUID for the partition with lsblk -f

vi /etc/fstab
UUID=de719924-72d7-4c8b-ab38-d00e489a9eea	/mnt/encrypted	ext3	rw,user,nofail
/mnt/encrypted /mnt/decrypted ecryptfs defaults,nofail 0 0

Then to verify it all actually works, unmount and then remount

umount /mnt/decrypted
umount /mnt/encrypted
mount -a

Assuming that all worked, your next test is a reboot

reboot

---

Conclusion

There are valid reasons for wanting to use FDE in a way that's convenient, despite it providing no protection against someone who's got the advantage of proximity to your machine.

Unfortunately, many responses to posts on things like StackOverflow prioritise this trade-off above all else, so despite being asbsolutely trivial to set up, it's something that many users won't have done - leaving a plethora of disks out there with no encryption, the worst of both worlds.

The steps though, are absolutely trivial and allow you to operate a system where you don't have to worry about whether a RMA or HD upgrade means sending your data out into the world.