56

I'm running 13.10 Saucy. If I didn't enable disk encryption during installation, is there any way to enable it post facto?

I found this, which says that encryption has to happen at install time, but it's also referring to Fedora. I can easily boot into a live disk if there's any way to do it from there.

  • Full disc encryption or just your /home folder? – Joren Oct 27 '13 at 14:36
  • Full disk. (Follow up question: what are up and downsides of full disk vs. just /home? :)) – Isaac Dontje Lindell Oct 27 '13 at 16:27
  • /home disk encryption does not include swap space. Sensitive data may be written to unencrypted swap, if only /home is encrypted. This can be recovered. Ubuntu has automatic decryption of /home during logon. Full disk encryption needs a password at both boot and login. Resizing an encrypted drive is a painstaking process. If you have an external drive, it is easy to encrypt after installation in 13.10 Saucy Salamander: back up your data, launch "disks" from the dashboard, select your external drive, click on the cog, select encrypt, unlock your newly encrypted drive, copy back the data. – user75798 Nov 1 '13 at 17:43
47
+50

If you want to enable encryption of your home folder you will need to install and use these packages: ecryptfs-utils and cryptsetup. Also you will need another user account with administrator (sudo) privileges. The full documentation is here:

If you want to enable full disk encryption after installation, the short answer for now is probably: no, you can't. Anyway, if you are interested about this, your question is duplicate of:

  • 7
    Please include at least the basics steps of your linked howto here. Just in case your link goes offline, changes or is temporary unreachable. – con-f-use Nov 6 '13 at 21:53
  • 1
    @con-f-use If you read carefully (without confusion),the very basics steps are included in the answer. – Radu Rădeanu Mar 21 '14 at 16:04
  • 1
    What happens if you have a samba share in your home folder that is encrypted? Can network users not read the files any more or are they decrypted over the share? – Rush Frisby Mar 3 '15 at 18:54
18

Follow up question: what are up and downsides of full disk vs. just /home?

Encryption in /home is done using a user space filesystem called ecryptfs. It is very well done and tightly knitted into the default auth system so that you'll have zero usability drawbacks: when you enter your account(either from a remote shell or from the default login screen) your password is used to unwrap a secure key, which is then used to encrypt/decrypt your files in your home directory on the fly(The mounted filesystem will reside directly in /home/username). When you log out /home/username is unmounted and only the encrypted files remain visible in the system (usually in /home/.ecryptfs/username/.Private/). They look like a bunch of scrabbled/random files since filenames are encrypted as well. The only information leak is: filesize, timestamps and number of files (with full disk encryption these are hidden as well).

If your system is to be shared between multiple users, this is a very nice feature to have even if you decide to add full disk encryption along with this: the safety of Full disk encryption is off when the machine is up and running while home(ecryptfs) encryption is On as long as you're logged out.

So, full disk encryption and home encryption are not necessarily mutually exclusive.

Here's a list of possible set-ups, depending on different security needs:

  • FULL DISK ENCRYPTION ONLY: If you're the only one using your computer and your machine can handle the overhead of full disk encryption (all modern desktops can do that without the user noticing, netbooks and old laptops not so much) you can use full disk encryption and put home in the same partition as your OS(/).
  • FULL DISK ENCRYPTION AND HOME ECRYPTFS ENCRYPTION: If you're worried about your private data being read while your pc is on or you share your computer with other users, then you could have home in a different partition from / and use ecryptfs along full disk encryption(that is encryption of / through LUKS)
  • HOME ECRYPTFS ENCRYPTION ONLY: If you're not too worried about someone tampering your system while you're away but you still like to keep your private data safe then skip the full disk ecryption and just use ecryptfs (encryption of home). An added bonus of this scenario is that this is quite easy to set up even after you've installed Ubuntu, by just using ecryptfs-migrate-home. Also this has been the default Ubuntu setup before it changed a few releases back, adding the possibility of full disk encryption. Since most modern desktops can handle full disk encryption without a sweat and it adds a thin layer of security against off-line code injection, full disk encryption was added into the installer. Notice though that for most users just encrypting their home with ecryptfs will be enough for their needs: keeping their friends and the common laptop thieves off their private data. Besides, if you've been singularly targeted by an organization with the right means, having full disk encryption or just home encryption will not make much of a difference unless you've also established a lot of other paranoid behaviours(like: keeping the kernel in a separate pen-drive which is always on you; constantly checking for hardware tampering/keyloggers and so on)

If I didn't enable disk encryption during installation, is there any way to enable it post facto?

