Encrypting the backups

Tags: encryption

As of the time of writing, the website still looks crumby. But there has been progress! You just can't enjoy it yet.

Considering I implemented the strictest level of encryption on my website before I even built a way for users to submit data, I obviously care about security. In fact, I probably approach security in way that could be construed as paranoia, but that's just because I think such an approach offers the greatest about of fun.

Anyway, my latest addition to the website has been a custom user model which will eventually facilitate the ability for users to order prints of my photographs if they so choose. Unfortunately, this created some dependency issues when I attempted to apply the Django migrations to all the tables that had been built using the default wagtail user model. So rather than mess around editing the migration files for hours and probably just ruining things further, it probably makes more sense to just drop the database entirely and rebuild it from scratch using the custom user model. But wait! Then I'd lose all three of these masterfully crafted blog posts. Time for backups.

My fancy new workstation has a separate 1 TB HDD that would be ideal for such a backup. But all that fancy-shmancy web encryption would be wasted if I backed up all the data to an unencrypted drive. Which brings us to the exciting world of:

Full Disk Encryption!

Step one of course is to fire up gparted and delete the existing partitions. Then we create a new partition which uses up the whole drive, but we leave the filesystem unformatted. We'll do that ourselves by following a guide such as this. We also want to zero out the drive before the encryption part so you'll probably want to confirm the location of the disk and partition with something like:

fdisk -l

And throw something like this at it, where you replace sda1 with whichever disk partition you happen to be targeting:

sudo dd if=/dev/zero of=/dev/sda1 bs=1M

You'll want to be extra careful when using a command like dd since a typo there could result in irreversible loss of data if you target the wrong disk or partition. So at this point if you haven't ruined your computer by mistyping the above command and you're zeroing out a large disk like my 1 TB HDD, you can go out and play with your friends because it will take about forever for the command to complete. Just be patient and don't worry about how it seems to hang, dd just doesn't output any info to describe its progress.

If you've been patient enough to wait for forever, you're now ready to actually start doing the encryption stuff, like so:

sudo cryptsetup luksFormat /dev/sda1

You'll want to make sure you're using latest version of cryptsetup before running this command, since we're using all the defaults here which will offer plenty of security as long as your using version 1.6.0+. If you're interested, you can read a bit more about the tool here. Once you run the command, you'll be prompted to supply a password that will be used to unlock the disk. The encryption won't be worth much if you use a weak password, but you'll also need to make sure you don't lose it as there will be no way to recover the data on the disk if you misplace the password. As such, this might be a good time to start using a password manager like Keeper which makes it easy to create and use complicated passwords without having to worry about forgetting them later.

Now we need to mount and unlock the drive:

sudo cryptsetup luksOpen /dev/sda1 encrypted-hdd

This lets us give the drive a filesystem:

sudo mke2fs /dev/mapper/encrypted-hdd

And finally we want to transfer ownership of the drive to our unprivileged user so that user can actually write to the disk. It will look something like this, where the username in my case is ave:

sudo chown -R ave /media/ave/ae722e82-1476-4374-acd8-a8a18ef8ae7a

You can check where your disk is mounted using:

df -h