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.