Yes and it's going to be easier if you're currently using LVM and have enough space on your system to copy all of your unencrypted system files into an encrypted LUKS partition. I'm not going into the details at the moment because I don't know if you're using LVM and if you'd rather not just use ecrypfs for now and skip the hassle of full disk encryption until the next fresh install.

2

Well, you could make a backup of all the important directories and installed software. Make sure your 13.10 is fully updated to avoid version conflicts. Usually the things do back up would be:

After that you reinstall the system only now encrypted. Update it to the full extend. Then move the backup to the encrypted system and install all the software from the previous version.

Just be sure not to overwrite files important to the encryption, when putting back the back up (e.g. /etc/fstab, /etc/cryptab, some grub related stuff and some stuff in /boot should not be replaced with the backed up files).

0

Simple answer: No.

Complicated answer:

Encrypting a disk or partition will erase everything currently on that disk or partition, so to encrypt a disk you also should remove the contents of the disk. You should make appropriate data backups prior to starting. Obviously, this means that you should reinstall the system to use full disk encryption, no other way around. This is because random data will be written over the entire disk to make more difficult the recovering of the data.

But, nowadays you don't need to encrypt your root partition. Remember that if something goes wire you are out of your system without possibilities to recover the data. You should consider only encrypt your personal information instead.

