Note: this wiki is no longer maintained. If you have any questions related to this wiki, please post them on the CrunchBang forums.
This deals with securing your data in case your hardware falls in mallicious hands. I want to feel safe that if my Netbook goes missing, my personal files stay personal.
Hint: Save this page to a usb drive, for easy reading during the live install.
Always backup your data when working with your partitions. Accidents do happen. You can use rsync: http://crunchbanglinux.org/wiki/howto/ssh_rsync_backup or dd: http://www.linuxquestions.org/questions/linux-newbie-8/learn-the-dd-command-362506/
I like dd, as you can backup a whole drive, or just a partition, byte-for-byte, including the boot loader and all.
- If you forget the encryption password, your data stays encrypted, and even you won't get to it. It's a good idea to remember your password!
- This boot-time password is not your user account password, but for the purpose of ease-of-use, I will be using the same password for my encrypted /home, as my user account.
- If you ever change your user password, the boot-time password will stay the same. You can't change the luks password either, however you can recreate the luks device with a new password, and move your data across.
- When working with the luks (encrypted) volume, we call it by name. I chose to use 'vault', as it doesn't conflict with any other names and it makes it pretty clear what the volume for.
We use ecryptfs to setup an encrypted swap. It uses the same method as our encrypted home, but the process is done automagically via a setup script.
sudo apt-get install ecryptfs-utils
run the setup
That's it! It creates a /dev/mapper/cryptswap luks entry in /etc/crypttab, it uses random data each boot to encrypt instead of a passphrase.
Note this does break hibernation (RAM written to swap doesn't work), however suspend will still work as that doesn't write RAM to disk.
Reboot and verify your new encrypted swap with
:~$ swapon -s Filename Type Size Used Priority /dev/dm-1 partition 3583992 0 -1
Existing installation users please read this phase.
You must know the new /home will need it's own partition. If you have a seperate /home partition then just re-use it (backup first!). If you don't have seperate /home, you may need to repartition and/or reinstall.
Boot the live USB and start the installation process. Partition your drive based off the basic structure below: /, swap, and /home. But _don't_ map /home to any mount points. We will do this manually afterwards, just reserve that space in a partition for now.
sda1 = / (10 GiB) sda2 = swap (2 GiB) sda3 = none (140 GiB) ←- this is our future encrypted /home
* Write your partition paths on paper like so: ROOT /dev/sdaX SWAP /dev/sdaY HOME /dev/sdaZ
(of course you will replace X/Y/Z with your own numbers)
I will refer to them as /dev/ROOT and /dev/HOME, you will then know to replace them with your own values. Finish the install and reboot into your new OS.
* You are now logged into your new install, with a fresh user profile, and a fresh cup of coffee big_smile
become root for a while (PLEASE double check your commands)
apt-get install cryptsetup
load the device mapper kernel module
setup a new encrypted container on /dev/HOME
cryptsetup luksFormat /dev/HOME -c aes -s 256 -h sha256
The passphrase it prompts is for the boot-time decryption of /home.
open the luks container under the name of 'vault'
cryptsetup luksOpen /dev/HOME vault
/dev/mapper/vault now points to our luks container. Format it as ext4 (you may format to any other file system type you prefer)
mke2fs -t ext4 -j /dev/mapper/vault -L vault
(The '-L vault' option simply labels the fs as such)
mount the formatted container to /mnt/vault/
mkdir /mnt/vault && mount /dev/mapper/vault /mnt/vault
lets see the mount contents
Great it worked!
Now we copy our backup/home files across. If you don't have a backup (a brand new first time installer) then you would copy from /home.
NOTE /mnt/vault must contain your user profile starting with the $USER/ directory, not /home. Thus you want to see a structure like: /mnt/vault/kbmonkey (and not /mnt/vault/home/kbmonkey). *This is important*
Ensure this by adding a trailing slash to our rsync source, '/home/' and not just '/home'.
# For new profiles without backed-up files:
rsync -a /home/ /mnt/vault
# For users with backed-up files:
rsync -a /mnt/your-backup-device/ /mnt/vault
-a is archive mode, it preserves file ownership and other options.
See the copied files
ls -l /mnt/vault/
drwxr-xr-x 33 kbmonkey kbmonkey 4096 Jan 16 20:22 kbmonkey
That's what we want to see: our user profile directory in /mnt/vault.
Edit /etc/fstab to point /home to /dev/mapper/vault
# <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/vault /home ext4 rw,errors=remount-ro 0 0
Add a line to /etc/crypttab to make the boot process aware that it must decrypt the luks container (replace /dev/HOME)
# <target name> <source device> <key file> <options> vault /dev/HOME none luks
sync disks, unmount and close the encrypted container
sync && umount /mnt/vault
cryptsetup luksClose /dev/mapper/vault
To ensure we work with the correct /home, let us create an empty file called 'old-home' in the current profile. It will help us differenciate the current user profile from the soon-to-be encrypted profile.
We now have two copies of our user files: one in /dev/ROOT (old-home) and one in /dev/HOME (encrypted). Now let us move the current /home files out of the way, so that the encrypted /home can take it's place. Reboot with the live CD/USB - I will wait here until you get back to PHASE 3 …
(Continued in Live environment …)
enter a root console
mkdir /mnt/disk && mount /dev/ROOT /mnt/disk/
ls /mnt/disk/home/USER you will see the file 'old-home', an indication this is our old profile files.
move old home out of the way
mv /mnt/disk/home/ /mnt/disk/home_old
recreate the /home directory (needed by fstab) and unmount
mkdir /mnt/disk/home && umount /mnt/disk
On boot you are prompted for a password before you get to the gdm login. This will decrypt the /home partition.
You will then be greeted by the gdm login. All that's left is to setup auto login, so that we only enter the one password (to decrypt our /home), and it boots us straight into our user profile.
# Verify our mounted luks device:
:~$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 9.7G 2.0G 7.2G 22% / /dev/mapper/vault 136G 234M 129G 1% /home
Fantastic! /home is mounted to /dev/mapper/vault, which is our encrypted partition on /dev/HOME smile
We can also check with cryptsetup status:
sudo cryptsetup status vault
<code>/dev/mapper/vault is active: cipher: aes-cbc-plain keysize: 256 bits device: /dev/sda3 offset: 2056 sectors size: 287999992 sectors mode: read/write</code>
The tricky part: Automatic Login
I use Openbox, for me I do: [Super + Space] → System → GDM Login Setup
Security tab: I check 'Enable Automatic Login' and choose myself as the user.
Remember that all our files and settings under /home are still encrypted, so you won't even get to the desktop without your password.
So let's reboot and try it out…
You will notice your keyring (if set to auto-login) won't work anymore. That's because automatic login disables the automatic keyring functionality. It's a well designed security measure, but in this case I want both automatic login, and no keyring prompt. (Both are already covered by our encrypted /home).
The only way to stop the keyring from asking for a password, so far as I know, is to use a blank password for your keyring. To remove my current keyring data, I delete the login.keyring file - This will clear all saved keyring passwords. You don't have to use a blank keyring password, if you don't want, but if you do:
Log out/in, enter any network/wireless creds, if the keyring asks you to enter a new password, use a blank one. It will warn you that it is unsafe, and accept.
That is pretty much it. Hang on to /home_old for a few days, and delete it when you are happy everything is running.
For the novelty, here's an idea of what it might take someone to decrypt your data without your passphrase:
“Imagine a computer that is the size of a grain of sand that can test keys against some encrypted data. Also imagine that it can test a key in the amount of time it takes light to cross it. Then consider a cluster of these computers, so many that if you covered the earth with them, they would cover the whole planet to the height of 1 meter. The cluster of computers would crack a 128-bit key on average in 1,000 years.”
That is for a 128-bit key. We use 256-bit for our /home.