84

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.

3
  • Full disc encryption or just your /home folder? – Joren Oct 27 '13 at 14:36
  • 1
    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
74
+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:

1
  • 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
29

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 encryption 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 behaviors (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 installation.

1
  • 1
    "The only information leak is ..." You missed off the big one: /tmp. Applications running as your user might put temporary files there (e.g. copies of your documents while you're editing them) that remain visible after you've logged out and turned the computer off. Another possible leak: I imagine your files could be accessible to a determined attacker if you hibernate the computer instead of shutting it down fully. – Arthur Tacca Aug 3 '20 at 8:15
9

As this is still the top result on google, I want to update it with some new information. As user Frederick Nord mentioned on: Is there a way to do full disk encryption after the install?

There is a tool called luksipc(Luks in place encryption) after further research I found the most recent documentation and a warning from the author of that tool:

luksipc was created before any alternative from dm-crypt/cryptsetup/LUKS side was available. This is not the case anymore. Therefore I recommend switching to cryptsetup-reencrypt, which is properly maintained and tested upstream even when the format of the LUKS header changes (to my knowledge, this has at least happened twice and can cause luksipc to catastrophically fail, i.e., destroy all your data in the worst case).

So cryptsetup-reencrypt seems to be the recommended way.

High Level Overview:

  1. The tool suggested can only work on partitions which aren't in use so use a live cd/usb
  2. Manipulate the partitions so there is enough space at the right location for the LUKS Headers
  3. Use cryptsetup-reencrypt to encrypt the partition
  4. Repeat for every partition (except for boot)

Short guide taken from Ubuntu Documentation :

   Add LUKS encryption to not yet encrypted device 

          First, be sure you have space added to disk.  Or alternatively shrink filesystem in
          advance.
          Here we need 4096 512-bytes sectors (enough for 2x128 bit key).
          fdisk -u /dev/sdb # move sdb1 partition end + 4096 sectors

          cryptsetup-reencrypt /dev/sdb1 --new --reduce-device-size 4096

Detailed guide taken from Arch Wiki - Encrypt an unencrypted filesystem :

umount /mnt # As mentioned this only works on partitions/devices which aren't mounted. You can skip this if you used a live cd and didn't mount this partition yet - but be sure to check
e2fsck -f /dev/sdaX # check that the file system is ok -f == force validation even if it looks ok
resize2fs -M /dev/sdaX # Shrink the filesystem to the minimum size.
cryptsetup-reencrypt /dev/sdaX --new  --reduce-device-size 16M # Encrypt the unencrypted partition
cryptsetup open /dev/sdaX recrypt # Open the encrypted partition so we can give it back the disk space we removed by using the -M option on resize2fs
resize2fs /dev/mapper/recrypt # enlarge partition again
mount /dev/mapper/recrypt /mnt # Mount if you want to access data

Question: Why shrink to Minimum Size ?

Answer: Assumption - this is done because the size of the LUKS header can change in the future so this steps are generic and won't get out of date. The Header Size changed from LUKSv1 = 2MB to Luksv2 = 16MB in the past

Troubleshooting Guide - /boot is encrypted and I can't boot

Update 12/2020

So for me it happened that I only had 1 partition which included /boot. Afterwards I couldn't boot into my system anymore. If you experience the same issues, this guide might help getting back a working system.

High Level Overview

  1. Make sure you have the necessary software for decryption in grub and in initramfs.
  2. Know how to boot

Grub

  1. Boot into a "live cd" ubuntu
  2. Decrypt the partition
  3. Chroot switch into the decrypted system (if you don't know how this might help: https://superuser.com/questions/111152/whats-the-proper-way-to-prepare-chroot-to-recover-a-broken-linux-installation)
  4. In the chroot environment
root@ubuntu:~# echo "GRUB_ENABLE_CRYPTODISK=y" >>/etc/default/grub
root@ubuntu:~# update-grub
root@ubuntu:~# grub-install /dev/sda???
  1. Stay in the chroot !

Initramfs

  1. Create a initramfs hoock script which copies cryptestup via copy-exec
  2. update-initramfs -u -k all

How to boot

  1. You get an empty grub menu hit "c" to get a command line.
  2. Execute the following:
insmod luks # load kernel module
cryptomount hd0,gpt6 # decrypt your encrypted partition
configfile (crypto0)/boot/grub/grub.cfg # tell grub the path to the now unecrypted config file
  1. Now you should get grub menu with the appropriate boot entries.
  2. After selecting "Ubuntu" you should get into initramfs.
  3. Now execute the following
cryptsetup luksOpen /dev/sda6 system
exit

Alternative

Maybe consider using this guide below instead . It seems to deal with the issues mentioned above. Though i haven't tried so I can't be sure it works. But might be worth looking into. https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

P.S The troubleshooting guide was written from memory, so there might be some missing pieces. But i wanted to write it anyways as it still might help some people. However if you find something which is missing/inaccurate please tell me in the comments so i can update the guide thx.

4

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).

3

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.

1
  • In section 5, I guess it should be /mnt/etc/crypttab (with double t). – rvf Apr 23 at 7:11
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?

6
  • "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

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.