See related question How to encrypt full disk after installing?

  • "Are out of your system without possibilities to recover the data" <--- That is incorrect. As long as one has the encryption key, the data can be recovered with a Live Medium. – con-f-use Nov 2 '13 at 16:26
  • @con-f-use take into account that there was a conditional "if something goes wire" meaning that if something incredibly bad happens to the drive/partition that it's encrypted. – Braiam Nov 2 '13 at 16:34
  • Well yes if you are nitpicky, one should also maintain a recent backup of the LUKS header on the encrypted disk. But I'd include that in "encryption key". Other than that there is no harm in full encryption from the data-recovery point of view. However, the fact that you can tell which version of Ubuntu is on there, what programs are installed and so on provides a possible attack vector on not fully encrypted disks. Also SSDs generally do. So for the paranoid there is still no way around full disk encryption. – con-f-use Nov 2 '13 at 16:45
  • "But, nowadays you don't need to encrypt your root partition." Please speak for yourself, I completely disagree. "Encrypting a disk or partition will erase everything currently on that disk or partition, so to encrypt a disk you also should remove the contents of the disk." Again, disagree. Truecrypt is a very nice example of doing FDE on Windows with existing disks. In fact, it is the de facto method of installing - unencrypted, and once done, encrypt it. It doesn't change the answer in that it isn't possible atm on Ubuntu, but your statements are very categoric, and incorrect. – Cookie Mar 21 '14 at 14:04
  • @Cookie why would you encrypt a partition that has stuff you can install later? (and please, I'm talking about run-of-the-mill user system, nothing to do with corporate/enterprise servers that might have stuff installed in it) 2) what you are talking about is a feature of truecrypt only available to Windows up to the date and if you can't find a Linux encryption system that can encrypt a partition after installation, my statement are correct since right now it's not possible. – Braiam Mar 21 '14 at 14:22
0

From a working Ubuntu 16.04, I succeeded in post-installation root partition encryption, with the root partition containing everything except /boot. I put /boot on a separate removable usb. Notably I did this before upgrading to Ubuntu 18, and the upgrade worked fine on the encrypted disk version.

The encryption was not done "in place", which was fine with me because I didn't want to overwrite the working version until the new setup was working, anyway.

Performing the correct procedure is extremely simple and fast. (Although figuring out the correct procedure was extremely time consuming because I followed some false leads.)

OUTLINE

  1. Create a live linux USB disk - it is convenient to have persistence enabled. Boot in on that live USB disk.
  2. Create a luks encrypted volume group on an empty partition. (In my case it was on the same disk as the original linux, but it could be another disk.) Create / (root) and swap logical volumes on that encrypted partition. These will act as virtual partitions as far as the copied linux is concerned.
  3. Copy the files from the old root to the new root.
  4. Set up and partition another USB to act as the removable boot disk.
  5. Set up some files in the new root, do some magic, and chroot into the new root and then install grub onto the boot disk from the chroot'd new root environment.

DETAILS

1 - Boot with a live linux USB disk - it is convenient to have persistence enabled.

Installed Ubuntu 16 on a usb with unetbootin. The GUI allow "persistence" to be specified, but another step is also required to get the persistence to work - modify /boot/grub/grub.cfg to add --- persistent as follows:

menuentry "Try Ubuntu without installing" {
    set gfxpayload=keep
    linux   /casper/vmlinuz  file=/cdrom/preseed/ubuntu.seed boot=casper quiet splash --- persistent
    initrd  /casper/initrd
}

Boot in with the live USB

2- Create a luks encrypted volume group on an empty partition. Create / (root) and swap logical volumes on that encrypted partition.

Assume the unused partition to be encrypted is /dev/nvme0n1p4.

Optionally, if you have old data on the partition you want to hide before encryption and formatting, you might random wipe the partition. See discussion here.

dd if=/dev/urandom of=/dev/nvme0n1p4 bs=4096 status=progress

Set up the encryption.

cryptsetup -y -v luksFormat /dev/nvme0n1p4

You'll be asked to set a password.

cryptsetup luksOpen /dev/nvme0n1p4 crypt1

You'll be asked to enter the password. Note that crypt1 is an arbitrary user decided name. Now create the volumes and format.

pvcreate /dev/mapper/crypt1
vgcreate crypt1-vg /dev/mapper/crypt1

lvcreate -L 8G crypt1-vg -n swap
mkswap /dev/crypt1-vg/swap

lvcreate -l 100%FREE crypt1-vg -n root
mkfs.ext4 /dev/crypt1-vg/root

Use these utilities to view the volumes and understand the hierarchy.

pvscan
vgscan
lvscan
ls -l /dev/mapper
ls -l /dev/crypt1

3- Copy files from old root to new root

mkdir /tmp/old-root 
mount /dev/ubuntu-vg/root /tmp/old-root/
mkdir /tmp/new-root
mount /dev/crypt1-vg/root /tmp/new-root/
cp -a /tmp/old-root/. /tmp/new-root/

umount /tmp/old-root
umount /tmp/new-root

cp -a ... copies in archive mode, preserving all file modes and flags.

4- Set up and partition another USB to act as the removable boot disk.

I used gparted for this. Set up two partitions. The first partition is vfat, the second ext2. Each was 512 MB, you might get away with less. Assume device /dev/sdf.

# The first partition: (will be /dev/sdf1)
Free space preceding (leave default value)
New size 512 MiB
Free space following (leave default value)
Create as: Primary Partition
Partition Name: (leave)
File System: fat32
Label: (leave)

# The second partition: (will be /dev/sdf2)
Free space preceding (leave default value)
New size 512 MiB
Free space following (leave default value)
Create as: Primary Partition
Partition Name: (leave)
File System: ext4
Label: (leave) 

5- Set up some files in the new root, do some magic, and chroot into the new root and then install grub onto the boot disk from the chroot'd new root environment.

Find some UUIDs for later use. Note the outputs from the following commands:

blkid /dev/sdf1
blkid /dev/sdf2
blkid /dev/nvme0n1p4

Mount the root partition and boot partitions

sudo mount /dev/mapper/crypt1--vg-root /mnt
sudo mount /dev/sdf2 /mnt/boot
sudo mount /dev/sdf1 /mnt/boot/efi

Setup the file /mnt/etc/fstab

/dev/mapper/crypt1--vg-root /               ext4    errors=remount-ro 0       1
/dev/mapper/crypt1--vg-swap none    swap    sw              0       0
UUID=[uuid of /dev/sdf2] /boot           ext2    defaults        0       2
UUID=[uuid of /dev/sdf1]  /boot/efi       vfat    umask=0077      0       1

where "[uuid of ...]" is just a letter-number-hyphen combination.

Create the file /mnt/etc/cryptab

# <target name> <source device>     <key file>  <options>
crypt1 UUID=[uuid of /dev/nvme0n1p4] none luks,discard,lvm=crypt1--vg-root

Some magic required to enter the root directory environment:

sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
chroot /mnt

Now set up the boot USB disk with grub :

apt install --reinstall grub-efi-amd64
grub-install --efi-directory=/boot/efi --boot-directory=/boot --removable
update-initramfs -k all -c
update-grub

Now you should be able to reboot and bootup using the newly created USB boot disk.

Toubleshooting-

(a) The network must be connected for the apt install --reinstall grub-efi-amd64 command. If the network is connected but DNS is failing, try

echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf > /dev/null

(b) Before calling initramfs, the current vmlinuz... file used in the original linux must be present in the new root directory. If it isn't, find it and place it there.

(c) The grub-install command will by default search all other linux disks it can find even if they are not mounted, and put them in the boot menu on the new boot USB. Usually this is not desired, so it can be avoided by adding this line to /boot/default/grub.cfg :

GRUB_DISABLE_OS_PROBER=true

NOTE: A text file with the encryption key can be added to the removable boot USB.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.